The aim of the game is to rescue people littered around some off world cavern. You control the lander by applying thrust (space bar) and rotating left and right (arrow keys), gravity does the rest. Try to land upright, don't crash and keep an eye on your fuel!

It's almost complete, however I'm not quite sure how much further I want to take it. To go much further will probably require a move away from plain old Java2D as the performance is just barely passable. I can run it on a Core2Duo Macbook Pro, but anything older might struggle to get the rendering done within the fixed frame intervals. You can press the shift key during the game (not the intro screen) and some debugging info will appear on the top left. As long as the "last tick time" is below 16ms then it should run smoothly. If anybody is getting values higher than this, I would appreciate it if you could let me know your hardware and JRE. I've tested it on earlier Java 6 releases with some poor results. Newer versions on my hardware tends to hover around 5 - 10 ms.

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.

Timing

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.

Graphics

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.

Sound

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.

Editor

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.

At the moment, tallying up the remaining fuel is a bit flawed so it needs something else. The original Lunar Lander game rewarded the player for choosing to land on more difficult landing pads. I could do something like that, but have a few other ideas in mind. There may be a way to determine if a landing is particularly spectacular or dangerous and provide extra points for that. Or giving a bonus if the lander is kept upright (within a few degrees) at all times that a rescuee is on board. I like the idea of rewards for extreme behaviour - providing a safe journey for your passengers or scaring the hell out of them.

Fuel Cannisters

Place cannisters around the level which replenish a small amount of fuel. This will alow for much more complex and demanding levels, and and element of risk/reward when deciding to go for more fuel. I was thinking of implementing them as their own landing pad, but just having little icons floating around that need to be flown through will be help to keep the game flowing.

Multiple Passengers

Allow picking up more than one rescuee at a time, but have their weight slow the lander down. Given the same amount of thrust, the added mass will result in lower acceleration which in the long run will require more fuel to get around. This will also come into play when trying to navigate moving obstacles where speed and timing is critical.

Moving Obstacles

Allow creation of polygons separate from the boundary. These can be made to rotate around a point or oscillate between two points, and will create interesting obstacles that require timing to navigate. Even a static obstacle can be used to create more than one pathway to an objective, each with their challenge.

Large Levels

Levels will be larger than the screen size, requiring the screen to scroll when approaching the edge. I'll have to put in some arrows giving a hint as to where the rescuees are when offscreen, although the best path might not necessarily be the most direct one. This will require fuel cannisters as mentioned above, in order to allow for some exploration.

Filling Levels

Some levels can appear to fill with water/lava, which will consume rescuees. This will only really work if we make it optional to rescue everyone. A finish pad at the end will be the target. Once a rescuee is consumed by the rising liquid, they can no longer be rescued. Falling into lava will also prove fatal for the lander, but perhaps water will just slow it down considerably.

Additional Forces

Gravity and its own thrust are the only two forces acting upon the lander. It would be feasible to add some new forces, such as wind operating through certain areas of the map or a gravity well. There will need to be some form of visual cue to indicate their presence and the sort of effect they will have on the lander.

Defensive Structures

One design decision I made and will probably stick to in quite a few games is to avoid portraying acts of violence. As much as I love shooting the place up, I do like the idea of creating something for kids. Having said that, there may be scope for some sort of gun emplacement that fires very slow moving projectiles in the direction of the player. There will be no ability to fire back, but they should be easily avoided.

Bonus Round

Regularly spaced levels which have a different, but perhaps slightly more hectic game mechanic. They become a top-down scroller with no gravity, where the objective is to pick up randomly located rescuees floating in space. The lander always moves forward, and can shift left and right but not rotate. Various bonuses can also be picked up. We might have obstacles, such as asteroids that move down the screen.

Persistent User Accounts

The user is assigned a unique key from the site the first time they play. This is then used when uploading their scores, custom levels (see next item) and registering achievements (also below). I don't think we can do this effectively in an Applet without either using the Persistence API (requiring the applet be signed), or somehow using cookies from the browser. I really want to avoind the user having to trust an applet - personally I'm extremely hesitant when doing this.

In Game Editor and Level Sharer

