Genau wie ich es mir vorgenommen habe, habe ich jetzt die Kollisionserkennung zwischen Rechtecken mit abgerundeten Ecken realisiert:



Alle sichtbaren Rechtecke mit abgerundeten Ecken werden übrigens live gezeichnet - aus insgesamt 18 Triangles, über die eine sparsame Viertelkreistextur gezogen wird. Und ja, wie man vielleicht sieht können die Eckenradien unterschiedlich sein

Es wird Zeit, Kollisionen erkennen zu können. Angefangen habe ich dummerweise mit den Kollisionen zwischen Figur und Level. Das Level besteht aus quadratischen Tiles, die Kollisionsbox der Figur hingegen ist ein Rechteck mit abgerundeten Ecken. Die Kollisionserkennung zwischen Rechtecken und Rechtecken mit abgerundeten Ecken funktioniert nun auch schon:


Aber ich hätte lieber vorher etwas weiter studiert: Die Kollision zwischen Figur und Gegnern wird im Allgemeinen der Fall Rechtecke mit abgerundeten Ecken untereinander sein. Und ein Rechteck ohne abgerundete Ecken ist im Prinzip auch nur ein Rechteck mit Eckenradius 0. Hätte ich also mit der Kollisionserkennung für Rechtecke mit abgerundeten Ecken untereinander angefangen, wäre nun schon beides erledigt

Ist es halt mal wieder so weit, dass ich etwas kaum fertiggeschriebenes neu schreiben werde. Aber was soll's, die Notizen und Skizzen, die mir für den ersten Fall halfen, werden mir sicherlich auch das Leben für die neue Arbeit erleichtern


Übrigens habe ich angefangen neben The Gatherer Mobile an einem Beitrag zu arbeiten für den Code a game competition - Jan 30th - Apr 10th 2018 auf SyntaxBomb. Ich versuche an beidem dran zu bleiben, aber da der Wettbewerb eine fixe Deadline hat, könnte die Frequenz der Beiträge hier abnehmen

Wie auch beim Original wird das Blobmonster wieder der schwächste Gegner. Im Moment tut es aber noch nichts anderes als dem Spieler wie ein Haustier nachzulaufen

Beim letzten Beitrag zu den Animationen war ich übrigens nicht ganz präzise: Körperteile werden nicht "von selbst" gerendert. Das Rendering übernimmt die Figur - diese entscheidet dann eben auch, was an welchen Animationspunkten angeheftet wird. Im Falle der Spielfigur sind das Bilder für zwei Hände, zwei Füsse, ein Körper und ein Kopf.

Wieso ich das schreibe? Weil das Blobmonster nicht aus mehreren Körperteilen/Bildern besteht, sondern aus neun Triangles, über die eine Textur gezogen wird. Bewegt werden bislang vier Vertices über Animationspunkte, so dass ein "Kriecheffekt" entsteht.



Das Blobmonster besteht also u.A. aus einem Array für die X/Y-Koordinaten und einem für die U/V-Koordinaten (oder S/T, wie es mancherorts auch genannt wird) für alle Vertices, einem Array für alle Triangles mit den Vertex-Indizes und zu guter Letzt zwei Arrays für sämtliche zu zeichnenden Dreiecke mit jeweils allen XY und UV-Paaren. Vor dem zeichnen via canvas.DrawPrimitives() werden einfach die beiden letzten Arrays neu befüllt. Diese letzten Schritte versuche/hoffe ich jetzt aber mit canvas.DrawIndexedPrimitives() zu überspringen.

Ohne mich gross um Eingabe/Steuerung zu kümmern, stelle ich ein Animationssystem auf die Beine. Da die Grafiken pixelmässig grösser sein werden, müsste ich mehr Frames in die Animationen einbauen, damit diese noch flüssig dargestellt werden. Oder ich animiere die Körperteile direkt im Spiel. Ich entschied mich für letzteres.

Der jetzige Prototyp des Animationssystems besteht aus:
Animationen
Für jede Animation (stehen, gehen etc) wird eine Klasse erstellt, welche die Methode Update zur Verfügung stellt. Diese positioniert "Animationspunkte" abhängig von der Animationszeit. An diese Animationspunkte können dann beliebige Körperteile angeheftet werden.

Animations-Player
Quasi das Abspielgerät für Animationen. Jede Figur wird einen davon erhalten. Das Abspielgerät wird mit einer Animation gefüttert und kann befohlen werden, diese in einer beliebigen Geschwindigkeit abzuspielen. Ausserdem können Animationen mit zusätzlichen Parametern gesteuert werden. Auch diese nimmt der Player entgegen.

Körperteile
Körperteile werden an Animationspunkte angeheftet und mit deren Hilfe und einer Transformationsmatrix positioniert. Die positionierten Körperteile werden dann auch gerendert.

Figur
Besteht aus Körperteilen, einem Animations-Player und natürlich den Animationen. Die Routine, welche die Steuerung der Figur übernimmt, startet auch die passende Animation in der passenden Geschwindigkeit. Alle gestarteten Animationen werden global aktualisiert.

Bis jetzt gibt's die beiden Animationen gehen und stehen für die Spielfigur:


Wie man sieht, wird die gehen-Animation der Bewegungsgeschwindigkeit angepasst.

Hallo Leute!

Ich habe mich entschieden, auszuprobieren, wie ein Jump'n'Run für Android funktionieren könnte/kann/wird. Mobile Geräte stellen ja eine komplett andere Herausforderung dar in Sachen Eingabemöglichkeiten. Aber auch die Grafik muss für die eher kleine Ausgabe optimiert werden (ich möchte nicht nur 3mm grosse Figürchen auf dem Schirm rumhüpfen sehen )

Dafür werde ich mich grösstenteils am Spiel The Gatherer orientieren. Ein paar von euch mögen sich noch daran erinnern, es war mein Beitrag zum 79. BCC: