Motion Planning in Games

1. Motion Planning in Games Mark Overmars Utrecht University

2. Goals and Contents • Try to formulate the requirements for motion planning in games • Rather different from other applications • Investigate what techniques are suitable • Almost none of the existing techniques are • They still use scripting and A* for a reason • Indicate some of the open issues

3. Motion or Path Planning or … • Many different terms: • Motion planning • Path planning • Navigation • Route planning • … • Motion deals with • Interaction • Animation • Navigation • Simulation

4. First or Third Person Games • Environment • Complex: • Rooms, corridors, narrow passages • Stairways, ramps • Sometimes outdoors • Objects like trees, furniture, etc. • Created offline • Takes huge amount of time • Small changes occur, often at known places • Doors, bridges that are blown up, etc. • Sometimes user can make further changes

5. First or Third Person Games • Moving entities • In general alone or in very small groups • Number of different types • Varying number • Motion • Locally 2-dimensional, but 3-D obstacles • Often orientation is not important for planning • Some special moves possible • Jumping, climbing ladders • Path must be natural • On a local level • But only within the (small) visible range • Goals not precise • Goals change often, like when tracking an enemy

6. Strategy Games • Environment • Simple: • Basically planar, or terrain • Simple obstacles (can be modeled in 2D) • Few narrow passages • Created offline or during “loading” • Takes not much time to create • Environment changes continuously • Forrest grows and is cut away • Buildings are constructed • Fences can be made (reducing possibilities) • Bridges can be made (extending possibilities)

7. Strategy Games • Moving entities • Many different types of units of vary different shapes • Often moving in groups • Varying numbers • Non-holonomic constraints • Motion • 2-dimensional • Some can be seen as cylinders but for others orientation matters • Path must be natural • On a global level • Both for the entities and for the groups • Goals not precise • Goals change often, like when tracking an enemy

8. Time Issues: Preprocessing • Offline • During scene modeling • Time can be as large as we want (hours, days) • There should also be a faster technique for testing • Memory can be an issue • During initialization • When a scene is “loaded” or created • Time can typically be a few seconds

9. Time Issues: Runtime • Calculation frame rate: 20 – 100 frames per second • Leaves something like 0.02 seconds per step • This includes • Updating game status • Handling user input • Some graphics processing • Physics computations • Strategic AI • Path Planning • This leaves something like a millisecond per step for path planning!

10. Time Issues: Runtime • Path calculation can be distributed over a number of steps • But visible units better start moving soon • Queuing of path planning requests can easily occur • Many moving entities • Replanning requests • There must be a fast backup plan • The Game Must Go On

11. The Approach • Do everything you can offline • Alternative routes • Preparation for changes • Dealing with unknown numbers of entities • Dealing with groups • Quality of results • Preprocessing time is not very important for this • Unless during initialization • Build efficient data structures • Query time should be close to 0 • Even A* on a big graph can be too much • Avoid collision checking at runtime • Plan while execute

12. A High Quality Roadmap • Given an environment, construct a roadmap that can directly be used for motion planning queries, without the need for improving the path • Every path must be • Short • Has some preferred minimum clearance • Must be C1-continuous

13. Basic Technique: PRM • Problems: • Paths can take long detours • Paths can have a very low clearance • Paths will have C1-discontinuities at the nodes • Remember, we cannot remedy this at the query time

14. Reducing Path Length • Add cycles • Add an edge when the edge is considerably shorter than the current path through the graph • Can be done efficiently, avoiding expensive graph search • We do not want the graph to get too large by adding all edges, as this will slow down the query phase

15. Improving the Clearance • Push nodes and edges away from the objects • Remove or merge overlapping parts • More difficult than it sounds when dimension > 2

16. Create C1 Continuity • Replace nodes by circle arcs • Centers of the edges become the nodes • Connect by line-arc-line in a single plane • This is always possible • The longer the edges the better the result • Reduce the number of nodes

17. Result • Smooth roadmap, resulting in smooth paths • Preprocessing time is still reasonable • Query is instantaneous

18. Additions • Dealing with known changes, like doors • Coordinate multiple entities using these roadmaps • Adapting to additional obstacles • Use them as the basis for group motion

19. Research Questions • What is natural motion • How do people walk through buildings • How does the path change depending on the speed • Preprocessing versus real-time • How can we do more work during preprocessing • Calculation paths while moving • Locally adapting to changes • Dealing with groups • Multiple groups • Strategic behavior • Goals • Dealing with imprecise goals • Motion interruption and changing goals