AI in games
Simple steering, Flocking
Production rules
FSMs, Probabilistic FSMs
Path Planning, Search
Unit Movement
Formations
Oct 30, Fall 2006
IAT 410
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 30, Fall 2006
IAT 410
2
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 30, Fall 2006
IAT 410
4
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 30, Fall 2006
games have used AI effectively?
IAT 410
6
Chase/Evade
 Algorithm
Oct 30, Fall 2006
for the predator?
IAT 410
7
Enhancements to Chase
 Speed
Control
– Velocity, Acceleration max/min
– Limited turning Radius
 Randomness
– Moves
– Patterns
Oct 30, Fall 2006
IAT 410
8
Enhancements to Chase
Anticipation
Build a model of user behavior
Oct 30, Fall 2006
IAT 410
9
Steering Behaviors
Pursue
 Evade
 Wander
 Obstacle Avoidance
 Wall/Path following
 Queuing

 Combine
behaviors with weights
 What could go wrong?
Oct 30, Fall 2006
IAT 410
10
Group Behaviors
 Lots
of background
characters to
create a feeling of
motion
 Make area appear
interesting, rich,
populated
Oct 30, Fall 2006
IAT 410
11
Flocking -- (HalfLife, Unreal)
Simple version:
Compute trajectory to
head towards centroid
 What
Oct 30, Fall 2006
might go wrong?
IAT 410
12
Group Behaviors
 Reaction
Oct 30, Fall 2006
Craig Reynolds
SIGGRAPH 1987
to neighbors -- Spring Forces
IAT 410
13
What could go wrong?
Exactly aligned
 Repulsive
Forces balance out in
dead end
springs around obstacles
 Does not handle changes in strategy
Oct 30, Fall 2006
IAT 410
14
“Perceptual” Models
Oct 30, Fall 2006
IAT 410
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 30, Fall 2006
IAT 410
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 30, Fall 2006
At woods
IAT 410
At depot
Drop wood:
Go back to woods
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 30, Fall 2006
IAT 410
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 30, Fall 2006
IAT 410
19
Probabilistic Example
Fire At Enemy
Enemy Within Handto-Hand Range
50%
Enemy Within Handto-Hand Range
50%
Run out of
Range
Oct 30, Fall 2006
Run Away
Far Enough to
Take Shot
IAT 410
20
Probabilistic State Machines

Other aspects:
–
–
–
–
–
–
–

Sight
Memory
Curiosity
Fear
Anger
Sadness
Sociability
Modify probabilities on the fly?
Oct 30, Fall 2006
IAT 410
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 30, Fall 2006
IAT 410
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 30, Fall 2006
IAT 410
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 30, Fall 2006
IAT 410
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 30, Fall 2006
IAT 410
25
Breadth-First Search

Expand Root node
– Expand all Root node’s children
• Expand all Root node’s grandchildren
Root
Root
Child1

Root
Child2
Child1
Problem: Memory size
Oct 30, Fall 2006
GChild1
IAT 410
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 30, Fall 2006
GChild2
5
GChild3
3
IAT 410
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 30, Fall 2006
IAT 410
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 30, Fall 2006
IAT 410
29
Iterative Deepening
Root
Root
Child1
Child1
Child2
Root
Root
Root
Child1
Child2
GChild1
Child1
GChild3
GChild1
Oct 30, Fall 2006
GChild4
GChild2
IAT 410
30
Bidirectional Search
 Start
2 Trees
– Start one at start point
– Start one at goal point
Oct 30, Fall 2006
IAT 410
31
Avoid Repeating States
 Mark
states you have seen before
 In path planning:
– Mark minimum distance to this node
Oct 30, Fall 2006
IAT 410
32
Heuristic Search
 Apply
approximate knowledge
– Distance measurements to goal
– Cost estimates to goal
 Use
the estimate to steer exploration
Oct 30, Fall 2006
IAT 410
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 30, Fall 2006
IAT 410
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 30, Fall 2006
IAT 410
35
A* Search
 Fails
when there is no solution
– Avoid searching the whole space
– Do bi-directional search
– Iterative Deepening
Oct 30, Fall 2006
IAT 410
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 30, Fall 2006
IAT 410
37
Coordinated Elements
 Collision
detection
– Detection of immediate collisions
– Near future
 Perform
the usual collision detection
optimizations
– Spatial hierarchies
– Simplified tests
– Unit approximations
Oct 30, Fall 2006
IAT 410
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 30, Fall 2006
IAT 410
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 30, Fall 2006
IAT 410
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 30, Fall 2006
IAT 410
41
Prediction line
 Given
prediction, use next prediction as
move
 Prediction must have dealt with collisions
already
Oct 30, Fall 2006
IAT 410
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 30, Fall 2006
IAT 410
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 30, Fall 2006
IAT 410
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 30, Fall 2006
IAT 410
45
Avoidance
 Case
2: I’m not moving, other unit is
moving
– Non-moving unit stays immobile
Oct 30, Fall 2006
IAT 410
46
Avoidance
 Case
3: I’m 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 30, Fall 2006
IAT 410
47
Avoidance
 Case
3: I’m moving, other is not:
– Else: Can higher unit push lower along
• Push!
– Else: Recompute paths!
Oct 30, Fall 2006
IAT 410
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 30, Fall 2006
IAT 410
49
Storage
 Store
predictions in a circular buffer
 If necessary, interpolate between
movement steps
Oct 30, Fall 2006
IAT 410
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 30, Fall 2006
Blocking Get-To
unit
Point
Predicted Position
IAT 410
51
Units, Groups, Formations
 Unit
– An individual moving NPC
 Group
– A collection of units
 Formation
– A group with position assignments per group
member
Oct 30, Fall 2006
IAT 410
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 30, Fall 2006
IAT 410
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 30, Fall 2006
IAT 410
54
Formations
 Groups
with unit layouts
– Layouts designed in advance
 Additional
States
– Forming
– Formed
– Broken
 Only
formed formations can move
Oct 30, Fall 2006
IAT 410
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 30, Fall 2006
IAT 410
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 30, Fall 2006
8
IAT 410
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 30, Fall 2006
1
IAT 410
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 30, Fall 2006
IAT 410
1
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 30, Fall 2006
IAT 410
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 30, Fall 2006
High-Level Path
IAT 410
Low-Level Path2
Low-Level Path2
High-Level Path
High-Level Path
61
Path Stack
Avoidance Path
Low-Level Path1
High-Level Path
1
Low-Level Path2
Low-Level Path2
High-Level Path
High-Level Path
High-Level Path
2
Low-level path
Avoidance path
Oct 30, Fall 2006
IAT 410
62
Compound Collisions
 Solve
collisions pairwise
 Start with highest priority pair
– Then, resolve the next “highest priority pair”
now colliding
Oct 30, Fall 2006
IAT 410
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 30, Fall 2006
a brief collision history
IAT 410
64