oct 6, fall 2005game design1 ai in games simple steering, flocking production rules fsms,...
TRANSCRIPT
Oct 6, Fall 2005 Game Design 1
AI in games
Simple steering, FlockingProduction rulesFSMs, Probabilistic FSMsPath Planning, SearchUnit MovementFormations
Oct 6, Fall 2005 Game Design 2
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 3
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 4
Learning/Adaptation Increment aggressiveness if player
is doing well– 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 5
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 6
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 games have used AI effectively?
Oct 6, Fall 2005 Game Design 8
Enhancements to Chase
Speed Control– Velocity, Acceleration max/min– Limited turning Radius
Randomness– Moves– Patterns
Oct 6, Fall 2005 Game Design 10
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 11
Group Behaviors
Lots of background characters to create a feeling of motion
Make area appear interesting, rich, populated
Oct 6, Fall 2005 Game Design 12
Flocking -- (HalfLife, Unreal)
What might go wrong?
Simple version:Compute trajectory to head towards centroid
Oct 6, Fall 2005 Game Design 13
Group Behaviors Reaction to neighbors -- Spring
Forces
Craig ReynoldsSIGGRAPH 1987
Oct 6, Fall 2005 Game Design 14
What could go wrong?
Repulsive springs around obstacles Does not handle changes in strategy
Exactly aligned Forces balance out in dead end
Oct 6, Fall 2005 Game Design 16
Production Rules
If( enemy in sight ) fireIf( big enemy in sight ) run awayIf( --- ) ----
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 17
Finite State Machines
States: Action to take– Chase– Random Walk– Patrol– Eat
Transitions:– Time– Events– Completion of action
Chopping
Take Wood to closest depot
Enough wood
Drop wood:
Go back to woods
At depot
At woods
Oct 6, Fall 2005 Game Design 18
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 19
Probabilistic State Machines Personalities
– Change probability that character will perform a given action under certain conditions
Aggressive PassiveAttack 50% 5%Evade 5% 60%Random 10% 10%Flock 20% 20%Pattern 15% 5%
Oct 6, Fall 2005 Game Design 20
Probabilistic Example
Fire At Enemy
Run out of Range
Enemy Within Hand-to-Hand Range
50%
Far Enough to Take Shot
Run Away
Enemy Within Hand-to-Hand Range
50%
Oct 6, Fall 2005 Game Design 21
Probabilistic State Machines
Other aspects:– Sight– Memory– Curiosity– Fear– Anger– Sadness– Sociability
Modify probabilities on the fly?
Oct 6, Fall 2005 Game Design 22
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 23
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 24
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 25
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 26
Breadth-First Search
Expand Root node– Expand all Root node’s children
• Expand all Root node’s grandchildren
Problem: Memory size
Root Root
Child1 Child2
Root
Child1 Child2
GChild1 GChild2 GChild3 GChild4
Oct 6, Fall 2005 Game Design 27
Uniform Cost Search
Modify Breadth-First by expanding cheapest nodes first
Minimize g(n) cost of path so far
Root
Child1 Child2
GChild19
GChild25
GChild33
GChild48
Oct 6, Fall 2005 Game Design 28
Depth First Search
Always expand the node that is deepest in the tree
Root
Child1
GChild1 GChild2
Root
Child1 Root
Child1
GChild1
Oct 6, Fall 2005 Game Design 29
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 30
Iterative DeepeningRoot
Child1
Root
Child1
GChild1
Root
Child1 Child2
Root
Child1
GChild1 GChild2
Root
Child2
GChild3 GChild4
Oct 6, Fall 2005 Game Design 31
Bidirectional Search
Start 2 Trees– Start one at start point– Start one at goal point
Oct 6, Fall 2005 Game Design 32
Avoid Repeating States
Mark states you have seen before In path planning:
– Mark minimum distance to this node
Oct 6, Fall 2005 Game Design 33
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 34
Greedy Search
Expand the node that yields the minimum cost – 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 35
A* Search
Minimize sum of costs g(n) + 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 36
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 37
Coordinated Movement
Somewhat more difficult than moving just one NPC– Disappearing goal– New obstacles in path– Collisions with other NPCs– Groups of units– Units in formation
Oct 6, Fall 2005 Game Design 38
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 39
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 40
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 41
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 42
Prediction line
Given prediction, use next prediction as move
Prediction must have dealt with collisions already
Oct 6, Fall 2005 Game Design 43
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 44
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 45
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 46
Avoidance
Case 2: We’re not moving, other unit is moving– Non-moving unit stays immobile
Oct 6, Fall 2005 Game Design 47
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 48
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 49
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 50
Storage
Store predictions in a circular buffer If necessary, interpolate between
movement steps
Oct 6, Fall 2005 Game Design 51
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
Blocking unit
Get-ToPoint
Predicted Position
Oct 6, Fall 2005 Game Design 52
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 53
Groups
Groups stay together– All units move at same speed– All units follow the same general path– Units arrive at the same time
ObstructionGoal
Oct 6, Fall 2005 Game Design 54
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 55
Formations
Groups with unit layouts– Layouts designed in advance
Additional States– Forming– Formed– Broken
Only formed formations can move
Oct 6, Fall 2005 Game Design 56
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 57
Formations
12
3
4
56
7
8
9
1 2 3
4 5
6 7 89
12
3
4
56
7
8
9
Not so good…
Better…
Oct 6, Fall 2005 Game Design 58
Formations: Wheeling
Only necessary for non-symmetric formations
1 2 3 4 5
1
2
3
4
5
Break formation hereStop motion temporarily
Set re-formation point here
Oct 6, Fall 2005 Game Design 59
Formations: Obstacles
1 2 3 4 5 Scale formation layout to fit through gaps
1 2 3 4 5 1 2 3 4 5
1 2 3 4 5Subdivide formation around small obstacles
Oct 6, Fall 2005 Game Design 60
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 61
Formations
Low-level path– Detailed planning within each segment
of high-level path– Details of obstacle avoidance
Implement path hierarchy with path stack
High-Level Path
Low-Level Path1
High-Level Path High-Level Path
Low-Level Path2
High-Level Path
Low-Level Path2
Avoidance Path
Oct 6, Fall 2005 Game Design 62
Path Stack
High-Level Path
Low-Level Path1
High-Level Path High-Level Path
Low-Level Path2
High-Level Path
Low-Level Path2
Avoidance Path
1 2
Low-level path
Avoidance path
Oct 6, Fall 2005 Game Design 63
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 64
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 a brief collision history