When I started programming I quickly found out that for me the best way to learn is to see how other people did it(not copying, but understanding).

Messing around with open source stuff, trying to see how it works.Disable function if you don't understand it and see what have changed.Trying to break things and then fix them(look up the solutions to the problem in google, instead of restoring the old code).Add another step into the loop, make it for example rotate the object or rotate the camera around the object.Try to join 2 small opengl programs.

Regarding 2d and 3d, most people will say that you should start as simple as possible.But there are few thing you should consider when choosing between 2d and 3d:-Do you know enough maths to work with 3d? (or if you are good at maths you can pick it up quickly)-Do you find it easier to create a set of 2d graphics or 3d models and textures?

2d most likely will be easier, but if you have enough maths and prefer 3d models go with 3d.If you will start with 2d you will have better understanding of the maths behind collisions, rays and selecting, which is similar in 3d except for 1 extra dimension.

What type of game would you be aiming at?(I wanted to start off a MORPG, which obviously failed, I got stuck at inventory management, it was working but I couldn't concentrate on anything else as I though there was something missing in it and eventually I gave up. The first working one was a simple tower defense game in 2d, followed by improved and rewritten sequel, which still was really simple)

Tower defense game are really simple in 2d, a bit more complicated in 3d,making them really good starting point.If you are making tower defense game there is few things I can tell you.

It will be easiest to start with defined path instead of true path finding.Placing the towers in designated areas it much simple than checking for collision between towers.

Checking for distance between the tower and enemy can be CPU consuming.Easiest solution is to find first target within radius from a LinkedList.(As they will be ordered by insertion time it should be the closest to target as well, making the towers attack the best target, or else you will have enemies with different speeds, then you will need to implement another type of search)

Make sure you will remove the projectile when it hits enemy or leaves the map, so that there is no memory leak.Keep the collision checking to simple box or circle instead of per-pixel (consuming lots of CPU and harder to implement).

Good luck,And make sure to PM me when you will have a demo.(Also keeping backups of the source code is a great idea in case you will need to revert the code)

Do you want to get better at game programming? Understanding how to store maps, items, player saves; working with collision and basic physics; organizing multiple screens and game states; writing AI, pathfinding, and so forth; creating a fun user-computer interaction; using easing and other math concepts to create smoother and more polished gameplay/UIs; etc.

Or do you want to get better at graphics programming? Understanding how the graphics pipeline works under the hood; understanding how to render millions of particles even if you'll never design such a complex game; understanding how to program shaders to create impressive optimizations and visual effects; creating your own "rendering engine" per se, rather than a game engine; etc.

If the latter, you should continue with LWJGL, OpenGL and GLSL -- see here. Another great series here. LibGDX or lwjgl-basics will be useful to get you started, and once you are more comfortable with basic OpenGL/GLSL concepts, you can try writing your own 2D shader-based sprite batcher.

If you aren't concerned so much with "under the hood" graphics programming, I'd suggest LibGDX or something even higher level, like Unity3D.

Either way, write simple games and demos before you try anything complex. e.g. Take Pong or Snake and change it to make it more challenging -- see what kind of advanced game and/or graphics programming concepts you can introduce into such a simple game.

The best thing to do is to just make sure you actually just do something. If you sit around watching tutorials and not understanding, or thinking up games in your head you get nowhere. I found that if you just go out and do something, even if your not certain of how you'll do certain things, give it a go and eventually you'll build up your knowledge base and you'll learn about your own style of coding.

Just glBegin();!... Mind that every glBegin() has an glEnd() too... or at least is should have...

+1, forgetting glEnd may or may not cause graphics driver crashes.

Am I correct if I assume that you wrote this to mean that if you don't put a glEnd() somewhere after a glBegin(...), you will experience crashes? At first I thought you meant that you liked the answer despite the fact that glEnd() usage might cause graphics driver crashes, but that doesn't feel quite right.

Ah, sorry for confusing you. Depending on the driver, you'll get one of many different behaviors if you forget to close a glBegin() with glEnd(). So far I've experienced complete graphics driver crashes (Windows 7 just reboots the driver though), black screens and nothing breaking but extremely bad performance on different hardware.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org