Several variations of A* have been proposed to either speed up A* or reduce the space complexity of A*. The variations that speed up A* either use an abstraction of the state-space (e.g. a game map) or reduce the size of the state space or create a true distance heuristic in a pre-processing phase. The variations of A* that build an abstraction of a game map in the pre-processing phase are presented in section 2.1.1.1
To reduce the space complexity of A*, Iterative Deepening A* (IDA*) [42] expands a node in a depth-first style and without maintaining the OPEN and CLOSED lists.
IDA* and its variations are discussed in section 2.1.2.
Dynamic D* is a variation of A* that has been designed to solve path planning problems in a dynamically changing domain world. This kind of search is also known as incremental search. D* and its variations are described in section 2.1.3. The variations of A* and D* that are suitable for path planning in RTS games are discussed in section 2.1.4.
Anytime variations of A* use a non-admissible heuristic (then it is also inconsistent) to find a quick solution and then improve that solution if more time is given to the algorithms. Anytime A* [29] finds a solution faster than A* by using an inadmissible heuristic function and then iteratively improves this solution until the open list is empty. Even Anytime A* is faster in terms of finding the first solution (than A*) but its convergence can take a long time because a node can be expanded many
times (due to the inconsistent heuristic). Anytime Repair A* (ARA*) [47] extends Anytime A* by imposing a limit on the number of times a node is expanded in the look-ahead search. Anytime A* and its variations are not suitable for path planning in RTS games for two main reasons. First, these variations require complete information about the domain world to find the first solution for a path planning problem. Second, these algorithms do not provide a guarantee for the real-time constraints. A guarantee means the algorithm should find a solution under a fixed time interval (for all planning problems) such that this time interval is independent of the size of the state space.
Real-time heuristic search (discussed in section 2.1.4) provides such a guarantee and therefore, the real-time heuristic search algorithms are suitable for path planning in RTS games.
2.1.1.1 Abstraction of State Space
The variations of A* that use an abstraction of the game map include Hierarchi-cal Pathfinding A* (HPA*) [15], Partial-Refinement A* (PRA*) [67] and memory efficient abstraction [66]. These variations are faster than the original A* but they produce suboptimal solutions. The quality of the solution depends on the kind of abstraction built during the pre-processing of the map. HPA* divides the map into large rectangular blocks. Each block has some entry points on each border. A block is connected to another block through these entry points. The paths between all entry points of a block are computed and stored in a look-up table during the pre-processing phase. The abstraction and the look-up table are stored in memory for online planning. To find a path between two locations on the original map , HPA*
finds the corresponding blocks of the initial and the goal locations. A high level path
between the block of the initial location to the corresponding abstract block of the goal location is computed using A*. The pre-computed paths in the look-up tables are used to refine the abstract path. The refined path is improved by using a post-processing path smoothing phase. The problem with this abstraction is that it allows the path between two blocks through entry points only.
Partial refinement A* (PRA*) builds a multi-level hierarchy of a map by grouping together several locations (connected with each other) into one abstract state. PRA*
finds an abstract path at an arbitrary level and refines it within a predefined window (called a corridor) of the low level hierarchies. PRA* finds a partial path and executes it (i.e. interleaving planning and execution). For large maps, PRA* is expensive in terms of memory. A memory efficient abstraction called Minimal-Memory (MM) ab-straction [66] combines HPA* and PRA* in such a way that the map is first divided into large blocks and then each block is abstracted by PRA*. This abstraction tech-nique uses less memory than HPA* and PRA* but it is also suboptimal as it finds a path from the centre of one block to the centre of another.
The use of abstraction of a game map for pathfinding has also been explored by using the navigational-mesh [28] and points of visibility (or way-points) [55]. In navigational-mesh, a set of convex polygons is constructed offline such that each con-vex polygon (e.g. a regular pentagon) represents an obstacle-free (walkable) surface of a game world. The main advantage of this approach is that it is equally suitable for 2D and 3D game maps. As walkable surfaces are computed offline in a prepro-cessing phase, therefore, a navigational-mesh approach is not applicable for dynamic environments.
In the points of visibility approach, a set of nodes is created offline in such a way
that the path between two nodes is a straight line. These nodes are usually placed on the actual map manually, commonly on the corners of static obstacles. The ef-fectiveness of this approach hugely depends on the topology of the game map e.g. if static obstacles are irregular shapes then this approach requires a large set of nodes and motion can also look non-realistic as characters would not be able to move to many obstacle-free spaces that are not part of the straight line. Another problem with visibility points is that path planning becomes slow if there are a large number of points.
In RTS games, the building of abstractions in a pre-processing phase is not possible because the maps are initially unknown to the players. Therefore, HPA*, PRA*, MM abstraction, way-points and navigational-mesh are not suitable for the path planning problem in RTS games.