Kollision mit Block (Wand)

[Jake2.0]

Hey Forenuser =),

Ersteinmal meine Bewunderung an dieser Stelle das ihr hier so nen cooles Forum habt.
Werd mich demnächst hoffentlich auch mal hier und da einbringen.

Also, ich bin zwar kein Neuling in Java,
allerdings fange ich nun grad mit der 2D-Programmierung an.

Bisher hab ich nach Quaxlis Tutorial nen Panel aufgebaut wo sich auch die Figur völlig frei drin bewegen kann.
Dann hab ich einen Block eingefügt in den die Figur nicht hineinfliegen können soll.
Allerdings hänge ich bei der Kollisionsabfrage.

Bisher hab ich mit .intersects geprüft ob sie kollidiert sind und dann anhand der Bewegungsrichtung der Figur wieder vor die Wand gesetzt. Wenn sich nun aber eine Figur schräg bewegt könnte das ja jeweils von 2 Seiten her sein.
Wenn ich nun noch die Koordinaten mit als Bedingung nehme komme ich aber an den Ecken des Blocks an Probleme,
da ich hier ja wieder nicht genau entscheiden kann.

Wie gestalte ich denn die Kollisionsabffrage am besten?

Viele Grüße
und thx im Vorraus

Jake

 

[Marco13]

Ohne 100% sicher zu sein, das richtig verstanden zu haben: Könnte es helfen, zu überprüfen, an welcher der Seiten die Kollision zuerst auftritt? Also quasi den Kollisionszeitpunkt in x- und y-richtung zu berechnen, und nur die Kollision zu behandeln, die früher auftritt?
(BTW Sehr ambitionierter Nickname :wink: )

 

[Jake2.0]

Ohne 100% sicher zu sein, das richtig verstanden zu haben: Könnte es helfen, zu überprüfen, an welcher der Seiten die Kollision zuerst auftritt? Also quasi den Kollisionszeitpunkt in x- und y-richtung zu berechnen, und nur die Kollision zu behandeln, die früher auftritt?

Naja, das ist ja aber genau das Problem. Wie erkenne ich denn die Seite auf der die Kollision auftritt. Ich weiß, das wenn er genau in der Mitte einer Seite liegt und auftritt. Aber das funktioniert ja nicht an den Eckstücken.
Wenn er genau im 45° Winkel auf die Ecke zusteuert ... Könnte es ja sein das er eig. von 2 Seiten kommt.

Und wie ich das an dieser Stelle lösen sollte weiß ich nicht.

Was meinst du außerdem mit Kollisionszeitpunkt?

(BTW Sehr ambitionierter Nickname :wink: )

Was meinsten damit?!

greetz

Jake

 

[EgonOlsen]

Naja, das ist ja aber genau das Problem. Wie erkenne ich denn die Seite auf der die Kollision auftritt. Ich weiß, das wenn er genau in der Mitte einer Seite liegt und auftritt. Aber das funktioniert ja nicht an den Eckstücken.
Wenn er genau im 45° Winkel auf die Ecke zusteuert ... Könnte es ja sein das er eig. von 2 Seiten kommt.

Und wie ich das an dieser Stelle lösen sollte weiß ich nicht.

Das Problem an dieser Stelle ist, dass du eine bestehende Kollision auflöst, indem du auf Überschneidung prüfst, nachdem die Kollision eingetreten ist. Du kannst hier nicht immer sicher entscheiden, welches der richtige, korrigierte Zustand wäre. Im extremen Fall kannst du so sogar Kollisionen "verlieren", wenn der Anfangszustand vor dem Hindernis und der Endzustand danach ist. Die Kollision dazwischen würdest du nie erkennen (ist aber vielleicht für deine Anwendung auch nicht nötig...). Ein anderer Ansatz ist, die Kollision gar nicht erst stattfinden zu lassen. Dazu brauchst du im Prinzip sowas: www.peroxide.dk/papers/collision/collision.pdf, nur halt in 2D, was die Sache deutlich einfacher machen sollte.

 

[Jake2.0]

Also ohne das Dokument jetzt hier gelesen zu haben,
du meinst ich müsste vorher erkennen wann die Kollision eintritt?
Also bevor sie überhaupt erst eingetreten ist?

Aber dazu bräuchte ich ja min. 2 Hilfsvariablen oder?!
Und zwar die, welche die vorherige Position der Figur speichern ... oder ?

hmmm ... hatte gedacht ich komme vlt auch ohne sowas aus ... Schade

Jake

 

[EgonOlsen]

Also ohne das Dokument jetzt hier gelesen zu haben,
du meinst ich müsste vorher erkennen wann die Diskussion eintritt?
Also bevor sie überhaupt erst eingetreten ist?

