530 likes | 657 Views
Administrative. Project due Tuesday: Email your code to Yisheng Tang (yit311@lehigh.edu) no later than 11:59PM EST Monday February 6 (the day BEFORE the competition)
E N D
Administrative • Project due Tuesday: • Email your code to YishengTang (yit311@lehigh.edu) 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; foreach 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; foreach 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 Credit: AIMA fig 3.11, pg 74
Informed Search: A* Algorithm Astar(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); foreach 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… 75% LESS NODES! But we also show examples where A* performs poorly Breadth-First Search A*, Manhattan, W=3
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
Navigation Forms in Regular Grids NWSE Diagonals String-Pulling Catmull-Rom Spline
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 • Waypoints around obstacles
Corner Graphs • How do we generate them? 1.Identify convex corners 2. Check if character can walk in straight line between them 3. 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.
Waypoint Graphs • Place nodes in middle of rooms instead of at convex corners
Waypoint Graphs • 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
Circle-Based Waypoint Graphs • Add radius parameter to indicate open space near waypoint
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 • Use rectangles or 3-D Boxes instead of circles
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 walkablesurfaces • 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) ) thentransition(v,w) w • else transition(v,w) null • for each node u do • for each node v do • for each node w do • ifpath(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|*maxGSG,{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