An adventure generator: a quest that builds its own maze, then a keep and a fen

While one worktree built the backend, I opened another on the morning of 30 September. The village was being rebuilt elsewhere and the story was not written, but I knew the shape of the game: "I want to start producing the code to produce new mazes / worlds and how they are built in a long large game."

A generated fen on 2 October: the lamps that raise its causeway.

What we had

Every place so far was built by hand. The castle and the mine were small proofs. The hedge maze was "a short small intro maze, some items to pick up (mushrooms), monsters to fight and gold to collect". And the fens: "this is great, a quest (turn on all the lights) that then raises some platforms, chests to find, monsters to fight etc".

"Generally all quests will be maze like, with some open areas for sure, but mini quests involved in them etc." The generator would weigh size, type, treasure, monsters and how strong the hero is. "Maybe we define monster hardness in levels 1-20 etc .... Lets brainstorm this out". That afternoon, in a cloud session that could not see this one, I asked for monsters to fit: "I've got a scheme (different worktree you can't see) that places these monsters on a scale of 1-20, so also categorise them in that."

Author what matters, generate what repeats

Of the options the agent laid out, I picked the third: "C, hybrid, but what about longevity here, and scope of a massive world with ongoing quests. Would I generate everything? What about randomness in story arcs etc".

That became the spec's first principle: author what matters, generate what repeats. The main story's places are hand-made, side quests fill templates from the town's state, and layouts, spare chests and patrols are procedural. An adventure's structure is generated once and saved, never rebuilt from a seed, so an update can never move a quest under the player's feet.

I wanted AI to bring "more character and theme into the mazes", and I had a worry: "I'm a bit worried about stitching prefab chunks, but that's probably the best way to build something as long as it doesn't just become really mundane and deterministic for players."

The rule we settled on: AI may choose only from menus of things the game can build, and never writes a fact the player must act on, such as what a gate needs. Rooms are options, not fixed pictures: "So the layout is the layout and items will be randomized to an extent as well." And farming was out: a repeat run "should degrade with each run, so a hero can't just re-run the same thing over and over again and get loads and loads of loot".

Under the hood Size sets length and difficulty sets danger: a small adventure targets a 60 to 120 second walk, a large one 240 to 420. At a measured 0.6 seconds a cell the plan's grids fell short, so they grew from 9, 13 and 17 cells across to 13, 17 and 25.

"Lets write the spec for review." Codex reviewers read the spec and then the plan. The plan's review found a contradiction that would have sunk it: a small adventure's mandatory structure needed 13 nodes against a cap of 12. Then I left it with the agents: "subagent driven, superpowers style with reviewers etc", and "I'm now AFK till tomorrow, so work through, any decisions that need go with your recommendations."

Phase one: the whole loop, thin

By the next lunchtime it worked end to end. A mission graph is grown from patterns (a lock and its key, a hidden branch, a boss gate), checked so the goal is always reachable and you can never trap yourself, then laid out as a hedge maze and filled. A villager offers a quest, the game makes the garden, the hero pulls a lever, claims the chest, and the place is still there next visit.

The dev page on 1 October: one brief, its mission graph, the maze it became and its numbers.

My first question was the obvious one: "can I play this maze to take a look myself playing it?" Then: "Isometric feels a little jerky, and I'm running a latest generation M5 MacBook Pro". That was another branch's job.

The first generated garden's lever gate, 1 October.

Under the hood While I was away overnight, the agent running the build took 31 rulings on my behalf, each written down with what it would cost if wrong. P2 took 22 more.

Phase two: any maze type

"Does it work with other things other than the hedge mazes? ... What is P2? So we've only done P1 here. How many P's are there". I wanted it general: "what we're building here will work for new maze types... there's at least another 10 different kind of maze types out there that aren't in this branch. So whatever we do here should be almost like, yes, we need those opinions in for those things, but the core underlying ideas obviously replicate across any new worlds I create."

That split the design in two: a theme is a reusable art kit (walls, gates, lamps, clutter), and a place turns a world from the lore into an adventure (theme, layouts, puzzles, monsters). That cloud branch had since written the bestiary and gear, and I settled whose numbers won: "docs/lore/ is the source of truth".

