Die ganze Dokumentation findet sich mittlerweile auf https://github.com/JungleState/ksr_junglestate
Alle Talenta/EF Schüler:innen gründen zusammen die Software-Firma CanopySoft Corp, 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:
JungleState möchte einen Game-Server entwickeln lassen, der remote Clients in einem rundenbasierten Game gegeneinander spielen lässt. Die Requirements definieren die Vorgaben zum Spiel und zur gewählten Technologie.
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
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 aus1).
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:
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. Das API soll mit der Anfangsanfrage mitgeliefert werden (HATEOS).
Clients greifen ausschliesslich über das REST-API auf ein Spiel zu. Zum Lieferumfang gehören:
Die Gruppe erarbeitet ein Proposal um die obigen Requirements umzusetzen. Das Proposal beinhaltet die folgenden zwei Teile:
Das Design wird als Markdown-Dokument auf Github gestellt. Es beinhaltet:
/gamestate/game123)GET)Die Umsetzung wird in kleinere Einheiten, sogenannte Tasks aufgeteilt, die in maximal einer Woche umsetzbar sein sollten. Für jede Woche wird in Github ein Milestone erstellt, und für jeden Task wird ein Github Issue erstellt. Zumindest für die ersten Wochen sollten die Tasks auf den passenden Milestone eingeteilt werden.
Gibt es Abhängigkeiten zwischen den Tasks? Wie gross sind die Tasks (1, 2, 3, 5 Stunden)?
Beispiel-Tasks: