Rooms get a workbench
Every room in this game is a text file: a grid of characters that is its own floor plan, plus a little metadata around the edges. The whole episodic model rests on that file being something a person can sit down and write in an evening, no tools required. We’d never actually tested that claim against a fresh set of eyes, so today we ran the experiment.
Good news: the format held up. Three new rooms, hand-typed straight from the spec, each picking a corner case no existing room used – a three-kid pack from one spawn instead of the usual one or two, two separate threats that both have to end up sealed away before the door opens, one threat split across two rooms behind two different doors. All three parsed, validated, and solved on the first attempt.
The bad news is what the experiment proved instead: typing a room is easy. Knowing whether it works is not. Every room ships with a proof that it’s solvable, and until today that proof meant writing a small program that walks a simulated person through the room and asserts they come out alive on the other side. That’s programming, not authoring, and it’s exactly the kind of gap that quietly kills a plan to ship new content “whenever it’s ready” – ready has to include someone other than a programmer being able to tell.
So we spent the rest of the day building the thing that closes it: a small program, separate from the game itself, that opens a room, lets you paint its floor plan and set its rules, and then – the actual point – lets you press one key and play it, live, against the exact simulation the shipped game runs. Not a preview. The real thing, with the real zombies doing the real zombie thing, in the room you painted a minute ago.
Notes from the build, since this devlog can’t resist confessing what its own tools caught:
- It’s a program, not a website. We went back and forth on hosting this somewhere and landed on no – it lives next to the game’s own code, reads and writes the same files a person would, and is gated by nothing more exotic than having a copy of the project. Trying an idea is editing a file; keeping it is saving one. No new door to build.
- It borrows the game’s actual look, not a sketch of it. The sitter and the kids chasing her are drawn with the exact same from-scratch pixel-art generator the shipped game uses, because a tool for testing whether a room feels right is worthless rendering a different game than the one people will play.
- It caught our own spec lying to us. Building narration-override editing meant reading the actual code that decides which override names are legal – which quietly disagreed with our own format documentation. One entry the code accepts was never written down; four the docs promised were legal have actually been rejected for a while, reserved for content that doesn’t exist yet. Nobody had hit it, because nobody had needed to type all twelve by hand before. Docs fixed, and there’s now a test that reads the real list instead of a copy of it.
- We ran out of function keys before we ran out of features. Save, browse, four flavors of resize, a visual filter, narration editing – most of the row was gone before undo/redo came asking for a slot. Undo got the shortcut everyone actually expects instead: the first thing in this tool that notices you’re holding another key down too.
What exists now, from one sitting: paint a room and its cosmetic dressing, set its objective and its threats, undo any of it, save it back out as the same format the game already reads, and prove it works by playing it instead of writing a program that swears it does.
What we haven’t done: looked at it. Every check above is a machine confirming the thing runs without falling over – nobody has sat down, played a room in it, and confirmed the sitter looks like the sitter is supposed to. That’s the honest next step, and a much easier one to take now than it was this morning.