The start of the 2019 year is passing quickly, so I needed to get a game in quick. I found a short little program called Trench Runner, but to my surprise, it had two listings. So, I took advantage of the situation and am offering two ZX81 games for January.
Version one—the typical program.
If you give the first program a try, you’ll find it is a simple graphic game. Much like what you’d expect from my ZX81 games, Trench Runner is that. A trench, a ship, and something to dodge. Typical for my games, use Z and . to move your ship. Easy.
The action seems endless, but the game has an end. Should you stick it out, you’ll get a win and the game ends. Feel satisfied. It isn’t a hard game, but it is difficult to die. As long as you stay away from the walls, you shouldn’t struggle to avoid the obstacles. Should you die, the game gives you a score to show how long you toughed it out.
Now, the program itself is quite short. Given the simple nature of the game that shouldn’t come as a surprise. One could argue the trench takes up most of the game. The rest is standard fare:
IF. It had a couple of bugs when I tried it out, so I corrected them to at least make the game playable, if not enjoyable.
Version two—memory fun.
Playing Trench Runner version 2 is a different experience. It feels faster, although I’m not convinced it is. Some of that might be from the lack of clearing the sprites as they move. In any case, it is enough to feel different, even if the game play hasn’t changed much.
The real difference is found as you dig into the code of the program. Unless you are familiar with programing in ZX81 BASIC, you’ll find it difficult to read, if not a bit complex. For the initiated with ZX81’s that are low on memory, you might recognize some common memory saving techniques. If you aren’t, let me enlighten you.
The ZX81 generally came with 1K or 2K of memory, depending on the version and or location. My ZX81 came with 2K, like the TS1000 did. This is pretty small, even by 1980 standards. Most users, like me, purchased the 16K memory pack. Without it, you are quite limited on screen real-estate, much less program footprint.
A full ZX81 screen takes up 793 bytes, which isn’t a great idea for a 1K ZX81. So, the ZX81 does some tricks for systems with less than 4K to reduce display size. If you are really interested in how all this works, check out this article on it.
In a game like Trench Runner, which takes up only a small amount of screen space, a programmer, such as me, might be tempted to make a game that fits in that small amount of space. Would this game fit in 1K, hardly. The display alone is uses 185 bytes at the worse. Even as small as the program is, it is well over a 1K. Yet, with some memory tricks, we can reduce it down quite a bit and get it to run in a 2K system.
And that is what version 2 does. On the ZX81 numbers consume 5 bytes each, due to their ability to represent real numbers. This is great if you want to use the ZX81 for complex math. But, for as little memory as it has, it is a waste. To get around this, you can use variables and other tricks to get below that 5 byte limit. All that math and use of
CODE allows you to save a few precious bytes. As a note, the original version was even smaller as it didn’t include the
REM or code to restart or save itself.
The more they stay the same, the more I can change them.
Now, beyond the memory saving bits, Trench Runner v2 uses slightly different logic and flow. That is why the display is different. There is also some changes in wording. But, in general, the two games are the same. They use the same elements, core logic, and play the same.
For me, I like the logic of the first version more. It is easier to read and looks better. I did tweak the second version to make winning it shorter, but otherwise they are both boring games. I had more fun comparing how I wrote them and why.
Now, during one of me evening runs before writing this, my mind started to dwell on game play. Given they are quite short, I wondered about rewriting Trench Runner as an MCODER game. That would give me a lot more speed, allowing me to expand them a bit. The first item, of course, is that they would have to be used in 16K systems. No more 2K versions.
Now, if the speed improvement were enough, I thought about what I could change. First off, I’d like to animate the trench to give it a feeling of motion. I don’t think that would be too hard. I thought of a couple of different methods to do that. I’d experiment a bit to see what was the most efficient.
The next thought was to add more obstacles that I could move in random or not so random ways. This would improve the playability, ramping up difficulty. If I had enough speed, I could even use some delay to ratchet things up. A good game needs stress, but not too much.
Starting down a long stretch of sidewalk, my mind continued to wander through other ideas. I started to design different perspectives for the trench. I was thinking about other obstacles, adding missiles, and stuff like that. Think ZX81 Xaxxon. At this point, I was getting too ambitious. My run ended soon after that, and with it my desire to put more effort into the game. Instead, I focused on starting this article.
As always, I leave you with these ideas. Perhaps you can write the game in machine code, fitting it into 1K while still making it enjoyable to play. For me, it is an idea to ponder and revisit when I run out of programs to enter.