spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Schorsch«

Die Layeranzahl könnte man ja im Prinzip auch beliebig gestalten. Tiled unterstützt afair 100 Layer. Da wird man ja erst mal nicht unbedingt beschränkt.

Ja, das stimmt. Entweder baut man pro Layer ein eigenes 2D-Array, was beim Rendern randüberschreitender Tile-Grafiken durchaus ein Vorteil ist, aber bei Tile-bezogenen Abfragen wie z.B. Kollisionstests hässliche Speicherzugriffsmuster verursacht. Aber ok, so kritisch ist das nicht. Oder man macht pro Tile ein kleines Array von Layern auf - das machen wir so. Dann allerdings sollte die Layer-Anzahl zur Compile Time feststehen, sonst hat man wieder eine Allokation pro Tile.

Ich hab schon beides umgesetzt. Für die Variante, bei welcher ein Tile die eigenen Layer kennt habe ich allerdings eine List verwendet. So muss die Größe nicht feststehen und in meiner Variante konnte ein Tile sich direkt von unten nach oben durch rendern, da die Layer wirklich genau übereinander waren. Kollision mache ich normalerweise unabhängig von den Layern. Jedes Tile hat unabhängig eine Information die festlegt ob mit dem Tile kollidiert wird oder nicht. Im Prinzip als eine Art extra Layer. So hat es mir persönlich bis jetzt immer am besten gefallen.

Eine std::list? Also eine Allokation pro Layer pro Tile? Hui... nuja, für kleinere Maps tut auch das nicht weh.

Kollision kann man so machen, ist eine prima Sache für z.B. Zelda-artige Spiele. Ich brauchte aber pixelgenaue Kollision, die sich dann aus der Grafik ableitet, also muss ich pro Map-Feld die Kollisionsmaps der Tiles aller Layer kombinieren. Da bietet sich es dann an, die lokal beieinander zu haben.

Also zum einen gibt es ja nicht nur std::map sondern auch noch std::unordered_map oder etwas eigenes. War ja nur ein Beispiel. Außerdem war im eingangspost ja nicht unbedingt nach der Effektivsten Lösung sondern allgemein nach einer Möglichkeit gefragt.

An den Kritiken kann ich nicht rütteln, das ist mir klar. Nur ich frage mich grad ob wir dem Thread Ersteller einen Gefallen tun. Ziel der von mir vorgestellten Lösung war auch eher ihre Einfachheit seinen Bedarf zu erfüllen als die maximale Effizienz.

Hm. Einfach ist der Vorschlag zweier geschachtelter Maps schon, da hast Du Recht. Ich halte den Vorschlag aber für gefährlich. Das ist dann eben kein 2D-Feld aus Tiles mehr, sondern eine lose Sammlung Tiles anhand ihrer Koordinaten. Kann man machen, hat aber hintenraus einiges Potenzial für unerwartetes Verhalten und Inkonsistenzen.

Wenn überhaupt mit Maps, sollte man statt zwei geschachtelter Maps eine einzige Map mit einem komplexen kombinierten Schlüssel nutzen. Dann kann man ziemlich gut alle möglichen Konstellationen abbilden (unterschiedliche Ebenen, X/Y/Z-Koordinate, Spielzustände...). Im Grunde läuft es ja auf eine Funktion hinaus: getTile(int x, int y, int layer)...

Ich hab dazu einmal ein schönes Tutorial gesehen:


In späteren Teilen wird das System immer weiter erweitert (so zB. auch das dynamische Festlegen der Grösse von der Map).

@Schrompf: Das mit den Listen war bei einer kleineren .Net Spielerei. Geschwindigkeitstechnisch war das alles überhaupt kein Problem. Viele Layer waren es am Ende nicht. Ich glaube bis zu 4 Layer gab es insgesamt und für Kollision gab es ein extra Bool Attribut im Tile. Pixelgenaue Kollision ist wieder etwas ganz anderes. Wobei ich letztens mal darüber nachgedacht habe inwieweit Pixelkollision nötig ist. Ich glaube wenn man mit einfachen Shapes arbeitet bringt das auch fürs Verhalten schnell Vorteile mit sich. Wirklich pixelgenaue Kollision benötigt man glaube ich eher selten. Ist natürlich auch eine Aufwandsfrage. Pixelkollision muss man ein mal implementieren und so Shapes müssen beim Map bauen halt irgendwie mit eingearbeitet werden. Das kann natürlich schnell zu Mehraufwand für den Leveldesigner sorgen.
Mit den geschachtelten Maps, bzw einer einzigen Map, das kann man natürlich machen, muss man aber nicht Ich wüsste nicht warum das viel einfacher sein sollte als mit einer anderen Datenstruktur. Wenn man mit std::vector arbeitet, so holt der selbstständig neuen Speicher. Wenn man nicht mit verschachtelten vectoren arbeitet muss man natürlich selbst dafür sorgen, dass die richtigen Daten an der richtigen Stelle sind. Wenn ich es mir einfach machen wollte würde ich einfach mit geschachtelten std::vector arbeiten.