anfängerfrage: kollision mit objekten<-->spielweltbegrenzungen
-
Hallo
Ich arbeite zurzeit an einem einfachen 2D Jump 'n Run. Das Level ist so aufgebaut, dass der hintergrund mit den Oberflächen auf denen man läuft, in 50*50pixel grossen Tiles aufgeteilt ist. Die Anordnung dieser Tiles ist in einem 2-dimensionalen Array gespeichert. Bei Objekten (wie Bäume, Gegner...) werde ich die Kollisionserkennung per bounding-boxen machen, aber wie erreiche ich, dass die Spielfigur immer auf den Wegen läuft und nicht einfach durch sie durchfällt? Ich kann ja schlecht mit jedem einzelnen Tile eine kollisionsabfrage machen, zudem ja der weg nicht immer genau an der oberen Seite des Tiles ist. Ich hoffe, ich konnte meine Frage etwas verständlich formulieren und danke schon jetzt für Antworten.
cu
-
speicher dir ein weiteres 2d-(Bit)-array in dem du true setzt wenn man durchlaufen kann und false wenn man es nicht kann.
dann müßtest du bei der bewegung der spielfigur, sie in das 2d array abbilden und prüfen ob sie sich an der neuen position irgendwo in einem "false-bereich" befindet. dann würdest du sie nicht dahin bewegen. (falls der bereich unter der figur ist, dann müßtest du sie soviel hochbewegen, dass sie drauf steht).
wenn du es dir vielleicht einfacher machen möchtest, kannst du die kollision in dein vorhandenes 2d-array einmaskieren
rapso->greets();
-
danke, so werd ichs machen. aber wie ist es denn, wenn ein wegstück auf einem tile schräg nach oben geht? dann würde die spielfigur ja über dem weg laufen.
-
(Sorry ich hab erst nicht gesehen, dass es sich um ein Jump&Run handelt. Aber was meinst du mit schräg nach oben?)
-
dann mußt du vielleicht anstatt eines bitarray ein (2d-)bytearray haben, indem du dann für collision 1 und für leer 0 hast, dazu kannst du dann noch bits maskieren die sonderfälle behandeln z.B. |=2; für schräg abfallend und |=4; für schräg steigend.
ist dann sicherlich ein wenig aufwand das zu implementieren, aber komplex sollte das net sein
rapso->greets();
ps. @optimiser, die 0.16 läuft cool, das bauen find ich auch gut, aber irgendwie klappt das abbauen nichtmehr
-
Möglich wäre es auch die Bitmaske für die Kollision feiner aufzulösen, oder den Umriss der Umgebung durch einen Polygonzug darzustellen. Aber die üblichste Methode ist tatsächlich, das ein Tile komplett leer oder voll ist und man sie dann auch grafisch so gestaltet. Falls du also nicht soviel Ahnung haben solltest, dann belass es einfach erstmal dabei, später kann man das ja immer noch verbessern.
-
ok, dann lass ich das mal mit den schrägen stücken. besten dank für die tipps.
@Optimizer: mit schräg nach oben meinte ich sowas wie ein berghang oder so.
-
@rapso: lass mich raten, die stehen alle vor der Oase und gehen nicht rein?
ka, warum ich solche Fehler immer erst nach dem release feststelle
-
Wie haben die das denn zb bei Worms oder Clonk gemacht? da kann man ja auch die Umgebung verändern so das es nicht wie in normalen J&R's wo di Umgebung eckig ist. Ich kann mir auch nicht vorstellen das die ein so ein großes 2D Array machen das die wirklich jeden einzelnen Bildpunkt abgespeichert haben.
Hier war doch vor kurzen einer der hatte ein Ballerburg Clon gemacht. Da konnte man auch die Landschaft wegschießen und die Kugeln sind immer richtig aufgeschlagen. Vieleicht könnte man das dann ja auch für eine Spielfigur anwenden?
-
Ich glaub anders als mit einem Array geht es nicht. Selbst wenn du die Landschaft als "Schwarz-Weiß-Bild" speicherst, ist es immer noch das selbe - nur langsamer. Soooo wahnsinnig viel Speicher braucht jetzt eine Karte auch wieder nicht.
Nimm mal bei einem Jump&Run ne Karte die wenig hoch und dafür sehr breit ist, sagen wir mal 5000x500 "Pixel" dann sind das 2500000 bool-Werte.
Ein bool ist bei mir 1 Byte groß (seltsamerweise?), das heißt du brauchst gerade 2,5MB RAM für die Karte.
-
Man kann es natürlich auch hierachisch machen, wäre zumindest die Methode, die ich benutzen würde, wenn ich sowas machen müsste. Erstmal würde ich alles in Quadrate einteilen, mit z.b. 64² Pixel. Ist dieses komplett leer oder voll, speichere ich das. Ansonsten sind vier Zeiger auf "Unterquadrate" gespeichert, diese sind dann jeweils 32² Pixel gross. Dann gilt wieder für jedes Quadrat dasselbe, entweder leer, voll oder 4 Unterquadrate. So kann ich jeden Pixel genau abfragen, trotzdem ist der Speicher begrenzt, weil ja die meisten Gebiete stark zusammenhängend sind.
P.S.: 5000 x 500 ist nicht grad viel, das sind nichtmal 5 Bildschirme bei 1024x500 (angenommen der Rest ist ein HUD).
-
clonk levels waren aber meistens nie größer als 5-6 bildschirme (640x480).
-
wenn es wirklich nur schräge stücke sind, ist es am einfachsten alles über eine logik auszurechnen anstatt boxen mit dreiecken zur häflte zur füllen und als bitmap abzuspeichern.
ich wüste net wozu die speicherverschwendung in diesem speziellem fall gut sein soll.rapso->greets();
-
rapso schrieb:
wenn es wirklich nur schräge stücke sind
Dann kann man sich theoretisch auch Kollisionstiles basteln, die dann zu einer Maske zusammengesetzt werden. Ich frage mich nur immer wieder (nicht nur in diesem Thread), was eine pixelgenaue Abfrage überhaupt bringen soll.
-
und ich frage mich immer wieder wie ich den rand mit dem der spieler kollidiert herausfinde...
