Making a game for the ZX Spectrum in 2020

Making a game for the ZX Spectrum in 2020

One of the aims for me creating my Spectrum emulator neccy (short for not a speccy) was so I could learn the ins-and-outs of the Spectrum - something I never did when I was using this machine back in the 80’s.

“What better way to learn it”, I thought, “than to create an emulator?". As it stands, writing an emulator for a 35+ year old machine is really only part of the puzzle. I liken it to understanding all of the notes and function of an instrument but then being absolutely clueless when it comes to playing a tune.

I am a person who learns through having a challenge; I simply can’t sit and read tutorials and copy/paste examples and expect any of it to stick. I have to have something that I believe in, something to motivate me. I also have to be thrown in at the absolute deep end and have to figure it out.

Armbands included

One thing about coding for an old machine in 2020 is that there are still folks out there who are programming for, blogging about and playing games on such systems. I dipped my toe into the retro gaming waters on Twitter and found a whole host of helpful folks and resources.

Whilst one may be in the deep end of programming for the Spectrum, there’s definitely some armbands to help you say afloat. Two such resources have come from Dean Belfield and Jonathan Cauldwell, both of whom were coders for the Spectrum back in the day and are still active today.

One thing I will say, however, is that much of the information out there already pretty much starts on/near the “end state” for Spectrum development, immediately talking about sprite shifters, pre-shifted sprites - self-modifying scroll routines, often with very few visuals. It’s all very cool stuff and hugely impressive - but it’s several steps ahead of where I am in my own personal journey. As such, there’s a gap in the market for the very basic detail on some of the techniques. Maybe one day I’ll feel motivated to type up my notes that I’ve been making whilst I’ve learned from the masters.

Peer Pressure

Anyway - I had to decide on a project. What was I going to make?

Pong? That should be ok as a starter project right?

How about Tetris? I even started it!

Falling block

Everything changed one evening during a little bit of banter with a couple of retro folks on Twitter.

At the time, I was mucking about with a really simple Point & Click Adventure game engine in C-like C++ using the olcPixelGameEngine.

olc Powered Point & Click

I was part way through creating a simple SCUMM-like scripting VM and had some of the basic interactions in place.

And then I chimed into a Twitter thread.

A healthy dose of peer pressure from @SpectrumNez and @BreakIntoProgram and it pretty much gave me one of those irritating ideas that I couldn’t shake.

So you’re making a Point & Click game - for the Spectrum?

I’m not sure where it’ll end up, but yes - it seems that way.

It took a relatively short space of time to get a basic joystick-powered “verb” menu up.

Verb Menu

I was seeing progress - and I had a purpose, let’s keep going!

Once I had verbs, I needed something to do with them. So I put together a simple inventory.

Inventory Menu

This made me think about how to handle all the controls and areas of the screen. We don’t have a mouse on the Spectrum, so I decided to make this joystick-controlled. You can move between the verbs, then press fire to action it - from there the intention is that you can switch between the inventory and the “stage”.

All of this may change in favour of the floating “crosshair” type cursor, but for now I’m happy with how this works.

Now I could select verbs and navigate the inventory, I decided it was worth thinking about how verbs and inventory items interact.

At this stage, I have a simple item description:

    item_table: [ list of item offsets ]
    item_1: {
        name,
        verb_table: [ ... ]
    },
    item_2: {....}

Using this, I could start putting dialog descriptions with the items associated with a “Look At” verb.

In Z80 it looks like this:

item_powder:
	.db 8,"Powder"		; item label
	.db 1			    ; action_count
	.db VERB_LOOK		; actions[action_count]
	.dw dialog_powder_look

I’m using two types of strings in the demo at the moment; one which is zero terminated, the other which is length prefixed. The length prefixed ones let me jump past the strings very quickly, but this is only effective if they’re inlined. In future I may scrap this for pointers to zero-terminated strings. But it’s fine for now.

Inventory Item Descriptions

It’s all very rudimentary but it’s quite nice to be able to start interacting with the system. It’s also brought together a few things; displaying text, timers and basic user interaction.

With that in place, I’ve spent some time learning how Sprites work on the Spectrum. In short, they’re annoying - and thanks to @BreakIntoProgram it’s made understanding things a lot easier. One day I’ll have a go at writing my own step-by-step technical breakdown on the subject, mostly scribing my notes into a blog for you to digest.

With some rough code to handle sprites in place, I needed something to actually show. Using AESprite, I cobbled together a 16x48 character that (depending how hard you squint) may or may not resemble a certain iconic pirate who visited a place surrounded by water that is inhabited by primates. Don’t worry, I’ll change it.

Talking sprite

What next?

Seeing the animated sprite saying a dialog line made it all feel very “real”, inspiring me to continue with the demo.

The way I see it, there’s three logical places forward:

  1. Implement a dialog system and a conversation between two on-screen characters
  2. Implement player interaction with the stage; pick up item, use item.
  3. Implement the ability to move your character around the “stage” area, swapping between screens.

There’s probably more, but those three points feel like the next natural steps - so that’s what I’ll do!

With this in mind, I need to start thinking about a way to structure this game data better; we need a system that can describe scenes, items, characters and their various interactions. SCUMM did a good job of this; perhaps it’s a model I can explore along with more modern ideas.

Either way, I need to be mindful of the constraints in place when developing for the Spectrum.

I think the next few days I’ll scribble down a very small plot for a demo that involves a few different things. It won’t be a full game, but it’ll be enough of a demo to decide where we go from there.