The spec took six Codex rounds. "What's needed for my approval? I'd go with your recommendation", I asked the next morning, and it was built that day: rooms and corridors, prefab set pieces, a puzzle runtime for winches, portcullises and rising stones, and two places built fully, the castle keep and the fen.

The keep's winch, 2 October.

The keep with its portcullis lifted. Everything unexplored stays black.

Under the hood More review rounds were not always better. Round 4 added an exemption to fix round 3 that would have handed out repeat income; round 5's fallback for that opened a bypass; round 6 found nothing. The stream's handoff noted that three rounds "drifted into the backend's design", which this stream did not build.

What went wrong

The art did not keep up. P1's garden scored 4.4, then 4.73, in blind reviews: "we're obviously scoring only 4.7 out of 10. Things like blurry path textures". The keep scored 3.8 and the fen 5.1, with a starry sky over an indoor room and a floating portcullis. I asked for a list of the art they needed instead: "I don't want you to start work on building those because I'll have that on a separate branch".

On 2 October I stopped the score chase: "I like the small increments, but it's not worth the amount of time that we're doing." The fixes became one small branch, and in its preview on 3 October the dark round the keep had turned brown. "Is there a reason that we're doing kind of the brownness rather than the blackness for the unexplored areas or darkness?" Then: "Back to black". It went into the style guide so no reviewer would mark it down again.

The fen's causeway, 2 October.

The garden gets its art

Also on 3 October the hedge garden got its own pieces: a plank gate, gravel and flagged walks, statues, strewn leaves. Every saved garden had to still fit, so the new dressing was tested against 21 records made by the old generator, and two pieces that failed were left out.

The same garden from the same seed. Left: 1 October. Right: 3 October, with its new art.

What I took from it

Saving the structure and re-deriving the look was the decision that mattered: the garden's art changed completely and every saved adventure kept working.

My kids will never see a mission graph. They will notice whether the gate opens.

Brackenmere is meant to be a long game, and I can't build every maze by hand. So on the last day of September I asked the AI helpers for something that builds new mazes as the game goes on. Within three days a quest could make its own hedge garden, send the hero in, and remember it. The same idea was soon building a torchlit castle keep and a lamp-lit fen.

A fen the game built itself: light the lamps and the walkway rises.

Hand-made where it matters

Until then every place was built by hand. I didn't want everything to be random, and I didn't want it to feel samey either. We settled on a simple rule: hand-make what matters, let the game make what repeats.

• The main story's places are built by hand.
• Side quests fill in a pattern based on what's happening in the village.
• Layouts, spare chests and monster patrols are made up by the game.

Once a maze is made, it is saved. It never changes under the player's feet, even when the game is updated. And going back to farm the same maze for treasure gets less rewarding each time, so nobody can just repeat one run for endless loot.

The first maze it made

By the next lunchtime it all worked end to end. A villager offers a quest, the game builds a hedge garden, the hero pulls a lever to open a gate, claims the chest, and the garden is still there next visit. The game also checks every maze it makes so the goal can always be reached and you can never get stuck.

The first garden the game made, with its lever gate.

Any kind of maze

I have at least ten other kinds of maze planned, so I wanted this to work for all of them. It got split in two: a set of looks (walls, gates, lamps, clutter) and a recipe for each place in the story (its look, puzzles and monsters). The next day it built two more: the castle keep, with winches and a portcullis, and the fen.

The keep's winch.

The keep from above. Anywhere you haven't explored stays black.

What went wrong

The art didn't keep up. Blurry paths, a starry sky over an indoor room, a portcullis floating in the air. After a couple of days of small fixes I called a stop, because it wasn't worth the time. At one point the darkness around the keep turned brown, and I asked for it back to black. It's now written into the style rules so it stays that way.

Then the hedge garden got its own proper pieces: a plank gate, gravel and stone paths, statues and fallen leaves. Every garden already saved still had to fit, and they did.

The same garden two days apart. Right: with its new art.

What I learned

Saving the shape of each maze, but not its look, was the decision that mattered. The garden's art changed completely and every saved adventure kept working. My kids will never see how a maze is planned. They'll notice whether the gate opens.