←All posts

The Tavern That Became a Warehouse

A location invented during play was overwritten one turn after the player walked into it

4 min read
playtesting
game-systems
architecture
midnight-cargo

A playtester spent five messages arguing with the DM about a door. They had walked into a tavern called The Iron Hearth. Out of character, the DM kept telling them they were standing somewhere else. The turn counter did not move the whole time.

I assumed the DM channel was at fault, because it was the part doing the arguing. When I traced the session, the DM was the last thing to go wrong. The game had lost the player's position several turns earlier, and the DM was reconstructing it from the last few paragraphs of story.

One Turn Later

The Iron Hearth did not exist before that session. The narrator introduced it mid-scene, and the game handled that correctly. It recorded the tavern as a real place, connected it to the street outside, and moved the player in.

On the next turn a separate position check ran. It compared the player's location against the list of places I had authored for Midnight Cargo. The tavern was absent from that list, so the check treated the position as corrupt and replaced it with Warehouse Twelve.

The screen still said The Iron Hearth. Underneath, the player was assigned to a different building. Every system that read the position after that got a different answer depending on which field it looked at.

Two Rules Reversing Each Other

Then the player tried to leave. Months earlier I had written a shortcut that marked the player as outside as soon as an action sounded like leaving, before the story had resolved anything. It changed that one flag and left the building untouched.

The position check then saw a player marked outside while assigned to an indoor location, and put them back inside. Both rules were mine, and they reversed each other every turn.

The Ask the DM channel made the damage visible. It was given the name of the location and no statement of whether the player was indoors. It filled the gap from recent story text and answered with full confidence.

What I Changed

I replaced the separate checks with one lookup that answers whether a place exists, what it is called, and whether it is indoors. Authored places and places created during play go through the same lookup. Everything that reads or checks position uses it.

The leaving shortcut is gone. The player stays where they are until a move resolves, and a resolved move updates every position field together.

I now hand Ask the DM the position as a fact from game state and tell it to repeat that as given. I also tell it to make no claims about doors or locks, because the game does not track them. If a player asks whether the door is shut, the correct answer is that they are inside and nobody recorded the door.

The Tests Stopped One Turn Early

I had already written tests for this feature. They covered discovering a new place and walking into it, and they stopped there. The bug lived on the following turn, so the suite was green while the feature was broken in play.

The new tests replay the full incident with an invented tavern. The player finds it, enters, saves, reloads, takes a turn, leaves, takes another turn, and asks the DM where they are. Against the old code those tests fail with the same wrong warehouse the playtest produced.

My first version of the repair was wrong too. It sent any player with an unrecognised position back to the Midnight Cargo docks, including a player who had sailed to another city. A review of the change caught that before release. The repair now applies only inside the scenario's own region, and that case has its own test.

What Is Still Open

I did not build a door system. Tracking every hinge in the world to settle one argument is a bad trade.

One behaviour needs watching in the next playtest. If the narrator describes the player leaving and the game does not register the move, the player still counts as inside until the next move lands.

The save from the original session still holds two conflicting locations. I have not repaired it automatically, because nothing in the data says which one is true.

A place the narrator invents becomes a fact of game state the moment the game accepts it. Every system that reads position has to treat it as one.