Can You Win in This Easy Game of ZX81 Dice


Revisiting one of my early programs as I reminisce about my ZX81 blogging.

Lately, I’ve been reflecting on my programming journey. It is hard to believe that it has been over nine years since I started writing my monthly articles. I’m nearing the end of my printouts, and thought I’d write about my ZX81 Dice Game.

Walk down retro lane.

Although I’d shared the program on my original ZX81 site back in 1998, I’d never written about it. Back then, listings and screenshots were about as far as I went. It was a simple site, created before I started blogging.

Over the years, I went way beyond blogging about my programs. I made them a monthly column with listings and ways to play them. I even shared original programs, and recreations, and lots of bug fixes.

Funny enough, it also show cased how technology changes. My onsite emulator went from Java to Javascript, allowing any mobile device to run them. I shared an Android emulator for a few years, which still works on my old Toshiba tablet.

Over that same time, my site went from static, or generated, to dynamic rendering. It has been through a few redesigns, migrations, and remakes. Like the emulator I used, each element works on phones, tablets or computers. I never expected any of this when I started blogging in 2006.

Old doesn’t mean old.

Will all that modernization and changes, the programs stayed consistent. The blocky graphics and quirky text fit well inside that modern chrome. For as modern and slick as things get, underneath they follow similar mechanics.

Dice Game, 1983, ZX81 screenshot by Steven ReidDice Game, 1983, ZX81 screenshot by Steven Reid

Dice Game, in theory, is based on analog dice. In this case the die doesn’t roll, using a random number generator instead of physics. There are four dice, two for each player. After display each face, dice game tells you who won based on the highest value rolled. The only key in the game is when you press one to start again. There is no score or tally. The mechanics were all about the dice and a little math.

Now, I admit the game could use some game play. But even written in a modern language with fancy graphics, it would play pretty much the same. Dice are, well, dice. You could say the pseudorandom number generator isn’t fair. But, loaded die aren’t either.

Peeking inside the dice.

Okay, we aren’t actually going to break dice open. But looking at the code for Dice Game, you get a sense of how simple it is. The program was one of my first, I still have hadn’t written notes somewhere for it. The main focus was playing with graphics and, in this case, the dice.

That said, it is very well formed and flows well. Dice Game is an easy program to read, even if you don’t know basic. It uses GOSUB to call each roll and display the dice. The rest of the program displays the results and who won.

Since ZX81 basic doesn’t have a switch or case statement, I used a series of IF checks to mimic one. Dice themselves are PRINT statements using ZX81 graphics. To reuse case, I had a GOTO’s on the five and six to display the last row of pips in the four.

As nice as the code looks, it could be more efficient. I could have simplified the throws to a single function. Yet, it would have required using another variable.

For the row of IF statements, an easy optimization would have been to use a variable GOTO instead. A simple GOTO 300+Z*40 would have worked. Although, I would have needed to adjust the lines numbers of the six. I didn’t know this trick at the time, but did use it in later programs.

A more complex way to achieve this would be to use a string array with all the die faces in it. Then, all I would need is a single print routine using Z as an index or to slice the string. There are a couple of ways to do that, but at the expense of readability.

Improving the game itself.

The game isn’t much of a game. I mean, there is no skill involved. As such, the program is a great demo, but has no replayability. To be a real game, it needs a mechanic for the player to keep playing.

An easy mechanic would have been to add a betting element of some sort. This is what I did on another game of my called STUD. That said, betting on dice rolls doesn’t seem that popular, even now.

More fitting would be to collect patterns or matches. I know that I wanted the dice to print next to each other, instead of down. But I didn’t know how to do that when I wrote the program. Fixing that, I can envision a couple of different matching or pattern games. Adding that with a dice substitution or tally mecahnism would add a strategy element.

Adding these changes would have made Dice Game more interesting. Yet, it would have lost its charm and simple nature. I’ll leave this one as is, and let the rest be a future experiment.



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