Type-in Mania: BASIC Programming on the TRS-80 MC-10: RetroChallenge 2017/10: Fly Wheel

When I have an idea for game, there can sometimes be a number of false starts before I get something that works. This is the case for my game Fly Wheel. Originally I thought I might be able to recreate the shifting 3 dimensional highway affect of Pole Position type games using a complex algorithm to adjust the road to represent straightaways and curves and sections of strings for moving the horizon with shifting mountains and clouds. My first attempt was rather crude. It kind of worked, but it was obviously going to be far too slow once I added all the code needed for a full game, such as being able to move the car, collision detection, scoring etc. Here's what my first attempt looked like:

Pretty funky that snaky road! The car looks a little weird too. What I needed was something much simpler for the road graphics. Nothing sprung to mind, and so I let the project languish. Then I paid a visit to a site for ZX81 programming that I have been visiting on and off for some time maintained by Steven Reid. He, like me, is an old 1980s BASIC programming hack who really enjoyed (enjoys) cooking up programs for his beloved Sinclair machine. I've created programs based on some of his ideas, such as Tower Dodge and Joust. This time I spotted his game "Fly Wheel." What it showed me is that creating the illusion of moving road curves could be as simple as slanting two perspective lines creating the road from joining at the centre of the horizon to joining a little to the left or right. Like this:

He also provided inspiration for the other elements for a game of this type such as how to depict the horizon (a simple unmoving city skyline) as well as some other nice graphic touches, such as the starting line and explosion when you die:

It's obvious that Steven got a real kick out of coming up with compelling visuals for games on his limited little machine (only 4 chips!). I can't imagine all the hellishly complex keystrokes he must have had to execute on the ZX81's infamous membrane keyboard to get the graphics characters input into strings on a real machine. Nor the horrors of the ZX's infamous ROM pack wobble possibly obliterating all his work before it could be saved to tape. It's nice to program these days in a Windows editor and then "quicktype" it into the VMC10 emulator.

The ZX81 has lowres graphics in the resolution 64X48, which is just like the resolution of the MC-10 when you put it in Semigraphic 6 mode (POKE 49151,28 or POKE 49151,68). The only difference is that the MC-10 doesn't allow mixing of text with graphic when in that mode. But that's okay. It just means using cut scenes to display messages, such as the score. The advantage of the MC-10 is that its Basic runs must faster than the ZX81's, especially if you use as few variables as possible, and other speed up techniques that I have built up over the years. So unlike Steven's game, mine is actually a little more than somewhat challenging. As Steven is obviously aware (just read his many blog postings) it was very easy for ZX user's dreams for their Basic game programs to far exceed their grasp, but that was okay back then, when half the fun was simply getting something to work. It's still fun now.

The higher speed allowed me to add a feature I wanted in the game from the beginning. I wanted the car to drift to the outside of a curve as you took the corners. In my program there are actually two degrees of road curve and the sharper the curve the more the drift. You therefore must continuously counteract the drift when cornering and be sensitive to the different degrees of curve that you are currently on. Straightaways don't have drift, but they do have a little bit of randomness. Your car will occasionally bump right or left, so you also have to be a little careful on the straight sections.

Steven's program was based roughly on Atari's Night Driver game, so the other cars appear only as oncoming tail lights. I borrowed his model of how to show the progression of those lights in size and spacing, and then, thanks to the two colours available in SG6, made them red. They come down the road in a line starting at a random location at the top, so they are either some degree left, central, or to the right side of the road. Where they appear gives you some warning of the path they will take. If needed, you can drive a little over the edge of the road, but you lose points every time you do and if you go too far over the edge your tires go and your car blows up. So the trick for getting high score is trying to limit the number of times you overshoot the edge as much as possible. A little sound attends any move over the edge. Thanks to Robert Sieg for providing me with a POKE routine that allows this sound to be generated while in SG6 mode (Q=PEEK(9)AND128:POKE49151,4+Q:POKE49151,128-Q+4). This routine works for the POKE 49151,28 colour set. Using the normal SOUND command automatically takes you out of SG6 and bumps you back into normal text mode.

Generating the sequence of the curves was something I simply encoded into DATA statements. Each cycle through the main loop a road variable is read indicating straight, or one of two degrees of left or right curve. Then I just coded the sequences of numbers for a simple oval, a slightly more complex liver shaped track, and a multiple tight-hairpin-curve track. The score you achieve is a sum of how far you go through these variables, minus any times you have gone over the edges and multiplied by the degree of difficulty of track (1-3). I have found it easiest to keep to the inside of curves as you try to counteract drift, so it's a good idea to study the maps and make preemptive moves on straightaways to get positioned for the upcoming curves. Thanks to Pippa from over on the CASA Adventure database forum for showing me the PEEKs and POKEs to reset the pointer for the READ statement. This allows me not to have to re-read all the prior DATA again for the other tracks each time you restart, which really helps speed things up.

Find position of next date item to be READ and store it in variable E:
E=PEEK(173)+256*PEEK(174)

Restore next READ to the E position:
POKE174,INT(E/256):POKE173,E-256*PEEK(174)

I'm under no illusions that this game is a rival to a real Pole Position or night driver game. Like Steven, I'm just in it for the challenge of seeing whether a certain vision for a game can be carried out given the limits of the machine and the limits of Basic as a programming language. I think the game I have come up with is a nice extension of Steven's concept. In particular I'm really pleased about how I was able to make use of the only two other useful characters (dark green and light green blocks) that are available in SG6. Because of the way the MC-10 was wired by Tandy, the lower 128 characters are not really rendered properly and simply show up as varying (ugly) sequences of green and dark lines. But the two useful ones (solid dark and solid green) provide some contrast to the red and blue graphics characters. I like the "brooding" green night skyline and the dark green tires actually alternate with one's with an outer light line to add some effect of tire movement. In Steven's program for ZX the skyline is rendered by the light grey stippled block character, as are the tires, with an alternating stipple to give the tires the illusion of motion. It was a neat challenge to figure out how to achieve similar effects using the MC-10's quirky semi-graphics. I have also figured out a way to render chunky alphabetic characters using only the graphics blocks, which I used on the start/finish sign.