spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Hol mich mal bitte ab, was ist 'Tile Layer' und 'Object Layer'? Kommt das von LibGDX, von dir oder von einer Lib, die 'Tiled Map' heißt (noch nie gehört)? Woher stammen diese Begriffe und was kann ich mir darunter vorstellen?
Ich weiß schon, was TileLayer und ObjectLayer rein logisch sind, aber du verwendest sie hier als wären sie Klassen oder Teile einer Lib oder sowas und mir erschließt sich nicht wieso du irgendwas von Iterieren erzählst, bei Box2D werden *alle* Objekte, die zur Physik gehören mit Polygonen modelliert und in die World gepackt, da iteriert man selbst eigentlich gar nichts und es ist auch egal in welchem Tile-Layer die liegen, weil Box2D sowas wie TileLayer gar nicht kennt. Tiles begehbar zu machen oder nicht würde ich persönlich allerdings nicht von Box2D abhängig machen, sondern von der reinen Logik der Tiles. Da gibt es eben begehbare und welche, die man nicht begehen kann und fertig is der Lack. Da iteriert man auch nix, da schaut man einfach per Ziel-Koordinate auf das jeweilige Tile, ob es begehbar ist oder nicht.

@BlueCobold:
Er verwendet den Tiled Map Editor. Die Map die dargestellt wird besteht aus einem oder meist mehreren 'Tile Layern'. Also Ebenen von sprites.
Darüber hinaus können - ein odere mehrere - 'Object Layer' definiert werden. Das kann alles mögliche sein. Rechtecke, Ovale, Polygone. Diesen Objekten können frei definierbare Werte zugewiesen werden (string, int, double, bool).
Diese "Tiled Map" wird als .tmx gespeichert, das eigentlich nichts anderes als ein XML-File ist mit all den Informationen über deine Layer.


@Topic:
Ich verwende für die Kollision einen eigenen objectlayer. Für mich lag der Vorteil darin, bei großen, nicht begehbaren Flächen (Waldrand, See, etc) ein großes Kollisionsobjekt das sich mitunter mit Eigenschaften füttern lässt ("verursacht Schaden" zum Beispiel).
Und was noch wichtiger ist, je nach Sichtbarkeit/Kamera würde ein als blockierend markiertes Tile ggf falsche Grenzen haben, so dass der Spieler zu weit davon entfernt stehen bleibt. Ist mir zB öfters passiert wenn eine Stange oder Pfahl irgendwo stand und der Spieler, aufgrund der Perspektive, optisch viel zu weit davon entfernt stehen bleibt. (Hat jemand verstanden was ich damit sagen will?)


Natürlich ist es mehr Aufwand die Kollisionsflächen separat in die Karte einzubauen als wenn du bei deinen Tiles schon definiert hast welche als "blockierend" zu erachten sind. Andererseits, ist man, finde ich, flexibler was die Grenzen angeht und man sieht im Editor sofort welche Bereiche blockiert sind.


Die Kollisionserkennung mit einem objectlayer ist denkbar einfach, aber das hast du ja eh geschafft.
Über den Tilelayer ist es etwas mühsam. Du musst vor der Bewegung des Spielers ermitteln auf welchem Tile er landen wird. Danach über die Tile-ID herusfinden ob dieses Tile begehbar ist, oder nicht.

In meiner Implementierung ist die Kollisionserkennung per objectlayer vielleicht 5 Zeilen Code.
Performanter ist wahrscheinlich dennoch der Weg über den Tile-Layer, weil nur für das Ziel-Tile die Kollision geprüft werden muss. Wenn du aber nicht 1000e Kollisionsobjekte prüfen musst, wird das wohl zu vernachlässigen sein.

Kommt ja drauf an was du machen willst. Wenn es eine tiled base game ist,flagst du ja die jeweilige Teile mit block = true oder falls.

Du kannst eine nav-mesh Implementierung nutzen um collisionsobjekte zu erstellen.

Richtig. In dem Beispiel sind auch 32x32 Kacheln in Verwendung (https://www.youtube.com/watch?v=04LPuVhctUY) Bei 0:22 wird der angesprochene Fall sichtbar. Wenn ich ich mich jetzt richtig erinnere, besteht diese Laterne aus 3 übereinander liegenden Tiles.
Ich hatte hier bei klassischer Tile-Kollision das Problem, dass die Spielfigur untypisch weit weg bzw. zu nah dran gekommen ist. Man könnte das natürlich mit einem offset lösen, aber das hat mir nicht gefallen.
Ebenso bei so "Übergangskacheln" wie man sie zB am Strand hat. (Meer<->Sand) da wollte ich, dass man doch zumindest bis zum Rand des Wassers kommt, was ja ungefähr in der Mitte der Kachel war.

Bei Top-Down Spielen oder jenen mit klaren Kanten (Bomberman zB) spielt das weniger eine Rolle, da ja dort die Perspektive fehlt und du den Spieler wirklich bis an den Rand der Kachel laufen lassen kannst. Hängt also auch ein wenig vom Anwendungsfall ab.

In meiner aktuellen Version sind die Kacheln 64x64, da kann es halt schon sein, dass das eigentliche Kollisionsobjekt kleiner ist, als die Kachel selbst, und das sieht dann einfach blöd aus.

An sich ist es eine Frage des Geschmacks. Da du Box2D verwendest wäre es schon sinnvoll Kollisionsflächen zu größeren Objekten zusammen zu fassen. Wie du das ganze in Tiled umsetzt bleibt dir überlassen. Versuch einfach mal ein paar Maps zu bauen und probier beide Varianten aus. Welche Vorhergehensweise sagt dir mehr zu? Genau die ist die richtige. Selbst bei Kacheln bei welchen der Collider nicht zu 100% deckend sein soll. Das kannst du ja im Code deines Spiels alles passend umsetzen. beim laden der Karte ist es jetzt aber an sich sinnvoll die einzelnen Kollisionsflächen zu wenigen kleinen Flächen zusammen zu fassen. Im Falle der Objektebene kannst du dir den Schritt sparen da du dort die Flächen zusammenfassend von Hand platzieren kannst.
Das ganze ist natürlich nichts was du unbedingt tun musst. Erspart aber einige Kollisionschecks.