Entering a Program Shouldn't Be This Frustrating


With failure stacked against me, I was able to get Star Probe Redo working. A reworked version of my ZX81 adventure game.

Back in July, I made a mistake and entered in Star Probe again. I had forgotten that I’d already shared it. But, unlike my first attempt, I had taken a different approach which made it a much different game. Jumping ahead, I decided to finish what I started. Here is Star Probe Redo, an updated version as October’s program.

Struggling a bit with writing.

To be honest, I’d already written the original blog post when I was thinking this was the first time I was sharing. I’ve had the game done for a couple of weeks, but couldn’t figure out how to write about it. I don’t normal have writers block. Once I get started, words seem to flow. This time, nothing. The struggle is real, and I was living it.

Since I don’t talk about the process of writing these articles, let me explain a bit. The first few articles tended to have a simplistic structure, often a few paragraphs about the program. As time went on, I tended to stick to a common theme: play, program, and improvements. The advantage to the formula is that I generally could focus on the what without worrying about the how.

To avoid being too formulaic, I’ve often taken different approaches to each article. Yet, the main theme is still there. You’d think that would make it easy to write, but some programs don’t fit the formula. It can be too dry or boring at times, and I try to add in some flavor. Those are often bits about my childhood or outside influences to my programs.

For Star Probe, it was that last part that I struggled with. I couldn’t come up with a starting theme that I liked. Given this was a redo of a previous article, I wanted it to have some flavor, a different color. Funny enough, I landed on sharing my struggle. It was right in my face, the inner monologue that was kicking around my head was the discussion.

Writing and programming have similar contexts. If you relate, to this, don’t fret and the creative juices will find a way. If you’re here for the program, fear not. I ended up sticking with my original theme for the rest of the article—sort of.

An adventure game, again.

It’s not easy being a star probe. Space is hard and unforgiving, which explains why we often think of space as the new frontier. An homage to the old west, forgetting that much of the west’s problems were man made. In this short space adventure, you are an intrepid star probe with a problem.

Star Probe Redo is at its heart a puzzle game. Although, it is not as sophisticated as an Infocom game. There is no text parsing or objects to manipulate. Instead, the player must figure out what to do by inputing numbers.

It is fitting that the game removes the guesswork given you play the role of the Star Probe, a mechanical device. As an added benefit, it simplifies the game design. Trying to use words would have required a much more sophisticated parser.

It won’t take more than a few minutes to finish the game, but I do recommend you play through a few times. Alter what you do, trying different things to see how the game changes. Decisions you make in earlier stages can alter later ones. Think of it as an adventure to figure out the adventure.

Star Probe Redo, ZX81 Screenshot by Steven Reid, 2020Star Probe Redo, ZX81 Screenshot by Steven Reid, 2020

Reworking the game.

Now the first time—err, second time as I realized later—I entered in Star Probe I decided to enter it using SZ81. I had been having issues with my Windows VM and thought I’d give it a try. After entering it in, I tried to load it up later to fix something and realized the program was corrupt. Frustrated, I went to bed to try again later.

Although disappointed, I’d been here before. Having lived through programing hell of the eighties, losing a program wasn’t new to me. I generally remember what I did, even if it never quite matches the original. I got back to work. Unable to load the images from SZ81, I started over using ZXSP. A program I’ve used before.

I had started off by typing in Star Probe again. In doing so, like before, I noticed there were a ton of spelling and grammatical errors. I was going to leave these in, but as I got into the second half of the game, my mind shifted. There were a couple of flow issues I didn’t like and it pushed me over the top. Good thing too, as this made Star Probe Redo a much different game.

To make things easier, I typed the story text in Scrivener. This allowed me to edit and correct it first. Entering a large amount of text on the ZX81 can be painful. Your cursor only moves from right to left. Even in FAST mode, the ZX81 is an unforgiving machine.

Once I had all the text written out and edited, I go to work updating the program. Not only was it faster to edit, things made more sense now. I’d removed much of the repetitive text and cleaned up the prose. Now I could work on the program.

Coding for reusability and readability.

With the text done, I started to clean up the display routines. Star Probe Redo breaks up each section into screens of text. Yet, those screens weren't consistent. To fix this, I added some subroutines that provided a consistent look to the text.

Along the same lines, I also cleaned up the responses. The original game tended to print words, often clearing the screen between input. In my new version, I coded in some pauses with prompts for the player to press a key. This also allowed me to combine some of the responses onto the same screen, making it easier to read and follow.

