AI in games
Simple steering, Flocking
Production rules
FSMs, Probabilistic FSMs
Path Planning, Search
Unit Movement
Formations
Oct 6, Fall 2005
Game Design
1
AI in video games
 5-10%
of CPU for Realtime
 25-50% of CPU for Turn-based
– Chase/Escape behaviors
– Group behaviors
– Finite State machines
– Adaptation/Learning
Oct 6, Fall 2005
Game Design
2
Questions
 How
good should the AI be?
 Why are people more fun than NPC’s?
 Will networked games reduce AI?
 New directions for AI in games?
Oct 6, Fall 2005
Game Design
3
Learning/Adaptation
 Increment
doing well
aggressiveness if player is
– The Computer-Based SATs do this!
 Levels
are a pre-programmed version of
adaptation
 Tuning
 Stability
 How might adaptation make play
Better or Worse?
Oct 6, Fall 2005
Game Design
4
Adaptation vs. Play quality
 Do
you want the monsters in Quake to
get better as you get better?
 Force the user to live with the
consequences of his/her actions
 Can surprise the designer (Creatures)
 Pit AI creatures against each other to find
bugs or tune actions
 Robotwar
Oct 6, Fall 2005
Game Design
5
What is good AI?
 Perceived
by user as challenging
– Cruel, but fair!
 User
is surprised by the game
– but later understands why
 Feeling
that reality will provide answers
– able to make progress solving problem
 What
Oct 6, Fall 2005
games have used AI effectively?
Game Design
6
Chase/Evade
 Algorithm
Oct 6, Fall 2005
for the predator?
Game Design
7
Enhancements to Chase
 Speed
Control
– Velocity, Acceleration max/min
– Limited turning Radius
 Randomness
– Moves
– Patterns
Oct 6, Fall 2005
Game Design
8
Enhancements to Chase
Anticipation
Build a model of user behavior
Oct 6, Fall 2005
Game Design
9
Steering Behaviors
Pursue
 Evade
 Wander
 Obstacle Avoidance
 Wall/Path following
 Queuing

 Combine
behaviors with weights
 What could go wrong?
Oct 6, Fall 2005
Game Design
10
Group Behaviors
 Lots
of background
characters to
create a feeling of
motion
 Make area appear
interesting, rich,
populated
Oct 6, Fall 2005
Game Design
11
Flocking -- (HalfLife, Unreal)
Simple version:
Compute trajectory to
head towards centroid
 What
Oct 6, Fall 2005
might go wrong?
Game Design
12
Group Behaviors
 Reaction
Oct 6, Fall 2005
Craig Reynolds
SIGGRAPH 1987
to neighbors -- Spring Forces
Game Design
13
What could go wrong?
Exactly aligned
 Repulsive
Forces balance out in
dead end
springs around obstacles
 Does not handle changes in strategy
Oct 6, Fall 2005
Game Design
14
“Perceptual” Models
Oct 6, Fall 2005
Game Design
15
Production Rules
If( enemy in sight ) fire
If( big enemy in sight ) run away
If( --- ) ---
Selecting among multiple valid rules
– Priority weighting for rules or sensor events
– Random selection

No state (in pure form)
Oct 6, Fall 2005
Game Design
16
Finite State Machines
 States:
Action to take
– Chase
– Random Walk
– Patrol
– Eat
Chopping
Enough wood
Take Wood to
closest depot
 Transitions:
– Time
– Events
– Completion of action
Oct 6, Fall 2005
At woods
At depot
Drop wood:
Go back to woods
Game Design
17
State Machine Problems
 Predictable
– Sometimes a good thing
– If not, use fuzzy or probabilistic state
machines
 Simplistic
– Use hierarchies of FSM’s (HalfLife)
Oct 6, Fall 2005
Game Design
18
Probabilistic State
Machines
 Personalities
– Change probability that character will
perform a given action under certain
conditions
Aggressive Passive
Attack
50%
5%
Evade
5%
60%
Random
10%
10%
Flock
20%
20%
Pattern
15%
5%
Oct 6, Fall 2005
Game Design
19
Probabilistic Example
Fire At Enemy
Enemy Within Handto-Hand Range
50%
Enemy Within Handto-Hand Range
50%
Run out of
Range
Oct 6, Fall 2005
Run Away
Far Enough to
Take Shot
Game Design
20
Probabilistic State Machines

Other aspects:
–
–
–
–
–
–
–

Sight
Memory
Curiosity
Fear
Anger
Sadness
Sociability
Modify probabilities on the fly?
Oct 6, Fall 2005
Game Design
21
Planning
 Part
of intelligence is the ability to plan
 Move to a goal
– A Goal State
 Represent
the world as a set of States
– Each configuration is a separate state
 Change
state by applying Operators
– An Operator changes configuration from one
state to another state
Oct 6, Fall 2005
Game Design
22
Path Planning
 States:
– Location of Agent/NPC in space
– Discretized space
• Tiles in a tile-based game
• Floor locations in 3D
• Voxels
 Operator
