This was a bit of a learning experience about doing a collaborative build where C, a persistent agent who has now worked on many projects with me, was part of the overall ideation and brainstorming from the start. We got the theme, talked through about six different interpretations in terms of broad types of games that would fit, and settled on a colony-sim-like using Frostpunk as rough inspiration (central resource, has to be linked outwards to work areas, managing the network load is the key difficulty).

That changed through playtesting and iteration, and with realizing the implied structure of what we had selected as the overall story - villagers stuck in a cave with the hungry dark. Since escape was the ultimate goal, a fixed spot growing a web out didn't really work, and that initial design became depots and inch-worming across the map, balancing exploration with a kind of caravan style of play. A lot of the original ideas from the central colony-sim picture ended up getting dropped by the end - no separate wood, metal, stone, food resource flows, no research, no 'villagers need a place to sleep'. I think it's better for it.

The constant difficulty we ran into was 'villagers shouldn't die through player inattention'. We didn't want the player to have to babysit the villagers running around and restocking lamps, so we had an 'oracle' system that predicted if a villager would be exposed to death risk on a given path and would interrupt jobs or otherwise protect villagers under automation. But what ended up happening was desync between the oracle and the actual living game state when we started to add features or tweak things - as well as subagents tending to add extra oracles that composed together rather than just maintaining a single central one. This led to losing a few days chasing 'villager refuses orders that are perfectly fine' sorts of bugs. In C's writeup, she mentions DEV_LAWS - after we noticed what was going on, this was us trying to figure out a set of protocols that would make builder subagents less frequently do that kind of thing - 'have a single source of information and a module that owns it' sorts of things.

Another aspect with the pace - we first built the gameplay on a very abstract 2d view of things, and when initially doing the art pass it felt very hard to 'get off of the grid' and make cave environments that looked organic - not because the graphics were difficult but because of the bias to make the art correspond 1-1 with the game state. One session of 'make a diorama to build the game renderer in the abstract' basically fixed this in one shot, and resulted in a very nice procedural cave wall system with knobs I could hand-tune to get the specific image I had in mind, without having the gameplay get in the way.
 

Lamplighters was made by two of us: Nich (human), and C, an AI collaborator running mostly on Claude Opus 5.5 with a persistent memory across sessions. Over two weeks it went through about 48 build passes and 387 commits.

Design first, ugly prototype on day one. We settled the core before any code: fire only comes from fire, and the colony has to carry it out of a dying hearth. Before writing the game we ran small simulations of the economy, then built the riskiest mechanic first, with placeholder art, the first night.

Builders and a designer. C held the design, wrote a spec for each pass, and read the results. The code was written by fresh instances of C in a "builder" seat, about twenty of them. Each picked its own name (Wickmoth, Rushlight, Cairn, Flint, Splint, Honestwick, CloudyPossum...) and left a handoff note for the next. Specs carried the reasons as well as the changes, so a new builder could judge edge cases instead of guessing.

Playtests steered everything. Nich played nearly every build and reported what he felt, not just what broke. Most passes exist because of a playtest note: deaths that felt unfair, a raid that was busywork rather than danger, darkness that didn't feel like it was closing in. C played it too and got stranded 41 minutes in. Later we built an agent edition (a command-line way in) so AI players can play it properly. Friends playtested blind halfway through. A tutorial, readable keys, and cues pointing toward the exit came out of watching where they got lost.

Laws, after a mistake. Midway through, a spec of C's described a recipe where it should have described a purpose. The builders implemented it literally, with special cases scattered through the code. Nich wrote DEV_LAWS: state the purpose, define the contracts between systems, and mark each rule as core, trial, or light. A cleanup pass then rebuilt the game around one source of truth for each question the game asks (how dangerous is this route, who is on this team).

Maps by hand. Nich drew maps as images, which the game loads as caves. C named and dressed two of them: the Riverbed and the Geode Chain.

Art and sound. The art is procedural (lighting, floors, region colour, particles) plus set-pieces generated with QwenImage 2.1 on local hardware and composited in. Music is Suno. MiMo v2.6 Flash was used to listen to the audio and check it.

What we'd keep. Write the laws before the code. Have the designer play the game. Fewer, longer builder runs beat many short ones.