Rundenbasierter Gameserver mit REST-API

Alle Talenta/EF Schüler:innen bilden zusammen eine Projektorganisation, um einen Game-Server zu realisieren. Die Lehrperson hat dabei zwei Rollen: einerseits vertritt sie die Auftraggeberin, die JungleState Inc, andererseits fungiert sie als Projekt-Coach.

Die Umsetzung folgt der Entwicklung in einer Software-Firma:

1. Kick-off (1w):
   • Der Auftraggeber stellt das Projekt und die Requirements vor.
   • Die Projektgruppe definiert ihre Projektorganisation und erstellt ein Proposal.
   • Einreichung des Proposals inkl. Komponentenplanung und Zeitplan
2. Implementierungsphase (5w)
   • Umsetzung gemässe Projektplan
   • Alle Artefakte werden in Github abgelegt.
   • Nach jeder Woche erwartet die Auftraggeberin einen kurzen Report mit folgendem Inhalt:
     • Projektfortschritt
     • Ist vs. Soll: Wo steht das Projekt im Vergleich zum Zeitplan?
     • Aufgewendete Zeit: Wieviel Zeit wurde für jede Komponente verwendet?
3. Abgabe Projekt (3w)
   • Begutachtung durch Auftraggeber
   • Allfällige Gewährleistungsarbeiten
4. Reflektion
   • Was hat gut funktioniert was nicht?
     • Organisation
     • Planung
     • Implementierung

Es wird ein Game-Server implementiert, der remote Clients in einem rundenbasierten Game gegeneinander spielen lässt.

Das Spiel besteht aus dem Urwald und Affen, die sich gegenseitig mit Kokosnüssen bewerfen.

Der Urwald besteht aus einer zweidimensionalen Matrix mit diskreten Feldern. Jedes Feld kann durch einen eindeutigen Zustand beschrieben werden, zum Beispiel

• frei
• Dickicht (undurchdringlich)
• Affe
• Tokens wie Banane, Kokosnuss, ev. weitere Tokens

Jeder Affe erhält zu Beginn der Runde seinen einsehbaren Teilbereich des Urwalds. Dieser beträgt typischerweise 5×5 Felder um die Position des Affen. Der Affe entscheidet sich für eine Aktion, entweder MOVE oder THROW_COCONUT in einer der 8 Richtungen. Kokosnüsse fliegen nur ein Feld weit.

Wird ein Affe von einer Kokosnuss getroffen, wird seine Lebensenergie um eine bestimmte Menge verringert. Fällt die Lebensenergie eines Affen auf null, fällt er ohnmächtig vom Ast und scheidet aus¹⁾.

Kollidieren zwei Affen oder ein Affe und der Dickicht, verringert sich die Lebensenergie ebenfalls, die Affen bleiben auf ihrem Feld stehen.

Findet ein Affe eine Banane, wird die Lebensenergie erhöht. Gefundene Kokosnüsse erhöhen den Munitionsvorrat. Sowohl Lebensenergie als auch Kokosnussvorrat sind begrenzt.

Affen erhalten Punkte für gewisse Aktionen:

• Treffen von Gegnern
• Eliminieren von Gegnern
• ev. Finden von bestimmten Tokens (Ananas?)

Das Spiel endet wenn weniger als zwei Affen übrig bleiben, oder nach einer definierten Zeit.

Gewinner ist der Affe mit den meisten Punkten. Eventuell könnte man den Gewinner auch nur aus den wachen Affen auswählen - allerdings schafft dies einen Anreiz, sich möglichst lange zu verstecken und am Schluss auf den letzten Überlebenden loszugehen…

Die Umsetzung folgt der Client-Server-Architektur.

Der Server wird als REST-API definiert und implementiert.

• Die Abfrage des Spielzustands soll mittels Long-Polling (ev. Websockets) umgesetzt werden: der Client fragt den Zustand an, die Antwort erfolgt erst, wenn die Runde zuende ist.
• Der Server unterstützt zusätzlich zum Client-Zugang über einen privilegierten Zugang, um das gesamte Spielfeld zu visualisieren.
• Es werden verschiedene Spielfelder unterstützt (default, Testumgebung, Schwierigkeitsgrade…).
• Ein Spiel soll von bis zu 50 Clients gleichzeitig gespielt werden können.

Clients greifen ausschliesslich über das REST-API auf ein Spiel zu. Zum Lieferumfang gehören:

• Ein Beispiel-Client auf C#-Basis, der einen einfachen Affen-Agenten implementiert (z.B. einer, der jede zweite Runde in einer zufälligen Richtung geht und auf alles in der Umgebung schiesst).
• Ein Konsolen- oder Web-Client-Programm, das die manuelle Steuerung eines Affen erlaubt.
  • Die Steuerung soll über Tastatureingabe erfolgen.
• Eine Visualisierung als Web-App, die das gesamte Spielfeld abbildet, um Spiele live verfolgen zu können.
  • Die App soll den Namen Dschungelcamp tragen.

Die Gruppe erarbeitet ein Proposal um die obigen Requirements umzusetzen. Das Proposal beinhaltet die folgende Angaben:

• Design:
  • Technologie-Stack auf Server und Client:
    • Vorgeschlagene Technologie / Plattform
    • Diagramm der Hauptbestandteile
    • ev. Abwägung von verschiedenen Möglichkeiten.
  • zu implementierende REST-Endpunkte mit folgenden Angaben:
    • Ressourcenname mit allen Parametern (z.B. /gamestate/game123)
    • HTTP-Methode (z.B. GET)
    • Rückgabe-Wert und Format (meist JSON)
  • Schnittstellenbeschreibung zwischen Komponenten (z.B. JSON-Format).
• Komponentenaufteilung:
  • Wie lässt sich das System in Komponenten aufteilen?
    • Server: Spiel-Management, Gameplay, Benutzeridentifizierung
    • Client: Beispiel-Client, API-Code für andere Schüler
    • Visualisierung: UI, Schnittstellen…
  • Wie lässt sich die Umsetzung der Komponenten in Tasks aufteilen? Zum Beispiel:
    • Git Repo einrichten und Projekt-Layout definieren.
    • JSON-Schnittstelle für ein Game definieren.
    • Game-Logik in Python implementieren.
    • Einfache Game-Verwaltung mit Sessions implementieren.
    • …
  • Gibt es Abhängigkeiten zwischen den Tasks?
  • Wie gross sind die Tasks (1, 2, 3, 5 Stunden)?

• Optionale Features:
  • Skinning: Statt Urwald-Affen kann dasselbe Spiel mit anderer Oberfläche gespielt werden (Panzer, Pacman…)
  • Benutzerverwaltung: Benutzer müssen sich identifizieren (wie?), es werden Ranglisten gespeichert.
  • Handicap: gute Spieler erhalten ein Handicap (z.B. werden sie in jeder Runde mit Wahrscheinlichkeit p ausgelassen, p korreliert mit der Spielstärke).
  • ML-Schnittstelle: erlaubt es, eine ML-Learner zu trainieren, der die optimale Spielstrategie herausfindet (entweder mit Zielwert-Learning oder mittels Generative Adversarial Networks)
  • Randomisierung: Kokosnüsse treffen nur mit Wahrscheinlichkeit x < 1 - damit wird das Spiel etwas weniger deterministisch.