Kollision eines 2D Jump'n'Run

Übersicht

Sonstiges

Smalltalk

	Kernle 32DLL Betreff: Kollision eines 2D Jump'n'Run	So, Jun 20, 2010 13:09 Antworten mit Zitat
Hiho, Mich habe vor kurzem mal wieder die Motivation ergriffen ein kleines 2D Jump'n'Run zu programmieren. Während mir die allgemeine Umsetzung keine Probleme bereitet, zerbreche ich mir genau wie vor X Jahren bei der Kollisionsabfrage den Kopf. Im Prinzip ist es ja ganz einfach: Ich bewege meinen Spieler um x Pixel, prüfe ob der Spieler mit dem Level kollidiert, und bewege ihn entsprechend zurück bis keine Kollision mehr statt findet (X und Y getrennt wohlgemerkt). Problem: Ein Tile hat nicht zwangsweise eine definierte Größe, und daher könnte es passieren das der Spieler Geschwindigkeiten drauf hat, mit denen er durch ein Tile "Durchrutscht" (Worstcase: 1x1 Pixel Tile). Irgendwo habe ich mal gehört das man dem Problem entgegen kommen kann indem man vom Spieler aus Vektoren zieht, und die Kollision zwischen denen und dem Level prüft. Problem: Was passiert wenn der Spieler eine nicht Rechteckige Form hat (Siehe unten). Dann müsste ich 2(Spielerhöhe+Spielerbreite) Maptiles Liniekollisionen pro Renderdurchgang machen. Ich kann schlecht einschätzen wie Performance Intensiv das ist. Und das letzte Problem: Schräge Flächen. Das ist was mir bisher am allermeisten Kopfzerbrechen bereitet hat. Mir fällt absolut kein Ansatz ein wie ich das Kollisionsverhalten für Schräge Flächen anpassen muss. Besonders wie der Spieler auf schrägen Flächen "stehen" soll. Ich hoffe mir kann jemand helfen, den dieser Kollisionskram quält mich schon seit Jahren. Wichtig ist auch das ich keine fertigen Codes haben will, sondern nur Ansätze, damit ich auch selber etwas daran lernen kann. So long, Kernle
Mein PC: "Bluelight" - Xtreme Gamer PC [Video] Meine Projekte: Cube-Wars 2010 [Worklog] Anerkennungen: 1. Platz BCC #7 , 1. Platz BCC #22 , 3. Platz BAC #89 Ich war dabei: NRW Treff III, IV ; Frankfurter BB Treffen 2009

Kernle 32DLL

Betreff: Kollision eines 2D Jump'n'Run

So, Jun 20, 2010 13:09
Antworten mit Zitat

Hiho,

Mich habe vor kurzem mal wieder die Motivation ergriffen ein kleines 2D Jump'n'Run zu programmieren. Während mir die allgemeine Umsetzung keine Probleme bereitet, zerbreche ich mir genau wie vor X Jahren bei der Kollisionsabfrage den Kopf.

Im Prinzip ist es ja ganz einfach: Ich bewege meinen Spieler um x Pixel, prüfe ob der Spieler mit dem Level kollidiert, und bewege ihn entsprechend zurück bis keine Kollision mehr statt findet (X und Y getrennt wohlgemerkt). Problem: Ein Tile hat nicht zwangsweise eine definierte Größe, und daher könnte es passieren das der Spieler Geschwindigkeiten drauf hat, mit denen er durch ein Tile "Durchrutscht" (Worstcase: 1x1 Pixel Tile).

Irgendwo habe ich mal gehört das man dem Problem entgegen kommen kann indem man vom Spieler aus Vektoren zieht, und die Kollision zwischen denen und dem Level prüft. Problem: Was passiert wenn der Spieler eine nicht Rechteckige Form hat (Siehe unten). Dann müsste ich 2*(Spielerhöhe+Spielerbreite) * Maptiles Liniekollisionen pro Renderdurchgang machen. Ich kann schlecht einschätzen wie Performance Intensiv das ist.

Und das letzte Problem: Schräge Flächen. Das ist was mir bisher am allermeisten Kopfzerbrechen bereitet hat. Mir fällt absolut kein Ansatz ein wie ich das Kollisionsverhalten für Schräge Flächen anpassen muss. Besonders wie der Spieler auf schrägen Flächen "stehen" soll.

Ich hoffe mir kann jemand helfen, den dieser Kollisionskram quält mich schon seit Jahren. Wichtig ist auch das ich keine fertigen Codes haben will, sondern nur Ansätze, damit ich auch selber etwas daran lernen kann.

