From Side Scripts to Infrastructure: Making My Game Toolchain Usable by Other Humans
This is the companion to Claude Hit 100%, Codex Kept Going, and it is really about one practical question: can someone else sit down at this repo and get useful work done without a guided tour?
For a while, the honest answer was “kind of.” There were scripts everywhere, lots of useful pieces, but too much of it lived in my head.
Between Feb 17 and Feb 22, the tools/ area changed hard: 35 commits touched it, 38 files were added, 51 were modified, and line churn crossed 41k. That sounds dramatic, but the intent was simple. I was trying to turn private convenience code into shared infrastructure.
What Made the Difference
The highest leverage change was introducing predictable startup. Once npm run tools:up became the norm, the local stack stopped feeling fragile. Before that, it was easy to waste time on port conflicts, stale processes, and “which URL do I open again?” issues.
tools/local_servers.js also made multi-port orchestration explicit instead of tribal knowledge. Main game on 9000, level editor on 9001, overworld editor on 9002, particle editor on 9003, text editor on 9004, bullet editor on 9005. It tracks health checks and runtime state, which means failures are visible instead of mysterious.
I also wanted /tools/ to feel like a real front door, not a hidden path. The tools index now gives clear entrypoints and expected project layout, so onboarding does not depend on chat history.
Finally, the static server grew proper tool APIs for scenes, overworld, UI, code, and bridge endpoints. That one piece connected runtime, browser editors, and content repos in a way that feels much less brittle.
Why This Matters Beyond Me
AI can make a solo developer very fast, but speed alone does not equal collaboration. If a codebase only works when one person remembers the secret command sequence, it is still a single-player system.
The infrastructure pass changed that. Another contributor can clone, run one command, open a clear tools page, make edits, test quickly, and commit with known file paths. That is what “accessible” actually means in day-to-day work.
It also helps non-engineering contributors. When the path from edit to validation is explicit, designers and content collaborators can participate without digging through engine internals.
How This Connects to Trello and MCP
The Trello bug pipeline fits the same pattern. In-game capture removed friction at the moment of failure. The next step was hardening the integration boundary so multiple AI tools can use it cleanly with centralized secrets and repeatable semantics.
I went deeper on that here: Should I Build My Own MCP for Trello?.
If I had to summarize this week in one line, it is this: I stopped shipping only features and started shipping the system that makes features repeatable.