What language should I look at to develop a 3D gaming engine ( probably a 2D engine first)? I was looking at Ray Tracing and Ray Casting demos. I'm just curious because eventually I want to move away from DM, which feels like training wheels largely because the grid for graphics is premade, and there is really only so much I can do with it. I love BYOND because it's simple and relativly easy to use and develop little 2D games and things, but to move into 3D or an engine strictly of my own design - I guess I have to learn to use a lower level programming language. I didn't really want to use C++...though I guess I could, but is there an easier programming language to play with?
Note: I'm a writer in college, not a programmer. My primary goal with coding is to have fun and make games.
ID:185843
 Oct 17 2005, 8:49 am
|
|
Oh, and if you want a suggestion for a language, look at python, D (digitalmars), or the old standby C.
| |
just to contradict the mis-information: BYOND is not limited to tile-based graphics anymore. there are several pixel-movement demos that allow you to break from 'the grid'. that coupled with a good iso-metric map can lead to several good game genres yet to be pursued.
otherwise, you can check out DarkBASIC, and Cube - the former a gaming language for 3D games, and the later a 3D engine for making games with. | |
I find that the only Pixel Moving Demo I found, when you made it to moving barely pixels at a time, there was much delay in movement. It would be great if you could be able to fix that.
| |
digitalmouse wrote:
just to contradict the mis-information: BYOND is not limited to tile-based graphics anymore. Realistically it is. 10FPS and a *queued movement system just doesn't cut it for any games that would need a pixel movement system. *I swear if anyone links that damn javascript KeyDown lib i'm going to shoot their frelling head off. | |
I've looked at DarkBasic, it's impressive from the demo I did. I couldn't do much with it though because I didn't feel like dishing out the 100 bucks for it (but, for a 3D gaming engine, this is cheap). I'll look at Cube, however.
| |
Actualy, I didn't like DarkBasic, seemed like a sorry excuse for a 3D engine. The demos for it where very low polys, ran slow, and where low resulution. All together, -5 out of 10. Never tried cube, could be interesting.
| |
What language should I look at to develop a 3D gaming engine ( probably a 2D engine first)? C/C++ I was looking at Ray Tracing and Ray Casting demos. I'm just curious because eventually I want to move away from DM, which feels like training wheels largely because the grid for graphics is premade, Just because it's easy to program a game doesn't mean it is easy to make a good one. BYOND is meant to provide a well setup framework so that it is design details you have to worry about not implementation details. Most games rarely build complete engines from group up anymore or don't if they are smart because the tricky stuff is in comming up with great game designs. and there is really only so much I can do with it. The NES had much much worse limitations yet produced a wide variety of original and impressive games. If you are feeling too limited it is most likely your own fault and not the language. I love BYOND because it's simple and relativly easy to use and develop little 2D games and things, but to move into 3D or an engine strictly of my own design This is poor mentaility which the industry has gotten into. If a game doesn't need to be 3D then it shouldn't be 3D. You shouldn't see building 3D games as moving on rather you should really consider why you need it to be 3D. There are many 3D games inwhich the 3D element only adds hassle to both the player and developer. - I guess I have to learn to use a lower level programming language. I didn't really want to use C++...though I guess I could, but is there an easier programming language to play with? Doesn't matter what language you're working in it won't be easy. If you even consider it to be possible you're still in the wrong mentality and have a whole lot to learn before even attempting it. Note: I'm a writer in college, not a programmer. My primary goal with coding is to have fun and make games. Then save yourself a lot of grief and don't even bother with trying to build a 3D engine. It requires much in the way of math and all sorts of fancy data structures and algorithms. You might(though I'm still thinking largly unlikely) be able to pull of rendering stuff however I don't think you'll get to the point of building anything that could support any non-trivial game. | |
Theodis wrote:
What language should I look at to develop a 3D gaming engine ( probably a 2D engine first)? Don't forget Python and Java, as well as C variants such as C# or D--C and C++ isn't always the best advice to give new programmers when they ask for a language to try! | |
Theodis wrote:
The NES had much much worse limitations yet produced a wide variety of original and impressive games. If you are feeling too limited it is most likely your own fault and not the language. Let's not forget that the NES programmers couldn't just move on to a better system because theirs was top of the line at that time. Byond is great but it really is limited. Yes you can do so much with it but let's face it for programmers it's just cracking the surface. Don't get me wrong though I love Byond. But still your dreams can't be recognized as realisticly with Byond as it can with other sytems. This is poor mentaility which the industry has gotten into. If a game doesn't need to be 3D then it shouldn't be 3D. You shouldn't see building 3D games as moving on rather you should really consider why you need it to be 3D. There are many 3D games inwhich the 3D element only adds hassle to both the player and developer. I agree with this but 3D does tend to bring out the true life in the environment. If he wants to learn how to do that let him. I plan to do it later on too as a professional though. | |
Don't forget Python and Java, as well as C variants such as C# or D--C and C++ isn't always the best advice to give new programmers when they ask for a language to try! He's asking to do a 3D engine though. Something you aren't going to be able to do realistically in those languages aside from possibly D but I haven't really looked into it. | |
Theodis wrote:
He's asking to do a 3D engine though. Something you aren't going to be able to do realistically in those languages aside from possibly D but I haven't really looked into it. I have played games with graphics done by Java or Python and they rendered fine. Why is C the only language that a 3d engine can be written in? | |
Why is C the only language that a 3d engine can be written in? If you want a decent 3D engine you're going to have to do it in C/C++. You could write a 3D engine in any language though in most you aren't going to be able to use it for anything non-trivial because it just won't be fast enough to handle large numbers of polygons. The stuff you write for hidden surface removal has to be very fast to decently handle realistic sized game worlds which just can't be sufficiently done with the overhead of most languages. C has no hidden overhead and it's mostly negligable in C++ which is why those languages work well. With garbage collectors and other hidden features lurking around you kill the effeciency you need. | |
Vector-based solutions sacrifice some amount of accuracy in favor of relatively excellent speed. Game designers who use a vector-based solution decide what is "good enough" for their game in terms of the "curviness" of curves (anywhere from 5000-sided polygons to triangles). The big advantage of vector graphics is speed. However, scale becomes an issue because the closer somebody gets to objects, the less real they look.
Of course, there are solutions the problems of each option. Raytracers that find the perfect balance between refresh rate, resolution, and detail (as well as taking shortcuts with far-off objects, scenery, etc) can be fast enough to make seamless movie graphics. Vector graphics that use advanced mapping, texturing, and dynamic object-reshaping techniques can preserve realism on a smaller scale while still running fast enough to keep a quick refresh rate going.
The important thing is to choose one, write/find software that implements it, and improve your techniques constantly to give the end-user the best experience possible.