So long,
Kernle

Mein PC: "Bluelight" - Xtreme Gamer PC [Video]
Meine Projekte: Cube-Wars 2010 [Worklog]
Anerkennungen: 1. Platz BCC #7 , 1. Platz BCC #22 , 3. Platz BAC #89
Ich war dabei: NRW Treff III, IV ; Frankfurter BB Treffen 2009

	Kruemelator	So, Jun 20, 2010 13:25 Antworten mit Zitat
Das Problem mit dem "Durchrutschen" kann man umgehen indem man die Bewegung in mehrere Schritte unterteilt. Das hat den Nachteil das man mehrmals auf Kollision prüfen muss. Was genau meinst du mit Kollisionsverhalten für schräge Flächen? Gruß Kruemelator

Kruemelator

So, Jun 20, 2010 13:25
Antworten mit Zitat

Das Problem mit dem "Durchrutschen" kann man umgehen indem man die Bewegung in mehrere Schritte unterteilt. Das hat den Nachteil das man mehrmals auf Kollision prüfen muss.

Was genau meinst du mit Kollisionsverhalten für schräge Flächen?

Gruß Kruemelator

	ZaP	So, Jun 20, 2010 15:00 Antworten mit Zitat
Sieh doch erst nach, wie weit der Spieler sich bewegen würde, und dann bewegst Du ihn. Wenn er sich zu weit bewegen würde, dann stellst Du ihn da hin, wo er kollidiert: BlitzBasic: [AUSKLAPPEN] [EINKLAPPEN] If SpielerSpeedX# + SpielerX# > AbstandZumTileX# Then SpielerX# = AbstandZumTileX# Else SpielerX# = SpielerX# + SpielerSpeedX# EndIf
Starfare: Worklog, Website (download)

ZaP

So, Jun 20, 2010 15:00
Antworten mit Zitat

Sieh doch erst nach, wie weit der Spieler sich bewegen würde, und dann bewegst Du ihn. Wenn er sich zu weit bewegen würde, dann stellst Du ihn da hin, wo er kollidiert:

BlitzBasic: [AUSKLAPPEN]


If SpielerSpeedX# + SpielerX# > AbstandZumTileX# Then
 SpielerX# = AbstandZumTileX#
Else
 SpielerX# = SpielerX# + SpielerSpeedX#
EndIf

Starfare: Worklog, Website (download)

	Kernle 32DLL	Di, Jun 22, 2010 12:44 Antworten mit Zitat
Kruemelator hat Folgendes geschrieben: Das Problem mit dem "Durchrutschen" kann man umgehen indem man die Bewegung in mehrere Schritte unterteilt. Das hat den Nachteil das man mehrmals auf Kollision prüfen muss.[...] Was aber bei hohen Geschwindigkeiten sehr Performance Aufwendig wird, also nicht ganz optimal. Zap hat Folgendes geschrieben: Sieh doch erst nach, wie weit der Spieler sich bewegen würde, und dann bewegst Du ihn. Wenn er sich zu weit bewegen würde, dann stellst Du ihn da hin, wo er kollidiert: Das Problem ist eben diesen Weg bis zur Kollision rauszufinden. Kruemelator hat Folgendes geschrieben: Was genau meinst du mit Kollisionsverhalten für schräge Flächen? Auf "Geraden" Flächen definiert man zumeist den ganzen Boden der Spielergrafik als Kollisionsfläche. Bei Schrägen ist es zumeist nur das "Mittigste" Pixel des Grafikbodens.
Mein PC: "Bluelight" - Xtreme Gamer PC [Video] Meine Projekte: Cube-Wars 2010 [Worklog] Anerkennungen: 1. Platz BCC #7 , 1. Platz BCC #22 , 3. Platz BAC #89 Ich war dabei: NRW Treff III, IV ; Frankfurter BB Treffen 2009

Kernle 32DLL

Di, Jun 22, 2010 12:44
Antworten mit Zitat

Kruemelator hat Folgendes geschrieben:

Das Problem mit dem "Durchrutschen" kann man umgehen indem man die Bewegung in mehrere Schritte unterteilt. Das hat den Nachteil das man mehrmals auf Kollision prüfen muss.[...]

Was aber bei hohen Geschwindigkeiten sehr Performance Aufwendig wird, also nicht ganz optimal.

Zap hat Folgendes geschrieben:

