Administrative Project due Tuesday: –Email your code to Yisheng Tang ([email protected]) no later...
-
Upload
maurice-wootton -
Category
Documents
-
view
220 -
download
0
Transcript of Administrative Project due Tuesday: –Email your code to Yisheng Tang ([email protected]) no later...
Administrative
• Project due Tuesday:– Email your code to Yisheng Tang ([email protected])
no later than 11:59PM EST Monday February 6 (the day BEFORE the competition)
– Presentation - A 3-5 slide power point presentation giving the basics of your bot design. What makes your bot different? Why will it win? This must be short (i.e., 5 minutes). Please bring a printout of your presentation
• A question: how many of you are interested in a career in the game industry?
Pathfinding: Region Representation and Looking
Beyond A*
Sources:• My own• Joseph Siefers presentation 2008• Jeremy Christman 2008• Wikipedia• Michael Moll, 2006 (main source)
Uninformed Search: Depth-First Search (DFS)
DFS(G,v,d) // G is a graph, v is the start and d is the destination
s emptyStack()
for each vertex u do visited[u] false; predecessor[u] null.
s.push(v)
while (not(s.empty()) do
v pop(s);
if (v = d) then return true;
if (not(visited[v])) then
visited[v] true;
for each unvisited neighbor w of v do
s.push(w); predecessor[w] v;
return false
Uninformed Search: Breadth-First Search (BFS)
BFS(G,v,d)
s emptyQueue ()
for each vertex u do visited[u] false; predecessor[u] null.
s.push(v)
while (not(s.empty()) do
v pop(s);
if (v = d) then return true;
if (not(visited[v])) then
visited[v] true;
for each unvisited neighbor w of v do
s.push(w); predecessor[w] v;
return false
Uninformed Search Strategies
• estimated with b= 10, a search rate of 105 nodes/sec, and 1 KiB/node• 1 mebibyte is 220 bytes• 1 tebibyte = 240 bytes• 1 pebibyte = 250 bytes• 1 exbibyte = 260 bytes
Depth(Breadth First)
Nodes Time Memory
2 110 1 sec 1MiB
4 11,100 11 sec 106 MiB
6 107 19 minutes 10 GiB
8 109 31 hours 1 TiB
10 1011 129 days 101 TiB
12 1013 35 years 10 PiB
14 1015 3,523 years 1 EiB
Credit: AIMA fig 3.11, pg 74
Informed Search: A* AlgorithmAstar(G,v,d, h, cost) // h is the heuristic function; cost(v,w) is the weight of the (v,w) edge
open emptyList(); open.add(v); closed emptyList();
for each vertex u do g(u) ; predecessor(u) null
g(v) 0
while (not(open.empty())) do
v open.select-element-with-lowest-f-value(g,h); //also removes v from open; f=g+h
if (v = d) then return true;
closed.add(v);
for each neighbor w of v do
if (open.contains(w)) then // if the function is not consistent has to check the
if (g(v) + cost(v,w) < g(w)) then // closed nodes as well
g(w) g(v) + cost(v,w)
predecessor[w] v
else if (not (closed.contains(w))) then
open.add(w)
g(w) g(v) + cost(v,w)
predecessor[w] v
return false
A* Search: A Look Back…• Breadth-First Search • A*, Manhattan, W=3
75% LESS NODES!But we also show examples where A* performs poorly
Memory Capacity
• Why not exploit this (i.e., use memory to improve pathfinding speed?• What is the memory complexity of A*?O(size of the graph)
The Increase in Memory Capabilities has Consequences
• Every year, computers are made with more and more memory
• This makes for bigger and bigger maps in games• Significant CPU time must be spent on pathfinding
which could be better utilized elsewhere• What can be done?
Regular Grids
• Advantages – Random access lookup (O(1)) to determine what tile lies
at any coordinate– Complete
• Negatives– Usually requires large number of nodes to accurately
represent world O(n2)– Path Quality
- Agent can only walk in four cardinal directions? That’s no fun.- Let them walk diagonals! Still not much fun
Representation of regions (2): Graphs
• Regions can be represented as graphs• Grids are graphs too
– Each cell is a node and edges are adjoining cells– Undirected graph could tell us about topography, etc,
whereas array can’t
Corner Graphs
• How do we generate them?1.Identify convex corners2. Check if character can walk in straight line between them3. Add edge if needed
• Advantages– Less memory– Faster generation
• Negatives – Character will “walk on a rail” hugging edges of obstacles instead
of walking through open space– And what about different sized characters?– Lookup is O(n2), have to check every node in graph against every
other.
• How do we generate? – Place nodes wherever we want (suits 3-D worlds But
requires hand tuning to be effective )• Advantages
– Reduce memory footprint from regular grids, reduce wall hugging from corner graphs
– Work well in “human” architectures• Negatives
– Still O(n2)– Path Quality vs. Simplicity– Works poorly in open areas
Waypoint Graphs
Circle-Based Waypoint
• Advantages– Only look at overlapping circles, alleviating O(n2)
problem from before– Easier to obtain optimal paths– Works well in open terrain
• Negatives– Doesn’t work as well in maps that aren’t circle friendly
Space-Filling Volumes
• How do we generate?– Seed and Grow (heuristic – best fill is NP-hard)– Make Grid and Merge
• Very similar to circle-based, but handles angles better
Representation of regions (3): Navigation Meshes
• Enough with the graphs already!• Let’s try and cover walkable surfaces with convex
polygons• Character can travel between adjoining polygons
Navigation Meshes
• How do we generate? – By hand (time consuming)
• Automated tools to analyze and optimize geometry of world
• Too complex and not represented as a single polygon mesh, instead may be overlapping, etc
Navigation Meshes
• Advantages– Quickly find optimal paths independent of character
shapes and capabilities– Handle indoor and outdoor terrains well
• Negatives– Can become complex and expensive memory wise– Difficult to generate
Interacting with Pathfinding
• What about dynamic objects in world?
• All the representations discussed are static and obviously can’t handle a dynamic world directly
• These representations need to be able to provide information to the pathfinding algorithm– Waypoint Graphs and Corner
Graphs don’t illustrate walkable surfaces
– Meshes and Grids do map every walkable surface
– Space-filling volumes and Circle Waypoints provide some representation of walk able areas
Further Options for Representation
• Any other ideas of what we can do to make job of path finding algorithm easier?
• Hierarchical Representations– Choose most suitable scheme
for given world, and break up into more manageable pieces
Cautionary Tale: Automatic Generation of Navigation Mesh
• Two clips:– http://
www.youtube.com/watch?v=swvLJ_DcXPA&feature=related
– http://www.youtube.com/watch?v=6XbiBDMCJ98– http://www.youtube.com/watch?v=9clDHkbRbUs– http://www.youtube.com/watch?v=jUO-qoH7twM
• It still needs manual adjustment (and/or wait until players find it and complain)
Pathfinding
• Now that we have world represented, how do we plan movement?– A*, Depth-First search, Dijkstra
• But: dynamic path finding is expensive– Precompiled solutions can eliminate runtime cost, but
memory expensive• Although memory is less of a problem nowadays• Navigation with transition tables works well• Navigation Set Hierarchy have shown to be particularly
effective
Transition Table• Main element in pre computed solutions is a lookup
table. This is how navigation in many games is implemented.
• Each entry represents next step to take from one node to some goal node
Transition Table
• Do not need to search nodes at running time, just series of lookups. So it is O(|length of the path|)– Very fast
• But becomes memory expensive as size of world grows– How expensive? n2
• …Is it possible to shrink transition tables?
Yes; using hierarchies
Building a Transition Table: The Floyd–Warshall algorithm
F-W(G,cost) // G is a graph
//cost(v,w) is the weight of (v,w) (if no (v,w) edge, then cost(v,w)= ) (cos(u,u) = 0 for all u)
return transition
for each pair vertex (v,w) do path(v,w) cost(v,w) if (path(v,w) ) then transition(v,w) w else transition(v,w) null
for each node u do for each node v do for each node w do if path(v,u) + path(u,w) < path(v,w) then path(v,w) path(v,u) + path(u,w) transition(v,w) u
Time: O(|V|3)Space: |V|2
Navigation Set
• Self-contained collection of nodes that requires no links to external nodes to complete a path
• Nodes can be members of more than one set• Goal: Find some way to partition large Navigation
Sets into smaller ones
Interface Nodes and Sets
• Need to account for paths that cross navigation sets• Any node that connects to a node in another
navigation set is an interface node• Have a second layer of nodes in addition to
navigation sets, called interface set• Interface set itself is a navigation set
– Therefore, can make transition table for it too
Complete Hierarchy
• 21 nodes– 1 Navigation Set = 441 Table Entries (21*21)– 4 Navigation Sets = 183 Table Entries (7*7 + 7*7 + 7*7 + 6*6)
Constructing the Hierarchy
Two goals to process– How many tables to create?
• Amount of data needed is 1/n of original size + interface set• As size of navigation sets increase, cost of interface set becomes less
a factor
– Where to place boundaries?• Keep interface nodes as low as possible
Building a Hierarchical Navigation Map
F-W(SG,I,cost) // SG is an array of graphs, I is the interface graph
//cost(v,w) is the weight of (v,w) (if no (v,w) edge, then cost(v,w)= )
return HT
How is SG computed?• Areas are user defined• Automatically computed with specialized procedures
for each G in SG do HT(G) F-W(G, cost)HT(I) F-W(I,cost)
Time: O(|SG|*maxG SG,{I}|V(G)|3)Space: G SG,{I}|V(G)|2)
Pathfinding
• Determine best paths leading from source node to boundary of source set
• Determine best path from source set boundary to goal set boundary
• Determine best path from goal set boundary to goal node
• Compile list of complete paths and choose one with least cost
Pathfinding Cost
• Amount of searching is limited to number of interface nodes in goal and source sets only
• Cost of searching between sets does not scale up with increases in navigation set size– Dependent on number of interface nodes
Applications of Navigation Set Hierarchy
• Interfacing heterogeneous navigation regions• Navigation data on demand• Extending beyond two tiers
Influence Fields
• Used in a previous competition in Robocode– And related to strategy employed by the “teenage mutant
ninja turtles” team
• Reactive approach to path finding– Setup virtual potential or force field around objects– Must define field and agents reaction to field
• Interactions in general are explicitly stated and movement “emerges”– Paths are not planned explicitly
Influence Fields
• Can be represented as a matrix– Each point has value representing the strength of field
under it– Assigns priority based on a variety of factors:
• Location of opponents• Location of friendlies
– Result: “Glide down gradient/path of least resistance”
Influence Fields
• Advantages?– Works in continuous space! No need to place waypoints
• Disadvantages?– Can get stuck in obstacles– It’s emergent, not sure what it will do
Pathfinding: Commercial Implementations
• Unreal Tournament– Waypoints with pre-computed paths
• Navigation Points placed throughout world– Assume world is generally static
• Run local path finding on top of global path finding for dealing with dynamic environments
• Local path finder constants queries physics engine to find dynamic objects
Commercial Implementations
• Area Awareness System– Designed for Quake 3, also used in Doom 3– Do not use waypoints, instead 3-D bounded hulls, called
areas• Cost of moving from one point to another within a hull
(reachable area) is minimal• Reachability can also be determined if a hull touches
another– So akin to meshes but 3-D