Up Is Down in Faller, May’s ZX81 Program

Walls and creatures always make for a nice game and Faller, our program of the month, has both. It takes a bit of imagination, but watch the icky spider climb up the wall towards you. Their goal, of course, is to knock you off and claim the wall for themselves. Like any good hero, you sit at the top and move over the spiders using Z and .. But be quick and knock them off using M to save the day. Just don’t be a faller should you miss.

Let’s Talk Play

As a game, Faller is a bit upside down. It probably would have been better named Dropper, except that nothing ever seems to drop. All the elements are there though, which is good as it helps the game work.

The game plays relatively fast, but will stutter when the spiders move. The slowness is by design. BASIC is about compromises. In this case a little bit of slowness to move the spiders is offset by move responsive movement.

The spiders may look easy to stop, but the game mechanics actually work against you. Not only is it hard to gauge when you are over the spiders, but the lack of feedback makes it hard to tell when you are successful. Because of this, you sometimes have to go back to stop a spider that continues to move.

To make the game just a little harder, you only get 20 attempts to stop the spiders. This is more than enough and it never decreases, although it probably should. Yet, you’l never know you you're out. The game doesn’t tell you how many are left, nor does it provide any visual cues to that effect.

These issues aside, as a package Faller isn’t bad. Perhaps not the best looking game, it fits the ZX81 style. And, unlike my other games, it is fair in both score and difficulty. That is, the score is predictable since each spider is worth 10 points and not some random number. The difficulty, determined by the time between spider moves, is linear as well.

Show Me the Code

Faller’s code is different from my other games. Right at the start, you may notice that I brute forced the spiders. Each has their own variables, their own display routines, their own test routines. It works, but I wonder if using an array would have been better.

For example, let’s look at the original code that prints each of the spiders:

 210 PRINT AT G1-1,C1;C$;AT G1,C1;B$ AND C1
 220 PRINT AT G2-1,C2;C$;AT G2,C2;B$ AND C2
 230 PRINT AT G3-1,C3;C$;AT G3,C3;B$ AND C3
 235 PRINT AT G4-1,C4;C$;AT G4,C4;B$ AND C4

As a note, this code is flawed and will print a black square in the top left corner. Can you tell why? I’ll give you a hint: C$ is a black square.

If G and C were arrays, I could have turned those four lines of code into this:

 210 FOR L=1 TO 4
 220 IF C(L) THEN PRINT AT G(L)-1,C(L);C$;AT G(L),C(L);B$
 230 NEXT L

It is a bit more compact, reads better, and, in case you didn’t notice, fixes the display bug as well. And, with a little work, you could vary the number of spiders on screen. Yet, although it looks better, I don’t know if this would be better. I’d have to test to make sure the program still ran well.

Another difference is the that comprise I talked about. The program uses the SP variable to speed up the game. It does this by reducing how often the hero moves before the spiders do. Using a technique like in Laser Blast, the delay is a simple loop. This makes it look like you are moving faster, slowing you down as the game goes on.

Although I’ve slowed things before, I usually try to keep the player’s speed constant. The game feels smoother that way and, generally, I’m moving everything at once. Using it in this way, I think it feels jerkier. Unlike Laser Blast, where it is clear the action is separate, Faller is more disruptive. Yet, at the same time, it is more responsive as there is less processing during your movement.

One flaw in this technique is that when you try to knock a spider off, a key press may not work done at the end of the loop. The test is only while you are moving, the fast part, and not during the spider movement, which is slower. Because of this, I found myself holding down the key which, if you aren’t careful, will use up all your shots

Testing and Other Changes To Try

No program is perfect, especially these were I spent more time entering them in than testing them. In fact, I actually have two versions Faller. Stapled together, it was the top one I entered in first. When I tried to run it, it failed. Apparently, the second copy was the working version. Just goes to show, that testing isn’t new, even for a kid in the eighties.

As a matter of course, I test the games I put here to ensure that they do work. I also make sure they auto-run when loaded and make sure you can repeatedly play them. But, working doesn’t mean the program is complete.

Playing through Faller, a couple of things became vary obvious. The wall, for example, is the width of the screen, but neither you nor the spiders can go past the first 15 squares. Making the wall shorter would have looked better. Also, looking at the code, I’m not sure you could reach some of the spiders. Another thing to check and test.

The biggest change would be redoing the way you stop the spiders. Adding some sort of visual cue would have helped. The simplest way would have been to change the spider when it was hit. A better way would have been to pause the game and shown a dropping animation that would miss or hit. Oh, and telling the player how much ammo they had would have been nice.

Wrapping This Up

And there you have it, another program of the month out there for you to try. Faller is an okay game, but I found the code much more interesting. Perhaps you did as well?