Implementierung des Wegfindungsalgorithmus. Spieleentwicklungs-Framework Unity 3D

Transkript

1 Implementierung des Wegfindungsalgorithmus Jump Point Search im Spieleentwicklungs-Framework Unity 3D Bachelor-Thesis Studiengang Informatik Fakultät für Informatik Hochschule Mannheim Durchgeführt bei der Firma Elaspix Betreuer: Dr. Tobias Günther Zweitkorrektor: Prof. Dr. Thomas Ihme

2 Eigenständigkeitserklärung Hiermit bestätige ich, dass ich den vorliegenden Bericht selbstständig verfasst und keine anderen als die angegebenen Hilfsmittel benutzt habe. Datum

3 Abstract In dieser Arbeit werden die Grundlagen der Wegfindung sowie die verbreitetsten Methoden und Algorithmen in diesem Themenbereich erklärt. Wegfindung wird in Spielen genutzt, um einen optimalen Weg zwischen einem Start- und Endpunkt zu finden, welcher von Charakteren und Objekten verwendet wird. Es wird ein kurzer Überblick über in bekannten Spiele-Engines verwendete Arten der Wegfindung gegeben. Der Fokus liegt dabei auf dem Spiele-Framework Unity 3D. Den Kern der Arbeit bildet die Implementierung des Jump Point Search Algorithmus in Unity 3D, welcher eine Erweiterung des gängigen A*-Wegfindungs-Algorithmus ist. Hierbei wird auf eine effiziente Implementierung Wert gelegt. Ebenfalls werden Tipps zu Datenstrukturen und weiteren Optimierungen gegeben. Jump Point Search wird erklärt und abschließend dessen Implementierung ausführlich evaluiert, indem er mit einer Implementierung von A* verglichen wird. Die Ergebnisse zeigen, dass dieser neue Algorithmus tatsächlich in den meisten Anwendungsfällen, insbesondere auf weiten Flächen, A* deutlich überlegen ist

4 Inhaltsverzeichnis Abstract... 2 Inhaltsverzeichnis... 3 Abbildungsverzeichnis... 5 Begriffsverzeichnis Einleitung Motivation Problembeschreibung Aufgabenstellung Aufbau der Arbeit Grundlagen Allgemeiner Ablauf Graphentheorie Wegfindungsalgorithmen Spiele-Engines Wegfindung in verbreiteten Spiele-Engines Unity 3D Unreal Development Kit (UDK) CryENGINE Source Engine Weitere Engines Repräsentation eines Levels als Graph Rectangular Grid Quadtree Waypoints Navmesh Häufige Wegfindungsalgorithmen in Spielen Hierarchical Pathfinding A* (HPA*) Iterative Deepening A* (IDA*) Simplified Memory Bounded A* (SMA*) D* Der Jump Point Search Algorithmus Einleitung

5 6.2 Algorithmus-Erklärung Evaluierung JPS Jump Point Search in Unity 3D Übersicht Implementierung des Algorithmus Datenstrukturen und Optimierungen Evaluierung Fazit Ergebnis Ausblick Literaturverzeichnis Bücher und Paper Webseiten

6 Abbildungsverzeichnis Abbildung 1 Allgemeiner Ablauf der Wegfindung... 9 Abbildung 2 - Ein nicht zusammenhängender Graph Abbildung 3 - Ein Graph mit Weg und Kreis Abbildung 4 - Ein Baum-Graph Abbildung 5 - Ein Graph mit Mehrfachkanten und Schlinge Abbildung 6 - Ein bewerteter Graph mit zwei Wegen von A nach B Abbildung 7 - Ein gerichteter Graph Abbildung 8 - Ein Wurzelbaum Abbildung 9 - Reihenfolge der Expansionen bei der Breitensuche Abbildung 10 - Reihenfolge der Expansionen bei der Tiefensuche Abbildung 11 - Die Unity 3D Entwicklungsumgebung Abbildung 12 - Beispiele der Levelrepräsentationen [11] Abbildung 13 - Symmetrische Wege mit jeweils 9 horizontalen und vertikalen Schritten [14] Abbildung 14 - Pruning der Nachfolger eines Feldes beim Expandieren [15] Abbildung 15 - Beispiel einer Suche mit JPS Abbildung 16 - Beispiel eines gefundenen besten Weges in der VisualTiles-Demo Abbildung 17 - A*-Benchmark in der TileExporter-Demo anhand eines Levels aus Baldur's Gate Abbildung 18 - Ergebnisse der Vergleichstests zwischen A* und JPS Abbildung 19 - Tests 1-3 (links: A*, rechts: JPS) Abbildung 20 - Tests 4-6 (links: A*, rechts: JPS) Abbildung 21 - Tests 7-9 (links: A*, rechts: JPS)

7 Begriffsverzeichnis Agent Closed List Division Scheme Engine Ein Objekt (z.b. Spielercharakter), welches Wegfindung anfordert Eine Liste von bereits besuchten Knoten während der Wegfindung. Ein Abbildungsschema, welches beschreibt, wie ein Spiele- Level auf einen mathematischen Graphen abgebildet wird. Ein eigenständiger Teil eines Computerprogramms, welcher für eine bestimmte Aufgabe zuständig ist. Eine Grafik-Engine kümmert sich beispielsweise um die Darstellung der Grafik in einem Spiel. Expansion Einen Knoten in einem Wegfindungsalgorithmus zu expandieren, bedeutet, seine Nachfolger zu bestimmen und der Open List hinzuzufügen. Frame Game Loop Graph Heuristik Open List Polygonfläche Suchraum Thread Ein Einzelbild aus einer Videosequenz, bzw. in diesem Fall der visuellen Ausgabe des Spiels Die Schleife, in der sich ein Spiel befindet, während es läuft Ein mathematischer Graph ist eine Datenstruktur, welche mehrere Objekte ( Knoten ) und deren Verbindungen untereinander ( Kanten ) beschreibt. In Bezug auf die Wegfindung beschreibt eine Heuristik- Funktion einen Schätzwert von der aktuellen Position zum Ziel. Eine sortierte Liste von Knoten, aus welcher in jedem Schritt des Wegfindungsalgorithmus der als nächstes zu expandierende Knoten bezogen wird. Die Fläche, welche ein Polygon (Vieleck) bildet Die Menge an Objekten, unter denen der beste Weg zwischen zweien dieser Objekte gesucht wird Ein Thread ist ein Teil eines Prozesses. Eine Anwendung kann in mehrere parallel laufende Threads aufgeteilt werden, um gleichzeitig Aktionen durchzuführen

8 1 Einleitung 1.1 Motivation Als Wegfindungsalgorithmus bezeichnet man einen Algorithmus, welcher den besten Weg zwischen zwei Punkten A und B sucht. Hierbei ist allerdings nicht nur eine möglichst kurze Weglänge wichtig. Liegt beispielsweise ein Fluss zwischen Start und Ziel, ist es im Normalfall vorzuziehen, den Umweg über die Brücke zu wählen, statt den direkten Weg durch den Fluss zu beschreiten. Wie gut ein Weg ist, ist also ebenfalls etwas, das von einem Wegfindungsalgorithmus beachtet werden muss. Wegfindung wird primär im Bereich der Spieleentwicklung verwendet. Sie wird beispielsweise eingesetzt, um einen Charakter in einem Strategiespiel von A nach B laufen zu lassen, ohne, dass dieser an möglichen Hindernissen hängenbleibt. Ein weiteres offensichtliches Anwendungsgebiet ist die Routenplanung. Navigationssysteme greifen auf Wegfindungsalgorithmen zurück, um dem Nutzer den besten Weg zu seinem Ziel zu präsentieren. Auch in der Robotik wird Wegfindung eingesetzt, um Roboter intelligent zum Ziel zu führen und Hindernissen ausweichen zu lassen. 1.2 Problembeschreibung Vor allem in der Spieleentwicklung gibt es weiterhin großen Verbesserungsbedarf an Wegfindungsalgorithmen. Selbst bei großen Spieleproduktionen mit hohem Budget lassen sich häufig Charaktere erkennen, die an einer Wand hängen bleiben, gegen unsichtbare Hindernisse stoßen oder scheinbar grundlos einen Umweg laufen. Durch immer detaillierter werdende Levels erhöht sich die Komplexität der Wegfindung und somit oft auch die Anzahl der Fehler. Der Bedarf von Ressourcen (CPU-Leistung und Arbeitsspeicher) steigt ebenfalls, was sich negativ auf die Spieleperformance auswirken kann. Somit ist es wichtig, dass Wegfindungsalgorithmen so effektiv wie möglich arbeiten, um auch in komplexeren Levels schnell einen optimalen Weg zu finden. 1.3 Aufgabenstellung Ziel dieser Arbeit ist es, einen neuartigen Wegfindungsalgorithmus namens Jump Point Search im Spieleentwicklungs-Framework Unity 3D zu implementieren. Diese Erweiterung von Unity 3D soll Entwicklern helfen, schnelle Wegfindung auch in komplexen Projekten anzuwenden. Jump Point Search ist bisher noch kaum verbreitet und es existiert noch keine Implementierung für das Unity 3D Framework, welches derzeit eines der beliebtesten Werkzeuge zur Spieleentwicklung ist. 1.4 Aufbau der Arbeit Im Grundlagenkapitel wird zunächst der allgemeine Ablauf der Wegfindung erklärt sowie eine Einführung in zum Verständnis notwendige Themen wie Graphentheorie, grundlegende Wegfindungsalgorithmen sowie die Unity 3D Engine und Spiele-Engines im Allgemeinen gegeben. Im darauf folgenden Kapitel werden verbreitete Spiele-Engines vorgestellt und bezüglich ihrer verwendeten Wegfindungstechnologien analysiert. Daraufhin werden mehrere Methoden vorgestellt, welche beschreiben, wie sich ein Level in Form eines zur Wegfindung verwendbaren

