Make game rules you can explain and test
Use a tiny state table to prevent duplicate rewards, impossible actions, and broken resets.
First Play Studios · Edition 1 · Updated November 14, 2026
A state table for a parcel-delivery mechanic, including rejected actions.
Before you start- A small game idea
- Paper or a text editor; no code required
In this guide
Store facts, then draw them
State is the information the game needs to remember. In a parcel game, useful facts include the character’s position, whether the parcel has been collected, and whether delivery is complete. A message or icon should reflect those facts. It should not be the only place the game remembers them.
Choose clear names for your states: waiting, carried, and delivered. A parcel cannot be in all three at once. Starting with one explicit state prevents contradictory combinations such as ‘already delivered’ and ‘still on the floor.’ Larger games need more detail, but the habit of naming valid states remains useful.
Describe each transition
An action requests a change. The rule decides whether to allow it. Picking up the parcel requires the waiting state and a nearby character. Delivery requires the carried state and proximity to the workbench. A repeated delivery request must leave the completed state alone.
Write a table with four columns: current state, requested action, condition, and next state. Include the requests that should do nothing. This gives you a design reference before you choose an engine’s scripting language. A collision or trigger can report proximity; your game rule still decides whether the reward is allowed.
Conceptual state table — not engine code
waiting + pick up + nearby -> carried
waiting + deliver -> waiting
carried + deliver + at bench -> delivered
delivered + deliver -> delivered
any state + restart -> waitingTest repeated and unexpected input
The happy path is only one test: pick up, walk, deliver. Also try delivering first, picking up twice, pressing the button quickly, and restarting after success. Record the expected state before you run each check.
When code is added, keep the rule separate enough that you can inspect the state without guessing from an animation. If an effect plays twice, ask whether the state changed twice or whether the visual effect subscribed twice. Those are different problems and need different fixes.
Predict five actions before running them
- Copy the state table and add the distance checks your game needs.
- Trace a valid delivery on paper, writing the state after each action.
- Trace delivery before pickup and repeated delivery after success.
- Add a restart check for the parcel, counter, player position, and success message.
Check your result.
- The reward occurs once per complete delivery.
- Rejected actions leave the state unchanged.
- Restart produces the same starting conditions every time.
Common mistakes to watch for.
- Letting every collision callback grant a reward without checking current state.
- Resetting the visible label while leaving the underlying counter unchanged.
Keep the conversation useful.
Review this small state table for my game. Identify impossible combinations, repeated-input problems, and missing reset rules. Ask before changing the design. Suggest a test for each concern, then help me implement one transition in my engine version.
Sources & version notes.
Engine-independent rules exercise. The table is pseudocode, not a script to paste into an engine.
Further reading from the original documentation:
Practice times are estimates. Software-specific exercises are documentation-based unless their version note says otherwise.A question or a small win?
Tell the workshop what happened when you tried this guide. Ask for a useful next step, or share something you got working.
See discussions about this guide We’ll include the guide link in your draft. Sign in to post, then add your own question or progress before sharing.