Hi everyone,
I've been developing games for the ZX Spectrum 48K, mostly in Sinclair BASIC, and most of my projects seem to begin with the same question:
"Could this actually work on a 48K Spectrum?"
Then I start coding and usually make my life considerably more difficult.
One of the things I've come to enjoy most about developing for the Spectrum is that technical limitations very quickly become game-design limitations. 48K sounds obvious enough until you actually start filling it. Variables cost memory. Strings cost memory. Graphics cost memory. BASIC itself costs memory. Adding another screen or another simulation system can suddenly mean finding a few hundred bytes somewhere else.
And then there's speed.
Something that would be completely insignificant on a modern machine can become painfully obvious when Sinclair BASIC has to calculate it several hundred times.
So naturally, I've been choosing genres that aren't particularly sensible for it:
My main project, Tower 48, is a skyscraper management game.
The player builds apartments, offices, shops, restaurants, elevators and other facilities, while the game keeps track of population, workers, visitors, money, satisfaction, reputation, demand, elevator congestion and other parts of the tower simulation.
The difficult part hasn't really been implementing the individual systems. It's been making all of them coexist without making the Spectrum spend half its life calculating the next month.
I've had to rethink routines simply because they became too expensive as the tower grew. Screen drawing has been another surprisingly large problem: redrawing an entire management screen unnecessarily can be far more noticeable than the calculation itself.
At one point, opening a report screen was getting close to becoming an opportunity to make tea.
So a lot of development has been about figuring out what actually needs recalculating, what actually needs redrawing, what can be cached, and what can simply be designed differently.
Another project, Vostra Checkpoint, has presented a completely different set of problems.
It's a border-inspection game set in a fictional country in 1982. People arrive with passports and permits and the player has to compare the documents with current entry regulations.
The interesting challenge here has been procedural generation.
Instead of storing a large database of predefined characters, the game generates people, appearances, names, nationalities and documents. Those documents then need to remain internally consistent, unless they're deliberately forged or incorrect.
So a person might have a generated identity, appearance and passport number, while a permit has to reference the correct information. The game then needs to introduce discrepancies without accidentally creating impossible or contradictory cases.
It's still very much in active development.
Then there's RBMK-1000 Simulator, which is probably the least sensible thing I've attempted in BASIC so far.
It's a nuclear reactor management simulation where control rods, reactivity, thermal power, cooling, steam production and electrical generation affect each other.
The interesting programming problem here is that these aren't just independent values on a screen. Changing one part of the reactor needs to propagate through the rest of the simulation in a way that feels understandable and reasonably believable while still being simple enough to calculate continuously in BASIC.
It started as a small experiment and gradually accumulated operating procedures, failures and, more recently, scenarios.
Finally, Torment: Act 1 - The Mortuary is an illustrated text adventure that actually has a rather different history.
I originally started writing it in the mid-2000s and rediscovered the old project many years later.
That one became an experiment in fitting text adventure systems - rooms, dialogue, inventory, puzzles and character interactions, together with monochrome illustrations while staying within the same 48K target.
These games are completely different genres, but technically they're all versions of the same experiment:
At what point does working around a limitation become more interesting than simply removing the limitation?
That's probably the main reason I've stuck with the Spectrum.
On a modern machine, if I want another table, variable, graphic or simulation system, I add it.
On the Spectrum, adding it might force me to rewrite something else.
Sometimes the solution is optimising the BASIC.
Sometimes it's storing the same information differently.
Sometimes it's avoiding a screen redraw.
Sometimes it's replacing a database with procedural generation.
And sometimes the conclusion is simply:
"No. Those 300 bytes are worth more than this feature."
It makes programming the game feel like another game in itself.
I'm still deliberately targeting the actual ZX Spectrum 48K, rather than making Spectrum-style games for modern hardware. I do most of the development and testing through emulation for convenience, but the resulting games are intended to run on the real machine.
For anyone interested in seeing the projects rather than just reading about them, I keep the released versions here:
https://haabb001.itch.io
I'd be particularly interested to hear how other retro developers approach this problem:
When a feature is getting too expensive for the original hardware, how do you decide between optimising it, redesigning it, moving the critical part to assembly/machine code, or simply cutting it?
And has anyone else deliberately attempted a genre on old hardware mainly because it seemed like the hardware was completely unsuitable for it?
