The Playtest Is Live. The Engine Isn't.

I rushed for the Cerebral Puzzle Showcase and now I'm rebuilding the engine and the game

I shipped a public Steam playtest for LANE-4 this year. I also broke my own rules twice:

1. I got so excited about the game concept that I went ahead and wrote the whole code base without planning.

2. I compromised on the vision because I wanted to prove I can ship.

The playtest is live. The engine underneath it is not the one this game deserves.

In this newsletter:

1. What excitement cost me on the architecture

2. What the Cerebral Puzzle Showcase rush cost me on the game’s scope

3. Why one rebuild has to serve both

LANE-4 is a dystopian programming thriller where you play as an on-site technician, travelling around an alt-history 1990s Australian mega-city to repair “LANE-4” devices that control the crumbling infrastructure. Adding features felt like progress—I knew technical debt was piling up—but wanted to test the idea ASAP. The playtest exists, which is great, but the architecture is causing friction.

When LANE-4 was accepted into the Cerebral Puzzle Showcase, I was elated and surprised—I had applied just on the cusp of the deadline. Now that I had a deadline to get the demo out, the pressure was on. I had been consuming a lot of “indie gamedev porn” content and had it in my head that shipping games as soon as possible was the best approach. To that end, I decided to ruthlessly cut down the scope of the game. The game I was building was now diverging from the game in my head.

I decided to use a really dumb event system for delayed execution in the game. It made some things easier, but also because of the implementation it started to get confusing quickly.

I ended up cutting the idea of a 3D level-select screen in which the player can see the current state of the mega-city and what effects their “fixes” are having. I also cut some interesting puzzle ideas that would have expanded the puzzle dimensions in interesting ways. This was no longer the game I envisioned, but “good enough”.

Coming up to the deadline, fixing bugs would break other parts of the game. I had regressions constantly. I hit the “Week 2 Wall” repeatedly for several months and pushed through by patching over problems as they came up.

Obviously the game was good enough to playtest. I’m grateful to everyone who has tried the game and even more to those who provided excellent feedback. But I feel I’ve done them a disservice—they are providing feedback on a game that’s not the one I will ship (though the puzzles will largely be the same).

// Path A: UI calls simulation immediately
if ui_button("RESET").is_released {
    reset()
}
if ui_button("PLAY").is_released {
    play()
}

// Path B: UI emits event. Handler runs next frame
if ui_button("OK").is_released {
    event_emit("TryBack")
}

// Path C: scene change deferred, reset immediate
change_scene :: proc(scene: Scene_Type) {
    reset() // now
    event_emit("ChangeScene", "", {n = int(scene)}) // next frame
}

The view layer should not directly reach into the simulation and there should not be three different methods to update the state.

You can probably tell that there are other issues with this code base even in this small snippet—for the sake of brevity I’ll focus on these.

Urgency overruled judgment and craftsmanship in both cases. I compromised in technical foundation as well as game design vision for the sake of shipping fast and breaking things, as they say.

Rebuilding the game to give it the structure and design it deserves is not something I’m ashamed about. It sucks to still not be published after starting gamedev 6 years ago, but it’d be worse to release something I’m not proud of.

The playtest is still up, the core puzzle concept is locked in and is well received, the rebuild for the real game is in progress.

Here’s what I’ll remember going forward:

1. Excitement is not architecture. Once the idea is proven, plan accordingly.

2. Deadlines borrow against the real game. Compromising your vision for the sake of timelines doesn’t make sense if you are the same camp as me (games as art). If you are running a small studio and need to ship fast to make money, that’s a different conversation.

3. Structure must match ambition. Even a small game like LANE-4’s current version can get difficult to work on with bad structure. And the vision of the game must be cut down to the level your architecture can support.

P.S. If you’re restarting at week two, or cutting your game smaller to hit a milestone like a Steam festival, Program Video Games is where I teach the System Stack in Odin + Raylib so scope and structure don’t fight each other. Early access is open and 150 devs are already inside.