– Move from one discrete location to next
Oct 6, Fall 2005
Game Design
23
Path Planning Algorithms
Must Search the state space to move NPC to
goal state
 Computational Issues:

– Completeness
• Will it find an answer if one exists?
– Time complexity
– Space complexity
– Optimality
• Will it find the best solution
Oct 6, Fall 2005
Game Design
24
Search Strategies
 Blind
search
– No domain knowledge.
– Only goal state is known
 Heuristic
search
– Domain knowledge represented by heuristic
rules
– Heuristics drive low-level decisions
Oct 6, Fall 2005
Game Design
25
Breadth-First Search

Expand Root node
– Expand all Root node’s children
• Expand all Root node’s grandchildren
Root
Root
Child1

Root
Child2
Problem: Memory size
Oct 6, Fall 2005
Child1
GChild1
Game Design
GChild2
Child2
GChild3
GChild4
26
Uniform Cost Search
 Modify
Breadth-First by expanding
cheapest nodes first
 Minimize g(n) cost of path so far
Root
Child2
Child1
GChild1
9
Oct 6, Fall 2005
GChild2
5
GChild3
3
Game Design
GChild4
8
27
Depth First Search
 Always
expand the node that is deepest in
the tree
Root
Child1
Root
Root
Child1
GChild1
Child1
GChild2
GChild1
Oct 6, Fall 2005
Game Design
28
Depth First Variants
 Depth
first with cutoff C
– Don’t expand a node if the path to root > C
 Iterative
Deepening
– Start the cutoff C=1
– Increment the cutoff after completing all
depth first probes for C
Oct 6, Fall 2005
Game Design
29
Iterative Deepening
Root
Root
Child1
Child1
Child2
Root
Root
Root
Child1
Child2
GChild1
Child1
GChild3
GChild1
Oct 6, Fall 2005
GChild4
GChild2
Game Design
30
Bidirectional Search
 Start
2 Trees
– Start one at start point
– Start one at goal point
Oct 6, Fall 2005
Game Design
31
Avoid Repeating States
 Mark
states you have seen before
 In path planning:
– Mark minimum distance to this node
Oct 6, Fall 2005
Game Design
32
Heuristic Search
 Apply
approximate knowledge
– Distance measurements to goal
– Cost estimates to goal
 Use
the estimate to steer exploration
Oct 6, Fall 2005
Game Design
33
Greedy Search
 Expand
cost
the node that yields the minimum
– Expand the node that is closest to target
– Depth first
– Minimize the function h(n) the heuristic cost
function
 Not
Complete!
 Local Minima
Oct 6, Fall 2005
Game Design
34
A* Search
 Minimize
 g(n)
sum of costs
+ h(n)
– Cost so far + heuristic to goal
 Guaranteed
to work
– If h(n) does not overestimate cost
 Examples
– Euclidean distance
Oct 6, Fall 2005
Game Design
35
A* Search
 Fails
when there is no solution
– Avoid searching the whole space
– Do bi-directional search
– Iterative Deepening
Oct 6, Fall 2005
Game Design
36
Coordinated Movement
 Somewhat
one NPC
more difficult than moving just
– Disappearing goal
– New obstacles in path
– Collisions with other NPCs
– Groups of units
– Units in formation
Oct 6, Fall 2005
Game Design
37
Coordinated Elements
 Collision
detection
– Detection of immediate collisions
– Near future
 Perform
the usual collision detection
optimizations
– Spatial hierarchies
– Simplified tests
– Unit approximations
Oct 6, Fall 2005
Game Design
38
Collision Detection
 Levels
of collision
– Hard radius (small)
• Must not have 2 units overlap hard radius
– Soft radius (large)
• Soft overlap not preferred, but acceptable
Oct 6, Fall 2005
Game Design
39
Collision Detection
 With
movement, need to avoid problems
with bad temporal samples
– Sample frequently
– Detect collisions with extruded units
– Use a movement line
– Detect distance from Line segment
Oct 6, Fall 2005
Game Design
40
Unit Line
 Unit
line follows path
 Can implement minimum turn radius
 Gives mechanism for position prediction
 Connected line segments
– Time stamps per segment
– Orientation per segment
– Acceleration per segment
Oct 6, Fall 2005
Game Design
41
Prediction line
 Given
prediction, use next prediction as
move
 Prediction must have dealt with collisions
already
Oct 6, Fall 2005
Game Design
42
Collision Avoidance Planning
 Don’t
search a new path at each collision
 Adopt a Priority Structure
– Higher priority items move
– Lower priority items wait or get out of the
way
 Case-based
reasoning to perform local
path reordering
 Pairwise comparison
Oct 6, Fall 2005
Game Design
43
Collision Resolution
Summary
 Favor:
– High priority NPCs over Low Priority
– Moving over non-moving
 Lower
Priority NPCs
– Back out of the way
– Stop to allow others to pass
 General