9 Graphen repräsentieren lässt. Während im Grundlagenkapitel die Basisalgorithmen wie A* erklärt wurden, werden im Kapitel Häufige Wegfindungsalgorithmen in Spielen einige auf A* basierende und häufig in Spielen verwendete Algorithmen präsentiert. Die folgenden beiden Kapitel behandeln das Kernthema der Arbeit: Jump Point Search und dessen Implementierung in Unity 3D. Zunächst wird der Algorithmus und dessen Ablauf detailliert erklärt. Dann wird ein Überblick über die im Zuge dieser Arbeit entstandene Implementierung in der Spiele-Engine Unity 3D gegeben. Dabei wird außerdem die Implementierung in Form einer Evaluation mit A* verglichen und es werden mögliche Optimierungen vorgeschlagen. Im abschließenden Kapitel wird ein Fazit gegeben, welches sowohl das Ergebnis zusammenfasst, als auch einen Ausblick auf die Zukunft gibt

10 2 Grundlagen 2.1 Allgemeiner Ablauf Der allgemeine Ablauf bei der Suche nach dem besten Weg zwischen einem Start- und Endpunkt läuft im Regelfall wie folgt ab: Level / Karte des Suchraums (1) konvertieren/ abbilden Repräsentation als Graph Optimaler Weg von A nach B (2) anwenden (Startpunkt, Endpunkt) Wegfindungs-Algorithmus Abbildung 1 Allgemeiner Ablauf der Wegfindung Zunächst wird der Suchraum in einen mathematischen Graph konvertiert. Möchte man beispielsweise den besten Weg von München nach Berlin herausfinden, wäre der Suchraum eine Karte von Deutschland, welche sämtliche Straßen beinhaltet. In einem Spiel ist der Suchraum das Level, in dem die Wegfindung durchgeführt werden soll. Bei der Konvertierung werden nur die zur Wegfindung essentiellen Informationen übertragen die Farbe einer Wand oder der Name einer Straße ist für den Algorithmus nicht von Bedeutung. Auf Basis dieses mathematischen Graphs wird nun der Wegfindungs-Algorithmus angewendet, welcher als Resultat den besten Weg zurückgibt. Das Konvertieren in einen Graphen geschieht gewöhnlicher Weise nicht zur Laufzeit, sondern wird schon vorher berechnet und gespeichert. Der eigentliche Algorithmus wird dann zur Laufzeit auf Anfrage ausgeführt. Bei dynamischen, sich verändernden Levels wird der Graph bei einer Änderung im Level sofort angepasst, sodass der Algorithmus jederzeit auf die aktuellen Wegfindungsdaten zurückgreifen kann. Manche Wegfindungsalgorithmen können sogar während der Suche noch auf Veränderungen im Level reagieren und den gefundenen Weg entsprechend anpassen. In einem Spiel ist die Wegfindung besonders zeitkritisch, da es mit einer bestimmten Anzahl an Frames pro Sekunde (FPS) abläuft. Als Frame wird ein einzelnes Standbild der konstanten Folge an Bildern (im Regelfall zwischen 30 und 60 Bildern pro Sekunde, d.h. ein neues Bild alle 16-33ms) bezeichnet. Grafisch aufwendigere Spiele haben oft weniger FPS, da die visuellen Berechnungen umfangreicher sind. Wenn nun viele Agenten Objekte, die vom Spieler oder der KI gesteuert werden gleichzeitig Wegfindungen anfordern, kann das in komplexen Levels dazu führen, dass die Algorithmen zu lange benötigen, um innerhalb eines Frames eine Lösung zu finden. Deshalb müssen sie in eigene Threads ausgelagert werden. Generell sollte der Algorithmus allerdings dahingehend optimiert werden, dass auch viele Wege in nur wenigen Frames gefunden werden können

11 2.2 Graphentheorie Im Folgenden werden die Grundlagen der Graphentheorie erläutert, welche für diese Arbeit vorausgesetzt sind Was ist ein Graph? Abbildung 2 - Ein nicht zusammenhängender Graph Ein Graph ist eine mathematische Struktur, welche verschiedene Objekte und deren Zusammenhänge darstellt. Die Objekte werden als Knoten (blau dargestellt in der Grafik) und die Verbindungen zwischen ihnen als Kanten (grün) bezeichnet. Ein reales Beispiel hierzu wäre ein U-Bahn-Plan: Stationen würden durch Knoten repräsentiert werden und jene, die Direktverbindungen zueinander besitzen, wären mit Kanten verbunden. Der Graph in der obigen Abbildung ist nicht zusammenhängend, da nicht jeder Knoten von jedem anderen Knoten erreichbar ist Wege und Kreise Abbildung 3 - Ein Graph mit Weg und Kreis Eine Folge von Kanten wird als Weg bezeichnet (oben in rot). Ein Kreis ist ein Weg in einem Graph, der von einem Ausgangsknoten über andere Knoten zum Ausgansknoten zurück führt (orange)

12 2.2.3 Bäume Abbildung 4 - Ein Baum-Graph Als Baum wird ein zusammenhängender Graph bezeichnet, welcher keine Kreise enthält. Diese Art von Graph ist eines der zentralen Elemente in einem Wegfindungsalgorithmus Mehrfachkanten und Schlingen Abbildung 5 - Ein Graph mit Mehrfachkanten und Schlinge Es ist auch möglich, mehrere Kanten zwischen zwei Knoten zu haben (oben in rot). Das kann beispielsweise notwendig sein, wenn es mehrere U-Bahn-Linien zwischen zwei Stationen gibt. Als Schlinge wird eine Kante bezeichnet, die von einem Knoten zu sich selbst führt (orange) Bewertete Graphen 7 5 A 2 3 B Abbildung 6 - Ein bewerteter Graph mit zwei Wegen von A nach B Wie würde man in einem Graph beschreiben, dass zwei U-Bahn-Stationen besonders nah beieinander liegen? Hier kommen bewertete Graphen ins Spiel: Sämtliche Kanten bekommen eine Bewertung zugefügt ihre Kosten. Die Kosten eines Weges lassen sich berechnen, in dem man die einzelnen Kosten seiner Kanten aufaddiert. Aus einer Vielzahl von Wegen zwischen zwei Knoten ist jener der beste, welcher die geringsten Kosten besitzt und dieser wird vom Wegfindungs- Algorithmus gesucht. In der obigen Grafik wäre der orangefarbene Weg von A nach B also günstiger als der rote. Zur Berechnung der Kosten einer Kante werden nicht nur die Distanz, sondern auch

13 weitere Parameter, die beschreiben, ob eine Kante besser oder schlechter ist als eine andere, beachtet. Eine ICE-Verbindung zwischen zwei Städten wäre beispielsweise besser als eine Busverbindung und hätte somit geringere Kosten, obwohl beide dieselbe Distanz zurücklegen Gerichtete Graphen B A Abbildung 7 - Ein gerichteter Graph Enthält ein Graph Informationen darüber, in welche Richtung zwei Knoten miteinander verbunden sind, spricht man von einem gerichteten Graphen. Die gerichteten Kanten in diesem Graphen werden mithilfe von Pfeilen repräsentiert. Im obigen Bild kommt man also von A nach B, aber nicht mehr zurück. In einem Spiel könnte das beispielsweise bedeuten, dass man von einem Felsen zwar herunterspringen, jedoch nicht mehr hinaufklettern kann. Als ausgehende Kanten bezeichnet man solche Kanten eines Knoten, die von diesem zu anderen Knoten führen. Das Gegenteil davon wird als eingehende Kante bezeichnet Wurzelbäume A B Abbildung 8 - Ein Wurzelbaum Ein Wurzelbaum ist ein gerichteter Baum, welcher eine Wurzel besitzt, d.h. einen Knoten, der ausschließlich ausgehende Kanten hat (Knoten A im obigen Bild). Besteht eine Kante von einem Knoten A zu einem Knoten B, wird B als Nachfolger oder Kind von A bezeichnet. Gleichzeitig ist A Vorgänger oder Vater von B

14 2.3 Wegfindungsalgorithmen Der Suchbaum Um einen Wegfindungsalgorithmus auf einen Graphen anzuwenden, wird aus diesem während der Suche automatisch ein Wurzelbaum aufgebaut und ständig erweitert. Der Startknoten der Suche bildet die Wurzel des Baumes. Dann wird dieser Knoten expandiert das bedeutet, man sucht dessen Nachfolgeknoten. Die Nachfolger eines Knoten sind jene Knoten, die von ihm aus erreicht werden können in der Regel wird dabei der Vorgängerknoten ausgelassen. Durch dieses Ausfächern entsteht der Wurzelbaum. Wird der Zielknoten gefunden, lässt sich über die Hierarchie des Baumes der Weg zum Startknoten zurückverfolgen. Doch was passiert, wenn man auf einen Knoten stößt, welcher bereits (über einen anderen Weg durch den Baum) expandiert wurde? Ein erneutes Expandieren würde zu einer Endlosschleife führen. Aus diesem Grund wird eine sogenannte Closed List geführt, welche sämtliche bereits expandierte Knoten speichert. Trifft man auf einen Knoten aus dieser Liste, wird er einfach ignoriert und nicht expandiert. Somit werden die Kreise des Graphen eliminiert und spätere Endlosschleifen vermieden. Die Entstehung des Suchbaums gleicht also dem Ablauf jedes Suchalgorithmus: Der Startknoten wird expandiert, indem dessen Nachfolger in eine Open List hinzugefügt werden. In jedem Schritt der Suche wird nun ein Knoten aus dieser Liste ausgewählt, expandiert und dessen Nachfolger wiederum zur Liste hinzugefügt. Das wird solange fortgeführt, bis der Zielknoten gefunden wurde. Die Auswahl des nächsten zu expandierenden Knotens aus der Open List gehört zu den größten Unterscheidungsmerkmalen der Algorithmen. Im Folgenden werden die grundlegenden Wegfindungsalgorithmen kurz vorgestellt und erklärt Breitensuche Die Breitensuche ist eine uninformierte Suche, welche einen Suchbaum Ebene für Ebene aufbaut und nach dem Ziel durchsucht. Uninformiert bedeutet, dass keine weiteren Kenntnisse über die Position des Ziels beachtet werden. Stattdessen werden für jeden Knoten erst alle direkten Nachfolger expandiert (d.h. nach dem Zielknoten geschaut), dann wiederum alle deren direkten Nachfolger usw., bis das Ziel gefunden oder der komplette Baum durchsucht wurde Abbildung 9 - Reihenfolge der Expansionen bei der Breitensuche

