Sort the failure before changing code
A program that cannot start and a program that runs the wrong route need different checks. Use the first matching branch:
- It does not begin executing.
- Check the reported location, indentation and nearby syntax. The line where parsing stops can follow the line that introduced the mistake.
- A name or operation is unavailable.
- Check spelling, whether the definition was reached and the feature’s current unlock/documentation. An editor suggestion is not proof that the game supports it.
- It executes, but an action fails.
- Check the action’s arguments and required world state. Record the last confirmed position and the attempted target.
- It executes without an error, but the result is wrong.
- Trace the state updates, branch condition and stop rule. A logical error need not produce an error message.
These are categories, not quoted game error strings. The language is Python-like, so a desktop Python diagnosis may not transfer unchanged.
A concrete repeat with no error message
In this original example, the intended job processes target numbers 0, 1 and 2. The run keeps processing target 0.
| Point | Expected target index | Observed target index |
|---|---|---|
| Before first work | 0 | 0 |
| After first successful work | 1 | 0 |
| Before second work | 1 | 0 |
The first mismatch is after the first success. Inspect the index update or a branch that bypasses it. Adding another movement command would not explain why the index stayed zero.
After fixing the update, repeat the same three-target case. Expected indices before work are 0, 1 and 2, followed by a stop. Also check a failed action: the program should preserve unresolved work rather than report completion.
Reduce the problem to one reproducible case
- Keep a copy of the last working version.
- Choose the smallest starting state that still triggers the problem.
- Remove unrelated work while preserving the failing condition.
- Inspect the relevant value immediately before and after the suspect step.
- Change one cause, then repeat the same starting case.
When available in your base-game unlocks, Output, stepping and variable inspection help reveal the execution order. This guide does not depend on a particular shortcut or button position.
If the small case no longer fails, restore the last removed dependency. If the result changes every run, first check whether the world or your stored state was reset consistently.
Keep the details that explain a failure
A useful note has the current game version, relevant unlock, small code fragment, starting state, expected first result and actual first result. A screenshot of the final wrong board alone may hide the earlier update that caused it.
For example: “Starting at (1, 0), an attempted move to (2, 0) did not change position, but my record added (2, 0) to visited.” That gives a precise repair target: the state update occurs before success is confirmed.
Next, inspect the failed-move state example, a loop’s exit path, or equivalent work that runs slowly, depending on the first failure you found.