Lawn Mower Script Thoughts

Implement a bot that performs the entire search space and stores the complete map state after each move.
I'd recommend doing this in C++, most other languages will have too much time overhead per operation.

A state consists of the following:
1: Position
2: Facing Direction
3: Next intended direction
4: Frame Count
5: Number of Tiles Mowed (Store number to reduce calculations)
6: Number of Non-lawn tiles mowed (Store number to reduce calculations)
7: Map State of Mowed Tiles
8: Fuel Count
9: (Probably more things I'm forgetting)

State[0] = Starting state
State[1] = State after mowing first tile in some direction
State[2] = State after mowing second tile in some arbitrary direction.

A: The bot will perform all iterations of 1: up, 2: left, 3: right, 4: down from the present tile.
B: If the bot reaches a failure condition, it will reset the game state back one tile and go the next direction.  The state it attempted when it failed will be erased.
- Failure conditions include:
- Too many non-lawn tiles mowed
- Out of fuel
- Attempted all viable directions
- Ran into edge of map
- Exceeded predetermined maximum frame count. (Slower than we came up with for the level by hand.)
- (Probably more things I'm forgetting)
C: If the bot completes the level, output the history of each move.

The following needs simulated in between frames, to move from one frame to the next:
1: Pixel, Subpixel, Velocity

Notes:
1: If you turn, you lose your subpixels.
2: Max speed is 49, by letting go of A for one frame.
3: The costs in frames of moving a direction ends up being 5,4,4,4,5,4,4,4,5,4,4,4,4,5,...  Moving in sets of 4 ends up being mostly ideal to not spend a frame, but the 13th square also saves 1 frame.  Turning loses a potential frame a lot of the time.  The script should not contain these oversimplifications, this is just some known observations.
4: Truly simulating fuel spawns is the difficult part.  If the rest of the bot is written, this can probably be done last.  For now we might try manually placing the fuel can(s).
5: Drawing the output is computationally intensive, maybe it's fine as a debug option, but if it runs during the brute forcing, it will probably be too slow.
6: The computational search space has been narrowed down by imposing failure thresholds in order to hopefully reduce the search space to something achievable within a reasonable amount of time.  It's probably fast enough for early levels.  Later levels might take a lot longer.