Kollision...nicht Diskussion,,, :wink: Ja, wenn du wissen willst, mit was als erstes kollidiert wurde und die Bewegungsrichtung dann anpassen willst, brauchst du irgendwie sowas. Du musst quasi das erste Hindernis in Bewegungsrichtung ermitteln und die Richtung dann entsprechend korrigieren. Bei deinem momentanen Ansatz geht das ja nicht. Je nach Aufbau deines Levels muss man aber vielleicht nicht gar so kompliziert treiben, um ein vernünftiges Ergebnis zu bekommen. Ist es wirklich tragisch in deinem Fall, wenn es an den Ecken evtl. nicht immer genau stimmt!?

 

[Jake2.0]

Ach du meine güte ... Diskussion statt Kollision :shock: :lol:

Also letzten Endes soll es um ein Bomberman - Klon gehen.
Der Levelaufbau ist da ja denke ich bekannt ...
Aber es wär halt blöd wenn es da nicht funktioniert.
Obwohl ich zurzeit eh noch überlege .. ob man da eigentlich überhaupt in x und y richtung gleichzeitig gehen kann ... oder nur in eine ... ?!

Wenn aber mit beiden würde mich das schon stören wenn das mit den Ecken nicht korrekt gelöst wäre ...

mfg

Jake

 

[EgonOlsen]

Also letzten Endes soll es um ein Bomberman - Klon gehen.
Der Levelaufbau ist da ja denke ich bekannt ...

In einem klassischen 2D-von-oben-Bomberman gibt es eigentlich kein Schräggehen. Die Bewegung ist üblicherweise tilebasiert, d.h. du bewegst dich immer von einem Leveltile zum nächsten und es gibt keine Zwischenschritte, du kannst also nicht zwischen den Tiles stehen(außer in der Bewegung und die muss erst abgeschlossen sein, bevor die nächste Eingabe greift). Deswegen sind die Kollisionbedingungen auch sehr einfach und du brauchst das eigentlich gar nicht so kompliziert....WENN du das so machen willst. Musst du natürlich nicht, du kannst die Bewegung auch frei gestalten. Das sieht dann so aus wie bei mir: jpct.de/robombs.game und das benutzt im Übrigen eine Variation des Ansatzes aus dem oben verlinkten PDF... :wink:

 

[Marco13]

Wo jetzt das Problem bei 2 Hilfsvariablen ist, weiß ich nicht. Jedenfalls klingt das, was du machen willst, nach einer rudimentären Form von kontinuierlicher Kollisionserkennung. Wenn man davon ausgeht, dass die Hindernisse sich nicht bewegen, ist das dramatisch viel einfacher, als wenn zwei sich bewegende Objekte auf Kollisionen geprüft werden sollen. So könntest du (ganz grob) sowas machen wie

Wiederhole
{
    Für alle Ecken E der Spielfigur F
    {
        Berechne das Liniensegment L, das duch die Bewegung der Ecke E im nächsten Schritt beschrieben ist 
            (d.h. der Anfang von L ist der Eckpunkt E, und das Ende von L ist der Eckpunkt E nach dem nächsten Bewegungsschritt)
    
        Für alle Kanten K aller Hindernisse
        {
            Berechne den Schnittpunkt S zwischen der Bewegunglinie L und der Kante K
            falls der Schnittpunkt S existiert
            {
                Bestimme den Zeitpunkt der Kollision 
                    (also die relative Position t des Schnittpunktes S auf der Bewegungslinie L -
                     ein Wert zwischen 0 und 1)
                Wenn der Zeitpunkt der früheste ist, der bisher gefunden wurde, merke dir alle relevanten Daten der Kollision (*zwinker*)
            }
        }
    }
    Behandle die früheste Kollision, die gefunden wurde *nochmal zwinker*
    
} solgange eine Kollision aufgetreten ist

Wie genau das Behandeln der Kollision aussehen soll, musst du dir dann überlegen. Also, ob der Spieler einfach stehenbleiben soll, oder ob er "abprallen" soll, oder ob er einen Drehimpuls bekommen können soll, wenn er mit einer Ecke irgendwo "hängenbleibt"....

 

[Jake2.0]

Vielen Dank
für die ganzen Anregungen =)

mfg Jake

 

[Marco13]

Ach ja: Der Nickname ist ambitioniert wegen http://www.bytonic.de/html/jake2.html :wink:

 

[Jake2.0]

^^
oh, cool =)
Eine 3D Engine in Java ist nach mir benannt x)
Den Name hab ich aber wegen etwas anderem gewählt.
Nur vielen Dank für den Hinweis

mfg
Jake