Sollte ich dieselbe Kachelstruktur für die Anzeige und Pfadfindung verwenden?

8

Ich weiß, wie man eine 2D-Karte mit Kacheln anzeigt.

Ich weiß, wie man mit A * einen Pfadfindungsalgorithmus erstellt.

Diese beiden Dinge erfordern eine Struktur oder eine Klasse. Meine Frage ist: Verwenden Sie dieselbe Struktur für die Anzeige und Pfadberechnung? Knotenstruktur für die Pfadfindungsanforderung zum Hinzufügen einiger Daten: x-Position, y-Position, F, G, H sowie der übergeordnete Knoten. Die Kachelstruktur für die Anzeige kann auf fast nur eine Information optimiert werden: den Wert der Kachel.

Verwenden Sie eine große Klasse für Ihre Kacheln, die sowohl die Anzeige als auch die Pfadfindung übernimmt, oder verwenden Sie eine andere Methode? Vielen Dank für Ihre Ratschläge!

path-finding tiles data-structure Raveline
quelle
Tolle Frage, ich musste das wirklich lernen, aber ich wusste nicht, was ich fragen sollte.
DFectuoso

Antworten:

6

Meine Frage ist: Verwenden Sie dieselbe Struktur für die Anzeige und Pfadberechnung?

Nein, ich nicht. Sie können die Berechnung Ihres A * direkt auf der Kachelkarte optimieren, aber dann können Sie Ihren A * -Algorithmus nicht einfach für Dinge verwenden, die nicht direkt auf die Kacheln abgebildet werden. Dies bedeutet auch, dass Sie den A * -Algorithmus nicht gleichzeitig in mehreren Threads ausführen können, da diese letztendlich die Kartendaten gemeinsam nutzen. Schließlich erlauben bestimmte Verschiebungsmethoden die Optimierung von Kachel = Knoten nicht. Ein Fahrzeug, das Platz zum Wenden benötigt, kann möglicherweise aus verschiedenen Richtungen auf dasselbe Plättchen gelangen und jeweils unterschiedliche Optionen haben - sie können nicht zu einer Punktzahl zusammengeführt werden.

Daher schlage ich vor, die Daten getrennt zu halten.

Kylotan
quelle
Es ist zwar interessant, sie getrennt zu halten, Sie müssen jedoch kein explizites Diagramm für die Pfadfindung verwenden. Sie können jedoch eine "Tilemap" mit nur den Kollisions- / Kosteninformationen erstellen, die vollständig vom Rendering und vom logischen Modell getrennt sind. Wenn Sie beispielsweise der Welt ein Objekt hinzufügen, das nicht in der Kachelkarte gespeichert ist, sondern nur (x, y) -Koordinaten verwendet, können Sie es dennoch in die Kollisionskarte einfügen und dieses für die gitterbasierte Pfadfindung verwenden.
Trinidad
3

Aus Sicht der Softwareentwicklung ist es immer gut , verschiedene Dinge getrennt zu halten .

Stellen Sie für eine schnelle und schmutzige Lösung alles zusammen und beginnen Sie mit der Arbeit an Spielspezifikationen.

Halten Sie für eine erweiterbare Lösung die Dinge auseinander: Sie möchten keine Kachelklassen ändern, da Ihr Pfadfindungsalgorithmus geändert wurde! Behalten Sie zwei Strukturen bei: eine für sichtbare Spielplättchen und eine für die Pfadfindungsstruktur. Im Idealfall wird ein Pfadfindungsalgorithmus auf einem niedrigen Niveau gehalten. Daher ist möglicherweise ein Array von x, y-Punkten als Eingabe für den Algorithmus eine bessere Idee, als ihn mit Ihren Kachelklassen zu versehen. Der Algorithmus selbst kann Arrays für F-, G- und H-Werte einrichten.

Ich denke, in diesem Fall (und ich gehe davon aus, dass Sie sich bemühen, ein guter Programmierer zu sein) sollten Sie sich für die erweiterbare Lösung entscheiden, da Sie nicht so viel zusätzlichen Aufwand benötigen, aber Ihr Code sauberer bleibt und Sie gute Praxis erlangen Erfahrung.

Nef
quelle
2

Ich habe einmal ein kachelbasiertes Spiel auf dem Amiga 500 mit 512x512 Kacheln erstellt, aber der Spieler konnte nur 8 Kacheln bewegen, also habe ich eine "9x9" Kacheln "Wandkarte" pr erstellt. Soldat. Wenn ich dies mit der Originalkarte gemacht hätte, hätte ich es zuerst nach jeder Berechnung "aufräumen" müssen.

Also nein, halten Sie die Dinge so klein wie möglich und getrennt, damit Sie sie pr optimieren können. Objekt / Klasse bei Bedarf. Eine andere Sache, an die Sie denken sollten, könnte auch sein, dass sich einige Ihrer sich bewegenden Objekte möglicherweise über bestimmte Teile der Karte unterschiedlich bewegen. Z.B. langsam im Sand, kann / kann nicht schwimmen, kann Türen öffnen usw.

BerggreenDK
quelle