Animation and Simulation Plus Interaction Norm Badler CSE 377 March 3, 2003

Discrete Simulation Event is primary entity. Time jumps forward to next event. Not good for animation per se as events may happen at arbitrary time points (e.g. customers arriving at a server) Time line

Animation Frames must be produced at fixed time intervals, whether or not anything is actually happening. In general, this means that animated actions must be represented as functions of TIME. Time line Frame times

So what about the EVENTS? Events are changes in the world environment caused by: User actions Objects in the world Interactions between objects (and user) E.g., Button push or mouse action Object property (movements or other attribute changes) Collisions or “in view”

Events Cause Branches in Action Stuff changes because of events in the world or user actions. HOW DO WE REPRESENT THE ACTION ALTERNATIVES? Representational options: Sequential logic (IF THEN ELSE) Finite State Machines Rule-based systems

Sequential Logic IF condition-a THEN action-1 ELSE IF condition-b ELSE IF condition-c THEN … PROBLEMS: Awkward, brittle, hard to debug and modify.

Finite State Machines Flexible for small-ish action sets. Simple semantics. Can be hierarchical (can invoke sub-FSMs) Allow clear think about the transitions in the action space.

Example Finite State Machine for a Game Watt and Policarpo

FSM Generally nodes are processes. Edges are transitions from one process to another: occur at events (as defined before) Edge transitions may be deterministic or dependent on a statistical distribution of options. Transitions may have side effects besides changing program state.

Edge Transitions Happen if something is observed (visible to entity): “Looking for enemy” changes to “Tracking enemy” Happen if objects interact: “Enemy destroyed” changes state to “Looking for [new] enemy” {note side effect!} Happen if user interacts: Button push may fire missile that collides with enemy causing it to be destroyed.

Implementing a FSM Determine process states and all possible transitions. Determine all possible variables that need checking in a state. Organize in a table. (May not be as efficient as sequential logic but easier to design and maintain!)

State Var –1: Enemy in view Var –2: User fires missile (in flight) Var –3 Collision detected Var –4 Missile position Var –5: User position Actions Required or Allowed Side Effects T (x,y,z)[t] (x,y,z)[inter-face] Run vaporize graphic Enemy deleted; Missile deleted; User arsenal-- User score++ F Enemy/user moves Missile deleted; User arsenal-- -

Existing FSM Packages Game engines (MOTIVATE) PaT-Nets KPL (Ken Perlin’s Language) Write your own…