Use a small, explicit record
A variable is useful when it answers a question the next decision needs. For a scan, three separate questions are often enough:
- Where am I?
- The last confirmed position, for example
(1, 0). - What have I already handled?
- A collection such as
[(0, 0), (1, 0)], where each entry means this example has arrived and completed its observation there. - What am I trying next?
- A pending target, for example
(2, 0). A target is an intention, not a completed visit.
These values describe an original teaching model. Their notation is not a promise that a particular tuple, set or list operation is available in the current game.
A move that fails should not rewrite history
| Record | Before | Failure | Success and completed observation |
|---|---|---|---|
| Position | (1, 0) | (1, 0) | (2, 0) |
| Visited | (0, 0), (1, 0) | Unchanged | Add (2, 0) |
| Pending | (2, 0) | Still unresolved | Choose a new target |
If you append the target before attempting movement, a failure leaves a false visited entry. The next scan can then skip the cell even though it was never handled. Repeating that error makes the saved map look complete while the job is incomplete.
Use this order: choose target → attempt action → confirm result → update matching state → choose the next target. If arrival and processing are separate, keep separate arrived and processed records or update “processed” only after both succeed.
Make the next decision explainable
Suppose two unvisited targets are equally suitable. Choose a stable tie rule, such as the first target in your planned route. With the same confirmed state, the same rule then chooses the same next action.
This makes debugging easier. If the drone unexpectedly changes direction, compare the state immediately before the decision with the rule. You can distinguish a bad rule from a bad record instead of guessing which line caused the route to drift.
Do not keep every observation forever by default. Retain the facts needed for the current job, and decide when they become stale. A changed world can invalidate an earlier observation; a coordinate in a collection is not proof that its contents never change.
Define what a restart means
- Fresh run: rebuild the record from the intended initial state. Do not accidentally retain completed markers from a different board.
- Resume: confirm that the stored position and world still match, then continue pending work.
- Failure recovery: keep the last confirmed state and the failed target so the next attempt can be diagnosed.
A general Python rule about globals or imports is not enough to establish how the game retains state across files or runs. Use current game documentation for those details. This guide only relies on the explicit state you choose to maintain during one conceptual job.
Next, use the route trace to see a full sequence, or the error guide to find the first wrong update.