Scripting & Gameplay

The engine is compiled, slow to change and written by programmers. Gameplay (what the goblin does when it sees you, how long the door stays open) changes every day and is often written by designers. Engines therefore keep gameplay out of the engine and load it as data or script. After this lesson your program will run a small gameplay script: a state machine that reacts to events and timers, and that can have its rules replaced while it is running without forgetting what state it is in.

Why scripts

• Iteration speed. Editing a rule and seeing it in the running game beats a recompile and a restart.
• Access. Designers and modders can change behaviour without building the engine.
• Safety. A script runs in a sandbox with a limited API, so a mod cannot read your files.

Unity runs C#, Godot GDScript, Unreal C++ and Blueprints (a visual graph), many studios embed Lua. The shape is the same everywhere: the engine exposes an API (spawn, play a sound, read a component) and calls lifecycle hooks such as start, update, on-collide and on-destroy; the script decides what happens inside them.

State machines

A character is in exactly one state at a time: Idle, Walk, Attack, Dead. Events move it between states. The whole behaviour is a table: (current state, event) gives the next state. That replaces the tangle of flags (isJumping && !isAttacking && !isStunned) that every first gameplay script grows. Each state may have an exit and an enter action, run in that order (stop the old animation, then start the new one).

Three rules that real machines follow:

1. Unknown events are ignored, not errors. A character in the Dead state still receives click; it just does nothing.
2. A transition back to the same state is a real transition. It runs exit and enter again and restarts the time spent in the state, which is how re-triggering an attack restarts its animation.
3. Wildcards. A rule from * applies in any state ("on die, go to DEAD, whatever you were doing"). A rule written for the specific current state always beats the wildcard.

Time in a state

Many behaviours are timed: an attack lasts 300 ms and then returns to idle, a door closes itself after 3 s. The machine tracks the time in the current state. A tick adds to it. When it reaches the state's timeout, the machine says timeout, then changes state exactly as an event would, which resets the time to zero. At most one timeout fires per tick and any time left over is discarded; otherwise one long frame could chain several states in a single update.

Hot reload

The rules are data. The running machine (its current state and time in it) is separate from the data. On a reload the rules are thrown away and re-read, but the machine keeps its state and its clock, so a designer can change the length of an attack while the character is in mid-attack. If reload also reset the machine, every tweak would send the player back to the start.

Worked trace

TRANSITION START unlock CLOSED
TRANSITION CLOSED open OPEN
TIMEOUT OPEN 3000 CLOSED
TRANSITION * lock LOCKED
EVENT unlock           exit START, enter CLOSED
EVENT open             exit CLOSED, enter OPEN
TICK 2000              (nothing yet: 2000 of 3000)
TICK 1500              timeout OPEN, exit OPEN, enter CLOSED; the extra 500 ms is dropped
EVENT lock             exit CLOSED, enter LOCKED       (wildcard)
EVENT open             ignored open

Behaviour trees, the other common AI structure, replace the single current state with a tree of sequences and fallbacks that is re-evaluated every tick. They suit complex AI; a state machine suits characters, doors and menus.

Common mistakes

• Printing enter before exit.
• Treating an event with no rule as an error.
• Letting the wildcard rule win over a rule written for the current state.
• Not restarting the clock on a transition back to the same state.
• Carrying leftover time into the next state, or firing several timeouts in one tick.
• Resetting the current state when the rules are reloaded.

Your exercise

Implement the event and tick handlers described in the exercise. The starter stores the rules and prints the results of the queries. The most likely mistake is the order of exit and enter.