[BB] Jump'n'Run (Kollision/Sprünge)

[Kernle 32DLL]

Hiho
lang lang ist's her das ich das letzte mal hier war

Nundenn...
Mein Problem ist, das ich seit etwa nem Monat für ein Team-Projekt eine Jump'n'Run Engine in Blitz3D (BlitzBasic) schreibe. Soweit funktioniert die auch schon ganz gut, aber mein größtes Problem ist derzeit die Sprungroutine. Sie sieht nicht gut aus, und sorgt für diverse Grafikfehler .

[Engine V.8_b]

Ich setze eine bestimmte Sprunghöhe (z.b. 64), und messe dann den Abstand des Spielers zur festgelegten Sprunghöhe. Bei Deckenkollision,etc. wird dieser Vorgang unterbrochen.

Der Spieler hat 4 kollisionsflächen. Oben, Rechts, Unten, Links. (In der oben verlinkten Engine werden die Kollisionsflächen für Oben und Unten üprigens nicht richtig dargestellt). Ich bewege den Spieler, prüfe ob er mit einem Objekt kollidiert (bzw. in ihm steckt), und bewege ihn ggf. in die andere Richtung wieder vom Objekt weg/raus.



Ich merke das ich es nicht richtig erklärt bekomme, also versuche ich mein Problem auf den Punkt zu bringen:

Der Spieler kann mithilfer einer gewissen Geschwindigkeit durch Objekte "durchspringen" (oder laufen). das Problem ist, das ich nicht garantieren kann, das jedes Tile 32x32 groß ist. Und wenn die Geschwindigkeit nun so groß ist, das der eigentliche Kollisionspunkt schon durch das Objekt durch ist, der Rest des Spielers aber noch im Objekt ist, hab ich den Salat (dann spring nämlich meistens die kollisionsfläche für die Seiten an und schmeißt den Spieler aus der Map).

Den Spieler Pixel für Pixel zu bewegen ist auch keine Lösung, da dann die Geschwindigkeit in den Keller sinkt.

Hat einer eine Idee wie ich das vernünftig geregelt bekomme ? Oder ist der ganze Ansatz einfach nur murks ?

Grüßle:
Kernle

[Ynnus]

Also die eigentliche Grafik als Kollisionsmaske zu nehmen ist immer dann problematisch, wenn es um schnelle Geschwindigkeiten geht, bei denen das Objekt pro Frame auch mal > 10 Pixel bewegt werden kann, und ein Kollisionsobjekt aber eventuell auch mal kleiner 10 Pixel ist. Deshalb würde ich von so einer Kollisionsmethode abraten, wenn du es mit hohen Geschwindigkeiten zu tun hast.
Ich würde zwar sowieso die Spielfigur etwas langsamer machen, denn hier auf meinem PC ist es extrem schnell. Weiß nicht obs am fehlenden Frame-Limiter liegt oder daran, dass es so schnell sein soll. Jedenfalls rast der Typ unnatürlich schnell.

