Lunar Rescue :: Boring Technical Details
Now that it is complete, I'd like to share some of the technical aspects of the game. Solving a lot of the problems detailed here was a heck of a lot of fun even if they were a little frustrating at times. One thing I have tried to avoid doing is relying on a lot of third party tools - they can do a lot of the dirty work for you but it's more rewarding to get right down to the nuts and bolts. My next effort will be using OpenGL via JOGL, LWGJL or libGDX but this one is just raw Java.
Input & Movement
This was one of, if not the most critical element of the game. In my opinion you can be a little sloppy in all other aspects but if your in game character (or the world) doesn't move in a satisfying way then you turn people off. Movement has to be responsive and predictable, even if not 100% realistic according to the laws of physics.
Rather than responding to key events appearing in the keyboard buffer, I've used a fairly simple keyboard handler that listens for key up/down messages and records their states in an array. This information is available when processing is performed for each frame. The lander is then moved according to some basic velocity and acceleration calculations. The result is that movement occurs consistently from one frame to the next, regardless of how many keys are held down and when they are released.
I've gone for a fixed frame timer, which essentially means that I try to process frames at fixed intervals. This makes the various movement calculations a lot easier, but of course requires that everything is wrapped up before the next frame is due and and the correct delay put in place. I understand this is a little problematic under Windows, with its fairly low resolution timer but in practice I've found that it works well enough. Everything seems pretty smooth and the job gets done quickly enough to easily fit into a 1/60th second frame. That is, as long as you have a fast enough PC. Initially my Core2Duo MacBook Pro was unable to get everything done quickly enough, but after a few performance tweaks it now runs just fine.
This started out as simple line drawings, and for the most part has remained that way. I've gone for some sprites for the rescuees as it's easier to get images to represent something very small. There are lots of instances of particle physics being used as well. This was surprisingly easy to get working, so I've used it for the lander exhaust, explosions and even message text. In fact with the exception of the score, all of the text is rendered using particles. These are assembled using pre-calculated vector fonts which are just a collection of dots per character. I've referred to them as vectors as each one has its own position in space and can be animated independently.
I've relied on the standard Java Sound libraries for music and effects. Apparently this is a bit rubbish in Java but I'm not really doing anything to push it's limits right now. The sounds are all samples found free on the web, and the music is by my girlfriend Sara. There is no way I would be able to compose anything myself and I'm too lazy to try capturing my own sound samples.
There is an editor for the levels. That was actually a whole separate project in itself, and required a bit of effort to get something that allowed me to create, drag and delete points in a usable way. I must admit to having to look up some of the mathematics on the web to get the line-point proximity calculations correct but in the end it was quite a rewarding exercise in itself.
At the moment it is launched separately to the game but has a "preview" mode which actually plays the level in its current state. You can load and save levels which is enough to show them off to others, although at this stage there isn't a way to load custom levels into the game with some JAR hacking.