Task 5: Gruppenprojekt: Jump ‘n Run Sandbox

© 2021 Nintendo. https://supermariomaker.nintendo.com/

Ihre Aufgabe ist der Entwurf und die Entwicklung eines Jump ‘n Run mit Level-Editor (Sandbox).

Sie sind in Aussehen, Benutzung und Auswahl der Features frei. Die unten stehenden grundlegenden Anforderungen müssen vom Endprodukt erfüllt werden.

Inspiration liefern können Super Mario Maker, Ultimate Chicken Horse oder SuperTux mit seinem In-game Level Editor.

Grundlegende Anforderungen

Das Spiel soll in zwei Teile aufgeteilt sein:

1. Existierende Level spielen

2. Neue Level entwerfen

1. Existierende Level spielen

Eine einzelne Spieler:in kann alleine ein Level spielen. Das Spielen eines Level gestaltet sich wie folgt:

1. Die Spieler:in verbindet sich zu einem Server und kann aus einer Reihe von existierenden Levels auswählen. (z.B. anhand von Namen oder durch Vorschau-Bilder)

2. Wenn die Spieler:in das Level startet, wird das Level-Layout vom Server heruntergeladen und das Level beginnt:

Die Spieler:in kontrolliert eine Spielfigur. Ziel jedes Level ist, vom Eingang des Level zum Ausgang des Level zu kommen (z.B. durch ein Symbol wie eine Tür oder ein Flugzeug repräsentiert).

Die Spieler:in kann unterschiedliche Aktionen ausführen, um sich zu bewegen und Hindernisse zu überwinden: Mindestens nach links und rechts gehen und springen. Die Steuerung der Spielfigur ist beliebig und kann mit Maus, Buttons, und/oder Tastatur erfolgen.

Wenn die Spielfigur nach unten aus dem Spielfeld fällt oder ein gefährliches Objekt berührt (optional, siehe unten), ist das Level verloren. Wenn die Spielfigur den Ausgang des Level erreicht, ist das Level gewonnen.

Zu jedem Level werden Statistiken auf dem Server gespeichert: Mindestens wie oft das Level versucht wurde, wie oft das Level geschafft wurde, und was die schnellste erfolgreiche Zeit für das Level war.

2. Neue Level entwerfen

Neben dem eigentlichen Spiel soll es möglich sein, neue Level zu entwerfen und auf dem Server zu speichern. Diese Level können dann von anderen Spieler:innen gespielt werden.

Zum Erstellen von Levels wird lokal ein Level-Editor zur Verfügung gestellt, in dem mindestens drei Komponenten zum Bau eines Level zur Verfügung stehen: Level-Eingang, Blöcke, und Level-Ausgang. Zusätzlich soll es möglich sein, existierende Komponenten wieder zu entfernen.

Nachdem eine Spieler:in ein Level erstellt hat, kann es am Server hinterlegt werden.

Es ist nicht notwendig, dass der Server seine Spieldaten über einen Neustart hinweg behält. Der Server muss jedoch die Anfragen mehrer Nutzer gleichzeitig verarbeiten können.

Zusatzfeatures

Es sind viele unterschiedliche Zusatzfeatures oder Interpretation der Aufgabenstellung möglich. Es müssen mehrere Kategorien an Zusatzfeatures zusätzlich zu den grundlegenden Anforderungen implementiert werden, so dass jedes Teammitglied einen essentiellen Beitrag zu mindestens einem Zusatzfeature geleistet hat.

Ein paar Ideenvorschläge; andere Zusatzfeatures sind ebenso möglich:

• Gefährliche Blöcke im Level, die nicht berührt werden dürfen (z.B. Lava)

• Zusätzliche Hindernisse im Level, wie Falltüren, sich bewegende Gegner oder eine rotierende Welt

• Zusätzliche Spielfigur-Aktionen wie “Bauen von Blöcken” oder kurzzeitiges Fliegen, um Hindernisse leichter überwinden zu können

• Unterschiedliche Spielfiguren und/oder Layouts

• Spezielle Spielmodi wie mehrere Leben pro Level oder starke/schwache Schwerkraft

• Side-scrolling Level, wie man es von Super Tux und Super Mario kennt: Kein starres Level, in dem man das komplette Level gleichzeitig auf dem Bildschirm sieht, sondern ein sich mit der Spielfigur bewegender Bildausschnitt in einem größeren Level.

• Multiplayer-Level (lokal oder über das Netzwerk)

• Fortgeschrittene Features im Level-Editor, z.B. Verwendung existierender Level als Schablonen, vorgefertigte größere Formen von Blöcken

• Detaillierte Statistiken pro Level

• Sortierung von Levels nach Schwierigkeitsgrad, Erstellungsdatum, Beliebtheit, etc.

• Erweiterte Persistenz von Spieldaten: Speichern aller Level und Statistiken über den Server-Neustart hinweg, lokales Speichern von Leveln im Level-Editor, etc.

• Soziale Möglichkeiten wie Spielernamen mit Statistiken pro Spieler, Chats, etc.

• etc.

Notwendige Nicht-Code-Dateien

Neben dem Code sind folgende Dateien gefordert: README, CHANGELOG, und Protokoll-Dokumentation.

Die README muss die notwendigen Software-Abhängigkeiten beschreiben, z.B. Java 11 oder Java 17, und muss erklären, wie man den Server und das Spiel starten kann.

Das CHANGELOG muss im Format https://keepachangelog.com/en/1.0.0/ sein und aktuell gehalten werden. Anhand des Changelog sieht man zu jeder Zeit, welche Änderungen am Produkt gemacht wurden.

Die Protokoll-Dokumentation beschreibt das verwendete Netzwerkprotokoll, das zur Kommunikation zwischen Client und Server verwendet wird: Alle verwendeten JSON-Typen sollten dokumentiert sein.

