AIIDE-15 Presentation on Inventory-Driven Jump-Point-Search, a way to solve pathfinding queries when map regions can be unlocked by specific items on the map.

1. Path Planning with
Inventory-Driven
Jump-Point-Search
DAVIDE AVERSA, SEBASTIAN SARDINA, STAVROS VASSOS
1

2. Motivation
In videogames navigation based on
items, events or agent capabilities
(e.g., power-up, equipment, etc.) is
very common.
Usually these challenges are designed
for the players. However, often we
want other agents in the game to solve
the same challenges.
2

3. Motivation
The classical and academic answer to this problem is:
◦Yes! Planning! :)
3

4. Motivation
The classical and academic answer to this problem is:
◦Yes! Planning! :)
However, in game related community the reactions is
◦Yes… well… planning. :
4

5. Motivation
So we tried to answer the question:
What if we can add this high-level reasoning directly in the
pathfinding search?
Thus, we defined a limited subset of planning problems and
investigated how it is possible to solve these problems and
the pathfinding task at the same time.
5

6. Problem Definition
6

7. Problem Definition: Input
We want a pathfinding algorithm which takes as input:
◦ A grid-based map 𝑀.
◦ A subset 𝑂 ⊆ 𝑀 of blocked nodes (e.g., walls).
◦ A function adj : 𝑀 → 2 𝑀
denoting the adjacency relation among
nodes.
◦ A set of items 𝑰 that may be scattered in the map.
◦ A function req : 𝑴 → 𝟐 𝑴
stating which items are required to
traverse a node
◦ A starting node S and a destination node G.
7

8. Problem Definition: Goal
We want to use this
information to find the
optimal path from S to G
under the constraint that
some locations along the
path may require the agent
to have previously visited
other special nodes.
8

9. Problem Definition: The Challenge
G
For instance: it is better to follow the purple route (taking the key and
traversing the door) or the green one looking for a complete alternative route?
9

10. Problem Definition: The Challenge
With more than one key, the problem becomes
way more difficult!
10

11. Problem Definition: Proposed Solution
In this work we present Inventory-JPS, an
“inventory-driven” variant of Jump Point Search that
preserves the symmetry breaking advantages of JPS
in the extended setting of navigation with
item/capabilities constraints.
11

12. Jump Point Search
12

13. Jump Point Search
JPS is a recent technique that provides an exceptional
fast and optimal pathfinding on uniform-cost
grid-based maps.
It is based on a massive pruning mechanism that
remove from the open list every node but the one
that may require a change of direction (jump points).
13

14. How Jump Point Search works
Starting from the starting point S, JPS starts
performing a local search over the main 8
directions. We can call this beams.
For every beam, the algorithm searches for:
◦ The Goal
◦ A point in which the optimal path may
change direction. This is a point who
contains a forced neighbor.
14

15. How JPS Works
◦ If a beam ends on a obstacle, the beam is completely discarded.
◦ If a beam contains the goal or a forced neighbor, the node is
added to the open list as a jump point.
15

16. How JPS Works
◦Searching for forced neighbors involves only local search.
At each step on the beam, only the 8 tiles around the
current tile are taken into account during the search.
◦When the goal is found, jump points are connected
backwards with straight horizontal, vertical or diagonal
lines in order to find the final optimal path.
16

17. Inventory Driven JPS
17

18. Inventory-Driven JPS
Inventory-Driven Jump Point Search (Inventory-JPS) is
obtained by modifying JPS in three simple ways.
18

19. First Modification
The first modification involves extending the state
representation to account not just for the location of the
agent, but also the current inventory.
<x, y> <i1,i2,…,in>
Binary Representation
Item StatePosition State
19

20. First Modification
1 “Map” for every
combination of
items.
2 𝑘 layers
with 𝑘
keys/items
𝒌 𝟏
𝒌 𝟐
Position
Inventory
20

21. Second Modification
The second modification to JPS involves treating any
node containing some capability or object as an
“intermediate” goal.
We call such jump point nodes, inventory jump
points.
21

22. Third Modification
So, the third modification included in Inventory-JPS
is to treat inventory jump point nodes as the
starting node, thus applying the jumping process
towards all possible directions.
22

23. Experiments
23

24. Inventory-JPS Experiments
We have implemented and tested our algorithm in Python
on a single core Intel i7 3.2GHz machine.
The goal is to verify how the item overhead behaves on
different items and doors distributions with respect to JPS
without item capabilities.
24

25. Experiment 1
Random placement of unnecessary keys over real game maps;
analysis per number of keys.
1. We took all the dataset of MovingAI of 512x512 Baldur’s
Gate map.
2. We evenly distributed different number of keys on the map
and no door (so that no key is really necessary).
With this experiment we can measure the direct overhead of
Inventory-JPS over JPS.
25

26. Experiment 1
The overhead increment is linear
and meaningful (However 100
keys are really a lot).
26

27. Experiment 2
Placement of unnecessary keys on the path over real game
maps; analysis per number of keys.
We are in the same setting of Experiment 1 but, this time,
keys are added along the optimal path.
In particular we want to verify the behavior when keys are
at the beginning (BEG), at the end (END) or evenly
distributed on the path (MID).
27

28. Experiment 2
Overhead is bigger if keys are concentrated
at the beginning of the path.
28

29. Experiment 3
Placement of unnecessary keys on the path over real
game maps; analysis per path length.
Same as Experiment 2 but this time we want to look
at the behavior over the different path lengths.
29

30. Experiment 3
Same as Experiment 2
but this time we want
to look at the behavior
over the different path
lengths.
30

31. Experiment 4
Incremental scenario of necessary keys over
synthetic maps; analysis per number of keys.
This time we start building artificial maps in which
keys are necessary in order to reach the goal.
31

32. Necessary keys usually perform
better. Sequential keys
(when a key is necessary to reach the next key)
is usually faster then Detour
(when multiple keys are available on the map
and the agent has to go back and forth to get
them).
Experiment 4
32

33. Experiment 5
Key performance overhead for unreachable destinations.
We want to see how the performance decays when there
are many keys but the destination is unreachable.
33

34. Unreachability is the
biggest problem in
Inventory-JPS because
it forces the algorithm
to fully search every
item state.
Experiment 5
34

35. Conclusions
35

36. Wrap up
1. Inventory-JPS has zero overhead if there are no
keys on the map (so it is “free” if keys are not
required).
2. If there are keys on the map, only the keys who
enter in the search horizon actually add
computational complexity to the search.
36

37. Wrap up
3. When a key enters the search boundaries, its
impact on the final performance depends on its
relative distance from the goal (keys far away from
the goal are more “heavy” than keys at the end of a
path).
4. On common sizes (3-4 keys for map), the algorithm
performs very well even without optimizations.
37

38. Wrap up
5. The worst scenario is when there are many keys
and it is not possible to find a path (because we
need to search every key-state combination).
38

39. Future Work
1. Solve the problem in practical time even for non-
JPS pathfinding algorithms.
2. The basic idea involves looking to a new optimal
solution that uses incremental-search inspired
ideas in order to avoid duplicate search in areas
that are not affected by the inventory state or that
are in common among several “item layers”.
39

40. Future Work
We already have some optimization which can cut by
50% the computational cost shown in this
presentation.
40

41. Thank you!
41