How to fix AI game code without starting over

1. Preserve the last version that worked

Before asking for another fix, save the current files and identify the most recent working checkpoint. Keep any unfinished changes you care about. A version-control diff or a comparison with a saved copy helps you see what changed between “the game ran” and “the game broke.”

Avoid stacking speculative patches. If movement breaks after adding collectibles, investigate that change first. Do not simultaneously replace the movement system, install a physics package and redesign the level. Too many changes make it hard to tell which one helped.

2. Describe a bug another person could reproduce

“Restart is broken” is a starting observation. A useful bug report states the initial conditions, exact actions and visible result. For our Lantern Run example, imagine a timer that seems normal on the first round but gets faster after restarting. This is an illustrative debugging scenario, not a report from a shipped game.

Copy the complete relevant error text when there is an error. If there is no error, describe the wrong behaviour and what still works. A short recording or screenshot can help with visual problems, but include written steps so the assistant knows what led to the image.

3. Ask for evidence before choosing a cause

A timer that speeds up after Restart could have more than one cause. Perhaps a previous timer was never stopped, an event handler was registered twice, or two update paths now change the same value. Those are hypotheses. The code and a reproduction should decide between them.

• Find where the round timer is created, updated and stopped.
• Find every restart path and any listeners or timers it registers.
• Check whether losing and winning both perform cleanup.
• Look for more than one place subtracting time.
• Compare that code with the last working checkpoint.

Ask the assistant to identify exact files and functions that support its explanation. If it needs temporary logging, limit the logs to relevant state and remove them after verification. Do not let a plausible explanation become a claimed diagnosis without evidence.

Godot: overview of debugging tools ↗

4. Request the smallest fix that addresses the cause

Investigate the round timer in [engine + exact version].
From a fresh launch it runs normally. After losing and pressing Restart, it counts down about twice as fast.
Reproduction: [exact steps]. Relevant error/log: [text, or none].
Last working checkpoint: [version]. Recent change: [change].

Inspect all timer creation, update, cleanup and restart paths. Explain the cause with file/function evidence before editing. If duplicate timers or handlers are responsible, fix their lifecycle using the existing architecture. Do not compensate by changing the countdown speed. Keep movement, scoring and art unchanged.

Verify a fresh round, three consecutive restarts, enemy loss, timeout and a win. Report what you actually tested and any remaining uncertainty.

The instruction about countdown speed matters. Halving the timer speed might hide the symptom for one restart while making the first round wrong and leaving the underlying duplicate work intact. The same principle applies to collision bugs: changing a magic number is not enough if a collision event fires twice.

Read the patch. A restart fix should have a clear connection to the round’s lifecycle. If the assistant changes unrelated systems, ask why each change is necessary before accepting it. Keep the original reproduction steps unchanged so the test remains meaningful.

5. Test the fix and the behaviour next to it

A successful build is useful, but it cannot tell you whether a lantern is counted twice or a round restarts cleanly. Match the check to the claim. For the example timer fix, play through more than the path that originally failed.

1. Fresh launch: confirm the timer begins at 60 and decreases at the intended rate.
2. Enemy loss: confirm the round ends once and the timer stops.
3. Restart three times: confirm the timer resets and does not get progressively faster.
4. Timeout: confirm the timer reaches zero, stops there and shows a loss.
5. Win: collect all five lanterns and reach the gate; confirm the timer and score stop changing.
6. After every restart: confirm movement, lantern count, enemy position and gate state reset correctly.

If your project already has automated tests, add a focused regression test for the failure when practical. Still check visible gameplay. A unit test of score reset does not prove that the restart button is connected correctly in the scene.

6. Know when to step back instead of asking for another patch

If two attempts change the code without improving the reproduction, pause the patch cycle. Ask for a summary of what is known, what was tried and what evidence is missing. Return to a preserved working version or isolate the problem in a smaller scene, while keeping a copy of your current work.

For engine API errors, confirm the installed version and consult that version’s official documentation. For missing assets, check names, paths and letter case in the shared build. For problems that appear only online, compare the browser console and network failures with the local version before rewriting gameplay code.

Once the original problem and nearby checks pass, save a checkpoint with a plain-language note: “Restart now clears the previous round timer; verified fresh round, win, loss and three restarts.” Your next feature starts from evidence you can trust.

Use smaller feature prompts to prevent avoidable rework ↗