Electon is August’s ZX81 Program

I painted more borders on the ZX81 than just about any other shape. An easy way to confine movement, it shouldn’t come as a surprise that Electon starts by building a box. And before you ask, this month’s ZX81 program isn’t another version of snake. Instead, you use the Z, X, N, and M keys to move in an attempt to capture the Electon. Sounds easy? Better give it a try and see.

That thing’s active.
Ah the elusive Electon. I’m not sure where the little inverted asterisk got its name—perhaps I just forgot the ‘r’ in electron. Yet, it is apt. The energetic particle bounces around, making it difficult to contain. That’s where you come in.

You have the ability to create a trail of dark energy that you can use to try to contain it. As with all energy, you can’t touch it or you’ll crash. Fortunately, you’re not forced to move—why I said this isn’t snake. Take your time as that Electon can be a bit of a pain to catch.

I find it best to just move out and try to wall it in. But, as you'll learn, the Electon moves faster than you. In fact, it can leap over your energy field to safety. Because of this, it pays to keep your distance. I recommend constructing double walls in a attempt to corner the renegade particle.

As you progress in the game, you might be surprised how it can be both frustrating and easy. Written in 1983, there is a duality to it that comes from my early experimentation. Yet, if you’ve looked at my other games, it’s also foundational. Setting that aside, let’s dig deeper into Electon.

Bad movement keys.
On purpose I didn’t tell you what direction the keys took you. Instead, I wanted you to experience the frustration of movement that doesn’t match expectations. The Z and X keys move you up and down respectively. If you found yourself crashing a lot, I can relate. The combination took me several games to overcome. But why?

For one, it’s not intuitive. Moving vertically using horizontal neighboring keys is hard to relate to. Had I used A and Z instead, I doubt you or I would have had any issues. For another, most gamers are so used to the WASD that anything else is just, well, weird.

I must have figured that out at some point as later games used either the ZX81 arrow keys or the AZ combination I mentioned earlier. Although unintentional, and forgivable for a game from the earlier ’80s, I was surprised at how difficult it was for me. If I changed anything, this would be the first.

Interesting logic.
I’m somewhat mixed on the second issue. If you sit still, it may surprise you that you can still capture the Electon. Perhaps I should also state that it can crash into you as well, so some about of cation is warranted. But that same logic is also what makes the game fun. Let me explain.

You see, the fun of the game is the chaotic movement of the Electon. The bouncing around is caused by the following code:

 125 FOR L=1 TO 3
 130 LET Y1=Y1+(INT (RND*3-1))
 140 LET Y2=Y2+(INT (RND*3-1))
 145 PRINT AT Y1,Y2;
 150 LET P=PEEK (PEEK 16398+256*
PEEK 16399)
 151 IF P=0 OR P=151 OR P=8
THEN GOTO 160
 152 NEXT L
 153 GOTO 300

Let’s walk through that code. Line 125 starts a loop using the L variable. The loop will go three times, unless we exit early as we’ll see in a minute. Basically, our little asterisk gets three changes to move.

Lines 130 and 140 are where Electon gets its bounce. Note that ZX81’s RND function generates a real number between 0 and 1—although not 1 itself. So, multiplying it by 3, subtracting 1 and then using INT to turn it into a whole number yields -1, 0 or 1. The asterisk will either move, or not, each loop.

Lines 145–151 decide if the Electon hit anything unimportant. In this case, it checks if the square it will occupy is a space, itself or you. If so, it breaks out of the loop and moves there. Note that at this point, if that square is you, it’s game over.

Now, the fun part. Line 152 continues the loop and, if after three moves of not finding a space to land in, line 153 takes you to the score screen. The energy wall—the inverted space—is considered an occupied space that it can’t move into. The intent was for you to corner it with your energy wall. But there is a problem.

You see, I forgot to reset the previous movement in lines 130–140. So, each loop is additive, meaning Electon can move more than a single space each time. On hand, this is great. It makes the game a lot more fun as the particle can leap around unexpectedly.

Yet, even if I fixed that I have a second issue. Given the movement is completely random, it is very possible that it will try to move into the same space each time. Thus, it is possible to capture the particle with only one block next to it. Not my intent, but fixing that is more difficult. Do you see a way?

Iterative programming at its best.
Instead of talking about all the flaws in the code—you can find those on your own, I want to focus instead on my development process. My coding then, much as it is today, wasn’t linear. I’d try something, run the program to see what didn’t work, and then adjust. In simple terms, I can sum up the sequence as follows: code, test, iterate.

The evidence of my process is quite visible in Electon. It was right there in the first few lines. The border routine, lines 20–23, were clearly added after the fact. I mean, come on, I added it right in the middle of declaring your starting location—lines 20 and 30.

  10 LET S=0
  20 LET X1=1
  21 FOR A=0 TO 21
  22 PRINT AT A,0;"_";AT A,31;"_
";AT 0,A;"__________";AT 21,A;"_
_________"
  23 NEXT A
  30 LET X2=15

The same thing can be seen in the earlier code snippet. Normally, I would’ve cleaned this up before printing. But this program predates that process. The original printout is even missing the comment line. I added that from the hand written title on it.

Now, this isn’t bad, just more visible in BASIC. The reason most people number programs by 10 is to give themselves room for just this sort of thing. But let’s be honest, this isn’t Agile. And, at 13, I didn’t caring about software development process. Nope, I was just doing what worked. And that, my friend, is fine—for this kind of work.

But, don’t take that to mean I don’t believe in process. I do. Consistency can be very valuable in improving speed and supportability. I also believe in automation and letting the computer do repeatable tasks that I otherwise would have to do. Yet, it’s just a tool and not an absolute. Personally, I’m always swinging that pendulum, trying to find that balance.

Hey, isn’t this normally on my other site?
Why yes, it is. Five years later, I’m close to merging my sites back together. When I broke my ZX81 site out in 2011, it was because it was a separate site on Geocities. Yet, Yahoo forced my hand.

My original plan was to have a single blog shared across sites, but I found it difficult. I’ve never been satisfied with the arrangement and recent issues are fueling my desire to bring them back together. It’s not super high on my priority list, but I expect it will happen before the end of the year.

Yet, don’t fret. I’ll make sure it all redirects when I pull the trigger. Until then, I’ll continue to cross post articles for those that are still linking to the sub-domain.