15 Abbildung 9 stellt die Reihenfolge dar, in der vorgegangen wird. Der Startknoten ist grün markiert, der Zielknoten rot. Wäre der orangefarbene Knoten das Ziel, hätte die Breitensuche es bereits nach 3 Schritten gefunden und müsste den restlichen Baum gar nicht erst aufbauen Knoten 4 bis 7 würden also wegfallen Tiefensuche Die Tiefensuche ist ebenfalls eine uninformierte Suche und der Breitensuche sehr ähnlich. Sie unterscheiden sich lediglich in der Reihenfolge, in der der Baum aufgebaut und durchsucht wird. Es wird in der Tiefe gesucht, was bedeutet, dass zunächst der erste Nachfolger expandiert wird, dann dessen erster Nachfolger usw., bis kein Nachfolger mehr vorhanden ist. Erst dann wird in der Breite nach einem Nachbarknoten geschaut. Ist hier keiner mehr vorhanden, wird wieder eine Ebene nach oben gegangen und weitergesucht. Sobald wieder ein Knoten mit Nachfolgern gefunden wurde, wird dieser Ast komplett nach unten durchgegangen Abbildung 10 - Reihenfolge der Expansionen bei der Tiefensuche Wäre der orangefarbene Knoten das Ziel, hätte es die Tiefensuche erst nach 5 Schritten gefunden. Je nachdem, wo das Ziel liegt, findet also einer der beiden Algorithmen es schneller als der andere. In diesem Fall würden demnach Knoten 6 und 7 wegfallen Bestensuche Die Bestensuche ist eine informierte Suche, welche eine Heuristikfunktion verwendet, um das Ziel schneller zu finden. Das bedeutet, dass gezielt Knoten expandiert werden, welche gemäß der Heuristikfunktion mit einer höheren Wahrscheinlichkeit zum Ziel führen. Das steht im Gegensatz zu den bereits vorgestellten uninformierten Breiten- und Tiefensuchen, welche lediglich nach einer vorgegebenen Reihenfolge Knoten expandieren. Durch diese zielstrebigere (statt willkürliche) Suche verringert sich im Normalfall die Anzahl der zu expandierenden Knoten, bis das Ziel gefunden wurde, deutlich. Die Bestensuche funktioniert nur auf einem bewerteten Graphen, da die Kosten der Kanten in die Suche (und die Berechnung der Heuristik) mit einbezogen werden. Beim Expandieren werden die Nachfolger eines Knotens anhand ihrer heuristischen Bewertung in die Open List einsortiert. In jedem Schritt wird der Knoten mit der besten Bewertung aus dieser Liste expandiert. Trifft man beim Expandieren auf einen Knoten aus der Closed List, wird er nur erneut in die Open List hinzugefügt, wenn ein besserer Weg zu ihm gefunden wurde als zuvor. Ansonsten wird er ignoriert, um Endlosschleifen zu vermeiden. Im Folgenden wird der Algorithmus zur besseren Veranschaulichung im Pseudo-Code gezeigt

16 Open List = {Startknoten} Closed List = {} while OPEN not empty { 1. Verschiebe Knoten x mit der besten Bewertung aus der Open List in die Closed List (im 1. Durchgang ist das der Startknoten). 2. Wenn x == Zielknoten, gebe zurückverfolgten Pfad als Ergebnis Zurück und terminiere den Algorithmus. 3. Expandiere die Nachfolger von x. Für jeden Nachfolger n: a. Wenn n nicht in Closed List, berechne f(n), setze x als Parent von n und füge n zur Open List hinzu. b. Wenn n in Closed List und neue Bewertung besser als alte, aktualisiere vorhandenen Knoten mit x als Parent. } Codelisting 1 - Die Bestensuche im Pseudo-Code A* A* ist eine Variante der Bestensuche und gleichzeitig der zur Wegfindung am häufigsten verwendete Algorithmus. Er expandiert die Knoten anhand einer Bewertungsfunktion, welche wie folgt aufgebaut ist: ( ) ( ) ( ) ( ) beschreibt die benötigten Kosten vom Startknoten bis zum Knoten und ( ) die geschätzten Kosten von zum Zielknoten. Die Summe dieser beiden Funktionen bildet die geschätzten Gesamtkosten ( ), anhand derer die Open List sortiert wird. Abgesehen von der erweiterten Bewertungsfunktion funktioniert der restliche Algorithmus exakt wie die Bestensuche Dijkstra Der Dijkstra-Algorithmus ist eine Art von A*, bei welcher ( ) gilt. Das Bedeutet, dass keine Heuristik verwendet wird, sondern nur die aktuellen Kosten eines Knotens beachtet werden. Der Algorithmus berechnet die kürzesten Wege von einem gegebenen Startknoten zu allen anderen Knoten im Graphen. Er beschränkt sich nicht auf einen bestimmten Zielknoten, sondern sucht gleichmäßig in alle Richtungen, abhängig von den Kosten der jeweiligen Knoten. Daher wird er im Normalfall nicht verwendet, um den kürzesten Weg zwischen zwei bestimmten Knoten zu finden, wie es bei normalem A* mit Heuristik der Fall ist. Es würden zu viele kürzeste Wege zu uninteressanten Knoten gefunden werden, ohne benötigt zu werden. Für spezielle Szenarien ist er aber auch in Spielen sehr nützlich. Beispielsweise kann er zur Suche des am schnellsten erreichbaren Power-Ups genutzt werden. In dem Fall wird der Algorithmus so lange ausgeführt, bis das erste Power-Up gefunden wurde, und dann abgebrochen, da es keinen kürzeren Weg als diesen dorthin gibt. Auch für taktische Entscheidungen wie die Suche nach Deckung wird er oft verwendet

17 2.3.7 Heuristik Eine Heuristikfunktion wird verwendet, um die Nähe eines Knotens zum Ziel abzuschätzen. Im normalen Fall nutzt man hierzu eine zulässige Heuristik. Dies bedeutet, dass die geschätzten Kosten immer geringer sein müssen, als die tatsächlichen Kosten die Voraussetzung für ein optimales Ergebnis im Algorithmus. Auch bei leichter Überschätzung kommen meist noch gute oder sogar optimale Ergebnisse heraus. Zu hohe Überschätzung kann sich allerdings schlecht auf die Performance des Algorithmus auswirken. Die folgenden Heuristikfunktionen sind weit verbreitet: - Euklidischer Abstand: Entspricht der Luftlinie zwischen Knoten und Zielknoten. - Manhatten-Abstand: Addiert die horizontalen und vertikalen Abstände zwischen Knoten und Zielknoten. - Chebyshev-Abstand: Sucht aus horizontalem und vertikalem Abstand zwischen Knoten und Zielknoten den Größeren heraus

18 2.4 Spiele-Engines Aufbau einer Spiele-Engine Eine Spiele-Engine (auch Spiele-Framework genannt) besteht aus den wesentlichen Komponenten, die benötigt werden, um ein Spiel zu entwickeln. Dazu gehören unter anderem: - Grafik-Engine (zur visuellen Darstellung dies ist die Komponente, in der sich unterschiedliche Spiele-Engines oft am meisten unterscheiden) - Sound-Engine (zur Ausgabe von Sound-Effekten, Sprache und Musik) - Input-Engine (setzt Eingabebefehle des Nutzers durch Tastendrücke, Mausbewegung und weitere in Spielbefehle um) - Physik-Engine (stellt sicher, dass sich Objekte physikalisch korrekt verhalten, miteinander kollidieren etc.) - Netzwerk-Engine (für Spiele mit Online-Funktionalitäten, um mehrere Spieler miteinander zu verbinden) Um die Entwicklung eines Spiels möglichst leicht zu gestalten, beinhalten die meisten Spiele-Engines eine Entwicklungsumgebung. Mithilfe dieser lassen sich häufige Arbeitsschritte deutlich verkürzen und vereinfachen. Während manche Engines nur einen Editor inklusive einer Scriptsprache (oft Lua) zur Verfügung stellen, erhält man in anderen kompletten Zugriff auf den Quelltext der Engine, um somit tiefgreifendere Anpassungen vornehmen zu können. Einige Spiele-Engines sind außerdem auf spezielle Genres ausgelegt und lassen sich nur mit umfangreichen Veränderungen für andere Spiele nutzen Unity 3D - Einführung In dieser Arbeit liegt der Fokus auf Unity 3D, welche momentan eine der beliebtesten freien Spiele- Engines auf dem Markt ist. Erstmals im Jahr 2005 präsentiert, wurde sie doch erst 2010 durch Version 3 populär. Das entwickelte Spiel kann auf viele verschiedene Plattformen exportiert werden: - Windows, OS X, Linux - mobile Geräte (Android, IOS, Windows Phone) - aktuelle Spielekonsolen (Xbox 360, PlayStation 3, Wii, WiiU) - kommende Spielekonsolen (Xbox One und PlayStation 4) - Tragbare Spielekonsolen (PlayStation Vita) - Web (Adobe Flash, Unity Web Player) Die Engine wird stetig verbessert und liegt bereits in Version 4 vor. Neben weiteren Plattformen werden auch regelmäßig neue Features hinzugefügt (u.a. verbesserte Animationen, DirectX 11 Unterstützung, NavMesh Wegfindung, HDR-Beleuchtung). Zusätzlich können Erweiterungen aus dem Asset Store heruntergeladen werden. Dort liegen sowohl kostenlose als auch kostenpflichtige Assets vor, die im eigenen Projekt verwendet werden können. Neben einer kostenlosen Version gibt es auch Unity Pro, welches zusätzliche Features bietet (vorallem in der Grafik-Engine), sowie die Möglichkeit, den Quelltext der Engine durch Plug-Ins zu erweitern. [1]

