Printable View
I have been programming games for almost 3 years in C#, C++ and in Java. I created many games using SDL, Allegro, and OpenGL but only in 2D. I'm not really great in math, is that a big problem for me? The latest math that I know is Calculus 1.
So, when should I know that I'm really ready in 3D game programming.
IMO, the biggest problem you'll have is with design (ie design of the game, engine etc).
Sure you'll need maths, but you'll need to understand the principals more than anything. Also 3D culling is a little different, more maths there :).
I think even a novice programmer can start coding 3D games. However, start of with extremely simple games. Look through nehe's tutorials (I really dislike them, but there aren't many good ones as far as I know).
Just start off rendering some simple triangle.
A possible first game would be a 3D maze game where you have to find the exit. That's extremely easy to code, but quite fun as well.
Don't start off with an engine, though. Just code the game.
But as long as you're not *really* good at your programming language, don't expect to code top-notch games. But learning OpenGL simultaneous to the programming language is easy enough.
WRONG!
Dont learn a 3D api alongside a language. You will need a good understanding of the programming language and you will have to be a good problem-solver before starting 3D games.
Design is the main strugglepoint that I have. To actually render something isnt that hard, its when you have to interact with the user in different ways that things gets complicated. And yes, 3D games programming is among the harder things you can do programming-wise, so to say its easy is dead wrong!
Well, maybe not easy, but not difficult either. Yes, you need to be a good problem solver before starting writing good 3D games. However, like I said, the maze game barely needed any problem solving. And once you've written a game, you feel fairly satisfied, so this may be a very good motivation to learn the programming language better.Quote:
Originally Posted by Shakti
Yes, you need to solve some basic problems even for the simple maze game. You'll need to understand the logic beyond coding. You need to know the basic syntax and keywords and functions and objects the language provides you. You must understand functions. But for instance, you don't even need to know std::vector exists for starting writing simple games. You need not know call-by-reference. Sure, you will definitely need it for good games, but you can write simple games without it. And you can learn those things when working on games.
3D coding hard? Well, using OpenGL, not really, in my opinion. Not the basics at least; simple rendering, texturing, simple lighting are really simple. Sure, it won't make a perfect game, but you can do some simple games.
Finally, this person seems to have experience with several languages for several years. He'll understand the concepts of programming. And even though you may not know C++ on more than a novice level (I don't know), he should have enough skill to write simple games.
You know the first time I touched C++ was in a DirectX book. I fully understood it without problems. After reading the book, my C++ skills weren't perfect, but they weren't dreadful either. And no, the book didn't explain the language itself, it only explained DirectX. I don't recommend this approach, though.
I didnt comment on him not knowing enough. I commented on your comments about 3D game programming being easy, its not.
And in my opinion its better to learn the language, learn the pitfalls and learn what works and doesnt work when it comes down to the design of the actual game. You might be able to write a maze game or a pong game or something like that but if you just hack it together without thinking things through you will end up having to face those problems when you write more complicated stuff, so why not get it right from the start, or at least consider it from the start?
Your approach works for the simplest games but once it gets complicated (and it gets complicated fast) you may very well end up ditching a project because of a decision you made in the beginning, went with it but it ended up limiting you to such a degree it would be easier to just rewrite it all (trust me, I know what bad design can do to a project).
Now to the OP: It sounds like you have enough experience to try on the 3D part. Really the graphics is very very little when you piece it all together. Its the resource handling, event handlers and all other behind the scene stuff you need to code that poses the real challenge. To get something to show up in a 3D environment is the easy part. But it sounds like you have done some 2D programming so why not give 3D a shot?
I don't know if I still lack programming skills but I do know how to use some advance concept like inheritance, polymorphism, templates, exceptions, typecasting, and etc.
Yeah I coded many 2D games and experience a lot of trigonometry that deals most in angles. And also I know some basic OpenGL like creating 2D shapes, rotating, scaling, translating.
I tried using an Ogre3D rendering engine but it really eats me because I don't understand why do I need to do this and that. I also tried the Irrlicht which is easier than ogre3d but I gave up already because I don't understand most of them. I told to myself that I think I should not hurry myself in using some existing 3D engine.
So, I think I'll use OpenGL which is a cross platform 3D API so most of the people can play my games not only in one specific OS.
Thank you for the replies guys
I just say dive in.
I would say dive in except I would temper it with a 'learn fundamental C++ first'. Once you learn or are exposed to C++ concepts then dive right in. You can learn the concepts from the graphics but it will take longer than just learning the concepts first and then the graphics.
Ok thank you very much for the reply.
Any suggestion what game should I make in 3D for a beginner like me in 3D spaces? Does creating a 3D maze as mentioned above would be easy for a beginner?
The most advanced math you will need in 3d programmign is advanced algebra. Specifically matrix math.Quote:
Originally Posted by m3rk
A maze would be a good start. Walking around a heightmapped terrain is pretty easy as well.Quote:
Originally Posted by m3rk
Agreed.Quote:
Specifically matrix math.
I tried to learn it last summer with just some knowledge in single variable calculus. I had to give up because of the linear algebra stuff. All of the few tutorials I tried to follow assumed knowledge of linear algebra (vectors, dot products, cross products, transformation matrices, projections, etc) and I couldn't keep up.
Going to try again this summer, after taking a term of linear algebra :).
Ok I'll start creating 3D maze this weekend.
By the way, my university doesn't have any linear algebra course for computer science. What should I do? I'm 18 years old and I think I am left behind.
@Elysia
What do you mean it is a serious problem? I know how to use those things because of my object oriented programming class. I know also how to use templates in C++ but only the basics. Do I need to master those things before going to 3D?
Ah, nothing. All seems in order ^_^
Good luck.
(I misread the original post. Hehehe. Oops.)
Ok. Thanks Elysia! I hope I can reach my dreams. lol
EDIT: By the way, why do people in gamedev.net told me that I should use an existing 3D engine in creating games? I don't get it.
Are you serious? Maybe it's offered by the math department? Definitely take a linear algebra course if you can. I'm surprised its not required for your degree.Quote:
Originally Posted by m3rk
Yes it is offered by the math department but my degree doesn't require to have it. The last math that is required for my degree is Calculus 2 which is I think all about Integrals.
Hmm at my university it's a required second year course for all science degrees (including computer science), and a first year course for engineering.
That explained everything about my university's standard. :(
Don't you get electives?
I know of a few universities that don't do maths until very late in the degree. Which is odd, get it down pat in first year and then build on it IMO.
I don't know if there are electives for linear algebra but I hope there's one. I'll try to ask the university if they're offering one.
By the way, anyone here knows can I recommend a good 3D math book that is focuses in 3D graphics programming? I heard that 3D Math Primer for graphics and game development is quite good for a beginner in 3D math.
No. You can write OpenGL programs using plain old C, Java, Python, Ruby, etc. Knowing templates is not a prerequisite.Quote:
Originally Posted by m3rk
That's what I would suggest as well. Why roll your own, especially as a beginner? I'd give Irrlicht another try. OpenGL will help you texture, light, and transform polygons, but there's a lot more to 3D graphics and games than that. Irrlicht gives you data loaders and animated cameras and particle systems and many other things for free.Quote:
Originally Posted by m3rk
Fortunately, I know how to use simple templates. ;)Quote:
Originally Posted by medievalelks
Yeah you're right. It takes so much time creating engine. I want to become a graphics(or physics) programmer so I think I'll just focus first in graphics. I want to learn how 3D graphics where done and also want to know how to use shaders which I'm really interested. Maybe few years from now, I'll just convert my 2D games in 3D. By the way, do I need to become a good artist to become a good graphics programmer? I really suck in art (ie. drawing, web designing) so bad. :(Quote:
Originally Posted by medievalelks
About Linear Algebra:
I'm starting to love this math! I've read about vectors and scalars lately. It's like an array and the basic is so easy. I've also read how to get the magnitude, how to normalize, how to add, subtract, and multiply. While scanning the book somewhere(lol), I found this dot and cross product which I heard that is related in 3D graphics. So I think I'm on the right track.
Re: learning graphics, if that's what you want to do, go for it! I thought from the Subject line that the primary goal was games. Nothing wrong with learning the nuts and bolts.
Re: being a good artist, heck no! In fact, lots of amateur games are "ruined" by programmer art :-)
Oh, and if you're sticking with OpenGL, check out NeHe's tutorials and google for "Steve Baker OpenGL". He's written some good articles over the years. There are also forums at opengl.org.
Have fun.
Yeah vectors are essentially arrays. And matrices are essentially 2D arrays. It gets a bit mind-twisting at first, but the bits and pieces aren't really too bad.Quote:
I'm starting to love this math! I've read about vectors and scalars lately. It's like an array and the basic is so easy. I've also read how to get the magnitude, how to normalize, how to add, subtract, and multiply. While scanning the book somewhere(lol), I found this dot and cross product which I heard that is related in 3D graphics. So I think I'm on the right track.
dot products allow you to determine if 2 vectors are perpendicular, which, among other things, allow you to define planes in 3D as all vectors orthogonal to a vector. (ax+by+cz = 0, or dot([a b c], [x, y, z]) = 0)
cross products allow you to find a vector perpendicular to 2 vectors, with a magnitude of sin(theta)*|A|*|B| so you can find, for example, the torque (moment) vector easily from arbitrary force and displacement vectors in 3D (t = cross(F, d)). This can also be done using high school physics (finding components, etc), but linear algebra makes it very easy, especially when you are trying to program a computer to do it.
Because they are a bunch of retarded trolls. No, retarded trolls aren't that bad. They are like the toe jam that a retarded troll wiped on its bed post last week. I dropped in there awhile back and as soon as I started suggesting thing's that werent 'The One and Only Truth', I was banned in short order.Quote:
Originally Posted by m3rk
I think Ill have to dig up the specific post that got me banned, but IIRC it involved me suggesting a non-standard solution to a problem when the OP of the thread had specifically stated that 'The One and Only Truth' had already failed, then some 'Ye Olde Pharte' ..........ing that my non-standard solution was non-standard and that the OP should use 'The One and Only Truth' instead. At which point I told 'Ye Olde Pharte' he needed to actually read the OP. It then devolved into him screaming (all caps) that I was just some noob etc etc blah blah and ended with me calling him "a retarded wishnick wannabe that needed to get back under his bridge and let people who wanted to actually help people do all the posting".
For giving sound advice?Quote:
Originally Posted by abachler
Here's a screenshot of my 3D maze so far.
http://img4.imageshack.us/img4/2417/crazykzd.jpg
I get confused sometimes creating the wall in 3D. Do I need to draw the 3D first in a graph paper? Do graphics programmer do that?
By the way, I didn't apply any linear algebra here. I don't know how to apply it here in opengl. I hope someone will teach where to use it.
I believe it is always good to try to visualize something on paper or such if you can't do it in your head.
I can visualize everything if it's only x and y axis but when the z axis is included, it really burns my brain. rofl. I'll try to draw it on a piece of paper for now. Maybe I'll get used to this someday, I hope.
Imagine viewing the maze from the top. Then it's quite easy. There is a third axis, being Y, but it's always a wall of the same height.
But you're coming along well. I'd say, when you're able to render the walls, do this:
- Collision detection. Not an advanced algorithm, just easily checking whether a move would cross a wall or comet too close to a wall.
- Lighting. Not even required for this game, but it will teach you a lot when you find out how it works.
It comes down to the age old dilemma of a debate becoming a personal attack. Regardless of our horribly poor examples in society around the world where opposing opinions tend to be squashed, ridiculed, or ignored there is actually a proven sound way to debate an issue and/or give advice without becoming personal.Quote:
For giving sound advice?
If you were wanting to create your own retail game as in the context of an upstart company then you would definitely want to get a license for an existing engine. You would do this so you could get the product done and out the door and start making money on it. However I would imagine that every employee or at least every employee on the core game dev team would understand how to go about creating their own engine. It really would come down to the cost of the engine vs the cost of the development of an internally developed game engine.
Now if you are a hobbyist programmer and do not ever intend or think it possible to release your game and are only trying to learn then I say roll your own. It is highly probable that those who come here and ask questions about game dev either do not know enough to create the game and/or do not truly understand the concepts behind the graphics engines. Therefore recommending an existing engine to them would only serve to confuse and confound and thus discourage their attempts.
So in short:
Hobby and want to learn more: Roll your own.
Hobby and understand most of the fundamentals: Use an existing engine
Professional: Based on cost you can either choose to develop an in-house solution or you can use an existing third party solution.
Hello gurus,
Here's the 3D maze screenshot so far.
Nothing special
http://img9.imageshack.us/img9/3136/boredjbp.jpg
I somehow improve visualizing shapes in 3D now.
-x = left
+x = right
-y = down
+y = up
-z = back
+z = forward
Cool. I can now create simple shapes. How about a teapot? lol
Weird Lighting
http://img6.imageshack.us/img6/6625/lightingh.jpg
I'm playing around with the glNormal3f for lighting though. I still can't get it work correctly with multiple triangles. I think I did something wrong.
Blending
http://img9.imageshack.us/img9/3227/blendk.jpg
I tried playing around with the glColor4f(); and glBlendFunc(); but still don't get why the ceiling and the floor is not affected. Did I do something wrong?
For the Collision detection: It just check if the camera is too close the wall. So I somehow make it work on the borders by using few if and else but still can't get it work with multiple maze. But I'm trying... really. lol
Hey m3rk:
In an earlier post in this thread you asked if programmers put graphics designs on paper.
No, not in many, many years. We will usually work with art departments.
However, in the earlier days, even then, one of the first common themes was to use the basic game engine to create simple modeling tools. That way you can place walls, doors and other objects in the scene with much less effort.
These days, though, I usually use 3DS Studio Max or Blender (the latter can be downloaded while the former is expensive), and Blender is quite good.
You also said:
"But I'm trying... really. lol"
Ok, then you should do yourself a favor and pick up a good text on the subject.
Frankly, I found that a book published by Morgan Kaufmann called "Mobile 3D Graphics", which is primarily aimed at OpenGL ES, was an excellent ground up discussion of nearly everything important. I think 95% or more of the code examples work in OpenGL 1.5.
Other books in the Morgan Kaufmann series are good, and many are quite in depth.
I think you deserve to have the benefit of a well guided path through the study. It will be much smoother, and faster, with better foundations of how things really should be done.
Even if you're just browsing the subject, instead of serious study, it all makes much more sense from a really good book on the subject, and not an old one, because OpenGL has been through several versions, and there are more than one way to accomplish the same thing, many of which are now no longer used because significantly better methods have been implemented in OpenGL.
Especially due to the mobile use of OpenGL ES, and it's basis on pre-2.0 versions of OpenGL, it is still worth studying a bit of the old and then the new versions of OpenGL, if your targets may need to be compatible with modest hardware.
@JVene
I though graphics programmer are like engineers/architect, lol.
Yeah, I'm creating a md2 loader for my program right now and I don't know what data structure to use. See this link (http://cboard.cprogramming.com/cplus...tml#post856878)
I didn't finish all the collision for all the maze but it works on the end of the map.
I dumped the immediate mode(ie glBegin, glEnd and etc) and studying the advance like using buffers to squeeze more frame rate. I think I'll just focus first in advanced 3D concept and later the collision.
BTW, I bought the book beginning opengl game programming and it's quite good. But I need a more advance book because most of the concept there are immediate mode.
I'd say you should start 3D programming the 32/13/1337 ... Not funny xP
Anyways, try using some 3D engine and see how stuff is done there? I mean a completed game engine, like the Source engine or Unreal Engine (Ain't sure if Unreal Engine starts as a finished product tho...)
Maybe it could be applied to the program flow, ie. how the game operates, since that actually has nothing to do with GL.Quote:
Originally Posted by m3rk
IMO, w/r/t rendering & such, trying to apply your knowledge of formal math may not be necessary or even helpful. I think this is because the conceptual reality of a 3D engine is different than that of a math lab (not to "denigrate" either one).
Here's a story to illustrate my point: I'm a total novice with openGL. The other day I was writing a function to create a non-curved cylindrical object with any number of sides (eg, something that might look like a symmetrical skyscraper with 6 or 7 sides). I was using quads to do this and couldn't get the length of a side (pictured orthographically from the top, such a cylinder would be a "regular polygon") to work out, so basically the sides were two long ("length" in relation to the orthographic top view, not the tower height, so in sense the "width" of a side). I was using the diameter of the cylinder as a function parameter, and I figured there must be a formula to determine how long a side should be in relation to the diameter of a regular polygon*. I learned there are actually (at least) several such formulas, only one of which is a straight-forward enough equation to be implemented in one line in a C program. When I did it, however, the sides were still a little bit too long. Finally I gave up on algebra and just figured I should divide 360 by the number of sides, rotate, translate the length of the side (so I changed the function parameter to that, instead of the diameter), and draw the side, which works. You (or at least I) might think after reviewing the algebra of regular polygons that somehow 180*(sides/2) is involved, but even that is not. This is what I mean by the different conceptual setting.
It could be that using an equation may be more optimized which is super important with 3D games, but since the GL functions should already be optimized, it is not necessarily so. For example, trigonometry is elegant, but I see no reason to believe that a couple of sinf/cosf calls are less expensive than a single glRotate. The only problem is you cannot call glRotate between glEnd and glBegin, whereas you can use math lib functions as much as you want.
RE: Surface Normals What do you think is weird about the lighting in your "weird lighting"? It looks like the roof maybe "unlit". How are you determining the normals? If you are using a function like this one:
which I think is kind of a standard thing that accepts three points on the surface, I've noticed that the order of those three points can reverse the normal, making a supposedly lit surface unlit except for ambiance. ("Normal" in this is just a global variable used with calls to glNormal3fv(), since there is no need to keep more than one at a time anyway).Code:void setnormal (vect P1, vect P2, vect P3) { /* from openGL wiki pseudo-code */
vect U,V;
vectminus(P2,P1,U);
vectminus(P3,P1,V);
Normal[0]=(U[1]*V[2])-(U[2]*V[1]);
Normal[1]=(U[2]*V[0])-(U[0]*V[2]);
Normal[2]=(U[0]*V[1])-(U[1]*V[0]);
}
*Of course, there are TWO obvious ways to measure the diameter, corner to corner or side to side. That may be where I went wrong....
Careful mk27 :)
Please don't take my reply to your points negatively, I hope to advance the discussion from the viewpoint of experience in the field.
I agree with part of the general thrust of you point, and I would put it this way; as programmers, we're consumers of math, not mathematicians.
However, the more one understands linear algebra, or the calculus (when it comes to a physics engine), the better of we are at choosing a method.
Let me take the point about glRotate as an example. A call to glRotate is a simple means of applying a rotation to the current transformation matrix. It is usually implemented in the client, meaning that the math is executed in the CPU, though in theory an implementation could choose to accelerate that in the GPU, I'm not aware of many implementations that do.
The call is performed by creating a matrix representing the rotation you're performing, the multiplying that matrix by the current matrix (one could think of that as applying that rotation to the matrix).
The usual implication is that a typical 4x4 matrix by matrix multiplication is performed. However, if you understand that the rotation matrix is 3x3 (upper left portion of the 4x4), and if you know that your rotation is the first one, you can simply drop the appropriate values into the correct positions as part of filling out an identity matrix, making a considerable performance optimization, if this is something performed in a critical interior loop. Whereas a typical OpenGL sequence might be to call glLoadIdentity, then call glRotate, and then likely a glTranslate - implying two 4x4 matrix multiplications - setting up a matrix according to knowledge of linear algebra (that is, knowing how the matrix is layed out) means you can avoid any matrix multiplication of a simple series like this, greatly improving performance.
I'm not sure what you mean by this, so I'm setting it aside and describing what is typically done with normals, just in case this ends up misleading the OP, or you.Quote:
("Normal" in this is just a global variable used with calls to glNormal3fv(), since there is no need to keep more than one at a time anyway).
Generally, at least in modern OpenGL, normals are supplied in interleaved buffers, and there's one per vertex. It is a good choice to prefer this to calling glNormal3fv because the data is sent to the graphics RAM much faster.
Models usually have a normal per vertex, which is why I'm not sure what you mean by a global variable for use with calls to glNormal3fv.
Creating a cylinder is not rocket science so I'm not sure how all of that applies to the discussion.
A cylinder is just two connected approximations of a circle. So if you approximate the caps and then connect the edges of the caps then you have the cylinder.
It's not a bad thing to understand the math underneath the hood even if most of it is done for you. The optimized approach however can only be found when one understand the mathematical concepts. There are moments in 3D where what is done for you is just not enough or doesn't quite take you far enough. From then on you must synthesize a solution based on what you know and what your research yields. No engine is game maker 101 and people who believe this will find themselves sorely wanting if they try to use an engine without understanding at least the basic math that is involved. As well an engine a game does not make. The engine is the tool that renders and updates all the objects. The game is much more than all that.
Hey, I have no doubt about that, and would never have implied otherwise. Your example and opinion about performance seems sound (thanks). Witness, though, that what you are saying does not mean actually implementing any algebra in code: what it really means is doing some algebra and applying the results. I was just trying to warn the OP against a pitfall: while s/he is there at school learning programming and math, I imagine there's a no end of opportunities to solve the problems of the one with the other. And that's great; but I don't think anyone should de facto assume that to be the best or most optimal solution -- even if it usually is.Quote:
Originally Posted by JVene
I really really am not interested in being the "anti-math" guy, so I will just leave it at that. I seem to recall from school that these arguments about the "theoretical" vs. the "applied" quickly become tedious if not ridiculous.