Zurück zum Problem: Ich würde dir raten, für den Spieler und jedes Levelobjekt eine Maske per Zahlenwerte festzulegen. Also obere Grenze, untere Grenze, linke grenze und rechte Grenze. Dann bekommt die Spielfigur auch grenzwerte. Das sieht dann etwa so aus: Grenze links = Spielfigur_position_x - 20 Pixel. Grenze Rechts = Spielfigur_position_x + 20 Pixel. (etc)
Wenn jetzt diese Grenzen-Position eine Grenzpositon eines Levelobejekts überschreitet bzw sich innerhalb befindet, wird die Position auf den Rand außerhalb zurückgesetzt. Erst danach wird die Spielfigur an dieser Stelle dargestellt. Das sorgt dafür, dass der Spieler optisch nie innerhalb von Objekten erscheint, weil erst die Kollisionsprüfung erfolgt, danach das Darstellen am Monitor.
Das heißt, du machst dann keine Kollision anhand der eigentlichen Grafik sondern legst für jedes Objekt mittels ein paar Variablen einen Grenzbereich an, indem sich der Spieler nicht befinden darf. Wenn du dann die Leertaste zum Sprung drückst, wird bereits vor dem Darstellen des Sprungs dann mit diesen Koordinaten die Sprungbahn des Typs berechnet und bei Kollision wird er zurückgesetzt und dann dargestellt.
Dadurch, dass man mit diesen Kollisionsboxen rechnen kann, ist diese Methode viel schneller als Pixelweise Bewegung der Spielfigur, da sie nur auf Variablenrechnungen basiert.
z.B. wenn Spieler_x > objekt1_Linker_Rand und Spieler_X < objekt1_rechter rand und spieler_y > objekt1_oberer_rand und spieler_y < objekt1_unterer Rand -> Dann findet kollision statt - und der Spieler muss wieder auserhalb des Objekts dargestellt werden. Dazu muss man die zuletzt getätigte Bewegung (bzw deren Errechnete Positionsänderung) nur rückwärts zurücklaufen bis die Kollision nicht mehr stattfindet.

[Kernle 32DLL]

Ah, danke

Das war genau worauf ich gehofft hatte Ich glaube ich habe jetzt den Gedankenanstoß den ich gebracuth habe

Danke ^^

Grüßle:
Kernle

PS: Ja, es fehlt noch ein Framelimiter Einzig im "Speedmode" (F3) ist er mehr der weniger kontrollierbar xD

[DFYX]

Die Ideallösung besteht wohl darin, beide Methoden zu kombinieren. Erst wird grob mit einer Bounding Box gerechnet und erst, wenn da eine Kollision stattfindet, wird pixelweise geprüft.

[nudelsalat]

Um das durchspringen bei hoher Geschwindigkeit zu verhindern könnte man auch per Ray Tracing auf kollisionen prüfen. Stellt sich nur die Frage, ob das bei einem simplen 2D Spiel wirklich sinnvoll ist.

[drunken monkey]

Um das durchspringen bei hoher Geschwindigkeit zu verhindern könnte man auch per Ray Tracing auf kollisionen prüfen. Stellt sich nur die Frage, ob das bei einem simplen 2D Spiel wirklich sinnvoll ist.

...

Ts, das ist jetzt wohl deine Lösung für alles!
Aber wenn ich das richtig verstanden habe, soll man ja mit hohen Geschwindigkeiten durch Objekte "tunneln" können:

Der Spieler kann mithilfer einer gewissen Geschwindigkeit durch Objekte "durchspringen" (oder laufen).

...

Ist nicht als Problem beschrieben.

[Ynnus]

Ts, das ist jetzt wohl deine Lösung für alles!
Aber wenn ich das richtig verstanden habe, soll man ja mit hohen Geschwindigkeiten durch Objekte "tunneln" können:

Ist nicht als Problem beschrieben.

...

Das ist als IST-Zustand beschrieben, der aber nicht gewünscht ist. Soll heißen, das IST das Problem an der Sache.

[nudelsalat]

Ts, das ist jetzt wohl deine Lösung für alles!

...

Ja, Ray Tracing ist das Antibiotikum der Informatik.

[drunken monkey]

Das ist als IST-Zustand beschrieben, der aber nicht gewünscht ist. Soll heißen, das IST das Problem an der Sache.

...

Ahja, jetzt wo du's sagst, könntest recht haben. ^^'

Ja, Ray Tracing ist das Antibiotikum der Informatik.

...

Du solltest ganz dringend studieren, das ist "Divide and Conquer"!
Raytracing ist in der Metapher am ehesten eine Laser-Augen-OP: wird von vielen, die's nie selbst wählen würden, als der neueste Hit gepriesen und verschlimmert das Ganze viel zu oft noch.
Warum eine Laser-OP, wenn's eine Kollisionsboxen-Brille genauso tut, und zwar weniger fehleranfällig und ökonomischer?