19 2.4.3 Unity 3D Wichtige Begriffe Unity besitzt einen sehr umfangreichen und leicht bedienbaren Editor, um ein Projekt zu verwalten. Den Kern bilden die sogenannten Assets einzelne Ressourcen, wie z.b. Modelle, Materialien oder Scripts. Mehrere Assets können für den Import und Export in ein Package zusammengefasst werden. Eine Scene wird mit solchen Assets ausgestattet und dann ausgeführt sie repräsentiert ein Level in einem Spiel. GameObjects werden Assets genannt, wenn sie sich als eigenständige Objekte in einer Scene befinden beispielweise eine Kamera, ein Licht oder der Spielercharakter. Diese können wiederum mit anderen Assets wie Scripts oder Materialien ausgestattet werden, welche dann Components genannt werden und das GameObject, dem sie zugewiesen wurden, erweitern. Ein GameObject wird als Prefab bezeichnet, wenn es als Vorlage für weitere GameObjects dient beispielsweise ein Gegnertyp. Von diesem Prefab werden dann in der Scene mehrere Instanzen erzeugt und angepasst. Diese Anpassungen geschehen mithilfe des Inspectors, welcher ein Teil der Benutzeroberfläche ist und auch aus anderen Anwendungen bekannt ist. Mit ihm können Position, Rotation und sonstige Eigenschaften eines GameObjects eingestellt werden. Selbstverständlich wird auch ein Script-Editor mitgeliefert. Ein sehr nützliches Feature dabei ist, dass vorgenommene Änderungen an Scripts oder im Inspector live ins laufende Spiel übertragen werden können und so das regelmäßige Neustarten des Spiels zum Testen wegfällt. Abbildung 11 - Die Unity 3D Entwicklungsumgebung

20 3 Wegfindung in verbreiteten Spiele-Engines Die meisten großen Spiele-Engines haben bereits eine oder mehrere Methoden zur Wegfindung integriert. Alternativ werden auch oft extern Plug-Ins angeboten, welche diese Methoden nachliefern. Wenn beides nicht der Fall ist, muss der Entwickler die Wegfindung selbst implementieren, was einiges an Zeit und Aufwand kostet. Alle der unten erläuterten Lösungen zur Wegfindung nutzen den Algorithmus A* zur Suche. Die meisten 3D-Engines nutzen außerdem einen Navmesh zur Repräsentierung des Level-Graphen. 3.1 Unity 3D Die Unity 3D Engine bietet in der kostenlosen Version keine Wegfindung an. Es besteht aber die Möglichkeit, auf eine der vielen Erweiterungen aus dem Asset Store zurückzugreifen. Zu den bekanntesten zu einem Preis von etwa 100 US$ aber auch teuersten Wegfindungs-Plug-Ins zählt A* Pathfinding Project Pro von Aron Granberg. Damit lassen sich u.a. Grids, Waypoint-Graphen und Navmeshs erstellen, die Pfade mit Smoothing-Algorithmen natürlicher machen und tausende Knoten pro ms durchsuchen. Weitere Plug-Ins wären beispielsweise SimplePath von Alex Kring (60 US$), Simply A* von BFGames (20 US$) und Pathfinder von Song-GameDev (35 US$). [2] In der Pro-Version von Unity 3D ist seit Version 3.5 ein Navmesh-System enthalten. Im Editor lässt sich ein Navmesh automatisch aus einem Levelmesh erzeugen. Den Agenten-GameObjects wird die NavMesh Agent -Component hinzugefügt, welche dann zur Laufzeit dafür sorgt, dass Wegfindung für dieses Objekt berechnet werden kann. Dabei können u.a. Geschwindigkeit und Höhe des Agenten festgelegt werden. [3] 3.2 Unreal Development Kit (UDK) Die Unreal Engine 3 ist eine der in großen Spieleproduktionen am häufigsten verwendete Spiele- Engines seit ihrer Veröffentlichung im Jahr Zu den bekanntesten Titeln, welche die Engine verwenden, gehören Unreal Tournament 3, Gears of War, Mass Effect, Batman: Arkham Asylum und Bioshock. Seit 2009 bietet das Unreal Development Kit größtenteils uneingeschränkten Zugriff auf die Engine. Mit dem UDK lassen sich nicht-kommerzielle Spiele kostenlos veröffentlichen. Das UDK verwendet die NavMesh-Methode zur Wegfindung, während ältere Versionen noch Waypoints nutzten. Zusätzlich zum automatisch generierten NavMesh wird noch ein Obstacle Mesh erzeugt, welcher die Trennwände um Flächen im NavMesh beschreibt. Somit lässt sich schnell testen, ob der direkte Weg zwischen zwei Punkten hindernisfrei ist: man erzeugt einen Strahl zwischen diesen beiden Punkten und schaut, ob er den Obstacle Mesh kreuzt. Wenn ja, liegt ein Hindernis vor und es muss ein Weg um das Hindernis herum berechnet werden. Die Erzeugung des NavMeshs ist in mehrere Schritte aufgeteilt. Zunächst wird ein rasterartiger Mesh erzeugt, ausgehend von den vom Entwickler gesetzten Startpositionen. Dieser umfasst die von diesen Positionen aus erreichbaren Flächen. Die vielen kleinen, quadratischen Flächen werden nun im nächsten Schritt zusammengefasst, wodurch eine vereinfachte und optimierte Version des Navmeshs entsteht. Im letzten Schritt erst werden die Kanten des Graphen erzeugt, welche zwischen den Knoten (Flächen) im Navmesh vorliegen, die miteinander verbunden sind. [4]

21 3.3 CryENGINE Die CryENGINE entstand für den im Jahre 2004 erschienenen Ego-Shooter Far Cry bei Entwicklungsstudio Crytek aus Frankfurt. Seitdem wurden neuere Versionen der Engine vor allem durch den indirekten Nachfolger Crysis und dessen Fortsetzungen bekannt. Sie wird primär für Actionspiele verwendet. Mittlerweile steht die CryENGINE 3 die aktuellste Version der Engine zur nicht-kommerziellen Nutzung kostenlos zur Verfügung. [5] Das Wegfindungssystem nutzt einen NavMesh, welcher in einem ungerichteten Graphen repräsentiert wird. Ein Knoten in diesem Graphen repräsentiert eine frei begehbare Fläche im Level ohne Hindernisse. Der Graph wird automatisch vom Editor mithilfe von Triangulierung erstellt. Dabei werden jeweils drei nah beieinander liegende Hindernisse gewählt und ein Dreieck erzeugt, welches die freie Fläche zwischen diesen Hindernissen repräsentiert. Angrenzende Flächen werden im Graph automatisch mit Kanten verbunden. Alternativ lassen sich die Knoten (und somit die Flächen) auch manuell im Editor festlegen. [6] Zur Berechnung des kürzesten Weges wird A* verwendet. Die Kosten der Kanten im Graph entsprechen üblicherweise dem tatsächlichen Abstand im 3D-Raum zwischen den Mittelpunkten der zu verbindenden Flächen. Diese Kosten lassen sich allerdings auch anpassen: Beispielsweise könnten die Kosten zwischen zwei Knoten auf einer Straße mit 0.1 multipliziert werden, um somit bevorzugt zu werden. [7] 3.4 Source Engine Die Source Engine von Spieleentwickler Valve kam erstmals bei den Spielen Counter Strike Source sowie Half-Life 2 zum Einsatz. Obwohl sie seitdem ständig mit neuen und verbesserten Features überarbeitet wurde, sieht man ihr im Vergleich zur Unreal Engine 3.0 oder CryENGINE 3 ihr Alter bereits an. Obwohl die Source Engine primär für Ego-Shooter konzipiert wurde, findet sie mittlerweile auch in anderen Genres Anwendung, wie beispielsweise Puzzle ( Portal ), Strategie ( DotA 2 ) und Top-Down-Action ( Alien Swarm ). Wie die meisten 3D-Spiele-Engines setzt auch die Source Engine auf NavMeshs. Durchschnittlich fünf Minuten benötigt der Editor, um für ein normal großes Level den NavMesh zu generieren. Dabei wird ausgehend vom Startpunkt des Spielercharakters das Level erfasst und anschließend werden erreichbare Flächen zum NavMesh hinzugefügt. Nicht begehbare Flächen lassen sich im Editor manuell verbieten. Auf Wunsch lassen sich auch spezielle Orte wie Verstecke oder Sniper- Aussichtspunkte automatisch berechnen. Ebenfalls wird die Größe der Agenten beachtet und so verhindert, dass beispielsweise ein Auto durch eine Gasse fährt, die nicht breit genug ist. [8]

22 3.5 Weitere Engines Zu weiteren recht verbreiteten 3D-Spiele-Engines zählen die Blender Game Engine (BGE), sowie die Java Monkey Engine (JME). Beide werden nur selten für größere Projekte verwendet und bieten sich eher für kleinere Spiele oder Prototypen an. Während BGE NavMesh nativ unterstützt, bietet JME keine Wegfindungsmethoden ab. Dafür muss man auf verschiedene von der Community entwickelte Klassen zurückgreifen. Die HTML5-Engine Construct 2 beinhaltet Wegfindung auf einem Grid. Parameter wie Tilegröße und Geschwindigkeit der Agenten lassen sich anpassen. Andere große 2D-Engines, die auf HTML5 basieren, sind die Impact Engine und EaselJS. Beide haben keine Wegfindungsmethoden integriert, aber auch hier existieren entsprechende Erweiterungen von der Community. [9]

