2.3

1
2.3 Path Look-Up Tables

• Owen Cummings

2
William van der Sterren

• Company
• CGF-AI specializes in tactical AI for 3D virtual
  worlds autonomous AI squads and individuals,
  squad maneuvers and team tactics, dynamic
  response to threats, smart use of the terrain,
  human-like situational awareness, and
  interpretation of combat situations.
• Products
• William is contributing to the AI for Guerrilla's
  Killzone (PlayStation2, 2004, published by Sony
  (SCEE / SCEA)). Killzone already collected an IGN
  Award "PlayStation 2 Best of Show" and another
  IGN Award "Best Shooter" at the May 2004 E3
  conference / trade show.
• William contributed to the AI used in Guerrilla's
  Shellshock Nam '67 (PlayStation2, Xbox, PC,
  2004, published by Eidos Interactive).

3
Why use Path Look-Up Tables?

• Path Look-Up tables can be 10 to 200 times
  faster than searching with A
• However, the amount of memory required for the
  tables often prohibits using them for anything
  other than small levels
• Also they have problems reflecting changes in
  terrain

4
Path Look-Up Matrix

• For N waypoints, the matrix has size NxN
• Each entry in the matrix contains, for the
  corresponding source and destination pair, the
  next neighboring waypoint to visit or a no path
  available marker.

5
Simple Example
1
3
5
6
7
A(2,9) No path sentinel
A(2,9) 1
A(1,9) 3
Failure!
8
Start
A(3,9) 5
So this means that we know right away with one
memory access and without searching that a path
does not exist from node 2 to node 9
2
4
9
A(5,9) 6
End
A(6,9) 7
A(7,9) 8
A(8,9) 9
Success!
6
Problems with Path Look-Up Matrices

• Memory Consumption
• Increase quadratically with number of waypoints
• Typical number of waypoints between 256 and 65535
  so 2 bytes per entry
• For 1000 waypoints -gt 2MB
• For 2000 waypoints -gt 8MB
• This limits the use of these tables to small
  levels

7
Problems continued

• Static representation of terrain
• Can only reflect changes via update or patch
• Updating the table is an O(n3) operation
• Patching also problematic
• To handle a central door being unlocked for a
  1000 waypoint level, the full 2MB table would
  have to be replaced

8
Smaller Indexed Path Look-Up Matrix

• Replace the 2 byte next waypoint to visit by a 4
  bit index in the waypoints list of outgoing
  waypoints
• Assumes a maximum of 15 outgoing waypoints per
  waypoint
• Memory Consumption
• NN0.5 for the matrix N152.0 for the
  outgoing waypoint list
• 542KB for 1000 waypoints
• 4MB for 2000 waypoints

9
Smaller Indexed Path Look-Up Matrix

• Pros
• Memory consumption reduced by a factor of 4
• Can deal with 4 times as much terrain for the
  same amount of memory, at a mere 5-percent
  reduction in performance
• Cons
• Still scales quadratically with number of
  waypoints
• Still hard to accommodate terrain changes

10
But

• Using 1 MB for path look-up tables is not an
  option on many game platforms
• So we need a different solution

11
Area-Based Path Look-Up Table

• Area-Based Approach
• Do path look-up at two levels
• Set of portals
• Clusters of waypoints (areas)

12
How it works

• To get from waypoint a to waypoint b
• Determine the nearby portals for a and b
• Determine the shortest path between these portals
  using a portal path look up table
• Translate this portal path into a waypoint path,
  for each pair of portals on the portal path,
  retrieve the waypoint path between them using the
  look-up table of the area connecting this portal
  pair

13
How to Partition the Terrain?

• Areas
• Should consist of co-located waypoints with good
  interconnectivity
• Small borders to neighboring areas
• Optimal area size is sqrt(N)
• Portals
• Waypoints that connect the areas
• Try to keep portals per area lt 10 for faster and
  smaller look up tables

14
When the number of areas is tripled, the memory
consumption of the area based look up tables is
3.3 times larger as opposed to 32 as large for
the other LUTs This is because the portal
table increases by a factor of 32 and the area
tables only increase by a factor of 3 and
because the portal table is much smaller this
only results in a total memory increase of 3.3
15
The Algorithm in more detail

• To look up a path from a (in area A) to b (in
  area B)
• If A B, retrieve the local path from area As
  own look-up matrix and we are done
• If A ? B do the following
• For source area A, retrieve the outgoing
  connections Ap
• For destination area B, retrieve the incoming
  portals Bp
• Pick the pair (Apo, Bpi) that yields the shortest
  path (a - Apo - Bpi -b)
• For the pair Apo, Bpi, retrieve a path consisting
  of inter-area connections
• Finally, retrieve and construct the detailed
  waypoint path, by retrieving the in-area path for
  each area on the path

16
What do we need to do this?

• For each area, we need to record how to travel
  from any waypoint in this area to another
  waypoint also in the area
• Need to record all connections from that area to
  other areas
• For every connection between two areas, we need
  to record the cost and shortest path to any other
  inter-area connection

17
Demo

• Show the demo program

