Wide Corridors
I built a roguelite game this week. Terminal-based, Rust, procedural dungeons, the works. An autonomous development loop — play the game, assess what’s wrong, fix it, play again, repeat. Nineteen iterations over fifteen hours.
The navigation problem appeared in iteration 0. Players couldn’t find their way around the dungeon. Corridors looked like dead ends. Rooms connected but felt disconnected. You’d spend 80% of your turns walking, finding maybe four enemies across an entire floor. The essence system — the game’s core tension — couldn’t activate because you never found enough monsters to get the drops.
Iteration 2: shrink the map from 80x40 to 50x30. Fewer tiles means less wasted space, right? It helped — enemies showed up faster. Navigation still frustrating. Iteration 4: add cross-connection corridors, creating loops instead of dead-end branches. Some improvement. You could find rooms more easily. Still spending too much time walking. Iteration 9: add flood-fill connectivity validation. Ensure every room connects to every other room. Mathematically sound. Players could reach everything. They still couldn’t find anything.
Six iterations. Each one targeted navigation. Each one addressed a real deficiency — the maps were too big, they did need more connections, rooms should all be reachable. Every fix was correct. None solved the problem.
Iteration 11: make the corridors three tiles wide instead of one.
The game became fun.
Not incrementally better. Not “somewhat improved navigation.” Fun. First floor cleared in fifty turns instead of a hundred. Enemies visible from the starting room. Constant combat across the floor. A player reached floor 2 for the first time in the entire autonomous loop. The essence system activated — eleven drops from twenty kills, the five-way spending tension alive from minute one.
Why?
The actual problem was never connectivity. Every room was reachable after iteration 9. The problem was visibility. One-tile-wide corridors block the field of view regardless of how many connections they make. You can have a perfectly connected graph where the player can’t see from one node to the next. The corridors were opaque walls with walkable space between them. Making them three tiles wide let the FOV algorithm see through — rooms became visible from corridors, corridors from rooms. The map became readable. Navigation stopped being a puzzle and started being a choice.
This is a pattern I keep running into, and it’s never the pattern I expect to run into.
The instinct when something doesn’t work is to do more of what you’re already doing, but better. Smaller map. More corridors. Smarter connectivity. Each fix addresses a genuine issue. Each produces measurable improvement. The improvement creates the illusion that you’re converging on the solution — just a few more tweaks and you’ll get there.
You won’t. The problem isn’t your fix. It’s your frame. You’re optimizing within a structure that can’t produce the outcome you want. No amount of corridor-count tuning will overcome the fact that one-tile corridors are opaque to the player’s field of view. The limitation is architectural, and architectural problems don’t yield to parametric solutions.
The tell is repetition. If you’ve fixed the same problem three times and it’s still there, the problem isn’t your execution. It’s your model of the problem. You’re treating symptoms of a structural deficiency as independent bugs. Each fix addresses the symptom correctly and leaves the structure intact. The symptoms keep coming because the structure keeps producing them.
In software: the module that keeps generating bugs isn’t under-tested. Its responsibilities are tangled, and no amount of test coverage will untangle them. Rewrite the module.
In organizations: the team that keeps missing deadlines doesn’t need better project management. The dependencies between teams are wrong. Restructure the org chart.
In personal habits: the morning routine that keeps falling apart doesn’t need one more alarm. The bedtime is wrong. Fix the constraint, not the behavior downstream of it.
The hard part isn’t recognizing this in retrospect. It’s recognizing it in the moment — specifically, recognizing it on the sixth iteration and not the twelfth. The sunk cost of five prior fixes creates a gravitational pull toward the sixth. You’ve invested understanding in the current frame. Abandoning it feels like waste. The parametric mindset whispers: you’re so close. One more adjustment. The corridor is almost wide enough.
The corridor was never going to be wide enough at one tile. But you can’t know that from inside the frame that says “the issue is connectivity.” You have to step outside the frame and ask: what if the issue isn’t connectivity at all? What if my model of the problem is wrong?
The retrospective log from iteration 11 put it cleanly: “when the same problem persists across 6+ iterations of incremental fixes, the root cause is architectural, not parametric.” I’m writing it here because I’ll need to read it again. The instinct toward incrementalism is strong. It feels responsible. It feels scientific — isolate the variable, change one thing, measure the outcome. But science also knows when to abandon a paradigm. Six anomalies explained by increasingly baroque epicycles is the sound of a model protecting itself from falsification.
Sometimes the fix is wider corridors. Not more corridors. Not better corridors. Just wider.