23 4 Repräsentation eines Levels als Graph Wie bereits im Grundlagenkapitel erklärt (Abbildung 1 Allgemeiner Ablauf der Wegfindung auf Seite 9), lautet der erste Schritt der Wegfindung, den Suchraum in einen Graph zu konvertieren, welcher vom Wegfindungs-Algorithmus verwendet wird. Im Fall eines Spiels wird ein Level in begehbare Bereiche oder Wegpunkte unterteilt (Knoten), welche miteinander verbunden werden (Kanten). Das geschieht auf Grundlage eines Division Schemes, also einem Abbildungsschema. Im Verlauf dieses Kapitels werden die verbreitetsten Division Schemes kurz vorgestellt. Es sei gesagt, dass jede dieser Repräsentationen ihre spezifischen Anwendungsbereiche, Stärken und Schwächen besitzt und es die Aufgabe des Entwicklers ist, das für sein Spiel am besten geeignete Division Scheme zu wählen. [10] [11] 4.1 Rectangular Grid Ein Grid (oft auch Tilemap genannt) besteht ähnlich wie ein Schachbrett aus vielen einzelnen quadratischen Feldern ( Tiles ). Ein Tile ist üblicherweise entweder begehbar oder nicht begehbar, was bei der Wegfindung berücksichtigt wird. Die meisten Strategiespiele verwenden diese zweidimensionalen Grids, welche dem eigentlichen, deutlich detaillierteren 3D-Level unterliegen. Je höher die Tile-Dichte, desto präziser wird der Algorithmus arbeiten viele Algorithmen werden dadurch aber spürbar verlangsamt. Ein Tile repräsentiert einen Knoten im Graph, angrenzende Tiles sind mit Kanten verbunden. Problematisch wird es in 3D-Spielen, die wie die meisten aktuellen Actionspiele aus mehreren Ebenen bestehen. Für eine Brücke, die man überqueren, aber auch darunter durch laufen kann, bräuchte man schon ein weiteres Grid und einen speziell angepassten Algorithmus. Ein Vorteil der Grid-Repräsentation besteht darin, dass sie schnell auf sich dynamisch ändernde Levels angepasst werden können. Tiles lassen sich direkt über ihre x- und y-koordinate ansprechen und auf begehbar oder nicht begehbar setzen. 4.2 Quadtree Ähnlich einem Grid, wird auch hier das Level in viele Quadrate unterteilt. Während beim Grid aber sämtliche Tiles dieselbe Größe besitzen, wird in einem Quadtree je nach notwendiger Genauigkeit die Tilegröße variiert. Das ist gerade bei größeren begehbaren Flächen von Vorteil, da zum einen weniger Speicher benötigt, als auch die Algorithmus-Laufzeit verringert wird. Die einzelnen Tiles können allerdings nicht frei in ihrer Größe geändert werden, sondern müssen einem bestimmten Schema folgen: Die komplette Ursprungsfläche wird zunächst in 4 gleichgroße Quadrate unterteilt, welche wiederum selbst so weit wie benötigt unterteilt werden. Auch dieses Division Scheme eignet sich weniger für 3D-Levels mit mehreren Ebenen und somit vor allem für Strategie- und Rollenspiele. Für diesen Zweck gibt wird ein Octree verwendet. Hierbei läuft das Verfahren wie beim Quadtree ab, mit dem Unterschied, dass von einem Würfel ausgegangen wird, welcher jeweils in 8 gleich große Würfel unterteilt wird. Von hier an werden die einzelnen Würfel jeweils so oft unterteilt wie gewünscht

24 4.3 Waypoints Ein in aktuellen 3D-Spielen häufig verwendetes Division Scheme ist das Waypoints -Schema (auch Points of View ) genannt. Hierbei werden Wegpunkte (Knoten) im Level bestimmt und jene miteinander verbunden, die sich gegenseitig sehen können (Kanten). Dieses Schema ähnelt im Aufbau am deutlichsten dem von einem Graphen und eignet sich auch für Actionspiele mit mehreren Ebenen. Im oben genannten Beispiel würde man einen Wegpunkt sowohl auf als auch unter die Brücke setzen. Nachteil ist, dass die Wegfindung dann nur einen begrenzten Überblick über das Level besitzt es weiß nicht, was sich abseits dieser Wegpunktverbindungen befindet. Um ein Level optimal zu repräsentieren, wären also extrem viele Wegpunkte notwendig. Ansonsten ist der resultierende Weg sehr eckig und oft nicht optimal (Abbildung 12, links unten). Dieses Schema wird oft zusammen mit dem aufwendigeren Navmesh-Schema verwendet und besonders bei Nicht-Spieler-Charakteren (NPCs) genutzt. In Rollenspielen werden damit beispielsweise Wegrouten für unwichtige NPCs erstellt, auf denen sich diese kontinuierlich (zufällig) bewegen, um den Eindruck einer lebendigen Welt zu geben. Da sich diese Charaktere niemals zu einem nicht auf dieser Route befindlichen Ort begeben müssen, reicht das Waypoint-Schema also für sie (auch mit wenigen Wegpunkten) aus. 4.4 Navmesh Ein sogenannter Navigation Mesh wird direkt aus den 3D-Informationen des Levels erstellt. Statt aus quadratischen Flächen besteht der Navmesh aus vielen unterschiedlich großen Polygonflächen (also Vielecken). Hierbei werden natürlich nur jene Flächen in den Navmesh übernommen, die auch begehbar sind. Welche das sind, kann der Entwickler anhand verschiedener Parameter bestimmen. Alternativ lassen sich Flächen auch manuell aus dem Navmesh ausschließen. Die übrig gebliebenen Flächen repräsentieren dann die Knoten im Graph, während aneinander angrenzende Flächen durch Kanten verbunden werden. Obwohl Navmeshs eine relativ neue Entwicklung sind, werden sie bereits von den meisten modernen Engines unterstützt und verwendet (siehe Kapitel Wegfindung in verbreiteten Spiele-Engines )

25 Abbildung 12 - Beispiele der Levelrepräsentationen [11] Der gefundene Weg ist in Gelb eingezeichnet, die expandierten Knoten (d.h. Felder, Punkte oder Polygone) in Rosa. Links oben: Rectangular Grid Rechts oben: Quadtree Links unten: Waypoints Rechts unten: Navmesh

26 5 Häufige Wegfindungsalgorithmen in Spielen Die meisten Wegfindungsalgorithmen in Spielen basieren auf dem A*-Algorithmus. Hierbei wird in der Regel eine erweiterte, speziell auf das Spiel angepasste Form verwendet und nur selten unveränderter A*. In diesem Kapitel werden einige der verbreitetsten A*-Varianten vorgestellt. Dies ist nur ein kleiner Auszug aus einer Vielzahl von Algorithmen. Keine dieser Varianten ist allumfassend oder besser als eine andere - jede ist für spezielle Situationen und Spieltypen besser geeignet als eine andere und hat demnach ihre Daseinsberechtigung. Ein Wegfindungsalgorithmus bekommt als Eingabeparameter den Graphen sowie Start- und Zielknoten. Er liefert wenn vorhanden den besten Weg zwischen diesen beiden Knoten zurück. Bei Graphen ohne Mehrfachkanten ist dies für gewöhnlich eine Liste der Knoten dieses Weges. Gibt es allerdings Mehrfachkanten, wird es notwendig, stattdessen eine Liste der Wegkanten zurückzuliefern. [10] 5.1 Hierarchical Pathfinding A* (HPA*) Sehr detaillierte Levels benötigen in der Regel auch einen sehr umfangreichen Graphen zur Wegfindung. Die Berechnung des kompletten Weges kann unter Umständen zu lange benötigen, um noch innerhalb eines Frames berechnet zu werden, was zu störenden Verzögerungen führt. Bei weiten Wegen ist auch die Wahrscheinlichkeit höher, dass sich die Spielwelt in der Zwischenzeit schon wieder geändert hat: eventuell ist der vorherbestimmte Weg mittlerweile blockiert oder muss gar nicht mehr begangen werden. Das führt dazu, dass Rechenzeit unnötig verschwendet wurde, da nur ein Teil des gefundenen Wegs benutzt wurde, da der Rest mittlerweile ungültig geworden ist. Diese Probleme versucht HPA* zu umgehen. Der ursprüngliche, detaillierte Wegfindungsgraph wird in einzelne Teilgraphen unterteilt. Zusätzlich wird ein abstrakterer Graph erzeugt, welcher diese Teilgraphen miteinander verbindet, ohne die Detailinformationen dieser Graphen zu kennen. Wird nun ein Weg gesucht, geschieht dies zunächst auf dem abstrakten Graph mit der Information als Ergebnis, welche Teilgraphen (in welcher Reihenfolge) für den kompletten Weg benötigt werden. Nun kann der Anfang des kompletten Weges durch den ersten Teilgraphen schnell gefunden werden und es können bei Bedarf weitere Teile des Weges in den folgenden Teilgraphen on the fly berechnet werden. Dadurch wird sichergestellt, dass immer nur die relevanten Teilprobleme berechnet werden. Der eigentliche Suchalgorithmus dafür ist im Regelfall aber nicht zwangsweise - Standard-A*. Angenommen, man suche den besten Weg von Mannheim nach Berlin. Statt nun in einem einzelnen, komplexen Graphen zu suchen, welcher sämtliche Straßen Deutschlands beinhaltet, wird zunächst auf einem abstrakteren Graphen nach dem groben Weg gesucht. Dadurch ergeben sich Orte (Zwischenstationen), die auf dem besten Weg liegen, z.b. Auf- und Abfahrten der zu befahrenen Autobahnen. Wie man von der aktuellen Position zur nächsten Autobahn oder von der abschließenden Autobahn zum Ziel gelangt, wird schließlich aus entsprechenden detaillierteren Graphen entnommen. Der große Vorteil dabei ist, dass jeweils nur der Weg zur nächsten Zwischenstation und nicht der komplette Weg zum Ziel gesucht werden muss. [12]

