After looking at the other entries this year (and many from previous years), I'm not happy that mine is up to the same standard. Obviously it lacks a lot in the visual department, but what I'm really concerned about is the actual gameplay and controls. So, what i'm interested in getting some feedback on is:

Does it make sense what the player is supposed to do?

Is it challenging enough?

Is it even remotely fun?

I plan on making some changes to the gameplay and visuals which will involve:

random obstacles to lay tracks around

replace bitmap images with procedural graphics

increase the tile size

bigger play area (perhaps an 8x8 grid or even larger)

smoother train movement to give a better idea of how far away it is

I'm still completely lost as to how to effectively incorporate sounds into this thing. I've written applets before that have sound effects and music (http://www.stimware.com/projects/pacman), but not sure if it is even worth attempting given the space constraints.

It's looking good, particularly for your first 4k game. Graphics are always a compromise, particularly if you really need bitmaps, as there just isn't space for decent sized sprite bitmaps. Scaling up and antialiasing might work for a soft focus look, but generally procedural graphics is a better bet.

The best gameplay strategy I found was to keep selecting and dumping sections at the edge, until I got a horizontal section. I wasn't really getting the best use of the different sections, although that might just be me. There was one freeze up when the train tried to run off the bottom of the screen; probably some null pointer or array bound error.

Sound would be nice, but the calls to set it up eat 100's of valuable bytes. My best Java1.4 effort is to create an AudioFormat, then a DataLine.Info for a Clip object and then use AudioSystem.getLine(Line.Info) and cast the result to a Clip. For Java1.5 there is a new AudioSystem.getClip() which gets a clip directly, although strangely that didn't seem to save much space (I need to look at that more). Once you have a Clip, you can open it, using the AudioFormat and an array of byte data, which you can generate procedurally. Some people use a SourceDataLine rather than a clip and feed data directly into it. Trouble is, all these library calls use way too many bytes.

The Applet also provides methods to play .au & in recent JREs .wav files directly. Problem is these are really too big for 4k. I have tried creating a very small wave (a few milliseconds of sine wave) and looping it. This actually worked, but only gave me a continuous tone and still used too many bytes. I briefly wondered whether could generate a .wav procedurally, write it out to a temporary file and then read it back in using Applet's play() method, but this requires signing the Applet, which is a pain.

There is also getToolkit.beep() which plays the default system beep; but you don't know what this sounds like on the target system. There is also the sun.audio classes, which are still there in JRE1.6 and provided you give them 8000Hz uLaw 8bit data, work Ok in applets. The problem is they only work in the sun JVM and are not present in some Linux JVMs and including them will cause the applet to fail to load. Ok one can monkey about with the Classloader at run time, but this rather defeats the objective of saving space.

It's pretty fun. Besides what you listed, the only change I'd really push for is something that makes it more clear what piece is under your cursor. It's also so risky to try to redo the track with bombs right now that I almost never do it, since you need both the bomb and a replacement; could you show a queue of the next few pieces so we know if it's safe to rearrange?

Not bad at all for a first attempt. What packing program(s) are you using?

Good concept, though at the moment the outcome seems to be strongly determined by luck of the draw.

Instead of using pure random numbers, perhaps you should randomize the order of a predetermined set.

There's a thread elsewhere on here from a while back (probably a few years ago by now ^^) that went into the topic of 'good randomness'.I'm sure someone else will remember it, and be able to point you in it's direction.

I'm not sure if it was just me, but the train appeared to randomly crash for no reason, typically because of turns and 4-ways. What are the exact rules for when it is allowed to turn a certain way?

Overall, I think the gameplay is indeed a bit too random. Okay, much too random. I would just place tiles on edges until I got one going left-right. Sometimes I would attempt to do curves and whatnot, but that rarely paid off. The worst was at the very beginning when I would get a curve tile that I literally could not use. Seems dumb.

I think the best strategy is to spend your curve pieces making zig-zagged paths one above and one below the straight path, starting near the exits. You can turn towards one of your curved paths when that meets up with your straight path. You could also attempt to use a crossover piece with one of them, but that's hard due to the way bombs work.

Thanks again for all the comments folks. I have fixed the bug raised earlier by Alan_W, if I get time I might see about making the grid bigger as this may make it a lot easier to play. I'm still looking at some rudimentary sound ideas given the feedback from Alan, a simple toot-toot as the train approaches would be satisfactory.

I like this train game. Maybe the mouse control will be better choice than keyboard control because the train is moved fast enough. The animation is not so smooth, pixel movement of train would be humane for eyes.

I have released an update to the applet which hopefully addresses some of the very useful suggestions given already:

Bigger grid size (7x7)

Complete removal of all bitmap images, replacing them with line drawings that make good use of the Java2D API. This has allowed for bigger tiles at a smaller cost. It also gves me more scope for creating an animated train that actually points in the correct direction along the track.

Tiles can now be rotated, which introduces more of a skill element and reduces the reliance on luck. It is just a bit too easy at the moment though.

A random tree is placed on the map. Adding more per level might provide for a much needed increase in difficulty.

The animation is not so smooth, pixel movement of train would be humane for eyes.

Thanks for the feedback, I was wondering if anyone found it annoying or not. Sadly, the inhumane treatment will continue for now. I might try to implement smooth transitions between grid squares, which shouldn't be too hard given the way the train is drawn.

You could also add points for going threw a corner tile and crossing tile.

I think that would add some much needed motivation to make interesting tracks, rather than just go for a straight line to finish the level. That Pipe Dream game gave extra points for crossing over an already used pipe, so that would work well. There were also pipes that would slow the flow down, which i could achieve by adding stations where the train has to stop and pause.

Quite a few good ideas and I've got nearly 200 bytes left to work with.

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