Kollisionserkennung in Pong
-
Hallo zusammen. Bevor der erste Google oder Suchfunktion schreit, kann ich euch versichern, dass ich mich bereits umfangreich mit diesem Thema vertraut gemacht habe und auch unzählige Forum - Einträge und Internet - Seiten dazu gelesen habe. Ausserdem habe ich mehrere Source - Codes studiert doch mir fällt dabei eine schir beängstigende Gemeinsamkeit auf. Die jeweiligen Kollisionserkennung sind in allen Fällen sehr fehleranfällig, unzuverlässig und setzen voraus, das der Zielrechner eine hohe Framerate erzielen kann:
Bsp. 1 Der Ball kann durch das Pad oder einen Block hindurchfliegen, ohne dass eine Kollision festgestellt wurde:
Der Ball befindet sich 2 Pixel oberhalb des Pads und fliegt senkrecht nach unten.
Keine Kollision. Im nächsten Frame bewegt sich der Ball um 5 Pixel senkrecht nach unten. Das Pad ist 2 Pixel breit. Wieder keine Kollision. Der Ball ist hindurchgeflogen.Bsp. 2 Der Ball kann sich im Pad oder in einem Block verfangen:
Der Ball ist wieder 2 Pixel oberhalb des Pads und fliegt senkrecht nach unten.
Keine Kollision. Im nächsten Frame bewegt sich der Ball 3 Pixel senkrecht nacht unten. Das Pad ist 2 Pixel breit. Das Programm stellt eine Kollision fest und inversiert die Y - Achse des Bewegungsvektors des Balls. Im nächsten Frame bewegt sich der Ball nur noch um 1 Pixel nach oben, da sich die Framerate geringfügig verändert hat. Wieder eine Kollision, obwohl der Ball noch immer im Pad ist, usw. Der Ball bleibt im Pad hängen.Das wahren jetzt nur zwei Beispiele. Doch ich könnte hier noch unzählige Fallbeispiele von Fehlern und dessen Uhrsachnen in existierenden Pong - Spielen berichten.
Für eine saubere Kollisionserkennung kommt man nicht umhin, jede einzelne Seite eines Blockes auf eine Kollision zu prüfen. Den Bewegungsvektor gegebenfalls verändern, um den Ball schön an eine Seite eines Blockes zu führen, anstatt ihn 2 - 3 Pixel hineinfliegen zu lassen. usw.
Hierzu wiederum kommt man nicht umhin eine Kollisionserkennung auf der Basis einer Geradengleichung zu programmieren. Eine Funktionsgleichung ala
f(x) y = m*x+b kann allerdings nicht verwendet werden, da der Ball ja auch genau senkrecht fliegen kann und dann m = [unendlich] währe.Was meint ihr dazu? Diese Frage richtet sich besonders an TGGC, da er bereits ein Pong geschrieben hat, wo die Kollisionsabfrage gut zu funktionieren scheint.
Gruss Ishildur
-
Ist doch heutzutage gar kein Problem in JEDEM Frame ein paar kleine Berechnungen zu haben...
-
Wenn der Ball genau vertikal flöge, wäre es ja nich so ein tolles Pong-Spiel.
Dieser Fall dürfte nach meinen Pong Kenntnissen gar nicht auftreten.
-
machs doch einfach mit vektorrechnung..
-
sieh dir mal einen Algorithmus zur feststellung einer Line - Rectangle - Intersection (is zB in ClanLib implementiert glaub ich) an. Das mit dem verfangen lässt sich einfach lösen, indem man feststellt mit welchem Pad der Ball kollidiert.
Ich hab sowas vor kurzem auch geschrieben. Allerdings auch eher Hack als schön.
-
Meine Lösung ist sicher nicht die beste. Erstmal konnte ich von konstanter Framerate ausgehen, da ich VSYNC hatte.
Die Pads und Wände sind noch simpel, überschreitet der Ball eine bestimmte Höhe und ist gleichzeitig im passenden x Bereich (bzw. Wände halt immer), wird er nach oben geschossen (egal von voher er kommt, daher kann man beim DoublePad von unten durchschiessen).
Für die Steine wird alles in ein Tileraster aufgeteilt. Der Ball ist punktförmig, befindet sich in genau einen Feld. Vor der Bewegung wird nun geschaut, ob er das Feld verlassen würde, und in welche Richtung(en). Dann werden zunächst die vier Nachbarfelder getestet. Also bewege ich mich nach oben aus dem Feld, ist oben frei? Wenn nicht Stein löschen und reflektieren. Hab ich zwei Richtungen z.b. links und oben und habe weder links noch oben einen Stein, dann schaue ich schräg, wenn dort was ist löschen und beide Achsen reflektieren. Wird überhaupt nichts reflektiert, wird dann die Bewegung ausgeführt, sonst einfach auf der Stelle bleiben.
Bye, TGGC (Keine Macht den Dummen)
-
-
Ishildur redet von Breakout bzw. Arkanoid, und nicht Pong.
Bye, TGGC (Keine Macht den Dummen)
