Was solls denn können bzw. für welchen Zweck?
Bei Kollisionsabfragen kommt immer schnell der Begriff "pixelgenau", was je nach Anwendungszweck unbrauchbar und unnötig kompliziert ist.
Ich hatte es in meinem 2D-Movement so gemacht:
- Kollisions zwischen Figuren und Dekorationsobjekten über Kreise zu Füßen der Charaktere, inspiriert von dem sehr einfachen Prinzip der "Hitbox" wie man sie als alten Spielen kennt. Abstand Zwischen Char1-XY und Char2XY < Char1Radius+Chars2Radius = Kollision. hab das Prinzip auch mal in einem Beispielprojekt gesehn in dem es drum ging wie man tausende Sprites (explosionen etc.) gleichzeitig haben kann ohne dass die Engine an der Kollisionsberechnung zugrunde geht.
- Kollision mit der Map über einen unsichtbaren Kollisionslayer, eine 2D Grafik in der Größe der Map mit geringer Farbauflösung wobei die einzelnen Farben für "unpassierbar" und die verschiedenen Bodentypen standen. In Java kann man problemlos in Grafiken hineinmalen, Plan war es auch, dass Objekte im Raum, die nicht auf den Mapgrafiken vorhanden sind sich ihre Kollisionsumrisse in die Kollisionsmap mit hineinmalen. Die 2D Grafik als Kollisionsinformation mag etwas sonderbar wirken, ist aber im Grunde auch nicht mehr als ein pixelgenaues Raster, dass sich sehr einfach im Grafikprogramm zusammen mit den Mapgrafiken erstellen lässt. Abfrage der Kollision "Kollisionslayer<->Charaktere" erfolgte über Punktprüfung entlang des Kreisrandes der Charaktere in Bewegungsrichtung, je nach Radius der Charakterkollisionskeises reichen mitunter 8 Prüfunkte, was je Bewegung zu 4 Koordidatenberechnungen führt.
War sicherlich nicht die technisch ultimativste Lösung, besonders letzteres war eher Zuarbeit für meine Art und Weise Grafiken zu basteln, sieh diesen Post also nicht als "so ist es toll,so solltest du auch" sondern eher als kleinen Denkanstoß im Für- und Wider der Entwicklung deiner Lösung.
Deine Lösung würde mich auch mal interessieren.
Zitieren
