Speccy, Vol 10: Rotten Egg Mines

June 10th, 2016

I talked about making games for the speccy on IRC with some people who were not familiar with the device, and someone tried to think of a game that would use all the keys on the speccy keyboard. I feel that was a rather bad idea - most modern games on the PC don't try to use all of the keys on the keyboard. Actually, if you forget flight simulator (and I haven't looked at recent versions), I don't think modern games use all that many keys, even if they're designed for the PC.

Anyway, I noticed that "Comp Sys Sinclair Crap Games Competition 2016" is a thing, and figured I'd spend one evening making a minesweeper.

I've never done a minesweeper game before, but the idea is simple. Assuming you didn't manage to step on a mine, you'll get a number that tells how many mines are adjacent to the tile you're standing on. If you can uncover all tiles that don't have mines, you're a winner.

So I started working. I googled for top-down pictures of the speccy, which was surprisingly difficult - most people like to take really angled shots of their computers for some reason. Having found one that I could live with, I did some lens corrections in photoshop, and then blew the image up in image spectrumizer.

Then I painstakingly wrote down the x/y coordinates of all the 40 keys in the image, and tried drawing text on the coordinates, only to realize that my text output only works on 8x8 pixel aligned grid. Rats.

Instead of fixing my text output to work everywhere, I drew nine 16x16 sprites and ran them through my sprite processor. Each sprite took 768 bytes, meaning I was wasting about 7kB only to draw numbers 0 to 8. (You can't have 9 adjacent mines because you'd be standing on one).

That done, I also directly hex edited the background graphics so that all completely black tiles still had a visible foreground color so that my sprites would show up. This way I wouldn't need to touch the color attributes at runtime at all.

Then followed the minesweeper how-many-mines-do-I-see logic, random level generation, key input, a "slideshow" of text at the bottom of the screen, tracking which tiles have been opened so we can keep score and find out when we won, printing out said score... and sound. I used the BeepFX which has served me fine for the past couple projects, and added a couple of sounds (for successful turn and flow blowing up). A simple graphical effect for when you die, and text to congratulate the player when they win, and.. done.

Well-behaving minesweepers make sure your first step doesn't kill you, and making that happen would be relatively simple, but I didn't bother with it. If you die, you'll automatically start a new game anyway. Many minesweeper games also auto-fill zero tiles when you find one, but here we only have 40 tiles so we should leave some work for the player. There's also no flagging (how would you do that anyway, considering all keys are in use). Better remember where you think the mines are!

For the score printing, I didn't bother with BCD this time, and instead just did while loops to do the division by 10. This also contains the game's only bug (that I'm aware of), which may or may not be fixed in a version you play. Since it's not a game breaking bug, I didn't bother updating the competition version.

Mackarel 2.1 by Jari Komppa, http://iki.fi/sol
Progname set to "R.E.Mines "

"crt0.ihx":
        Exec address : 40960 (0xa000)
        Image size   : 14367 bytes
        Compressed to: 3750 bytes (26.101%) by ZX7

Generated loading screen
        Image size   : 6912 bytes
        Compressed to: 138 bytes (1.997%) by RCS

"lowblock.dat":
        LowBlock addr: 23296 (0x5b00)
        LowBlock size: 6912 bytes
        Compressed to: 2871 bytes (41.536%) by ZX7

Boot exec address: 58624 (0xe500)
BASIC part       : 51 bytes
Screen unpacker  : 122 bytes
App bootstrap    : 123 bytes (69 codec, 54 rest)
"remines.tap" written: 7109 bytes
Estimated load time: 57 seconds (7 secs to loading screen).

Memory : 0       2       4       6       8       10      12      14      16
         |-------|-------|-------|-------|-------|-------|-------|-------|
On load: rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
         sssssssssssssssssssssssssss..b..................................
         ................................................................
         .....................................BLLLLLLLLLLLCCCCCCCCCCCCCCC

On boot: rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
         sssssssssssssssssssssssssssLLLLLLLLLLLLLLLLLLLLLLLLLLL..........
         ................................CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
         CCCCCCCCCCCCCCCCCCCCCCCCC.......................................

Key    : r)om s)creen b)asic L)ow block C)ode block
         H)igh block .)unused -)reserved

Packaging was done via Mackarel as usual, and I didn't even bother with a custom loading screen. All in all the whole project went without many problems. If I could have made games of this quality as easily back when I was 10 years old, I would so have spammed the speccy market full of games. Oh well. =)

As you can see in the Mackarel report, there's plenty of space left. The low block is for the background image, and most of the code block is sprite data.

You can play the game online here, download the .tap file or ogle at the source code on github.

The next speccy project (which I'm working on currently) is a bit more challenging, but more of that next time.