Nicht-funktionale Anforderungen

Die Qualität und Benutzbarkeit des Produkts hat großen Vorrang gegenüber möglichst vielen unterschiedlichen Features. Entsprechend sollte durch Code-Reviews, gegenseitiges Testen und automatische Tests sichergestellt werden, dass die kritischen Komponenten des Systems zuverlässig funktionieren.

Benutzbarkeit

Übliche GUI-Interaktionen wie das Vergrößern oder Verkleinern des Spielfensters sollen sinnvoll behandelt werden.

Entwicklungsmethoden: Git und GitLab

Die korrekte Verwendung von Git und Commit Nachrichten wird bewertet. Im Projekt muss das Branching-Model GitHub Flow verwendet werden: Für jede anstehende Arbeit im Projekt muss zuerst ein Issue erstellt werden, das die Aufgabe beschreibt. Wird die Arbeit an einem Issue begonnen, wird aus dem Issue heraus ein Feature-Branch und ein Merge Request als Entwurf erstellt. Die Namen von Feature-Branches müssen immer mit der Issue-Nummer beginnen.

Sobald die Arbeit an einem Issue beendet ist, wird der dazugehörige Merge Request als “fertig” deklariert. Jetzt können Teammitglieder einen Code Review durchführen und den Merge Request eventuell approven. Erst nach mindestens einem Approve und korrekt laufender CI darf der Merge Request in den main-Branch gemerged werden. Schon während der Arbeit am Issue kann der Merge Request zur Kommunikation über die laufenden Arbeiten verwendet werden (z.B. bei Problemen oder Anmerkungen).

Jeder Merge Request muss Änderungen oder neue Features im CHANGELOG vermerken!

Man sollte anhand der Issues zu jeder Zeit sehen können, wer gerade an was arbeitet. Man sollte anhand der Merge Requests zu jeder Zeit sehen können, wie der aktuelle Stand in der Bearbeitung ist (also häufig pushen!).

Entwicklungsmethoden: Agile Entwicklung

Das Projekt soll agil durchgeführt werden. Es findet jede Woche ein Treffen mit dem Team-Tutor statt. Zu Beginn jedes Treffen soll ein Standup-Meeting durchgeführt werden, in dem jedes Teammitglied in maximal 5 Minuten erzählt:

• was es seit dem letzten Treffen gemacht hat,

• was es bis zum nächsten Treffen machen wird, und

• was es aktuell für Probleme oder Risiken für seine Arbeit gibt.

Zu Beginn des Projekts werden erste Issues erstellt, um eine grobe Projektplanung zu erhalten. Im Laufe des Projekts sollten die Issues jedoch von allen Teammitgliedern ständig erweitert und angepasst werden, um auf den Fortschritt im Projekt und neue Ideen zu reagieren. Es wird nicht erwartet, dass zum Projektende alle Issues erledigt sind. Stattdessen muss am main-Branch zu jeder Zeit ein ausführbares und funktionales Produkt verfügbar sein (ein potentially shippable product).

Die Arbeit sollte also so auf Issues aufgeteilt und eingeteilt werden, dass jedes aktuell bearbeitete Issue einen direkt sichtbaren Mehrwert im Projekt liefert, und wichtige Issues zuerst bearbeitet werden. Die Definition von Interfaces oder Verwendung von Design Patterns kann dabei helfen, die Arbeit feingranular unter den Teammitgliedern aufteilen zu können.

Entwicklungsmethoden: Unit Testing

Die Programmlogik sollte per JUnit Unit-Tests getestet werden.

Entwicklungsmethoden: Pair Programming

Pair programming ist erlaubt.

Jeder Commit, der im Pair Programming entstanden ist, muss vom “Piloten” comittet werden, und am Ende der Commit-Nachricht den Namen und die Mail-Adresse des “Co-Piloten” in folgendem Format enthalten:

Co-Authored-By: Name <mail-addresse, die GitLab kennt>

Beim Pair Programming sollten sich Pilot und Co-Pilot regelmäßig abwechseln.

Projektablauf

Abgaben werden von uns zur jeweiligen Deadline per GitLab-Tags in eurem Projekt markiert. Nur der main-Branch wird betrachtet.

Es gibt die folgenden Abgabedeadlines:

• 20. Dezember 2021: Initiale Projektplanung

  GUI Mockups (Skizzen von den geplanten GUI-Fenstern und den jeweils enthaltenen Komponenten) helfen, dass das gesamte Team eine gemeinsame Vorstellung vom angestrebten Produkt hat. Issues für geplante Features und Aufgaben sollten vorhanden sein, erste Architektur-Ideen als Diagramme und/oder Java Interfaces mit ausführlichem JavaDoc. Lösungsansätze für grundlegende Fragestellungen wie z.B. die Steuerung und Repräsentation der Spielfigur in einem Level sollten existieren.

• 10. Januar 2022: 1. Zwischenabgabe

  Aktueller Stand des ausführbaren Produkts und der Nicht-Code-Dateien.

• 17. Januar 2022: Zwischenbericht jeder Gruppe im Plenum

  Kurze Live-Demo des ausführbaren Produkts, Vorstellung der noch geplanten Features (5-10 Minuten).

• 24. Januar 2022: 2. Zwischenabgabe

  Aktueller Stand des ausführbaren Produkts und der Nicht-Code-Dateien.

• 06. Februar 2022: Finale Abgabe

  Aktueller Stand des ausführbaren Produkts und der Nicht-Code-Dateien.

• 07. Februar 2022: Produktpräsentation

  Live-Demo des ausführbaren Produkts mit “Highlights”, 7 Minuten pro Gruppe.

Viel Erfolg!