27 5.2 Iterative Deepening A* (IDA*) Diese Variante von A* kombiniert die Iterative Tiefensuche mit A*. Bei der iterativen Tiefensuche wird eine normale Tiefensuche wiederholt bis zu einer bestimmten Tiefe ausgeführt, welche mit jedem Schritt erhöht wird, bis eine Maximaltiefe erreicht oder zuvor das Ziel gefunden wird. Bei IDA* werden statt der Tiefe die maximalen Kosten des Knotens als Limit gesetzt und iterativ erhöht. Der Vorteil hierbei ist, dass die bereits besuchten Knoten nicht gespeichert werden müssen, es durch das Kostenlimit aber trotzdem nicht zur Endlosschleife kommt. Das führt zu einem geringeren Speicherverbrauch. Ein Nachteil ist allerdings, dass IDA* etwas langsamer als Standard-A* ist, da einige Knoten zu einem gewissen Grad mehrfach besucht werden. 5.3 Simplified Memory Bounded A* (SMA*) Der SMA*-Algorithmus bekommt nur begrenzten Speicher zur Verfügung gestellt, welcher nicht überschritten wird. Das ist in Situationen nützlich, in denen der Speicher knapp und die Anzahl der zu findenden Wege hoch ist. Bei ausreichend Speicher verhält sich SMA* exakt wie A*. Ist der Speicher des Algorithmus allerdings aufgebraucht, schneidet er diejenigen Äste ab, welche die höchsten Kosten haben, da vermutet wird, dass diese später sowieso nicht mehr benötigt werden. Stellen sich die nun expandierten besseren Äste als schlechter als zunächst vermutet heraus, müssen die zuvor abgeschnittenen Äste wieder rekonstruiert werden. Hierzu wird in jedem Vaterknoten der Kostenwert des abgeschnittenen Kind-Astes mit den geringsten Kosten gespeichert, um diesen später wiederherstellen zu können. 5.4 D* D* wurde speziell für sich dynamisch stark ändernde oder für den Agenten unbekannte Levels konzipiert. Im Gegensatz zu A* wird hierbei die Suche beim Zielknoten begonnen und rückwärts der Weg zum Start gesucht. Weiterhin ist nur die direkte Umgebung des Agenten bekannt vom restlichen Level wird ausgegangen, dass es frei begehbar ist. Erst wenn neue Umgebung erkundet und Hindernisse gefunden werden, wird der Algorithmus entsprechend angepasst und die entdeckten Hindernisse mit einberechnet. D* wird bevorzugt in der Robotersteuerung verwendet, da er unter Berücksichtigung von vielen Agenten in einem Spiel aufgrund der häufigen Neuberechnungen oft zu langsam ist

28 6 Der Jump Point Search Algorithmus 6.1 Einleitung Jump Point Search (JPS) ist ein relativ neuer Wegfindungsalgorithmus. Er wurde im Jahr 2011 von Daniel Harabor und Alban Grastien entwickelt. JPS ist eine Erweiterung von A* und benötigt eine Grid-Repräsentation des Levels zur Anwendung. Dabei muss der Graph unbewertet sein, d.h. alle Felder besitzen dieselben Schrittkosten zu ihren angrenzenden Feldern. Der Algorithmus führt Symmetriereduktion durch, was bedeutet, dass mehrfache Pfade derselben Länge zwischen zwei Feldern entfernt werden, um so die Anzahl der möglichen Wege zu reduzieren und die Wegfindung zu beschleunigen. Außerdem werden sogenannte Jump Points berechnet: diese führen dazu, dass weite Flächen, die von A* Feld für Feld erkundet werden würden, einfach übersprungen werden können. Jump Point Search lässt sich leicht mit anderen Optimierungstechniken verbinden, wie beispielsweise Abstraktion der Ansatz, welcher auch von HPA* umgesetzt wird. [13] 6.2 Algorithmus-Erklärung Symmetriereduktion Der JPS-Algorithmus basiert zum Großteil auf der Idee der Symmetriereduktion. In einem Grid existieren stets mehrere gleich lange Wege zwischen zwei Feldern, welche sich nur in der Reihenfolge ihrer Schritte unterscheiden. Durch Symmetriereduktion werden solche symmetrischen Wege entfernt, sodass nur noch ein einzelner Weg übrig bleibt. Das führt dazu, dass deutlich weniger Wege betrachtet werden müssen und die Wegfindung entsprechend schneller abläuft. [14] Abbildung 13 - Symmetrische Wege mit jeweils 9 horizontalen und vertikalen Schritten [14]

29 6.2.2 Expansion von Feldern Während Jump Point Search im Wesentlichen wie A* abläuft, unterscheiden sie sich am meisten beim Expandieren der Felder. Statt sämtliche direkten Nachbarn des Feldes zur Open List hinzuzufügen, wie A* es tut, versucht Jump Point Search, Symmetrien zu erkennen, zu vermeiden und entsprechende Felder/Knoten zu ignorieren. Das Ignorieren bzw. Abschneiden der Kanten zu diesen Knoten wird auch Pruning genannt. Dadurch, dass somit die meisten Felder lediglich überprüft, aber nicht sofort in die Open List einsortiert werden müssen (da sie übersprungen werden), ergibt sich ein großer Geschwindigkeitsvorteil. Die Felder, die dann übrig bleiben, werden Jump Points genannt und bilden die Nachfolger des Knotens, von dem aus gesprungen wurde. Dabei wird zwischen horizontalem/vertikalem und diagonalem Springen unterschieden. Die Vorgehensweise wird in den nächsten beiden Unterkapiteln anhand von Abbildung 14 gezeigt. [15] Abbildung 14 - Pruning der Nachfolger eines Feldes beim Expandieren [15] (a) zeigt die Felder, welche bei einer horizontalen Expansion ignoriert werden (grau) (b) zeigt einen Forced Neighbor auf Feld 3, da Feld 2 blockiert ist (schwarz) (c) zeigt die Felder, welche bei einer diagonalen Expansion ignoriert werden (grau) (d) zeigt einen Forced Neighbor auf Feld 1, da Feld 4 blockiert ist (schwarz) Horizontaler und vertikaler Sprung Angenommen, man kommt von Feld 4 nach x und möchte nun x expandieren (vgl. Abbildung 14 Teil a). Da wir von 4 kommen, kann das Feld 4 direkt ignoriert werden. Felder 1, 2, 6 und 7 sind von 4 aus direkt zu erreichen und somit schneller als über x, daher werden sie auch ignoriert. Als letztes lassen sich noch Felder 3 und 8 ignorieren, da diese ebenfalls von 4 aus ohne über x zu gehen genauso schnell zu erreichen sind. Somit bleibt nur Feld 5 übrig, d.h. das nächste Feld, welches in der Laufrichtung liegt. Solange keine Hindernisse vorliegen, wird also in diese Richtung gesprungen, was auch als horizontaler Sprung bezeichnet wird. Liegt nun aber ein Hindernis auf Feld 2 oder 7 vor (vgl. Abbildung 14 Teil b), wird der Sprung beendet und das aktuelle Feld x der Open List hinzugefügt. Der Grund dafür liegt darin, dass nun Feld 3 nicht mehr ignoriert werden kann, da nun der Weg durch x der (einzige) schnellste Weg dorthin ist. Feld 3 wird nun Forced Neighbor genannt, da wir es genauer betrachten müssen, statt es wie zuvor ignorieren zu können. Als nächstes besteht nun die Möglichkeit, von Feld x aus sowohl in Richtung 5 (nach rechts), als auch in Richtung 3 (nach rechts oben) zu springen

30 Sollte Feld 5 blockiert sein, wird der komplette Sprung verworfen, da er in einer Sackgasse enden würde. Ein vertikaler Sprung funktioniert analog dazu Diagonaler Sprung Bei einem diagonalen Sprung wird ähnlich vorgegangen (vgl. Abbildung 14 Teil c). Hier werden die Felder 1, 4, 6, 7 und 8 ignoriert, da der Weg von 6 aus ohne x zu nutzen schneller oder gleich schnell wäre. Ist Feld 4 oder 7 blockiert, werden Feld 1 bzw. 8 zum Forced Neighbor (vgl. Abbildung 14 Teil c). Im Gegensatz zum horizontalen bzw. vertikalen Sprung kann man hier aber nicht einfach diagonal weiterspringen, bis ein Forced Neighbor auftritt schließlich gibt es 3 Felder, welche potentielle Nachfolger sind (2, 3 und 5). Von jedem Feld, das man nach einem diagonalen Schritt expandiert, führt man also zuerst einen horizontalen, dann einen vertikalen Sprung aus. Wird hier ein Forced Neighbor gefunden, fügt man die aktuelle Position des expandierenden Feldes der Open List hinzu und beendet den Sprung somit. Ansonsten führt man einen weiteren diagonalen Schritt zum nächsten Feld in der bestehenden Richtung aus und expandiert es. Das wiederholt man solange, bis entweder ein Forced Neighbor durch einen der horizontalen oder vertikalen Sprünge gefunden wurde, oder bis der diagonale Sprung auf ein direktes Hindernis trifft. In letzterem Fall wird der komplette Sprung verworfen, da er wieder in einer Sackgasse endete und kein geeignetes Nachbarfeld gefunden werden konnte Ablauf Das allgemeine Vorgehen bei JPS unterscheidet sich nicht von A*: Man expandiert einen Knoten und fügt dessen Nachfolger in eine Open List hinzu. Dann nimmt man von dieser den mit der besten (niedrigsten) Bewertung und expandiert ihn usw. Lediglich bei der Suche der Nachfolger unterscheidet er sich. Statt der angrenzenden freien Felder werden Jump Points des zu expandierenden Knotens gefunden und in die Open List eingefügt. Dabei wird beachtet, aus welcher Richtung man auf das expandierende Feld gelangt ist. Gesprungen wird dann in die Richtung jeder Felder, welche nicht durch Pruning wegfallen (vgl. Abbildung 14). Horizontal/vertikal wird in derselben Richtung sowie in Richtung des Forced Neighbors weitergesprungen. Es muss hier nämlich einen Forced Neighbor geben, denn sonst hätte der vorangegangene Sprung zu diesem Feld nicht gestoppt. Diagonal wird analog dazu vorgegangen. Zur Wiederholung und Zusammenfassung der Suche nach einem Jump Point: Bei einem horizontalen oder vertikalen Sprung wird so lange gesprungen, bis ein Feld mit einem Forced Neighbor gefunden wurde. Dieses Feld ergibt dann den Jump Point. Wird ein direktes Hindernis in Sprungrichtung gefunden, ist der Sprung ungültig und ergibt keinen Jump Point. Bei einem diagonalen Sprung wird für jedes Feld auf dem Weg zunächst horizontal und vertikal nach einem Jump Point gesucht. Wird einer gefunden, wird das diagonal angesprungene Feld zum Jump Point. Ansonsten wird weitergesprungen, bis ein Hindernis in diagonaler Richtung auftaucht (oder vorher ein Jump Point in einer der horizontalen bzw. vertikalen Suche gefunden wurde). Beim Treffen auf ein Hindernis wird auch hier der Sprung ungültig und es gibt somit keinen Jump Point in dieser Richtung

