What happened to SMEG?

Chances are that a bunch of people reading this post will remember SMEG. Either from the introduction blog entry, the posts on twitter, the itch.io page or maybe you even pre-alpha tested the demo I put out to a couple of insiders.

I originally started the project in November 2019 as a way of learning Z80 assembly and the ZX Spectrum hardware. I was (and still am) extremely excited by the idea - a point and click adventure game and system designed for the Speccy. I’ve always dreamed about making a point and click game based on Red Dwarf too (literally, it’s a childhood dream).

The game started to become pretty well developed as an advanced prototype/alpha into early/mid 2020. I commissioned some art assets (which suit it perfectly) and was rattling out some rooms and then… it stopped.

The reasons for the hard stop are numerous. The first is that I started seriously messing about with hardware. Restoring old micros, designing PCBs (I still need to blog about the TZX Cassette PCB), 3d printing and generally doing a bunch of the content that you can find on this blog. Working with hardware is a joy; it’s taking something out of the computer and into the real world. As a professional software developer by trade, this had a much bigger impact on me than I expected. Designing, building, touching, using - it’s all very different to software and very satisfying. Addictive, almost.

The next set of reasons are down to SMEG itself.

The Flaws

To recap, SMEG is an adventure game authoring system as well as being the rough title for the game itself. I set about making a system that others could use to make their own games; my intention was to ship my game and then release the source for others to enjoy. This was the first flaw.

Designing for others

Pretty early on I stated that I was going to release the source “at some point”. This lead to a small group of retro enthuiasts sending me aggressive demands that I release the source NOW so they could use it. I shrugged this off initially, but it got pretty tiresome after the 5th message. The majority of people were nice; but you always get one or two that like to spoil the party.

The biggest issue was that I spent a lot of time on creating a BASIC like scripting language for the system that was eventually chucked away. I did this originally to replace the crappy tcl-like language I was using to make my demos, but moved to BASIC as a way of attempting to be more inclusive to beginners.

This proved to be a huge mistake; I sunk a load of time into it and it was a lot harder to integrate than I expected. It was also non-obvious, and actually made development harder for me. So I ripped it out and deleted it. Probably about a month’s work gone. In hindsight, I should have just finished a bigger demo on my existing system and refined it as I went along.

Poor workflow

The biggest issue I faced was that my workflow was pretty horrible. I’d based everything around the Tiled Map Editor; having a room in a single map with tile layers, object layers and scripts entered as properties on these. This was fine for a couple of levels, but when scaling it up to 9 rooms for the first demo it became pretty hard going.

For a start, having convention-based properties was a source of error. Having free-text boxes for scripts was a source of error. The rooms in standalone maps was a source of error, as I often needed “global” objects (inventory, characters, scripts) that ended up living in a json file that tied all the stuff together.

Don’t get me wrong, Tiled is a great editor and I’ve used it a tonne in the past, but it just isn’t a great fit for what I’m trying to do here. Adding content became annoying; it just didn’t scale well from a 3 room prototype to a 9 or 12 room bigger demo.

I’ve been playing with LDtk and it’s got some real strengths around object definition and map editing but again will fall down on things like dialog editing.

The problem is that I don’t know what would be a good fit, except for a custom editor. I’ve got dialog, rooms, objects, inventory, characters - all of which need to be placed and scripted together to make a game.

Early shortcuts

Call it technical debt, call it bodges - but the early shortcuts I took in the SMEG engine are haunting me now. Examples such as not being able to define animations well and foreground redraw/layering are real pains to implement. As time got more scarce the use of Z80 assembly made a lot of this slow to work with.

Some of the main characters (Dave) are still bodged in; this is evident in the way that I can’t truly data drive parts I want to; things still have specific bodges I work around. To do it all properly I’ll need to implement a first class animation system and use a nicer way of dynamically managing memory.

I also need to completely redo the background/foreground rendering of a scene to handle depth properly. The thing is, to do this requires a fair rework of a lot of the tools and engine code.

So what is it?

I’ve never seen one, no-one has, but I’m guessing it’s a… white hole?

In short, there’s a lot of work ahead and I lost the energy to work on it; primarily because of the setbacks with the BASIC language that I had to throw away and complete annoyance with the workflow.

All that said, I’m still very fond of the project and it irks me that I haven’t taken it over the line to something slightly bigger. As time goes on I’m feeling more inclined to pick it up and work on it again.

I’m not sure what that would look like; perhaps throw away the existing tools and pipeline and start afresh with a fixed up engine. Much of that Z80 code is worth keeping and can likely be bashed into shape.

So what is it?