Build the Cheat Menu First: Debug Tooling That Pays for Itself in a Week

Your boss fight sits four hours into the game. To test one change to its second phase, you load a save, walk through two corridors, clear a mini-arena, sit through a 40-second elevator ride, then die in nine seconds because the new attack is too fast. Total loop: eleven minutes of travel for nine seconds of information.

Do that twenty times and you have spent three and a half hours testing and three minutes designing. The fight does not improve because you are tired of the elevator.

The fix is not discipline. It is tooling: a debug menu built before the content it tests. On a small team that is a day or two of work, and it pays itself back inside the first week.

Count the cost before you argue about priorities

Tooling arguments go in circles because nobody puts a number on them. Take your three or four most-iterated systems and write down the setup cost per attempt.

What you iterate on	Setup per attempt	Attempts to tune it	Time lost to setup
Hour-4 boss, phase 2	11 min	25	4h 35m
Shop prices at mid-game	6 min	40	4h 00m
Ice-cave jump spacing	3 min	60	3h 00m
Endgame crafting tier	14 min	15	3h 30m

That is roughly fifteen hours of walking, in four systems, on one project. A warp command and an inventory cheat cut most of it to seconds. The question stops being "can we afford tooling" and becomes "can we afford to re-walk the ice cave sixty times".

Write the table down where the team sees it — a decision-log entry in your project workspace is enough. The next person who says "we'll add debug stuff later" then has to argue with arithmetic instead of with you.

Tier 1: the five commands you build first

These five cover most of the pain and take an afternoon. Build them before you build the content they serve.

1. Warp. Jump to any level, checkpoint or named spawn point. Not "load level 4" — "load level 4 at the arena door, with the door already open".
2. Invulnerability and one-hit kill. Two separate toggles. You need to study a fight without dying, and you need to skip a fight you have already studied.
3. Give. Items, currency, ammo, resources, by id and quantity. give potion_health 10, give gold 5000.
4. Set flag / unlock. Grant an ability, complete a quest step, flip a story flag. Most "I can't test this" problems are really "the flag that gates it is set four hours earlier".
5. Time scale. Run the game at 0.25x to read an animation's tells frame by frame, or 4x to get through a slow sequence. One float, enormous value.

If your content is data-driven — levels, items and enemies defined in tables rather than hardcoded — all five are mostly lookups into data you already have. Keep item ids, level ids and flag names in one authoritative list instead of scattered through code, and pull them from the same source your design docs use, whether that is an exported table or your workspace's REST API. Then a typo in the console fails loudly instead of silently spawning nothing.

Tier 2: state you can set, not just grant

Once travel is solved, the next bottleneck is state. You can reach the boss, but you cannot reach the boss with 40% health, no potions, and the fire sword, which is the case players complain about.

• Stat override. Set current and max health, stamina, level, any tuning stat, at runtime.
• Snapshot and restore. One key saves full game state to a slot, another restores it. The best combat-tuning tool there is: snapshot at the phase transition, then retry that phase forty times without re-fighting phase one.
• Spawn. Drop any enemy, item or prop in front of the player. A spawn command plus an empty test room is a combat lab.
• Quest jump. Move a quest to any step, forward or backward. Backward matters more than you expect — it is how you reproduce bugs.
• Fixed seed. For anything random, let the tester pin the seed and show it on screen. "It happened on seed 88412" is a bug report you can act on; "sometimes the room has no exit" is not.

Tier 3: see what the game is thinking

Manipulation gets you to the moment. Observation tells you what happened in it.

A debug overlay, toggled with one key, is worth more than most of your logging. Useful lines: frame time, player position and velocity, state-machine state for the player and the nearest enemy, the last ten gameplay events with timestamps, the active seed, and the build id.

Add shape rendering for hitboxes, hurtboxes, trigger volumes and navigation bounds. A wall-clip bug that takes an hour to describe takes four seconds to see when the collider is drawn in magenta and visibly pokes through the geometry.

For enemy tuning, print the AI state above each enemy's head — patrol, suspicious, hunting, lost. That turns an argument about whether the AI "feels fair" into a question of whether the state you see matches the state the animation implies.

Four rules that keep debug tooling from biting you

Cheats never get their own code path. A god-mode toggle that sets invulnerable = true is fine. A god-mode toggle that branches the damage function is a second combat system you now have to maintain and that will diverge from the real one. Debug tools set state; they do not reimplement rules.

Gate it, do not delete it. Compile the menu out of release builds or hide it behind a launch flag, but keep it alive in internal builds through the whole project, including after launch. The day a player reports a late-game softlock is the day you want warp and quest-jump to still work.

Taint the data. The moment any cheat is used, set a persistent debug_used flag and attach it to every playtest note or event from that session. Nothing poisons a balance decision faster than a curve built partly on runs where someone had 5000 gold at minute three. Make it a required field on the playtest session record, not something a tester remembers to mention.

Keep bindings boring and documented. Pick a convention on day one — F1 overlay, F2 console, F3 snapshot, F4 restore, backtick for the command line — and write it in the same place your team finds build instructions. A tool nobody can remember how to open does not exist.

A one-day checklist

• Console or menu opens with a single key, in every internal build
• Warp to level and named spawn point
• Invulnerable toggle and one-hit-kill toggle
• give <id> <count> for items and currencies
• Set flag, unlock ability, jump quest to step
• Time scale with a reset key
• Snapshot and restore full state to one slot
• Overlay: frame time, position, player and enemy state, build id, seed
• Collider and trigger shape rendering
• debug_used flag written into session data on first cheat
• Bindings documented where the team already looks

The order that actually saves time

The common mistake is building tools at the end, as a reward for finishing production. By then the iteration they would have accelerated is already behind you, paid for in walking.

Treat Tier 1 as setup for any system you expect to tune more than ten times. When the boss goes on your task board, "warp to boss arena" and "snapshot/restore" go on as subtasks of that boss — not as a tooling epic that keeps sliding. Tier 2 earns its place when you start balancing numbers; Tier 3 the first time two people disagree about what the enemy was doing.

After the first week, check the arithmetic: attempts made on one system, multiplied by the setup you no longer pay. If that is smaller than the day you spent, you built the wrong five commands — go back to the table and build the ones that serve your longest loop.