2D-Karten von oben nach unten

Ich habe mich gefragt, wie das funktioniert.

Laden Sie die gesamte Karte beim Start des Spiels oder laden Sie Teile der Karte zur Laufzeit?

Und wie würden Sie die Karten speichern? Wäre es in XML oder einem Binärformat?

Vielen Dank!

Ich stimme eBusiness zu. Dies hängt von der Größe und der Art der Bearbeitung ab.

Schätzen Sie die Bytegröße Ihrer Karte in einer relativ kompakten Darstellung. Entscheiden Sie auch, welche Teile der Karte sich während des Spiels ändern können. Die Teile, die sich nicht ändern, können geladen werden und müssen nicht gespeichert werden. Wenn die geschätzte Größe klein ist, speichern Sie einfach alles im Speicher. Es lohnt sich nicht, Teile der Karte zu laden und zu verfolgen, was Sie geladen haben oder nicht, es sei denn, die Daten sind so groß, dass dies erforderlich ist.

Wenn Sie beispielsweise Civilization II geschrieben haben , beträgt Ihre Kartengröße möglicherweise 100 x 100 Kacheln.

1. Jede Kachel ist eine von 12 Arten, so dass Sie diese in 4 Bits speichern können. Das bedeutet, dass die Hauptzuordnung 100 x 100 x 0,5 Byte = 5.000 Byte zum Speichern der Kacheltypen ist. Die Hauptkarte ändert sich nie.
2. Sie können Kartenkacheln auch mit Straßen, Bewässerung usw. verbessern, und es gibt bis zu 7 Verbesserungen. Das bedeutet 2 ^ 7 verschiedene Werte, die 7 Bits benötigen, aber wir würden wahrscheinlich nur 1 Byte dafür verwenden. Das gibt uns 100 x 100 x 1 Byte = 10.000 Byte, um die Verbesserungen zu speichern.
3. Der Nebel des Krieges sagt uns, welche Kartenplättchen Sie gesehen haben, also benötigen Sie 1 Bit pro Spieler. Wenn Sie auf 8 Spieler beschränken, ist dies ein weiteres Byte pro Kartenplättchen oder 10.000 Byte für den Nebel des Krieges.
4. Schließlich gibt es alle Städte und Einheiten. Sie können schätzen, dass jeder Spieler bis zu 20 Städte und 100 Einheiten hat, und jede dieser Städte benötigt möglicherweise 100 Datenbytes (wilde Vermutung), das sind also 12.000 Bytes (viel mehr, wenn Sie XML verwenden).

Das sind weniger als 30.000 für eine kompakte binäre Darstellung der Civ II-Map + -Objekte, sodass Sie alles im Speicher speichern können, selbst wenn Sie ein ausführliches Format verwenden, das viel größer ist. Ich habe die obigen Zahlen von jemandem erhalten, der die Civ II-Kartenstruktur rückentwickelt hat .

Daggerfall , von einigen als lächerlich groß angesehen, scheint 5000 x 2500 und etwa 25 Megabyte groß zu sein , hat aber auch eine große Anzahl von NPCs (750.000 habe ich gelesen, aber das scheint sehr hoch zu sein). Auf heutigen Desktop- / Laptop-Computern könnte dies ebenfalls in den Speicher passen, auf Mobilgeräten oder Browsern jedoch etwas zu groß. Es gibt ein Wiki, das das Daggerfall-Kartenformat beschreibt .

Sie können die Größe reduzieren, indem Sie Redundanz identifizieren und ausklammern . Anstatt beispielsweise jeweils 100.000 identische Bäume oder Schwerter in einem XML-Format zu speichern, speichern Sie einen Baum und ein Schwert sowie 100.000 Verweise darauf. In den Binärformaten kann diese Referenz nur 1 oder 2 Bytes betragen, und in einem ausführlicheren Format kann die Referenz immer noch relativ klein sein.

Mach das Einfachste, was für dein Spiel funktioniert. Wenn die Karte klein ist, spielt es keine Rolle, ob Sie ein kompaktes oder ausführliches Format verwenden. Wenn das kompakte Format in den Speicher passen würde, das ausführliche Format jedoch nicht, müssen Sie entscheiden, ob die zusätzliche Arbeit des Binärformats mehr oder weniger als die zusätzliche Arbeit des Ladens von Teilen der Karte ist. Das hängt vom Spiel ab. In einem Civ-ähnlichen Spiel, in dem Sie alle Daten benötigen, um Runden zu simulieren, ist das Binärformat wahrscheinlich die bessere Wahl. In einem Dolchfall-ähnlichen Spiel, in dem Sie keine Bereiche laden müssen, außer in der Nähe des Spielers, ist das Laden von Teilen der Karte wahrscheinlich die bessere Wahl. Wenn die Karte so ist Wenn das kompakte Format nicht in den Speicher passt, fragen Sie sich zunächst, ob sich die zusätzliche Arbeit wirklich lohnt, und entwerfen Sie in diesem Fall ein Binärformat, von dem Sie Teile laden können.

Für mein aktuelles (Hobby-) Projekt passen die Karten und alle darauf befindlichen Objekte in 50 MB, sodass es in Ordnung wäre, alles im Speicher zu behalten. Ich möchte jedoch, dass es im Browser ausgeführt wird und 50 MB mehr sind, als ich über das Netzwerk übertragen möchte. Daher speichere ich sie alle auf dem Server und lade dann nur Teile der Welt in den Client. Meine Kartenkacheln sind 1 Byte pro Kachel, 2048 x 2048 Kacheln (4 MB). Die Objekte (Bäume, Stühle, Orks usw.) sind der Einfachheit halber JSON-codiert. Im Client lade ich nur die Kartenbereiche (einschließlich ihrer Objekte), die sich in der Nähe des Players befinden.

Wie viel geladen werden muss, hängt zumindest davon ab, wie groß die Karte ist. Wenn die Daten angemessen in den Speicher passen, gibt es wirklich keinen Grund, sich mit dem progressiven Laden zu beschäftigen.

Das Bemerkenswerteste, was XML tut, ist, viel zusätzlichen Speicher / Speicher / Netzwerkspeicher / Datenverkehr zu beanspruchen. Wenn Sie der Meinung sind, dass die Verwendung von XML Spaß macht, sollten Sie dies nur für relativ kleine Datenmengen tun.

Wenn Sie ein Datenformat entwerfen, sollten Sie berücksichtigen, wie Sie diese Daten bearbeiten möchten. Sie können Ihre Daten mit einem einfachen Texteditor als reine Textdatei schreiben, diese Dateien direkt verwenden oder platzsparend in ein Binärformat konvertieren. Sie können einen Bildeditor verwenden, um Ihre Ebenen als Bitmaps zu erstellen. Auch hier möchten Sie möglicherweise in eine kleinere Datei konvertieren.

Oder Sie können Ihren eigenen Editor erstellen. In diesem Fall gibt es wenig Grund, kein kompaktes Binärformat zu verwenden.

Auf diese Fragen gibt es keine Antwort. Dies liegt ganz bei Ihnen.

Sie können Karten jederzeit speichern und jederzeit anzeigen / rendern.