31 Die folgende Grafik verdeutlicht die Vorgehensweise des Algorithmus anhand eines Beispiels. Das grüne Feld ist der Startpunkt, das rote Feld das Ziel. Graue Felder sind gefundene Jump Points, das gelbe Feld ist der zuletzt gefundene Jump Point, von dem aus direkt ins Ziel gesprungen wird. Die Pfeile zeigen die versuchten Sprünge. Die blauen Pfeile im rechten Teil der Grafik entsprechen den erfolgreichen Sprüngen und stellen den optimalen Weg zum Ziel dar. [16] Abbildung 15 - Beispiel einer Suche mit JPS Es wird vom grünen Startfeld aus ein Weg zum roten Feld gesucht. Die Pfeile stellen die Sprünge dar, graue Felder sind Jump Points. Die tatsächlich vollzogenen Sprünge sind blau markiert. 6.3 Evaluierung Im Vergleich zu normalem A* und Erweiterungen wie HSPA* hat der JPS-Algorithmus den Nachteil, dass er nur auf unbewerteten Grids funktioniert. Es können somit keine Orte schlechter oder besser zu begehen sein als andere. Es besteht jedoch die Möglichkeit, den Algorithmus so zu erweitern, dass auch bewertete Grids verwendet werden können das würde die Performance allerdings mit hoher Wahrscheinlichkeit verschlechtern. Jump Point Search benötigt zur Suche des besten Weges im schlimmsten Fall etwas länger als A*, ist im optimalen Fall aber um ein Vielfaches schneller. Gerade weite Flächen können schnell übersprungen werden, sodass die Anzahl der expandierten Knoten am Schluss viel geringer ist als bei A*. Ein genauerer Vergleich zwischen JPS und A* folgt unter Evaluierung im Kapitel Jump Point Search in Unity 3D. 6.4 JPS+ Die Erfinder von JPS haben im Jahr 2012 einen weiteren Ansatz präsentiert: JPS+. Durch das Springen zu den Jump Points im JPS-Algorithmus werden viele zeitaufwändige Operationen, welche die Open List betreffen (hinzufügen, sortieren, löschen), vermieden. Das Berechnen dieser Jump Points ist allerdings ein Flaschenhals (wenn auch ein nicht so kritischer), der an diese Stelle tritt. JPS+ lagert diese Berechnungen in einen Pre-Processing-Schritt aus: Statt der tatsächlichen direkten Nachbarn eines Feldes werden dessen mögliche Jump Points im Graphen gespeichert und können zur Laufzeit dann direkt zum Sprung verwendet werden. [17]

32 7 Jump Point Search in Unity 3D 7.1 Übersicht Im Rahmen der Bachelorarbeit wurde ein Package für Unity entwickelt, welches die folgenden Assets beinhaltet: - Mehrere C#-Scripts, in denen sowohl A* als auch Jump Point Search implementiert sind, inklusive benötigter Helferklassen (Tile, Point) und Datenstrukturen (PriorityQueue) - Scripts, die beim Ausführen, Überwachen und Auswerten der Algorithmen helfen, ebenfalls in C# implementiert (Finder, FinderData) - Zwei Scenes, welche die Funktionalitäten der Algorithmen demonstrieren sollen, inklusive zugehöriger Scripts und Prefabs: VisualTiles und TileExporter VisualTiles Die Visual Tiles Demo umfasst ein interaktives Level, bestehend aus einem Grid von 70x70 Feldern ( Tiles ), in dem die beiden Wegfindungsalgorithmen ausprobiert werden können. Mithilfe der Maus werden Start- und Endpunkt gesetzt. Anschließend wird dann wahlweise von A* oder Jump Point Search der beste Weg zwischen diesen beiden Punkten gesucht. Die Tiles, die der Weg durchschreitet, werden grün markiert. Der gelbe Bereich stellt dar, welche Felder der Algorithmus expandiert hat, d.h. wo er nach einem Weg gesucht hat. Je größer die Anzahl der gelben Tiles, desto zeitaufwändiger war die Suche. Ebenfalls wird dem Nutzer die Dauer mitgeteilt, die der Algorithmus benötigt hat, um den Weg zu finden. Abbildung 16 - Beispiel eines gefundenen besten Weges in der VisualTiles-Demo

33 7.1.2 TileExporter Die Tile Exporter Demo dient dem Benchmark der beiden Algorithmen. Hierbei wird vor dem Start ein Level ausgewählt, das bis zu 512x512 Tiles umfasst, was einen deutlich höheren Rechen- und somit Zeitaufwand im Vergleich zur Visual Tiles Demo bedeutet. Somit lassen sich Zeitunterschiede sehr viel einfacher herausstellen. Analog zur anderen Demo werden auch hier der optimale Weg (in blau) und die expandierten Tiles (rot) eingezeichnet. Das gewünschte Level kann vor dem Start im Inspektor von Unity ausgewählt werden. Die Grafik, die in der Mitte des Bildschirms dargestellt wird, kann auf Wunsch automatisch als PNG-Datei exportiert werden. Die in der Demo enthaltenen Levels sind von einer Benchmark-Seite der Moving AI Lab [18] bezogen. Diese bietet eine umfangreiche Auswahl an unterschiedlichen Testdateien zum Auswerten von Grid-basierten Algorithmen. Neben speziell für Tests hergestellten Maps (Labyrinthe, Räume, zufällige Hindernisse) werden auch Levels aus Rollen- und Strategiespielen von BioWare (Baldur s Gate, Dragon Age) sowie Blizzard (Starcraft, Warcraft 3) angeboten. Mithilfe von diesen lässt sich gut abschätzen, wie ein Algorithmus tatsächlich in einem Spiel abschneiden würde. Abbildung 17 - A*-Benchmark in der TileExporter-Demo anhand eines Levels aus Baldur's Gate

34 7.2 Implementierung des Algorithmus Der Quelltext wurde in C# geschrieben. Zur späteren Evaluierung, vor allem in Bezug auf die Performance von JPS, wurde zusätzlich eine normale Version von A* implementiert. Da ein Spiel nicht einfach pausieren kann (selbst wenn es nur 100ms wären), läuft die Wegfindung in einem separaten Thread. Hierzu wurden zwei Helper-Klassen erstellt: Finder und FinderData. FinderData kapselt sämtliche Parameter, die der Algorithmus zur Berechnung des besten Weges benötigt u.a. die komplette Tilemap, Startpunkt und Endpunkt. Bei Abschluss wird die FinderData- Instanz mit Informationen über das Resultat also den gefundenen Weg aufgefüllt, welches dann vom Spiel abgefragt werden kann. Der eigentliche Aufruf wird über die Finder-Klasse stark vereinfacht. Es wird eine Finder-Instanz als Klassenvariable angelegt, mit welcher dann bei Bedarf der Algorithmus ausgeführt werden kann. Der Finder benötigt hierzu lediglich ein FinderData-Objekt mit den entsprechenden Informationen. In der Game Loop (die Schleife, in der sich ein Spiel befindet, während es läuft) wird kontinuierlich überprüft, ob die Suche abgeschlossen wurde. Wenn dies der Fall ist, kann man von der Finder- Instanz das Resultat abfragen. Hierbei sollte man allerdings nicht vergessen, zu prüfen, ob es eventuell zu einem Fehler kam // create the class variable private Finder finder; (...) // run pathfinder finder = new Finder(new FinderData(tileMap, start, end)).runjps(); (...) // in the game loop, check if it has finished if ((finder!= null) && (finder.isfinished())) { // check for error if (finder.haserror()) { finder = null; return; } } // use the pathfinder result MoveCharacter(finder.GetResult().GetCompleteBestPath()); finder = null; Codelisting 2 - Verwendung der Finder-Klasse zur Ausführung der Wegfindung

35 Es folgen zwei Quelltext-Auszüge, welche die Implementierungen der beiden Algorithmen gegenüberstellen. Es wird jeweils die While-Schleife gezeigt, die den zentralen Aspekt ausmacht und solange läuft, bis das Ziel gefunden wurde // JUMP POINT SEARCH IMPLEMENTATION // add start tile to open list openheap.push(start); // continue until open list is empty while (!openheap.isempty) { // get first (most primising) tile from the open Tile currenttile = openheap.pop(); closed[currenttile.pos.x, currenttile.pos.y] = true; } // check for goal in current tile if (currenttile.pos.equals(data.endpoint)) return data.calculatereturndata(currenttile, closed); // find and add successors foreach (Point neighbor in GetNeighbors(currentTile, data.tilemap)) { Point jumppoint = Jump(neighbor, currenttile.pos, data); } // skip this successor, if it is already on the closed list // or no jump point could be found if ((jumppoint == null) (closed[jumppoint.x, jumppoint.y])) continue; Tile jumpnode = new Tile(jumpPoint.x,jumpPoint.y,currentTile); jumpnode.g = currenttile.g + Tile.EuclideanDistance(currentTile.pos, jumppoint); jumpnode.calch(data.endpoint); jumpnode.calcfonly(); openheap.push(jumpnode); Codelisting 3 - Auszug aus dem Quelltext der Jump Point Search Implementierung