The last major change was to include adding new boolean variables. The game expected the player to try different numbers to see what would happen. However, it didn’t save the state of those responses. The result of which was later text didn’t make sense if the player had discovered something already.

Adding state required writing new text to differentiate the answers. Back to my editor, I wrote all the new alternative text. I also added in some error checking text in case the player used numbers that didn’t make sense. Although more work then I planned, the results were worth it. Star Probe Redo now has a decent adventure prose.

A better experience.

With its bones now fleshed out, Star Probe Redo flowed better across its three acts. The first act starts off as an introduction to the games mechanics. After some opening text, it drops you into the first puzzle to solve. This one has no time limit, instead waiting for the player to figure out what to do next.

The second act, unlike the first, does have a time limit to solve the problem. It is more than enough time, even after cutting down the loop, to solve the problem. I debated dropping it further, but decided it was a fitting length to the middle act.

The last and final act, provides the player an opportunity to solve the game. It may not offer any revelations, but there is some satisfaction in figuring out how to win. Three acts, three puzzles. Not a huge game, but still enough to whittle away some time.

With all the different states now programmed in, the game is repayable.If you die, it isn’t the end of the world. You can start over and try again. If you do succeed, I recommend playing again to see what happens with different input. I had a lot of fun testing all the different combinations. Hopefully I didn’t miss any!

Programming failure once more.

After a long night of coding, I decided it was time for bed and started saving my file. Given I was close to finishing, I did some final testing and noticed some wording was wrong. I decided to load up an older version of the program, only to find the files wouldn’t load.

Frustrated, I loaded up a previous save and saw the same thing. This was the second time I had this issue. I was distraught. I tried loading some of my earlier saves. Only the first one worked. That was something I guess.

I started hunting around for other ways to read the file, but my attempts failed. Back to square one. Although I had my text still, I didn’t want to have to start over. At this point, I still had forgotten that I’d already entered it. I went to bed in frustration.

Starting over once more.

The next weekend. When I returned to it, I realized I’d blogged about Star Probe before. At that point, I gave up and wrote about another program instead. That was where I left the program for the next couple of months.

At the beginning of October, I thought it was worth digging into Star Probe Redo again. I thought my reworked version would be worth sharing. I had all the text still, but I wanted to see if I could load up the original code.

I had my VM working and decided to try loading the program into EightyOne. I tried a couple of different ways, from machine states and different formats. None worked. But, I did find that I could read the code in the hex editor. Thinking some of the pointers were wrong, I tried adjusting them to no avail.

Although the program wouldn’t load, seeing the data in the hex editor made me wonder if I could list it. Loading it into my website, to my surprise I realized I could! Okay, that was something. That got me wondering, maybe I could compile the code. JSZeddy, the javascript emulator I use, allows you do just that.

After some trial and error, I had the program compiled. But there was still a problem. I didn’t have a way to save it. I tried pulling the program out of the editor, but it was in a hex format that doesn’t work as a binary program. But, after doing some research, I realized that I needed to convert the text to binary. Theoretically, that would make a .P program that I can load.

Jumping into Perl, I wrote a little program called hex2bin.pl. After some more trial and error, I figured it out. I found the right routines that would read in the hex code and output the appropriate binary data. Loading that file into EightyOne, I was excited to see my program working again!

Back to fixing things.

Excited that I had a working program again, I got to work doing some final testing. I found a couple more bugs that needed fixing. I was glad I had that old text still as a couple of the routines didn’t sound right. I made some more edits and fixed the code.

By now, I was planning on making this a proper rewrite. One of the ideas I had before was to remove the INPUT. It is too easy to mess that up and is confusing for modern players. Using INKEY$ instead, I rewrote the input routine completely.

Now, I could have gone further. The display, which clears the screen between text, would work better as scrolling text. I liked the way the old Infocom text games worked and creating a similar routine would be nice. I decided that was a bit too much for this program.

Wrapping up.

There are, of course a few things I could still do. As written, the puzzles rely on hard coded checks with text. Using a data structure would provide greater flexibility and variety.

The game is very linear as written. That isn’t bad. But, adding a more varied story with exploration would make the game last longer and more enjoyable. To be honest, that would be a complete rewrite. Given all the challenges I’ve had, that is out of scope for this effort.

With all the distractions and failures, it is amazing this program is even getting shared. As frustrated as I could have been, to be honest that is life. Instead, Star Probe Redo ended up a being a much better game in the end.



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