Make the comparison fair
Use a bounded job: for example, observe every cell on the same 4×4 teaching board once. Both candidates must finish all 16 observations, follow the same movement assumptions and end under the same completion rule.
Keep the same initial position and state. If one run begins with half the work marked complete, its result cannot be compared with a fresh run. Check correctness first, including the final target and a failed-action path.
The base game documents a game execution-cost model. Desktop Python speed, source-line count and time spent looking at an editor are different measurements. No DLC timing API or current tick price is assumed here.
Compare fixed hypothetical counts
In the direct route, 15 moves reach 16 cells because the start is already visited. Imagine a second candidate that performs 20 moves by revisiting some locations and makes twice as many observations.
| Work | Direct route | Repeated work |
|---|---|---|
| Successful moves | 15 | 20 |
| Observations | 16 | 32 |
| Completed cells | 16 | 16 |
If we assign a made-up cost of 2 units per move and 1 per observation, the totals are 15×2 + 16 = 46 and 20×2 + 32 = 72. These weights are only an explanatory model. They are not measured game ticks, a benchmark or a claim of a particular percentage speedup.
The second candidate has five extra moves and sixteen extra observations. Those are concrete places to investigate; fewer source lines alone would not reveal them.
Look for one repeated cost at a time
- Movement
- Does the route return to an already handled cell without needing to? Draw the positions before changing the movement loop.
- Observation
- Does one decision read the same unchanged fact repeatedly? Reuse an observation only while the world conditions that made it valid still hold.
- Rework
- Does a pass reprocess finished targets because completion was not stored correctly? Check state rather than masking it with a larger counter.
- Waiting or failure
- Does an unchanged failure trigger the same retry forever? A bounded failure branch may be needed before any speed comparison is meaningful.
Do not remove a check merely because it costs something. A check that prevents an invalid action can be essential to correctness.
Test one change against the same result
- Save the correct baseline and its starting conditions.
- Identify one avoidable action category.
- Change that category without changing the job.
- Repeat the same case and verify the completed result.
- Compare the relevant game measurement or action counts, then keep or reject the change.
If the new version skips a target, changes the intended puzzle result or handles failures differently, fix that difference before calling it faster. More complex strategies, including parallel work, require their own current game contracts and are outside this small comparison.