[Thesis] Spielideen und Escape-Rooms entwickeln

[cagix]

Unser Dungeon bietet aktuell viele verschiedene Spielelemente/-mechaniken und auch einige Levelgeneratoren. Was fehlt, sind konkrete Spiele (-ideen), d.h. konkrete Quests und Level und Aufgaben.

Spielideen entwickeln und Level aufbauen

Ziel ist es, ein oder mehrere in sich halbwegs konsistente Spiele aufzubauen und umzusetzen, in denen dann die Studierenden in Prog2 konkrete Programmieraufgaben übernehmen können (etwa Eigenschaften ändern oder neue Funktionalität einbauen oder Rätsel mit eigenem Code lösen oder eigene neue Spielelemente ... erstellen).

Beispielsweise hat man als Spieler in Shattered Pixel Dungeon auf jedem Level andere Aufgaben und andere Monster und Spielelemente, mit denen man interagieren muss.

Das Basisspiel sollte nicht zu komplex sein (4..5 Ebenen) und es sollte sich relativ schnell erlernen lassen, aber es sollte auch einen gewissen Spielspaß ermöglichen.

Jedes Level sollte klar erkennbare Strukturen haben (also zumindest optisch klar unterscheidbar sein). Auf jedem Level sollten andere Monster agieren, diese sollten zunehmend schwieriger zu besiegen sein. Es soll Quests geben, die zunächst nur unterschiedlich sein sollen (etwa das Besiegen von N Monstern, oder das Aufsammeln von N Tränken o.ä.). Das Tor zum nächsten Level darf erst aufgehen, wenn alle Monster und Aufgaben erledigt sind. Spielideen können im Original Shattered Pixel Dungeon studiert werden.

Das Spiel soll so organisiert werden, dass die Studierenden darin Modifikationen vornehmen können und dabei die ECS-Architektur kennen lernen (und Spielspass haben). Die Modifikationsmöglichkeiten sollen von einfach ("ändere Eigenschaften von Monster X") bis komplex ("ändere das Verhalten von Monster X" oder "ändere die Quest, so dass ...") reichen.

Es können dazu aus dem Projekt Game die Klassen in core und aus dem Projekt Dungeon die Klassen in contrib verwendet werden.

Für die Steuerung sollten nicht nur die klassischen WASD konfiguriert werden, sondern zusätzlich auch die Cursor-Tasten. Zusätzlich wäre es nett, wenn man per Mausklick steuern könnte (@AMatutat ist das überhaupt implementiert?).

Vorab zu klärende Fragen: Wie sollen die Strukturen aussehen? Soll dieses Spiel ein weiteres Projekt im Dungeon-Repo werden? Soll das Spiel ein eigenes Repo werden? Soll das Spiel die Game- und Dungeon-Klassen über ein Jar-File referenzieren?

---

Alternativen:

• Gurkenlabs litiengine, Demo: litiengine-gurk-nukem - ohne libGDX (!), auf der Basis der Demo könnte man evtl. die obige Aufgabe schneller umsetzen
• jMonkeyEngine
• Shattered Pixel Dungeon: Das Original mit schicker Grafik und funktionierendem Spiel - hier müsste man den Ablauf verstehen und die obersten Level umdefinieren
• FreeCol - Colonization Strategy Game - kein libGDX (!), basiert aber auf einer komplett anderen Spielidee. Evtl. lassen sich hier Escape-Rooms und Quests leichter umsetzen?

Escape-Rooms: Lösen durch spielerische Interaktion mit dem Dungeon

Es sollen Rätsel und Aufgaben als Escape-Rooms im/mit dem Dungeon realisiert werden.

Die Spieler lösen das Rätsel durch entsprechende Interaktion mit dem Dungeon, etwa durch Aufsammeln von Dingen oder durch Interaktion mit NPC o.ä. - also durch Spielen mit dem vorgegebenen Szenario.

Über Quests könnte man eine Art Escape-Room-Level aufbauen, die man nur verlassen kann, wenn die Quests komplett abgearbeitet ist.

Escape-Rooms: Lösen durch von den Spielern entwickelten Programmcode

Die Studis bekommen eine Aufgabe auf Papier und Hinweise im Level ("Escape-Room") und müssen das Spiel mit eigenem Code erweitern, um aus dem Raum/Level wieder rauszukommen. Zusätzlich können die Spieler natürlich wieder den Raum erkunden, Dinge aufsammeln, Monster besiegen, ...

Der Code soll dem vorgegebenen Spiel hinzugefügt werden und durch Neukompilieren/Neustarten des Spiels integriert werden (also kein dynamisches Nachladen).

Beispielsweise könnte es eine Kiste geben, die sich nur öffnen lässt, wenn in einer bestimmten Klasse in einer bestimmten Methode eine vorgegebene Funktionalität von den Spielern implementiert wurde.

Die Hinweise dazu könnte es interaktiv im Level (Escape-Room) geben oder klassisch als Aufgabenstellung auf Papier. Der Code für die Kiste (im obigen Beispiel) müsste entsprechend vorbereitet sein, d.h. es müsste eine leere Methode geben mit einem Hinweiskommentar. Oder die Studis müssen die als Parameter übergebenen Objekte erst noch erstellen o.ä. ...

Das sollte sich auf allen Schwierigkeitsgraden einsetzen lassen, von einfach (Farbe der Kiste ändern) bis zu komplex (neues Schließsystem implementieren und in den Dungeon/die Kiste integrieren).

---

Es bestehen Verbindungen zu #1482.