Why Python-shaped code can fail here

Treat the game as its own programming environment. A line that works in desktop Python can still fail because the language differs, a feature is not unlocked, or a game command does not accept the state you gave it. Check those three layers in that order.

Check three different layers

The developer describes a language similar to Python, rather than full Python. The base game introduces concepts gradually, so knowing a feature exists somewhere is different from having it available in your save.

From idea to valid action Python-shaped idea 1Language syntax rewrite 2Feature unlocked check 3Game action contract inspect
A familiar Python idea must pass three separate checks. A failure at one layer points to a different repair.
1. Language
Can the game read this syntax and support this operation? Familiar indentation does not establish support for every Python expression, module or method.
2. Availability
Have you unlocked the feature used by the line? A missing capability is not fixed by rewriting the same call several ways.
3. Game contract
Does the command exist in the current game, and are its arguments and world conditions valid? A correct loop cannot rescue an incorrect action assumption.

For example, “sort these observed values” is an algorithmic goal. It does not prove that a Python sorting method is supported, or that the underground puzzle lets you rearrange values in the same way.

Adapt an idea before adapting its code

Suppose an outside example says: read four values, sort them and move to the next location. First rewrite it as three questions:

  1. What can I observe? Identify the game’s documented observation and what it returns. Do not substitute a resource icon or screenshot color for a numeric value.
  2. What operation is legal? Check whether the current task allows a comparison, a swap, a movement or something else.
  3. What proves completion? Define an observable end state, such as “every adjacent pair satisfies the required relation,” only after that relation is known.

Then implement the smallest available version. The numeric sorting exercise shows the comparison logic; the actual mushroom rule still has to come from the game.

This decomposition also tells you which outside code to discard. A library call or a farm movement assumption is not essential if the underlying task can be expressed more simply.

A small check before a long program

  1. Open the current in-game documentation for the feature or command you intend to use.
  2. Confirm its availability in the current save.
  3. Try one harmless, bounded operation in a state where its expected result is clear.
  4. Inspect its result before adding repetition or a second command.
  5. Add a stopping condition and a failure path before scaling up.

If a tiny expression cannot be read, focus on syntax. If it can be read but a name is unavailable, check spelling, definition order and unlocks. If the action runs but the world is wrong, inspect the command’s assumptions and your saved state. The error guide expands this decision path.

A .py file is not a promise of Python compatibility

The official base-game page says code is stored in .py files and can be edited with an external editor such as VS Code. That makes editing convenient; it does not turn the game into CPython or establish support for pip packages.

Autocomplete can suggest a familiar Python feature that the game does not provide. The game’s own documentation and a small current test take precedence over an editor suggestion.

Use the File Watcher workflow to synchronize edits, then execute the file in the game. No general-purpose Python execution environment is provided by this site.

Sources and further reading