2D - JnR Techniken

Hallo ich wollte mal spasseshalber ein Mario-ähnliches Spiel schreiben und hab einige Probleme mit folgenden Sachen:

1.Kollisionserkennung

Ich verwende bisher ganz einfache Bounding-Boxes und bekomme damit heraus ob 2 Dinge kollidieren. Was aber auch wchtig wäre: von welcher Richtung kollidieren Dinge. Zum Beipiel wäre es wichtig zu erhren ob die Figur auf einen Gegner gesprungen ist oder hineingerannt.

Ausserdem noch dazu: Wie wird in echten SPielen überprüft, ob sich die Figur auf einer Plattform befindet?
Wird das auch über Kollision gesteuert oder irgendwie anders.

2. Springen

In vielen Spielen wird zwischen einem großen und kleinen Sprung unterschieden.
Je nachdem wie lange der Springenbutton gedrückt wurde.
Leider weiß ich nicht wie ich das praktisch umsetze
(Ich hab bisher Zustände der Figur wie Jumping oder Falling)

3. Generelles Design

Es gibt hier eine Bild-Klasse die ich verenden könnte.
In einigeb Spielen habe ich Code wie folgenden gesehen:

class Player extends Image
...

Das ist genaz nett, wenn man dann Dinge wie Player.move() schreiben kann, dennoch frage ich mich ob nicht eher Kapselung angebracht wäre a la

class Player 
    Image sprite
...

Nexus

shisha schrieb:

Ich verwende bisher ganz einfache Bounding-Boxes und bekomme damit heraus ob 2 Dinge kollidieren. Was aber auch wchtig wäre: von welcher Richtung kollidieren Dinge. Zum Beipiel wäre es wichtig zu erhren ob die Figur auf einen Gegner gesprungen ist oder hineingerannt.

Geschwindigkeitsvektoren der Objekte betrachten.

shisha schrieb:

In vielen Spielen wird zwischen einem großen und kleinen Sprung unterschieden.
Je nachdem wie lange der Springenbutton gedrückt wurde.
Leider weiß ich nicht wie ich das praktisch umsetze
(Ich hab bisher Zustände der Figur wie Jumping oder Falling)

Du musst mehr als 2 Zustände haben. Die Y-Geschwindigkeit ist (idealisiert) kontinuierlich.

Beim Loslassen der Taste bremst du den Sprung eben schneller ab (d.h. Y steigt schneller an, ist ja nach unten gerichtet). Da musst du wahrscheinlich etwas herumexperimentieren, bis du das gewünschte Ergebnis hast.

shisha schrieb:

dennoch frage ich mich ob nicht eher Kapselung angebracht wäre

Ja, Komposition ist das Richtige. Ein Spieler hat ein Bild, ist aber keins. Leider achten meiner Erfahrung nach viele Spieleprogrammierer nicht besonders aufs Design, zumindest hobby-mässige. Sich an solchem Code zu orientieren halte ich daher für sehr schlecht.

Du könntest sogar noch einen Schritt weiter gehen und Grafik von der Logik trennen. Also dass die Player -Klasse nur spiellogische Dinge wie Position, Geschwindigkeit, Leben, Waffen etc. speichert und die Grafik in einer anderen Klasse stattfindet. Das macht es dann leichter, Grafikroutinen auszuwechseln und rendering-spezifische Dinge an einem Ort zu regeln.

Zum Thema Geschwindigkeitsvektoren:

Was ist damit genau gemeint?
Wenn ich allein die Richtung betrachte, habe ich ja nicht alles abgedeckt. zB Könnte ein fallender Mario dennoch seitlich von einer Kanone erwischt werden.

Aber es steht ja Geschwindigkeitsvektor und nicht Richtungsvektor da. Nur leider kann ich mir darunter grad nichts brauchbares vorstellen

Nexus

Der Geschwindigkeitsvektor ist der Richtungsvektor der Geschwindigkeit. Ob nun der Geschwindigkeitsvektor bereits eine gegebene Länge hat (z.B. bei konstanter Framerate), oder ob er wirklich nur ein Richtungsvektor ist und jeweils mit der Geschwindigkeit skaliert wird, spielt eigentlich gar keine Rolle.

Normalerweise hat deine Figur 2 Vektoren: Position und Geschwindigkeit (= Positionsänderung pro Zeit), eventuell noch eine Beschleunigung. Für gegnerische Figuren und Kanonenschüsse gilt das auch. Mit all diesen Informationen kannst du herausfinden, ob Mario von der Seite angeschossen wurde. Je nachdem reichen auch schon die Positionen.