Rather than just save level files and open them in the editor, allow the user to upload them to the site and browse levels uploaded by others. Perhaps even have the actual game levels loaded dynamically from the site, with the ability to rate a level.

Achievements

Once we have a persistent account mechanism, implement achievements to make replaying the game enticing. These can be shared and compared with other players. Things like completing certain levels without loss of life, registering best times for each level etc.

That was fun, I love those type of games man.I'll keep checking in on the progress ^_^

Thanks for the feedback!

I've implemented an idea that I initially had but never made it into the game - levels that only have a single target landing pad (called a "Finish Pad" in the game) where you need to land to complete the level. Rescuing people will be optional. In fact, this sort of thing will be needed on levels where the people could potentially die, eg. rising water levels or being crushed by falling ceilings.

A new version has been uploaded with a different Level 1. This just has a target you need to reach and nobody to rescue, which I thinks serves as a better starting level. The idea is to very gradually ramp up the difficulty. Now I just need to come up with some really hard levels to finish it off.

I don't see this as being something easily fixable without resorting to some third party sound libraries which I'm keen to avoid for the sake of simplicity on this project. What I have done in the meantime is uploaded a version that will display a message to indicate that sound is unavailable but will still allow the game to be played.

A new level has been added to demonstrate obstacles. These are currently static but the next step will be to allow them to rotate and move around. This could create some challenging portals to require navigation through.

As mentioned before, there is an editor for creating levels but it's a little rough around the edges at the moment. I'll try to tidy it up a bit in the next update.

The page has some instructions on how to use it, plus a link to launch the web start app. The screenshot below gives you a basic idea of what you can do:

Note that although you can't load levels into the game itself, you can use the editor to play individual levels that you've created.

It's a little buggy, but I've tested it under Windows 7 (JDK 1.6 and 1.7) and OSX 10.6.8 (JDK 1.6) and most of the functionality does what is expected. Some things to look out for:

The editor/preview panels are displayed using a CardLayout but they don't get refreshed until you move the mouse over them. This has me stumped but I'll figure it out.

You can drag to select multiple items, but only from left to right. It's more of an omission that I haven't had a chance to look into.

Sometimes when multi-selecting a bunch of points close together, it gets the point order confused and draws the green highlight line between the wrong points.

I've had instances where the FileOpenService dialog pops up but is completely blank. The cursor becomes unresponsive even though nothing seems to be using CPU.

The process of creating the editor seems to have been just as involved as making the game itself. I had a rough idea of how to go about creating a user interface for editing points and lines but there was much more too it. Let's just say my knowledge of geometry was left wanting a couple of times. It certainly has been a rewarding experience.

My initial goal for this game was to have 10 levels, and as of tonight this is now done! I won't post any screen shots, but I will say that the last one is a bit of a challenge to complete. You should be able to scrape through with just barely enough fuel.

Also, some bugs in the editor have been fixed. You can drag to the left and up to select multiple items. Another one found and squashed was dragging with the right mouse button.

I reckon the only thing I'll add to the game for now is a high score table. I've already implemented this for a previous game a few years back, it's just a matter of figuring out the nicest way to incorporate it into the existing screens.

Some changes have been made to the screens to hopefully improve the flow a bit better and allow for some additional things. For example, displaying the high score table somewhere around the credits, which now appear at the beginning. I'm still trying a few things but they all seem to have problems visually. It's a matter of trying to cram everything in and make it flow nicely from one screen to the next. I can code it, but I'm hopeless at designing how the screens should look.

Another thing I still want to work on is the lives and fuel graphics. They don't really fit with the pixelly look of the score font. I'll still keep with the line drawing style of the cavern and lander, but the info at the bottom needs a more consistent look.

What really f**ks the game is text that never stops appearing on screen. You should make a disable option for it. Also make it so that you don't have to load game from level 1 once you die. Or at least not from tutorial.

Thanks for the feedback - that's actually the sort of input I'm after.

To alleviate some of the pain I've made it so the text within the levels explodes as soon as you hit space. This way it doesn't linger around and explode when you're in mid-flight. It's still not perfect, but a better compromise. Also the tutorial stage is skipped after your first game.

I've fixed a couple of bugs with the high score table, and made the lives/fuel images fit better visually with the score.

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