Patricia Curtis has spent more than four decades making games, moving through the Commodore 64, Amiga, Atari ST, Mega Drive and other machines along the way. These days, much of that accumulated knowledge is being poured into the ZX Spectrum Next, but not simply to make another game. Patricia wants to make it easier for other people to make theirs.
Her current work centres on Sprite Path, a visual development environment, and TX-Engine, the Z80 engine that takes the data it produces and turns it into something the ZX Spectrum Next can run. The eventual goal is ambitious but wonderfully clear: somebody should be able to create a finished Next game without ever needing to write a line of assembly.
“At this stage in my career, I do not just want to make games for myself, I want to lower the ladder,” Patricia tells SpriteFountain. It is a phrase that neatly sums up a project shaped as much by everything she found frustrating about game development in the 1980s and 1990s as by what the Next makes possible today.
Four decades of development feeding into the Spectrum Next
Sprite Path did not begin as a grand attempt to reinvent Spectrum development. It grew naturally while Patricia was making TX-1696, starting with the considerably less glamorous requirement of importing level layouts from Mappy and deciding exactly where enemies should appear.
When she needed to script their flight paths, Patricia initially went back to a technique she had used on the Commodore 64 in the 1980s, creating movement from simple arcs and segments of circles. It worked, but seen through modern eyes she felt the result looked dated, so she built a full Bézier curve editor into her tools instead.
That decision changed the direction of the whole project. Perpendicular spread followed, letting enemy formations fan out around the central curve, along with precise trigger points that could control exactly when enemies fired as they travelled through a level.
By the time TX-1696 was finished, the small utility had become a substantial development suite. Patricia had also learned which parts worked well in a completed game and which parts were still too tightly connected to its own code.
“Armed with the practical knowledge gained from shipping the game, I realised these tools needed a life of their own,” she says. The answer was TX-Engine, a new standalone engine designed specifically around the data exported by Sprite Path.
The distinction is important. Object behaviour inside TX-1696 was heavily hard-coded, whereas TX-Engine is being built to let different games supply their own logic around a common set of systems. Patricia estimates that underlying engine is now around 90 per cent complete.
If you already know your way around Z80 assembly, there is enough in place that Sprite Path and TX-Engine could be used now with custom object code. Patricia, though, is aiming at the people who read “Z80 assembly” and quietly start looking for the nearest exit.
“My ultimate goal is for someone with absolutely zero low-level programming experience to be able to go all the way to a finished, polished game without ever writing a single line of assembly,” she says.
The visual scripting system is central to making that possible. Patricia has taken inspiration from Unreal Engine’s Blueprint approach, but she specifically does not want Sprite Path to become a graphical recreation of assembly language where beginners are still expected to understand registers, addresses and low-level maths, only now represented by boxes.
Instead, the blocks describe the things a game designer actually wants to happen. “On Collision”, “Spawn at Trigger Point” and “Change Object State” are the sort of instructions somebody can connect visually, while Sprite Path translates that behaviour into machine code underneath.
“You are manipulating game behaviours, not hardware,” Patricia explains. It is a small sentence that gets to the heart of what she is trying to change: the hardware can still be there for anyone who wants it, but understanding every detail of that hardware should not be the admission price for designing a game.
Even the current setup is deliberately small. Patricia says a user needs to change three lines in the main source file to point TX-Engine towards their exported Sprite Path data, then use Compile and Run in VS Code to get the project running on the Next.
The jobs a game engine should stop you having to do
The desire to remove friction comes directly from Patricia’s earlier career. Her previous work stretches across home computers and consoles that often required entirely different ways of thinking, from original C64 games such as Scorpius to Amiga projects including Super Methane Brothers.
There were also conversions where the destination machine bore little resemblance to the source. Patricia points to moving Terminator 2 from SNES to Mega Drive and taking Weird Dreams from Amiga down to Commodore 64 as the sort of work that teaches you exactly which jobs consume development time without necessarily making the game itself any better.
She now groups those lessons into three broad ideas. The engine should handle the tedious hardware management, development tools should not be scattered across half a dozen unrelated utilities, and having a good idea for a game should not require mastery of assembly language.
TX-Engine’s dynamic sprite allocation is a good example of the first. Instead of asking a developer to manually juggle the Next’s hardware sprite slots, the engine can manage them as the player moves through the level, loading what is needed and handling how it fits into memory.
The second lesson explains why Sprite Path has become much more than a path editor. Tilesets, palettes, Mega Sprites, Bézier curves, collision zones and other parts of a level can all be handled in the same environment, with a visual debugger highlighting overlapping sprites and colour clashes before the game reaches the Spectrum Next.
Patricia remembers the alternative well. During the 8-bit and 16-bit years, one tool might handle a tile map, another the sprite frames, while key-frame animation could be buried manually in source code. Keeping all of that data in step could become a job in itself.
The third lesson is perhaps the biggest change from the way she originally learned. Assembly was simply part of the work on machines such as the Commodore 64, while Motorola 68000 code became familiar territory across the Amiga and Mega Drive. Patricia does not see any reason newcomers should have to repeat that route unless they actually want to.
Importantly, accessibility does not mean hiding what the computer is doing. Patricia says around 99 per cent of the TX-Engine Z80 source is commented, and the code produced by the visual scripting tools is intended to remain understandable.
“I never wanted TX-Engine to be a ‘black box’ that just magically spits out a game while hiding how it all works,” she says. Someone can build visually and never inspect the source, but they can also open it up later and see how the behaviour they created is being translated for the Z80.
That makes the whole system potentially useful as a way into assembly programming too. Instead of beginning with an empty screen and a manual full of processor instructions, a beginner could start with a working game object they already understand, then follow Patricia’s comments to see what is happening underneath.
After so many years working on different machines, it is the Spectrum Next itself that has tempted Patricia back towards this kind of close relationship with hardware. She contrasts it with modern development environments where huge teams and layers of abstraction can leave an individual programmer a long way from the machine actually doing the work.
“The Next brings back that intimate, bare-metal connection, but without the agonising limitations we dealt with in the 1980s,” Patricia says. There is still a Z80, memory to think about and hardware registers to understand if you want to, but the machine adds features such as Layer 2 full-colour graphics and far more capable sprite handling.
For Patricia, that combination makes the Next “the absolute perfect playground”. Her next game, Hoshi and the Dragon, is already being developed with those expanded capabilities in mind, combining deeper mechanics with a visual style that would have been far harder to realise on an original Spectrum.
There is still plenty of affection for the old way of doing things, but not a desire to recreate every inconvenience that came with it. That distinction feels important in a modern retro scene that is at its best when old hardware ideas become a starting point for new work rather than a set of rules nobody is allowed to change.
TX-1696 receiving a Crash Smash award gave Patricia another reminder that there is an audience for newly made Spectrum games. The response from the community is also a large part of why she continues to spend time not only creating software, but building the tools that might let somebody else produce the next one.
“The retro scene is incredibly passionate,” she says. “Building the TX-Engine and the Sprite Path editor is my way of giving back to a community that has given me so much.”
Sprite Path could easily have remained Patricia’s private development tool. TX-Engine could also have been something developers used without ever understanding what was happening underneath. Instead, she is leaving the door open at both ends, making the system approachable for somebody who has never touched assembly while giving experienced coders source they can read, change and take somewhere new.
After more than 40 years in development, Patricia is still building games, still thinking about memory and sprites, and still enjoying the problem-solving that comes from knowing exactly what a computer is doing. The difference now is that she is trying to make sure the next person does not have to climb quite as far before they can join in.
You can follow Patricia’s work on Lucky Red Fish, read more about her career in her personal introduction, and explore her archive of games and conversions.