– Resolve all high-priority collisions first
Oct 6, Fall 2005
Game Design
44
Avoidance
 Case
1: Both units standing
– Lower priority unit does nothing itself
– Higher unit
• Finds which unit will move
• Tells that unit to resolve hard collision by shortest
move
Oct 6, Fall 2005
Game Design
45
Avoidance
 Case
2: We’re not moving, other unit is
moving
– Non-moving unit stays immobile
Oct 6, Fall 2005
Game Design
46
Avoidance
 Case
3: We’re moving, other is not:
– If lower priority immobile unit can get out
of the way:
• Lower unit gets out of way
• Higher unit moves past lower to get to collision
free point
– Else If we can avoid other unit
• Avoid it!
Oct 6, Fall 2005
Game Design
47
Avoidance
 Case
3: We’re moving, other is not:
– Else: Can higher unit push lower along
• Push!
– Else: Recompute paths!
Oct 6, Fall 2005
Game Design
48
Avoidance
 Case
4: Both units moving
– Lower unit does nothing
– If hard collision inevitable and we are high
unit
• Tell lower unit to pause
– Else: If we are high unit
• Slow lower unit down and compute collision-free
path
Oct 6, Fall 2005
Game Design
49
Storage
 Store
predictions in a circular buffer
 If necessary, interpolate between
movement steps
Oct 6, Fall 2005
Game Design
50
Planning
 Prediction
implies
– A plan for future moves
 Once
a collision has been resolved
– Record the decision that was made
– Base future movement plans on this
Oct 6, Fall 2005
Blocking Get-To
unit
Point
Predicted Position
Game Design
51
Units, Groups, Formations
 Unit
– An individual moving NPC
 Group
– A collection of units
 Formation
– A group with position assignments per group
member
Oct 6, Fall 2005
Game Design
52
Groups
 Groups
stay together
– All units move at same speed
– All units follow the same general path
– Units arrive at the same time
Obstruction
Goal
Oct 6, Fall 2005
Game Design
53
Groups
 Need
a hierarchical movement system
 Group structure
– Manages its own priorities
– Resolves its own collisions
– Elects a commander that traces paths, etc
• Commander can be an explicit game feature
Oct 6, Fall 2005
Game Design
54
Formations
 Groups
with unit layouts
– Layouts designed in advance
 Additional
States
– Forming
– Formed
– Broken
 Only
Oct 6, Fall 2005
formed formations can move
Game Design
55
Formations

Schedule arrival into position
– Start at the middle and work outwards
– Move one unit at a time into position
– Pick the next unit with
• Least collisions
• Least distance
– Formed units have highest priority
• Forming units medium priority
• Unformed units lowest
Oct 6, Fall 2005
Game Design
56
Formations
Not so good…
1
1
2
3
4
7
5
9
3
9
2
6
7
8
5
6
8
4
1
2
7
3
5
9
6
Better…
Oct 6, Fall 2005
8
Game Design
4
57
Formations: Wheeling
 Only
necessary for non-symmetric
formations
1
2
3
4
Break formation here
Stop motion temporarily
5
5
Set re-formation point here
4
3
2
Oct 6, Fall 2005
1
Game Design
58
Formations: Obstacles
1
2
1
2
3
3
4
5
Scale formation layout to
fit through gaps
1
4 5
Subdivide formation
around small obstacles
Oct 6, Fall 2005
1
Game Design
2
2
3
4
3
5
4
5
59
Formations
 Adopt
a hierarchy of paths to simplify
path-planning problems
 High-level path considers only large
obstacles
– Perhaps at lower resolution
– Solves problem of gross formation
movement
– Paths around major terrain features
Oct 6, Fall 2005
Game Design
60
Formations
 Low-level
path
– Detailed planning within each segment of
high-level path
– Details of obstacle avoidance
 Implement
stack
path hierarchy with path
Avoidance Path
Low-Level Path1
High-Level Path
Oct 6, Fall 2005
High-Level Path
Low-Level Path2
Low-Level Path2
High-Level Path
High-Level Path
Game Design
61
Path Stack
Avoidance Path
Low-Level Path1
High-Level Path
1
High-Level Path
Low-Level Path2
Low-Level Path2
High-Level Path
High-Level Path
2
Low-level path
Avoidance path
Oct 6, Fall 2005
Game Design
62
Compound Collisions
 Solve
collisions pairwise
 Start with highest priority pair
– Then, resolve the next “highest priority pair”
now colliding
Oct 6, Fall 2005
Game Design
63
General
 Optimize
for 2D if possible
 Use high-level and low-level pathing
 Units will overlap!
 Understand the update loop
– It affects unit movement
 Maintain
Oct 6, Fall 2005
a brief collision history
Game Design
64
References
 Used
with permission from CS4455 course
at GA Tech by Chris Shaw
 http://www.cc.gatech.edu/classes/AY2005
/cs4455_fall/
Oct 6, Fall 2005
Game Design
65