Entwicklung eines Jump & Run Spiels Video-Tutorial

[Finalspace]

[Java] Entwicklung eines Jump & Run Spiels Video-Tutorial

Hallo,

ich möchte euch mein Projekt vorstellen, bei dem ich ein Jump & Run Spiel komplett von Grund auf programmiere und dabei aber jedes noch so kleine Detail kommentiere/erkläre.
Dazu werden alle Grundlagen wie Vektor-Mathematik, Physik, Spielmechanik, Architektur in einem sehr hohen Detailgrad - basierend auf meiner 20+ jährigen Erfahrung als Anwendungeentwickler euch näher gebracht.

Das Spiel selbst wird ein aufwendiger Vektor-basierter Puzzle-Action-Physik-Geschicklichkeits-Platformer in 2.5D - also schonmal recht ambitioniert.
Grob wird das ne Mischung aus Mega Man, Zelda, Mario, Turrican, Commander Keen und vielen Weiteren.

Daher wird das hier kein einfacher kachelbasierter Platformer, den man in ein paar Std. zusammenzimmert, sondern eher ein etwas längeres Projekt bei dem ich unter anderem folgende Themen durchnehme:

- Fenstererstellung / Game Loop
- einfacher 2D Software-Renderer zum Zeichnen von Pixeln/Linien/Kreisen/Rechtecken/Bitmaps/Fonts
- Eingabenverarbeitung
- Vektorgrundlagen
- Kollision und Reaktion
- Geometrie
- Visualisierungen
- Bewegungsintegration
- Kontaktgenerierung
- 2D Rigid body Physik-Engine
- Game/Engine-Trennung
- Asset-Management / Speicher-Management
- Animationen
- Kamera
- Eventhandling
- Debug-Techniken
- Deployment
- Spatiale-Strukturen
- Optimierungen

- und viele Weitere die sich während der Entwicklung ergeben.

Das ganze wird realisiert mit Java 7/8 in der Entwicklungsumgebung Eclipse - ohne Nutzung von Fremdbibliotheken oder einer fertigen Engine. Daher setzte ich auch entsprechende Programmierkenntnisse in Java voraus und werde nur Programmiertechniken erklären, die relevant für die Spielentwicklung sind oder nicht als Grundlagen zählen wie z.b. Threading, Reflection, Programmiermuster usw. Normale (Schul-)Mathematikkenntnisse reichen in der Regel aus. Ihr braucht also keine Physiker oder Mathematiker sein um, das zu verstehen - ich habe mir viel selbst erarbeitet und erschlossen.

Das Projekt läuft folgendermassen ab:

Wir beginnen damit ein kleines Framework zu bauen mit dem wir überhaupt mal was auf den Bildschirm bringen können und erweitern dieses Systematisch. Hier werde ich nicht viel Wert auf sauberen Programmierstil oder Architektur legen. Allerdings werden notwendige "Generische Ansätze" getrennt damit diese mehrfach verwendet werden können und logischer zusammenhängen. Dadurch entsteht automatisch eine sogenannte "Game Engine".

Das ganze wird dann in mehreren Iterationen zu einem Prototypen entwickelt, indem dem dann die gesamte Spielmechanik implementiert werden soll - allerdings ohne große Optimierungen.
Zeitgleich werden wir einen Leveleditor entwickeln, mit dem der gesamte Inhalt des Spiels erstellt werden kann.

Ab einem Punkt wird dieser Prototyp dann auf Performance optimiert und wir gehen dann zum "Fancy"-Part über. Das Rendering wird dann komplett auf OpenGL umgestellt und wir versuchen ein 2.5D Grafikstil zu etablieren.


Die letzte Episode: (Ep 103 - Geisterkontakte ein für alle mal aus der Welt schaffen)
https://www.youtube.com/watch?v=TKL7Zy03D-Q

Spoiler: Erste Episode

Ep 0 - Einführung:
https://www.youtube.com/watch?v=0FUuXQW9jq8