Sieh doch erst nach, wie weit der Spieler sich bewegen würde, und dann bewegst Du ihn. Wenn er sich zu weit bewegen würde, dann stellst Du ihn da hin, wo er kollidiert:

Das Problem ist eben diesen Weg bis zur Kollision rauszufinden.

Kruemelator hat Folgendes geschrieben:

Was genau meinst du mit Kollisionsverhalten für schräge Flächen?

Auf "Geraden" Flächen definiert man zumeist den ganzen Boden der Spielergrafik als Kollisionsfläche. Bei Schrägen ist es zumeist nur das "Mittigste" Pixel des Grafikbodens.

	ZaP	Di, Jun 22, 2010 13:35 Antworten mit Zitat
Ich denke, Du wirst nicht um eine Vektormap herumkommen, also eine Art Kollisionslayer, der nicht sichtbar ist, und nachträglich für das Level erstellt wird. Du kannst natürlich auch einfach jedes Tile voll ausfüllen, also keine schrägen Tiles machen, und dann Tile-based collision nehmen, dann musst Du nur das Leveldesign entsprechend anpassen. Und dann gibt es noch die Möglichkeit die Blitz3D Kollisionsroutinen zu nehmen, da gab's mal einen Thread dazu, suchen musst Du allerdings selber (Ist im Grunde das, was ich mit Methode #1 meinte, aber nimmt dir viel (Mathe-) Arbeit ab)
Starfare: Worklog, Website (download)

ZaP

Di, Jun 22, 2010 13:35
Antworten mit Zitat

Ich denke, Du wirst nicht um eine Vektormap herumkommen, also eine Art Kollisionslayer, der nicht sichtbar ist, und nachträglich für das Level erstellt wird.
Du kannst natürlich auch einfach jedes Tile voll ausfüllen, also keine schrägen Tiles machen, und dann Tile-based collision nehmen, dann musst Du nur das Leveldesign entsprechend anpassen.
Und dann gibt es noch die Möglichkeit die Blitz3D Kollisionsroutinen zu nehmen, da gab's mal einen Thread dazu, suchen musst Du allerdings selber Wink

