Astrofix: postmortem

Four months of pushing crates into holes. The teleporter that broke my 'level editor', the forum that shaped the game, and learning to be content with imperfection.

Contents
  1. 01 The teleporter that broke the parser
  2. 02 The forum shaped the project
  3. 03 The vortex (and being OK with imperfection)
  4. 04 On Sokoban
  5. 05 What “done” felt like
  6. 06 A hypothetical revisit
The Astrofix title card. Cyan glowing letters on a starfield background.

A look back at Astrofix, my second Godot project (after The game within, which was a 9-day jam). This one was a little different: it took four months on and off, there was no external deadline, and a lot more give-and-take with people on the Godot Forum. The level count tripled from what I’d originally planned to ship. The image-based level editor I started with didn’t survive contact with teleporters. And I picked up a few things about shipping in public that I think I will never forget. Not bad for a self-imposed game jam.

The teleporter that broke the parser

Animated GIF showing the teleporter mechanic. The player steps onto an up-arrow tile on one grid and exits at a down-arrow tile on another.
Animated GIF showing the teleporter mechanic. The player steps onto an up-arrow tile on one grid and exits at a down-arrow tile on another.

I started with a setup where I parsed levels from images. Each pixel was a grid cell, each colour a tile type. It was fast. I could draw a level in Aseprite in a whim and have it show up in game within seconds.

It worked for ten levels. Then I tried to add teleporters.

One pair of teleporters is fine: pick a colour, link them and stay consistent. But what if you want two pairs? Three? How does the parser know which yellow links to which yellow? You can keep adding colour combinations, but it’s a brittle direction (and a fast-shrinking one). I realised I had to rethink the process.

The Godot Forum’s answer was, gently and rightly, just use the editor (the thread is here). Tilemaps for the grid, custom tileset metadata for tile properties, scene-as-tile for interactive things. I rebuilt around that, and added the command pattern for clean undo while I was at it (so adding new mechanics later wouldn’t mean rewriting the player controller for the third time).

The rebuild was faster than I expected. There’s a real lesson in there: building something you’ve already figured out is so much faster than figuring it out as you build. The first version is exploratory and slow. The rewrite is just typing and optimising.

Switching to engine-native tools was honestly fine. The image workflow was faster (drawing in Aseprite beats clicking tiles in any editor, and linking up the teleporters), but tilemaps were way more powerful. A good trade, a bit of speed, for a bit of power.

The forum shaped the project

Astrofix was the first non-jam thing I’d shipped, and the release thread on the Godot Forum was the first time I’d put a project in front of strangers during development. The lesson I keep coming back to is simple, and I’d tell it to anyone in the same spot: get people playing or critising your game much earlier. Much, much earlier.

yesko pointed out things players didn’t get (such as controls, goals and level cohesion). grulps caught mechanical issues (such as input queueing, camera framinga and puzzles that weren’t surprising enough). The first version had no undo, no menu, no movement queueing, no end-game screen, an audio bug after seven levels, and isolated puzzle segments that read more like exercises than levels. Weeks of patches followed, almost all of it from people I’d never met.

What’s interesting in retrospect is that the mechanics didn’t really change. You still push boxes, plug holes and have three undos. The forum’s contribution was almost entirely the layer around the mechanics, the finesse: onboarding, polish, quality-of-life, the pause menu, world-specific backgrounds, the icons and counters in the HUD. That layer turns out to be most of the experience.

It’s a niche puzzle game, but I’d argue it’s pretty polished for a second project. I’d also argue that almost none of that polish would have happened without the forum. (Sincerely, thank you, to everyone who took the time 🙌.)

One of the levels is shaped as a heart.
One of the levels is shaped as a heart.

The vortex (and being OK with imperfection)

The background was supposed to look like flurries of stars being sucked into a black hole at the centre of the screen. I asked for help on GPUParticles2D, and mac_deth suggested switching to 3D and using a particle attractor. I gave that a try but couldn’t get that to work, so I stayed in 2D and kept poking at it instead.

What I eventually landed on: I played with different accelerations until I had a single spawn area outside the screen swirling inwards. Then I duplicated it three times, rotated, to get something that reads like four spiral arms feeding the centre. It’s not 100% of what I envisioned, but it sold the impression I was after. That’s the thing I keep relearning. If the effect lands, the method doesn’t have to be exactly matching the one in your head.

There’s still a brief startup hang on each level load and on the initial game load (since the menu also uses the background) that I’m guessing is GPU particle warmup time. I never investigated properly. It’s a gut feeling. But it is what it is now.

On Sokoban

During development, somebody on the forum pointed out Astrofix was a bit like Sokoban. I’d never heard of Sokoban (which is, in hindsight, a little embarrassing for someone who’d spent four months building one).

Reading up on it didn’t change my design decisions, but it did give me a source of inspiration to look at for level ideas. The constraints, the kinds of thinking the puzzles ask for, the way good levels teach the mechanic without telling you they are. Designing puzzle-game levels turns out to be really fucking hard. (I would say I underestimated this, but the truth is I didn’t realise this at all going in.)

What “done” felt like

I kept adding to Astrofix past the point I’d originally called done. The first version had ten levels and almost nothing around them. By December it had three worlds, ten levels each, a new mechanic per world (teleporters in two, one-way tiles in three), a menu, a HUD, audio, reworked graphics and more. It had stopped feeling like a prototype and started feeling like a small but actual game.

And then, honestly, I lost interest. Not in a bad way. Just the way a project ends when you’ve solved the problems you wanted to solve and the next thing has started to glow. December felt like the right moment to move on.

That’s what done turned out to mean for me on this one: original scope long behind, the structure I’d hoped for in place, and the energy quietly moved elsewhere.

A hypothetical revisit

I probably won’t come back to Astrofix. But if I did:

I’d make it 3D, to make it visually richer (the vortex might actually work properly, for one thing).

Mobile, with touch controls. The game suits mobile and I never built for it.

Way more juice. Movement and pushing both need more oomph: shake, sound, a tiny pause, something that makes each action feel like it lands.

More mechanics, though here’s the catch. With a grid game like this, you’re genuinely limited. You can stack new tile types and new interactions, but the underlying design space is small. That’s part of what made it hard, and part of what made the levels-are-difficult realisation hit so hard.

For a second project with no external deadline and a lot of public iteration, I’m content with where Astrofix landed. I’d give the image-based level editor more thought before committing to it again. But honestly, this is game dev: learning, making mistakes, sometimes landing on something that works, and figuring out the rest along the way. I’d do it differently next time, and I’m glad I did it this way this time.