One of the less glamorous lessons of building The Last Cartographer is that a game can become large enough that editing the game becomes its own game.
The fastest way to build eighty rooms is not to become faster at typing coordinates. It is to build better tools.
There are rooms, hotspots, blockers, exits, inspect areas, NPCs, paths, dialogue, objects, clues and dozens of small state changes. At some point, changing coordinates by hand stops being a reasonable workflow.
That is why the Dev Workshop has become such a major part of development. I want to enter a room, toggle developer mode, see the interaction boxes, move them, add a new one, test the change immediately and save it. The same idea applies to NPCs: choose who appears in a room, place them visually, define where they can wander, select the sprite or model being used, and preview the behavior without rebuilding the whole project.
I have also been working on a conversation development view that shows follow-up branches instead of only the first layer of dialogue. When a response is wrong or repetitive, I need to be able to find it quickly.
The hard part is making developer tools powerful without letting them damage production data. A test patch needs to behave like a real hotfix. Saved overrides need to survive point releases. New versions must not silently replace the work done through the editor.
That has pushed me toward a cleaner separation between engine code and content data. The more room setup, dialogue and interaction state can live in data files rather than scattered scripts, the safer future releases become.
Developer tools are not something players will see in the final game, but they affect almost everything players will see. Better tools mean I can spend more time improving puzzles and scenes instead of spending the night trying to remember why a rectangle moved twelve pixels to the left.