Den Sourcecode zur letzten Episode findet man hier: https://github.com/f1nalspace/leverman-devlog/tree/v0.1

Viel Spaß,
Final

 

[Koschkolosch]

Cool, so etwas suche ich scho länger.
YT Channel wird gleich mal abonniert.

Gruß

 

[Innensechskant]

Super!
Habe auch direkt mal ein Abo dagelassen!

Gruß

 

[Nero1]

Da ich selber mit Java entwickle lass ich auch ma n Abo da, vlt kann ich mir ja das ein oder andere mitnehmen Darf man fragen was du beruflich machst? Auch im Java- bzw. Programmierbereich tätig? Oder mehr als Freizeitbeschäftigung?

 

[max_1234]

Viel Aufwand für eine exakt 1:1 abgekupferte Videoreihe.
(Youtube, "Java 2d game").

mfg,
Max

 

[kling1]

Da ich selber mit Java entwickle lass ich auch ma n Abo da, vlt kann ich mir ja das ein oder andere mitnehmen Darf man fragen was du beruflich machst? Auch im Java- bzw. Programmierbereich tätig? Oder mehr als Freizeitbeschäftigung?

wird wohl eher das letztere sein, wenn er den unterschied zwischen methode und eigenschaft nicht kennt

 

[Finalspace]

Danke für das Feedback, hier mal entsprechende Antworten:

Da ich selber mit Java entwickle lass ich auch ma n Abo da, vlt kann ich mir ja das ein oder andere mitnehmen Darf man fragen was du beruflich machst? Auch im Java- bzw. Programmierbereich tätig? Oder mehr als Freizeitbeschäftigung?

wird wohl eher das letztere sein, wenn er den unterschied zwischen methode und eigenschaft nicht kennt

Naja, ich hab lediglich 25 Jahre Programmiererfahrung und mach beruflich Java EE im Bereich Business/Competitive Intelligence. Als Hobby allerdings mach ich Multimedia -und Spieleentwicklung in x-verschiedenen Sprachen und Varianten...

Allerdings ist kommentieren und programmieren gleichzeitig noch komplett ungewohnt für mich, daher kann das öfters mal passieren das ich Begriffe verschmische. Ebenfalls reche ich damit, dass auch die ein oder anderen fails passieren... alleine schon weil ich die Videos zu unregelmäßig aufnehmen kann.

Werde aber besser darauf achten - muss halt einfach langsamer machen. Normalerweise programmiere ich deutlich schneller und ohne große Unterbrechungen.

Viel Aufwand für eine exakt 1:1 abgekupferte Videoreihe.
(Youtube, "Java 2d game").

mfg,
Max

Es gibt unzählige Videoserien und alleine das JFrame-Konzept wird im Grunde überall identisch gemacht - geht nun mal nicht anderst mit Java. Wird sind ja nicht in C unterwegs wo wir auf OS-API Befehle wie CreateWindowEx() nen Fenster erzeugen und die Nachrichtenschleife selbst verarbeiten müssen mittels GetMessage() und unsere Nanosekunden mit QueryPerformanceCounter() holen. Daher gibt es hier zu nahezu allen Java Spiele Tutorial Videos parallelen. Und die Game-Loop ist Industriestandard - diese wird auch in sehr vielen Spielen/Tutorials verwendet. Spät. aber ab Ep 2 ist schluss mit den parallelen, da ich z.b. direkt Pixel für Pixel zeichne und nicht die Graphics Geometry-Funktionen nutzen werden - mit Außnahme von drawImage um den FrameBuffer irgendwie auf den Bildschirm zu bringen. Irgendein Blitting muss man ja machen.

 

[Tumbleweed]

Macht einen ziemlich guten Eindruck. Meinen Segen hast du.

Allerdings muss ich sagen, wäre ich kein recht fitter Entwickler, der zudem auch schon einige Male Spielchen programmiert hat, wäre es mir wohl hier und da schwer gefallen, dir zu folgen. Für Anfänger dürfte das schon etwas zu hoch sein.

