Test if You Think Your Reflexes Are Good in This ZX81 Game

Quickly dodge the obstacles in the tunnel using “Z” for left, “.” for right, “X” for down, and “M” for up.

Tunnel Dodge, ZX81 screen shot, by Steven Reid, 1985I’m running a bit late this month, but I’ll try to make it up by offering a larger game. Of course, it wouldn’t be the Eighties unless it was almost impossible to play. But, at least it looks good.

All in the looks.
Although only a few lines, the game does a good job of presenting depth. Given the limitations fo the ZX81, Tunnel Dodge offers a decent 3D look that works for the game. A plus is the number of obstacles presented. There are eight different animations offered to enhance the experience.

That said, it is a difficult game. This is primary due to the limitation of the animations. I used a simple loop in the code to advance each frame. But, you only have a few frames to move. Much of the time, it isn’t enough to avoid the obstacle.

Maybe not that hard.
That said, it isn’t quite impossible. Playing through the game, I could usually get through a few obstacles before crashing. Which is actually a pretty cool part of the game, and one you won’t enjoy on all emulators.

The reason for that, is that I use FAST and SLOW to jitter the screen before showing the crash animation. Although it may look like the game paused with the Javascript emulator, on a real ZX81 it is neat to watch.

Tunnel Dodge, ending ZX81 screen shot, by Steven Reid, 1985Some complex code.
The game is quite long and, given it was created towards the end of my ZX81 programming days, well structured. The game uses the ZX81’s ability to compute a GOSUB by adding a multiple of the random obstacle variable. This acts similar to a branching switch statement in other languages.

The ending, not surprising, is also quite long. Beside the crash code mentioned above, it shows the blinking remains of your ship. It is almost sad, given you might not have made it past the first obstacle. Given the length of the ending, it can be like adding salt into a wound.

Still some room for improvement.
In the end, there is still room for improvement—hindsight offers opportunity. An easy improvement would be adding in a way to move more often between frames. The game is plenty fast enough, so I expect using a fractional step in the loop would be enough.

Another idea would be to allow multiple lives or add shields. This would allow you to mess up a few times before the game ends. Shields might be the better idea as I could replenish them if you are doing well.

Another fix would be to add some stripes to the tunnel. Using an alternating image, or set of images, would mimic motion. This would enhance the depth of the tunnel and add to the action. I don’t think this change would be hard to implement either.

Related to the above, I could also do a bit of optimization. When you crash, I need to print the the tunnel so that it clears the obstacle. Using an array or routine for the tunnel would would reduce the memory used.

And with that, we are done with November’s program. Now, I wonder what I should do for December?

Comments on this article:

No comments so far.

Write a comment:

Type The Letters You See.
[captcha image][captcha image][captcha image][captcha image][captcha image][captcha image]
not case sensitive