Ist es besser, Daten hart zu codieren oder einen Algorithmus zu finden?

8

Ich habe an einem Brettspiel gearbeitet, das ein Hex-Gitter als dieses Brett hat:

Da sich das Board niemals ändert und die Leerzeichen auf dem Board immer mit denselben anderen Leerzeichen um das Board herum verknüpft sind, sollte ich jedes Leerzeichen mit den von mir benötigten Werten hart codieren? Oder sollte ich verschiedene Algorithmen verwenden, um Links und Traversen zu berechnen?

Genauer gesagt handelt es sich bei meinem Brettspiel um ein 4-Spieler-Spiel, bei dem jeder Spieler ein Hex-Raster von 5 x 5 x 5 x 5 x 5 x 5 hat (siehe Abbildung oben). Das Ziel ist es, von der Unterseite des Gitters nach oben zu gelangen, wobei verschiedene Hindernisse im Weg sind und jeder Spieler sich vom Rand seines Gitters aus auf der Grundlage eines Entfernungsmultiplikators auf andere Spieler angreifen kann.

Da sich das Gitter des Spielers niemals ändert und der Abstand eines beliebigen Feldes vom Rand des Gitters immer gleich ist, sollte ich diese Zahl nur hart in jedes der Felder codieren oder trotzdem einen breiten ersten Suchalgorithmus verwenden, wenn Spieler greifen an?

Der einzige Nachteil, den ich mir für die harte Codierung vorstellen kann, ist, dass ich 9+ 2 (5 + 6 + 7 + 8) = 61 einzelne Zellen codiere. Fehlt mir noch etwas, das ich in Betracht ziehen sollte, komplexere Algorithmen zu verwenden?

algorithm procedural-generation hexagonal-grid

— OghmaOsiris
quelle

Ich kann Ihnen sagen, dass die Fläche für einen Radiusangriff 1 plus die Summe der Terme der durch f (n) = 6 (n-1) gegebenen Folge von n = 1 bis n = x ist, wobei x die Anzahl der Zeilen ist. EG 3 Reihen (10 Fuß Radius) = 1 + 6 + 12 = 19

— eazimmerman

Hier ist Pseudocode von dem, was ich beschrieben habe

int numberOfHexagonsInArea(int rows)   {    	int area = 1;   	while(rows>0)   	{   		area += (rows-1)*6;   		rows--;   	}   	return area;   }

— eazimmerman

Es scheint nicht sehr schwer? Von können {X,Y}Sie natürlich zu {X-1, Y}und {X+1, Y}in die gleiche Reihe gehen. In den Zeilen darunter und darüber können Sie zu {X, Y-1}und gehen {X, Y+1}. Schließlich können Sie abhängig von der Gleichmäßigkeit von Yzu {X-1, Y-1}und {X-1, Y+1}oder {X + 1, Y-1} `und{X+1, Y+1}

— MSalters

12

Ich denke, ich werde hier den Kontrapunkt nehmen und gegen die Verwendung statischer Werte argumentieren. In diesem Fall sind alle Hex-Regionen, über die Sie sprechen, (a) einfach zu berechnen - Sie müssen kein BFS oder etwas so Kompliziertes verwenden; Sie sollten in der Lage sein, alle Felder in einem von ihnen mit einfachen, doppelt verschachtelten Schleifen zu durchlaufen. und (b) nicht etwas, das Sie sehr oft "on-the-fly" berechnen müssen. Im schlimmsten Fall sollten Sie nur einmal pro Umdrehung berechnen müssen, und wenn mehrere Systeme haben die Zellen durch einen Effekt berührt wollen , dann können Sie ganz einfach die Werte aus in eine ‚reachableCells‘ Array oder etwas ähnliches zwischenzuspeichern; Unabhängig davon ist die Berechnung so einfach, dass sie in Bezug auf die Kosten pro Frame effektiv kostenlos sein sollte.

Also, was bekommst du dafür? Flexibilität. Im Moment ist es leicht zu sagen, dass sich diese Werte niemals ändern werden, aber Spiele haben ein Händchen dafür, Sie zu überraschen. Selbst wenn es wahrscheinlich ist, dass sich diese Regionen nicht ändern, geben Sie im Wesentlichen nichts auf, indem Sie diese Flexibilität einbauen, und es besteht eine gute Chance, dass Sie sich in Zukunft bei Ihnen bedanken werden. Selbst wenn dies die endgültigen Regionen sind, die Sie verwenden, sind gut geschriebene Schleifen zum Durchlaufen der Regionen wesentlich einfacher zu verstehen und zu debuggen als jede Art von Array mit festen Kacheln. Ich sehe einfach keinen bedeutenden Gewinn für hartcodierte Daten im Vergleich zu den Vorteilen, wenn man in die andere Richtung geht.

— Steven Stadnicki
quelle

11

Wenn sich die Werte niemals ändern, können sie auch statisch sein. Warum sollten Sie CPU-Zeit damit verschwenden, etwas neu zu berechnen, das mit dem letzten Mal identisch ist?

Sie müssen jedoch nicht unbedingt fest codiert sein:

Sie können die Werte in eine Datendatei einfügen und diese zu Beginn laden.
Sie können die Suche während der Wiedergabe durchführen und die Werte zwischenspeichern, sobald Sie sie gefunden haben.

Der erste Weg ist sinnvoll, wenn Sie glauben, dass Sie die Kartenform oder -größe in Zukunft ändern könnten. Der zweite Weg ist sinnvoll, wenn die Berechnung der statischen Werte etwas schwierig ist.

Ich habe keine Ahnung, wie eine sechsdimensionale Hex-Karte aussieht oder warum 9 + 2 (5 + 6 + 7 + 8) Zellen beteiligt sind, aber das beste Ergebnis für Ihre Situation - und in der Tat die meisten Situationen in der Spielprogrammierung - ist um zu codieren, was Ihnen am schnellsten das richtige Ergebnis bringt. Sie können es später bei Bedarf auf einen Algorithmus verallgemeinern. "Code für heute", wie manche sagen.

— Kylotan
quelle

Alles davon. Erst

— Mike Cluck

2

Um Ihre Verwirrung zu verdeutlichen, denke ich, dass sich das OP bei der Bezugnahme auf ein 5x5x5x5x5x5-Hex-Gitter nicht auf 6 physische (oder virtuelle) Dimensionen bezog, sondern auf ein Sechseck aus Sechsecken, wobei jede Seite des Sechsecks 5 kleinere Sechsecke entlang seiner Länge enthält. auf ähnliche dies (die schwarzen Punkte ignorieren). In diesem Fall würde die Karte 9 + 2 (5 + 6 + 7 + 8) Zellen enthalten.

Ja, das habe ich aus dem Diagramm gesehen, das in einer Bearbeitung veröffentlicht wurde.

— Kylotan

0

F: Ist dies das einzige Hex-Spiel, das Sie jemals schreiben werden? Nein?

A: Dann sollten Sie natürlich versuchen, flexibel zu sein, wo immer es Sie nicht viel zusätzlichen Aufwand kostet. Unabhängig davon, wie Sie das Board definieren, stellen Sie es zur Laufzeit mit expliziten Links dar. Es ist sehr praktisch, Bewegungs- und Beziehungslogik in Bezug auf das Durchlaufen von Links zu codieren, was unabhängig von der Größe oder Topologie der Karte ist.

— ddyer
quelle