18
Terrain Representation issues

• For a map with 1,500 waypoints and 20 areas,
  there might be some 300 waypoints lying on the
  border of connected areas
• Find the minimal set of waypoints that together
  still represent all inter-area connections
• Typically 60 75 smaller
• More efficient look-up at higher level
• Smaller inter-area travel info matrix

19
Per Area Information

• Waypoints within the area, and the connected
  portals (2 bytes per waypoint)
• Incoming and outgoing waypoints in dedicated
  arrays (2 bytes per waypoint)
• All in-area paths, as a matrix containing the
  index to the next neighbor. Index is a 1-byte
  index into the array of area waypoints.
• Travel time to the outgoing portal, for every
  combination of waypoint, outgoing portal (1 byte
  per entry)
• Travel time from the incoming portal, for every
  combination of incoming portal, waypoint (1 byte
  per entry)

20
(No Transcript)
21
Portal Path Information

• Matrix that contains for every pair of portal
  waypoints (pi, po)
• Travel time from pi to po or no path (2 bytes)
• Next portal to visit to get to po (2 bytes)
• Next area to traverse to get from pi to the next
  portal (2 bytes)

22
Performance Comparison
Short Paths 0 to 16 waypoints Long Paths 17
waypoints Far Travel Costs costs of paths
longer than 16 waypoints. AI typically
compares travel costs when selecting the nearest
item or power up to fetch. Path look-up matrices
offer 50 to 150 times better performance than A,
and 2 to 5 times better than area based Area
based look-up tables provide a speed up of 10 to
80 times
23
Pesky Dynamic Terrain

• Area based look up tables are much more suitable
  for handling terrain changes because of the
  partitioning
• Worst case the patch consists of several tens of
  KB when the portal table and an area table have
  to be changed
• More complicated when several portals can be
  opened or closed in arbitrary order. Have to
  compute various patches for all sequences

24
Quake 3

• Quake 3 Arena uses an approach similar to the
  area-based look-up tables, but for volume-based
  (as opposed to waypoints) navigation data.
• Link to pdf
• Section 6 and 12
• Very in depth, very technical, very confusing

25
2.4 - An Overview of Navigation Systems

• This exciting chapter goes over software
  engineering strategies to implement a navigation
  system
• What is a navigation system?
• A navigation system is a separate component
  responsible for synthesizing movement behaviors.

26
Levels of Abstraction

• Choosing the level of abstraction mostly depends
  on the complexity of the agent AI
• Planner Only the shortest path algorithm is
  abstracted out and implemented separately. Agent
  is responsible for making the path request and
  interpreting the result
• Pathfinder Gives slightly more responsibility
  to the navigation system, the pathfinder would
  deal with the execution of plans.
• Sub-architecture Its possible to use an AI
  architecture specifically for navigation. This
  will generally be composed of different movement
  behaviors and planning abilities, including the
  terrain model

27
Navigation Interfaces

• Agent AI has a certain level of complexity in the
  desires and motivations
• Creating intelligent movement involves
  transmitting these motivations to the navigation
  system
• The interface allows information about these
  motivations to be expressed

28
Interface Expressiveness

• Choosing an interface involves making a
  compromise between focus and flexibility
• Highly focused can be better tuned to a
  specific problem
• Flexible can have the expressiveness to handle
  a wider variety of scenarios

29
Different levels of expressiveness

• Existing paradigms
• Single Pair Two points are specified in the
  world (origin and destination), and the shortest
  path between them is returned
• Weighted Destinations Instead of limiting the
  requests to one destination, this can be extended
  to multiple goals, each with its own reward
  coefficient. An optimal path that maximizes the
  tradeoff between reward and cost
• Spatial Desires Abstracting out space, its
  possible to specify the movement by passing the
  motivations from the agent to the navigation
  system (e.g. get armor or a weapon)

30
AI Paradigms for Movement

• Reactive Behaviors
• Takes sensory input and performs direct mapping
  to determine output
• Possible Behaviors obstacle avoidance, seeking,
  fleeing
• Perfect for simple situations
• Cant handle traps or complex layouts
• Deliberative Planning
• Provably optimal paths
• Higher-level of spatial intelligence plans made
  according to terrain representation
• Hybrid Systems
• Combine common sense of reactive behaviors with
  intelligence of planning

31
Implementation

• Reactive Behaviors
• Steering behaviors based on highly explicit
  mathematical equations
• Two problems integration of multiple behaviors
  and realism
• Prioritize behaviors and use fuzzy logic to
  simulate realism
• Deliberative Planning
• Not necessarily a search, other techniques can be
  more efficient
• Precompute everything (like the look-up tables)
• Reactive approximation techniques to build near
  optimal paths without a search
• Dynamic environments make things tricky
• Trigger a replan when the conditions have changed
  sufficiently
• Quality of service algorithms

32
Conclusion

• The development of a navigation system takes more
  than understanding a heuristic search algorithm
• Numerous issues involved in synthesizing
  realistic movement in games
• Ignoring these can lead to a suboptimal solution,
  unnecessarily complex code, and visible problems
  with the behaviors