GitHub<\/a>\n<\/li><\/li><\/ul>\n\n![](\"http:\/\/tabesugi.net\/memo\/2013\/img\/ppp\/movie.gif\"\/)
<\/p>\n
Handling Continuous Space<\/h2>\n
\nThe first problem that we need to address is the continuous nature of\na platformer game. In a typical path planning, a problem is usually\nreprespented as a discrete space. However, in a platformer game where\ncharacters often are affected by gravity, handling its continuous\nmovement is crucial. We addressed this issue by dividing the problem\ninto two layers: macro-level planning and micro-level planning. The\nmacro-level planning takes care of a coarse-grained plan such as \u201cgo\nto this block\u201d or \u201cjump here and try to land at that block\u201d. The\nmicro-level planning takes care of more fine-tuned movement that\ninvolves a continuous 2-D space. The macro-level planning is done by\nusing typical AI techniques like a navigation mesh, constructing a set\nof possible actions at each discrete location. The micro-level\nplanning is done in a more greedy manner, by taking care of physical\ncollisions and character coordinates.<\/p>\n
\nThe macro-level planning can be implemented with a pretty\nstraightforward Dijkstra or A* search. It starts from the goal\nposition, and iteratively searches all the possible movements until it\nreaches the initial state (the position of the character). Each\naction is associated to its next action until it reaches the goal,\nforming a DAG structure. A plan graph can be dynamically constructed\nand periodically updated based on the current state of the game.\nAdditional restrictions (e.g. space constraints and ladders) are also\nconsidered.<\/p>\n
\n![](\"http:\/\/tabesugi.net\/memo\/2013\/img\/ppp\/plangraph.png\"\/)
<\/p>\n
\nWhen each action is executed, a character is entirely controlled by\nthat action, and the character cannot execute the next action until\nthe current action is finished. Each action only considers the\nstarting and ending point, and it moves the character in a rather\nstraightforward way. When the macro-level planner detects the\nsituation change (e.g. the goal is moved) during the execution, the\ncurrent plan is abandaned after the action is finished and a new plan\ngraph is created.<\/p>\n
Jumping \/ Falling<\/h2>\n
\nJumping and falling is the key element of platformer games and the\ncore of its planning problem. It has so many parameters that using\nnaive methods will easily lead to computational explosion. In the\nproposed method, the macro-level planner only takes care of its\nstarting point and ending point in the block coordinates. The planner\nhas to know in advance the speed of a character in question and its\njump impulse, as well as the gravity acceleration, so that it can know\nwhere it will exactly land. The macro-level planner uses two bounding\nboxes (a jumping part and a falling part) to approximate the clearance\nthat a character needs, but it doesn\u2019t take care of an actual\ntrajectory of the character.<\/p>\n
\nAn actual jump action is divided into three steps. First, it tries to\nmove the character to its starting position (Set), maneuver the\ncharacter movement during ascending (Ascend), and then land the\ncharacter to the ending position (Land). It takes a precise\n(pixel-wise) control of the character at each frame update.<\/p>\n
\n![](\"http:\/\/tabesugi.net\/memo\/2013\/img\/ppp\/jumping.png\"\/)
<\/p>\n
Landing Prediction<\/h2>\n
\nThe planner can find a solution only when the path planning is\nsolvable. When a character is following another character that is\njumping or falling, the goal position is often considered unreachable,\nmaking it impossible to find a solution. In a case like this, the\nplanner can optionally make a guess of the final landing position\nbased on the current speed of the character.<\/p>\n
\n![](\"http:\/\/tabesugi.net\/memo\/2013\/img\/ppp\/prediction.png\"\/)
<\/p>\n
Moving Platforms, Sprinting, Double Jumping, etc.<\/h2>\n
\nA path finding is based on an assumption that the floor map\nyou\u2019re planning on is static. When there are some parts that are\nchanging dynamically, those parts need to be handled specially by\nthe micro-level planner. In this case, the macro-level planner only\ntakes care of moving into that part and getting out of it.<\/p>\n
\n![](\"http:\/\/tabesugi.net\/memo\/2013\/img\/ppp\/movingplatform.png\"\/)
<\/p>\n
\nHandling moves like sprinting or double jumping can be more tricky,\nbecause such actions depend on the current state of a character. In\nother words, a plan becomes context-dependent. Now we would have\nto consider multiple possible states at each grid, making the search\nspace several times larger. I am not sure if we can find a really good\nsolution for this kind of planning, but in theory we can still take\nthis into account in the current framework.<\/p>\n
Source Code Structure<\/h2>\n
\nThe prototype is written in ActionScript. However, the planning parts\nare separated from the UI and I believe it\u2019s relatively easy to port them to\nanother language. Here are a couple of important classes:<\/p>\n
\n-
Actor<\/code>\n- This is an object that the planner takes control of.\n The object needs to support methods like
move(x, y)<\/code>, jump()<\/code>\n to perform actions on each character, as well as query methods such as\nbounds()<\/code>.\n-
TileMap<\/code>\n- An object that stores a 2D map that a planner can use.\n This is basically a two dimensional array of tile numbers.\n The class needs to handle a query like
getTile(x, y)<\/code> as well as\n range queries like \u201cif there\u2019s a certain block within this area\u201d in order to\n serve the efficient planning.\n-
PlanMap<\/code>\n- A macro-level planner that has a plan graph and its constructor.\n It maintains a grid of actions, which correspond to each tile in\n a
TileMap<\/code> object, so that an Actor<\/code> can query\n a possible action to take at each place. An action,\n which is a PlanAction<\/code> object, is represented as\n an edge of a plan graph. There\u2019s one important method addPlan()<\/code>,\n which fills the grid according to the given parameters and the associated\nTileMap<\/code>.\n A plan graph can be shared and reused as long as the goal is not changed\n and all the Actor<\/code>s has the same property (e.g. speed, gravity, etc.).\n-
PlanAction<\/code>\n- This object represents a single action planned by the macro-level planner.\n An action object has a detailed information about the action such as a\n starting and ending point, the type of the action, and the tile map it\u2019s referring to.\n The object is responsible for performing micro-level planning.\n It fires events to an Actor object so that it can carry out\n the corresponding actions (jumping or moving, etc).\n<\/dd><\/dt><\/dd><\/dt><\/dd><\/dt><\/dd><\/dt><\/dl>\n
Is This Smarter than Humans?<\/h2>\n
\nUnfortunately, no. Due to computational limits, the current\nimplementation considers only a handful of ways of possible jumps at\neach position. Since it uses a rectangle as an approximation of jump\ntrajectory, it cannot emulate a complex manuever that humans could\ndo. Also, since it\u2019s on block-by-block basis, it cannot consider a\npossibility of barely-make-it kinds of jumps. These are mostly\ncomplexity problems, but in some cases there might be need to give up\nto find an optimal solution.<\/p>","time":"November 24th, 2013 5:33 am","title":"Path Planning (AI) in Platformer Games: A Layered Approach","title_was_empty":false}