(Ist im Grunde das, was ich mit Methode #1 meinte, aber nimmt dir viel (Mathe-) Arbeit ab)

Starfare: Worklog, Website (download)

	Pitje Puck	Mi, Jun 23, 2010 9:27 Antworten mit Zitat
Ich hatte mich auch mal dran gesetzt. Bei http://www.tonypa.pri.ee/tbw/ findest du ein umfangreiches Tutorial, das sich mit den gleichen Problemen beschäftigt. Ist zwar alles Flash Actionscript, lässt sich aber gedanklich übertragen.

Pitje Puck

Mi, Jun 23, 2010 9:27
Antworten mit Zitat

Ich hatte mich auch mal dran gesetzt. Bei http://www.tonypa.pri.ee/tbw/ findest du ein umfangreiches Tutorial, das sich mit den gleichen Problemen beschäftigt. Ist zwar alles Flash Actionscript, lässt sich aber gedanklich übertragen.

	Noobody	Mi, Jun 23, 2010 12:36 Antworten mit Zitat
Wenn du Blitz3D benutzt, hilft dir vielleicht das hier weiter.
Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. -- Wernher von Braun

Noobody

Mi, Jun 23, 2010 12:36
Antworten mit Zitat

Wenn du Blitz3D benutzt, hilft dir vielleicht das hier weiter.

Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. -- Wernher von Braun

	Kernle 32DLL	Mo, Jun 28, 2010 21:50 Antworten mit Zitat
@Noobody Das geht leider nicht, da es mir um eine allgemeine Umsetzung geht, bei der ich nicht auf B3D zurückgreifen kann. Bei deinem Post ist mir aufgefallen das ich ins völlig falsche Forum gepostet habe, denn ich suche wie gesagt eine allgemeine Lösung, und keine Blitz spezifische. Die Idee mit Blitz3D's Kollisionsabfrage ist allerdings sehr gut, das muss ich mir für spätere Projekte mal merken. @Pitje Puck Im Prinzip ist das schon fast was ich suche, nur das ich eine "ultimative" (oh wie überheblich das klingt) Lösung für Schräge fläche (sog. slopes) suche, ich also nicht nur 45° slopes machen kann, sondern auch andere. Sprich, das ich sowas hier KANN: Zum Thema Kollision habe ich mir nun endlich auch schon ein paar Sinnvolle Gedanken gemacht. Ich bin auf die Idee gekommen das ich von jedem 2D Objekt eine Schwarz/Weiß Kollisions Map erstelle (siehe Bild unten), bzw. generiere. Kollision prüfe ich dann an den Überlappenden Flächen von 2 übereinander liegenden Grafiken, und eine Kollision findet dann halt statt wenn 2 Weiße Pixel übereinander liegen. Ein paar Bilder dazu: Spieler Spieler Kollisionsmap Das die Kollisionsmap des Spielers unten so spitz zuläuft hat durchaus einen Sinn. Ich erhoffe mir damit durch eine geeignete Kollisionsprüfung Slopes durch "normale" Kollisionen darstellen zu können, und nicht wie in allen Tutorials die ich bisher gelesen habe durch eine eigene Kollisionsroutine (was wiederrum Slopes wie auf dem Bild oben verhindert). Zudem wäre mit dem Spitzen Zulauf eine natürliche Barriere für zu steiel Slopes gelegt - zumindest theoretisch. Was haltet ihr davon? So long, Kernle PS: So slopes wie ich sie anstrebe sieht man hier am Anfang sehr gut. Es geht sich nur um 00:18 bis ca. 00:25
Mein PC: "Bluelight" - Xtreme Gamer PC [Video] Meine Projekte: Cube-Wars 2010 [Worklog] Anerkennungen: 1. Platz BCC #7 , 1. Platz BCC #22 , 3. Platz BAC #89 Ich war dabei: NRW Treff III, IV ; Frankfurter BB Treffen 2009

Kernle 32DLL

Mo, Jun 28, 2010 21:50
Antworten mit Zitat

@Noobody
Das geht leider nicht, da es mir um eine allgemeine Umsetzung geht, bei der ich nicht auf B3D zurückgreifen kann. Bei deinem Post ist mir aufgefallen das ich ins völlig falsche Forum gepostet habe, denn ich suche wie gesagt eine allgemeine Lösung, und keine Blitz spezifische. Die Idee mit Blitz3D's Kollisionsabfrage ist allerdings sehr gut, das muss ich mir für spätere Projekte mal merken.

@Pitje Puck
Im Prinzip ist das schon fast was ich suche, nur das ich eine "ultimative" (oh wie überheblich das klingt) Lösung für Schräge fläche (sog. slopes) suche, ich also nicht nur 45° slopes machen kann, sondern auch andere. Sprich, das ich sowas hier KANN:

user posted image

Zum Thema Kollision habe ich mir nun endlich auch schon ein paar Sinnvolle Gedanken gemacht. Ich bin auf die Idee gekommen das ich von jedem 2D Objekt eine Schwarz/Weiß Kollisions Map erstelle (siehe Bild unten), bzw. generiere. Kollision prüfe ich dann an den Überlappenden Flächen von 2 übereinander liegenden Grafiken, und eine Kollision findet dann halt statt wenn 2 Weiße Pixel übereinander liegen.

Ein paar Bilder dazu:

user posted image

Spieler

Spieler Kollisionsmap

Das die Kollisionsmap des Spielers unten so spitz zuläuft hat durchaus einen Sinn. Ich erhoffe mir damit durch eine geeignete Kollisionsprüfung Slopes durch "normale" Kollisionen darstellen zu können, und nicht wie in allen Tutorials die ich bisher gelesen habe durch eine eigene Kollisionsroutine (was wiederrum Slopes wie auf dem Bild oben verhindert). Zudem wäre mit dem Spitzen Zulauf eine natürliche Barriere für zu steiel Slopes gelegt - zumindest theoretisch.

Was haltet ihr davon?

So long,
Kernle

PS: So slopes wie ich sie anstrebe sieht man hier am Anfang sehr gut. Es geht sich nur um 00:18 bis ca. 00:25

	BladeRunner Moderator	Mo, Jun 28, 2010 21:58 Antworten mit Zitat
~Verschoben~
Zu Diensten, Bürger. Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3 Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64 B3D BMax MaxGUI Stolzer Gewinner des BAC#48, #52 & #92

BladeRunner

Moderator

Mo, Jun 28, 2010 21:58
Antworten mit Zitat

~Verschoben~

Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3
Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64
B3D BMax MaxGUI
Stolzer Gewinner des BAC#48, #52 & #92

Übersicht

Sonstiges

Smalltalk

Nach Oben

BlitzBasic Portal

Kollision eines 2D Jump'n'Run

Betreff: Kollision eines 2D Jump'n'Run