36 // A* IMPLEMENTATION // add start tile to open queue openheap.push(start); // continue until open queue is empty while (!openheap.isempty) { // get first (most primising) tile from the open Tile currenttile = openheap.pop(); } // if current tile is in closed list, ignore it if (closed[currenttile.pos.x, currenttile.pos.y]) continue; // check for goal in current tile if (currenttile.pos.equals(data.endpoint)) return data.calculatereturndata(currenttile, closed); // add current tile to closed list closed[currenttile.pos.x, currenttile.pos.y] = true; // go through successors of current tile foreach (Point suc in currenttile.getneighbors(data.tilemap)) { // calculate total cost and add it to the queue Tile suctile = new Tile(suc.x, suc.y, currenttile); suctile.calcfgh(data.endpoint); openheap.push(suctile); } Codelisting 4 - Auszug aus dem Quelltext der A* Implementierung Im Vergleich lassen sich leicht die vielen Ähnlichkeiten erkennen und es wird schnell sichtbar, dass JPS eine Erweiterung von A* ist. Der wesentliche Unterschied besteht in der Suche der Nachfolger. Dazu nutzt JPS eine speziell angepasste Version der GetNeighbors()-Funktion und führt auf diesen Nachbarn die Jump()-Funktion aus, um einen Jump Point zu finden. Die Kosten des Nachfolgers müssen ebenfalls gesondert berechnet werden, da hier der Abstand zwischen aktuellem und nachfolgendem Tile beachtet werden muss. Dieser ist bei A* immer gleich 1, da dort nicht gesprungen wird daher fällt eine entsprechende Rechnung weg

37 7.3 Datenstrukturen und Optimierungen Es ist nicht nur wichtig, dass der Algorithmus an sich effizient und schnell arbeitet. Ein wesentlicher Teil der Performance wird dadurch beeinflusst, auf welche Art und Weise er implementiert wird. Den wohl größten Unterschied macht hier die Wahl der Datenstrukturen aus, welche für die Open- und Close-Listen verwendet werden. Normale, unsortierte Arrays oder verknüpfte Listen sind die langsamste Variante. Das Hinzufügen eines Knotens ist zwar sehr schnell, die Suche nach einem vorhandenen Knoten oder dem mit den niedrigsten Kosten hingegen ist sehr zeitintensiv. Im schlimmsten Fall müssten hier alle Elemente durchlaufen werden, bis der gesuchte Knoten gefunden wird. Nach Kosten sortierte Arrays beschleunigen die Abfrage des kostengünstigsten Knoten (welcher sich an erster Stelle befindet), sowie die eines bestimmten Knoten (mithilfe von Binärsuche). Das Einfügen ist jedoch zeitaufwendiger, da hierzu alle nachfolgenden Elemente verschoben werden müssen. Eine weitere Möglichkeit vor allem bei grid-basierten Suchalgorithmen - sind indexierte Arrays. Hierbei wird für jedes Tile ein Speicherplatz reserviert, wodurch man sehr schnell auf ein bestimmtes Feld zugreifen kann, da direkt über den bekannten Index des Tiles im Array zugegriffen werden kann. Das Einfügen und Löschen eines Feldes läuft ebenfalls schnell ab. Die Suche nach dem kostengünstigsten Knoten ist allerdings aufwendig, da das komplette Array durchsucht werden muss. Für die Open List in dieser Arbeit wurde eine eigene, simple Datenstruktur erstellt. Diese besteht im Wesentlichen aus einer verknüpften Liste und einem Comparer-Objekt, welches zwei Knoten miteinander vergleicht und bestimmt, welcher die niedrigeren Kosten besitzt. Beim Einfügen in die Liste wird das Element direkt an die entsprechende Position geschoben, sodass die Liste jederzeit sortiert bleibt. Die Suche nach dieser Position wird von einer Binärsuche mithilfe des Comparers relativ schnell durchgeführt. Der kostengünstigste Knoten ist schnell abzufragen, da er immer an der ersten Stelle steht. Diese Lösung bietet somit einen sinnvollen Kompromiss zur Anwendung bei Wegfindungsalgorithmen. Sie ist hier besonders effektiv, da in dieser Jump Point Search Implementierung keine Suche nach einem bestimmten Tile notwendig ist, abgesehen von der Suche nach dem kostengünstigsten Tile, welche durch die Sortierung schnell passiert. Für die Closed List wird ein simples multidimensionales Boolean-Array verwendet. Für jedes Tile im Grid kann direkt abgefragt werden, ob es bereits expandiert wurde, oder nicht. Da hier nur Booleans gespeichert werden und nicht die eigentlichen Tiles, ist der höhere Speicherbedarf im Vergleich zu einer Liste auch in größeren Grids vernachlässigbar, jedoch ist der Geschwindigkeitsunterschied erheblich. Es gibt keine perfekte Datenstruktur, die für alle Anwendungsfälle optimal ist jede hat ihre Schwächen und Stärken. Daher muss man bei der Implementierung darauf achten, die für die verwendeten Operationen performanteste Datenstruktur zu wählen, beziehungsweise sich seine eigene zusammenzustellen. Idealerweise vermeidet man die für viele Datenstrukturen zeitaufwendigen Operationen (wie beispielsweise das Prüfen, ob ein Element vorhanden ist) so weit wie möglich

38 Einen kleinen Performanceschub kann es geben, wenn man das 2D-Grid auf 1D-Koordinaten abbildet: 1D-Position = X + Grid-Breite * Y Somit müssen die Koordinaten nicht immer erst von der Garbage Collection erzeugt und später wieder entfernt werden, sondern können direkt als Integer weitergegeben werden. Auch der Speicherbedarf sinkt etwas, da nur noch ein einzelner Integer gespeichert wird (statt zwei). Das klingt zunächst vernachlässigbar, kann sich aber bei großen Grids und parallel laufenden Wegfindungsalgorithmen um mehrere MB handeln. 7.4 Evaluierung Der Jump Point Search Algorithmus wurde speziell dazu entwickelt, Wegfindung auf einem Grid mit einheitlichen Kosten zu beschleunigen. Mithilfe der TileExporter-Demo wurden auf neun unterschiedlichsten Test-Levels sowohl A* als auch JPS ausgeführt und deren Laufzeiten in Millisekunden aufgezeichnet. In jedem Level wurden mehrere Durchläufe pro Algorithmus ausgeführt und die Ergebnisse gemittelt. Die Standardabweichungen innerhalb der einzelnen Testfälle betrugen nie mehr als 5ms und die Laufzeiten somit sehr konstant. Daher wurde auf eine ausführliche Auflistung der Resultate verzichtet und es werden lediglich die Mittelwerte pro Testergebnis angegeben. Getestet wurde auf einem Intel i prozessor. Die folgende Tabelle beschreibt die neun verschiedenen Testgrids und das Diagramm die Ergebnisse der Tests. TestID Levelbeschreibung (512x512 Tiles) 1 Innengebiet aus Baldur s Gate, bestehend aus einer größeren Halle mit verschiedenen angrenzenden Räumen 2 Labyrinth, das das komplette Grid umfasst und dessen Gänge nie breiter als 1 Tile sind 3 Labyrinth, das das komplette Grid umfasst und dessen Gänge 32 Tiles breit sind 4 zu 10% mit zufällig verteilten Wänden besetztes Level 5 zu 35% mit zufällig verteilten Wänden besetztes Level 6 Level bestehend aus 64x64 Räumen, die jeweils 7x7 Tiles groß sind und Verbindungen zu 1-4 angrenzenden Räumen besitzen 7 Level bestehend aus 8x8 Räumen, die jeweils 63x63 Tiles groß sind und Verbindungen zu 1-4 angrenzenden Räumen besitzen 8 Innengebiet aus Baldur s Gate, bestehend aus vielen Räumen und einigen verstreuten Hindernissen sowie langen Fluren 9 Außengebiet aus Baldur s Gate mit weiten Flächen und großen Hindernissen und einer Stadtmauer, um die ein Weg herum gesucht werden muss

39 JPS (in ms) A* (in ms) Abbildung 18 - Ergebnisse der Vergleichstests zwischen A* und JPS Wie man sehen kann, ist JPS tatsächlich in den meisten Fällen deutlich schneller. Gerade bei den realen Spielbeispielen (Tests 1, 8 und 9) kann ein Weg mit der 20-30fachen Geschwindigkeit berechnet werden. Das liegt daran, dass Jump Point Search bei weiten Flächen seine Stärken zeigen kann, da diese größtenteils übersprungen werden können. Tests 3 und 7 verdeutlichen das. Nur in Grids mit sehr vielen kleinen Hindernissen (Test 4) befindet sich A* im Vorteil: der Algorithmus bewegt sich zielstrebiger zum Ziel, während JPS breit gefächert nach vielen Jump Points sucht, die sich durch die Menge der Hindernisse ergeben. Hierbei muss allerdings beachtet werden, dass A* nur deshalb so schnell zum Ziel gelangt, weil der Weg beinahe geradlinig und ohne größere Umwege zu erreichen ist. Wäre dies nicht der Fall, könnte JPS einen entsprechenden Umweg wiederum etwas schneller finden. Das wird in Test 2 gezeigt, dessen Level ebenfalls ein Grid mit vielen Hindernissen, jedoch ohne direkt offensichtlichen Weg zum Ziel ist. In diesen neun (sehr unterschiedlichen) Tests benötigte A* im Schnitt 448ms und Jump Points Search nur 65ms. Das bedeutet, dass JPS im Schnitt etwa 7x so schnell war. Die Standardabweichung betrug 569ms bei A* und nur 47ms bei JPS. Damit lässt sich erkennen, dass JPS konstanter in seiner Performance ist, während die Suchdauer von A* stärker vom jeweiligen Level abhängt. Um die Unterschiede besser nachvollziehen zu können, folgen nun einige grafische Ausgaben aus der TileExporter-Demo

40 Abbildung 19 - Tests 1-3 (links: A*, rechts: JPS) Expandierte Tiles sind rot markiert, der beste Pfad blau. Je mehr rot, desto mehr Tiles wurden expandiert und desto mehr Zeit hat der Algorithmus benötigt

41 Abbildung 20 - Tests 4-6 (links: A*, rechts: JPS) Schwächeres rot bedeutet, dass die Dichte der expandierten Felder geringer ist

42 Abbildung 21 - Tests 7-9 (links: A*, rechts: JPS)