Mal sehen, wie lange du durchhältst.

 

[Finalspace]

Ich habe mir mal die ersten zwei Episoden detailiert angeschaut und muss hier leider zurückrudern.
So wie ich das verzapft habe, kann ich das nicht stehen lassen - denn wenn ich mich in die Zuschauer-Rolle hineinversetze, dann kann ich nahezu gar nicht folgen - vor allem wenn ich so tue als wüsste ich nicht viel von Java.

Daher werde ich dass wirklich nochmal von vorne machen - ist ja noch nicht wirklich viel passiert.

Allerdings werde ich mich diesmal deutlich besser vorbereiten:

- Themen im voraus zusammenstellen
- Langsamer sprechen. Man soll ja folgen können.
- Besser erklären und zeichnen

Mein Ziel von dem ganzen ist in erster Linie eine runde Dokumentationsserie zu erstellen die einfach auch gleichzeitig als Tutorial dienen kann. Dokumentation weil ab einem bestimmten Punkt man einfach ausprobieren und erarbeiten muss um ein interessantes Spiel zu entwickeln.

 

[Nero1]

Finde ich gut dass du dich selbst auch noch reviewst und eigene Fehler/Unstimmigkeiten erkennst. So lernt man an besten

 

[Zyboarg]

Ich fände es auch noch gute wenn du erklärst wieso du gerade etwas machst z.B. wieso du jetzt eine Spiel Variable mit private static final deklarierst obwohl ein private final auch gereicht hätte ^^

 

[Finalspace]

Sodale - habe nun das ganze neu anfangen und die alten 4 Episoden von der Playlist genommen und die neue reingepackt.

Gefällt mir deutlich besser und ich hoffe dass es ein wenig verständlicher ist.

Falls was unklar ist, einfach fragen - ich beise nicht.

 

[Raybeez]

Macht einen guten Eindruck. Ich werde es weiter im Auge behalten

 

[Finalspace]

Um mal nen Update zu geben:

Die Serie entwickelt sich bisher recht gut - wie ich finde.
Wir haben schon folgende Themen durchgenommen:

- Fenster -und Eingabeverarbeitung
- Einfaches Pixel Rendering (Punkt, Linie, Rechteck)
- Game Loop und Timing
- Bewegung und Numerische Integration
- Vektor-Grundlagen
- Die ersten Schritte mit Kollision und Reaktion
- Geometrytypen

und kommen ganz gut vorran.

Natürlich ist des was ich bisher so erzählt habe - nicht immer 100% verständlich - zumindest nicht auf anhieb, allerdings merke ich das und korrigiere es spätestens in der nächsten Episode.

Was meint Ihr? Ist mein Stil gut verständlich oder ist das zu schwer verdaulich?

Feedback ist erwünscht!

 

[rob-]

Ich glaube nicht Akademiker könnten davon überfordert sein, ist doch recht Mathe lastig.
Wenigstens verstehen sie dann was Softwareentwicklung wirklich ist

 

[Lacritz]

Definitiv sehr Mathematik lastig.
Werds mal die Tage ein wenig schauen. Eben nur mal durch die 13. Folge geschaut.
Aber man muss dir lassen sehr angenehm zu zu hören.

@rob-: Anwendungsentwicklung ist nicht nur höhere Mathematik - kommt stark darauf an was du Programmierst.

 

[thecain]

Entwicklung ist höhere Mathematik. Ich verstehe zwar nicht was das mit Akademikern zu tun hat, aber was solls.

Sobald man Anwendungen entwickelt, die in irgend einer Art performant sein müssen oder einen halbwegs sinnvollen Algorithmus beinhalten sollen, gehört Mathematik einfach dazu. Finde es also auch essentiell, dass es mit dabei ist, v.a. bei der Spieleentwicklung!

@Topic: Hab zwar nur ein paar mal reingeschaut, finde es aber interessant. Ein bisschen wie "Handmade Hero" einfach auf Deutsch, Java und ein bisschen weniger Professionell aufgezogen, wobei das auch ein sehr hoher Gradmesser ist.

 

[rob-]

So sieht es aus. Jede Zeile Code die ohne ein Gespür für Mathe entwickelt wird, ist wahrscheinlich ein Flaschenhals.

Spiele sind eigentlich Mathe pur, da so ziemlich alles auf der GPU per Lineare Algebra (Matrizen/Vektoren) berechnet wird. Die Arbeit wird einem von gewissen Bibliotheken und APIs erleichtert, dennoch muss man da fit sein um zu verstehen was da eigentlich passiert und wieso etwas besser ist als das andere.

Die gute Nachricht ist das Lineare Algebra relativ eigenständige Mathematik ist, die ich als relativ leicht empfunden habe. Letzten Endes muss man doch nur mit Matrizen multiplizieren, man muss nur wissen welche Matrix was tut (Drehung, Rotation usw.). Wer dies z.B. nicht kann, der wird extrem umständlichen und langsamen Code schreiben der an sich das simuliert weswegen eine GPU überhaupt gebaut wurde, nur läuft es dann nicht auf der GPU sondern auf der lahmen CPU.

Da braucht man sich nur die kommerziellen Games ansehen. Alles was eine Grafik von gestern hat aber ruckelt ist mieser Code ohne Mathe Verständnis.

 

[Finalspace]

Ja ich weiß die Serie ist recht Mathelastig - aber Ihr sollt wissen, dass ich wahrlich kein Mathegenie bin.
Daher basiert alles was Ihr bisher von mir gesehen und erklärt bekommen habt, komplett auf einfacher Mathematik: Plus, Minus, Mal, Geteilt, bischen Bruchrechnen, bischen Geometry (Rechtwinkliges Dreieck, Einheitskreis) - Fertig.

Aber ich gebe zu, manche Konzepte sind trotzdem nicht leicht zu verstehen - aber ich gebe mir Mühe!

Korrekt ist jedenfalls dass man ohne Mathematik in der Spieleentwicklung nicht wirklich weit kommt!

Ich selbst hatte lange keinen Plan von Vektoren, Algebra und Co - nur durch meine unzähligen Experimente/Techdemos in all den Jahren, habe ich es nach und nach verstanden und mir selbst beigebracht (durch Bücher, Tutorials, Videos aber das meiste durch "learning by doing"). Was mir ungemein geholfen hat war alles zu visualisieren und das werden wir spät. beim Kontaktgenerator machen.

Danke für das Feedback ;-)

 

[MoOderSo]

Die Fehler der ersten beiden Eulerverfahren resultieren übrigens daraus, dass du im ersten Fall die zurückgelegte Wegstrecke eines Zeitschritts nur mit der Anfangsgeschwindigkeit des Zeitschritts berechnest und deshalb das Ergebnis unterschätzt und im zweiten Fall mit der Endgeschwindigkeit rechnest und so die Wegstrecke überschätzt.
Das dritte Verfahren ist dann nichts weiter als die genaue Umsetzung des Weg-Zeit-Gesetzes für gleichmäßig beschleunigte Bewegung. Nur ein bisschen umformen und man erhält genau dieselbe Lösung:
s(t) = a/2*t² + v0*t + s0
s(t) = s0 + ( a/2*t + v0 ) * t
s(t) = s0 + ( a*t/2 + 2*v0/2 ) * t
s(t) = s0 + (a*t + v0 + v0)/2 * t
a*t + v0 = v(t)
=>
s(t) = s0 + (v(t) + v0)/2 * t



Ansonsten mach ruhig so weiter.
Wem es zu viel Mathe ist, der kann ja vorspulen.
Und wenn nicht sofort die optimalen Lösungen implementiert werden, ist auch nicht so schlimm. Ich kenne keinen Programmierer, der sofort den optimalen Code schreibt. Da würde man auch als Zuschauer kein Problembewusstsein entwickeln können, wenn die Fallstricke von Anfang an umschifft werden.