Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

--- ef_informatik:game-server_block [2021-08-31 07:43] – [3.2 Technische Vorgaben] hof
+++ ef_informatik:game-server_block [2021-10-05 13:41] (aktuell) – [Rundenbasierter Gameserver mit REST-API] hof
@@ Zeile 1: / Zeile 1: @@
 ====== Rundenbasierter Gameserver mit REST-API ======
-===== - Organisation =====
+Die ganze Dokumentation findet sich mittlerweile auf https://github.com/JungleState/ksr_junglestate
+===== - Organisation & Ablauf =====
-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.
+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.
-===== - Ablauf =====
 Die Umsetzung folgt der Entwicklung in einer Software-Firma:
@@ Zeile 13: / Zeile 12: @@
     * Einreichung des Proposals inkl. Komponentenplanung und Zeitplan
   - Implementierungsphase (5w)
-    * Umsetzung gemässe Projektplan
+    * Umsetzung gemäss Proposal
-    * Alle Artefakte werden in Github abgelegt.
+    * Alle Artefakte werden in Github abgelegt:
-    * Nach jeder Woche erwartet die Auftraggeberin einen kurzen Report mit folgendem Inhalt:
+      * Quellcode
+      * Dokumentation (als Markdown)
+      * Issues (Implementierungseinheiten)
+      * Milestones (jede Woche einer)
+    * Nach jeder Woche erwartet die Auftraggeberin einen kurzen Email-Report mit folgendem Inhalt:
       * Projektfortschritt
       * Ist vs. Soll: Wo steht das Projekt im Vergleich zum Zeitplan?
@@ Zeile 30: / Zeile 33: @@
 ===== - Requirements =====
-Es wird ein Game-Server implementiert, der remote Clients in einem rundenbasierten Game gegeneinander spielen lässt.
+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.
 ==== - Spielbeschrieb ====
@@ Zeile 46: / Zeile 49: @@
 Jeder Affe erhält zu Beginn der Runde seinen einsehbaren Teilbereich des Urwalds. Dieser beträgt typischerweise 5x5 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((Selbstverständlich erwachen alle ohnmächtige Affen nach dem Spielende ohne bleibende Schäden zu erleiden. Bei der Entwicklung dieses Spiels kamen keine Tiere zu Schaden!)).
+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((Selbstverständlich erwachen alle ohnmächtige Affen nach dem Spielende ohne bleibende Schäden zu erleiden. Bei der Entwicklung dieses Spiels dürfen keine Tiere zu Schaden kommen!)).
 Kollidieren zwei Affen oder ein Affe und der Dickicht, verringert sich die Lebensenergie ebenfalls, die Affen bleiben auf ihrem Feld stehen.
@@ Zeile 67: / Zeile 70: @@
 === - Server ===
-Der Server wird als [[https://de.wikipedia.org/wiki/Representational_State_Transfer|REST]]-API definiert und implementiert.
+Der Server wird als [[https://de.wikipedia.org/wiki/Representational_State_Transfer|REST]]-API definiert und implementiert. Das API soll mit der Anfangsanfrage mitgeliefert werden ([[https://de.wikipedia.org/wiki/Representational_State_Transfer#Beispiel|HATEOS]]).
-  * Die Abfrage des Spielzustands soll mittels Long-Polling (ev. [[https://en.wikipedia.org/wiki/WebSocket|Websockets]]) umgesetzt werden: der Client fragt den Zustand an, die Antwort erfolgt erst, wenn die Runde zuende ist.
+  * Die Abfrage des Spielzustands soll mittels Long-Polling (ev. [[https://en.wikipedia.org/wiki/WebSocket|Websockets]] in [[https://gitlab.com/pgjones/quart|Quart]]) 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, die zulange mit der Antwort zuwarten, werden aus dem Spiel ausgeschlossen.
 === - Client ===
 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.
+  * Ein Konsolen- oder Web-Client-Programm für Testzwecke, 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 App soll den Namen //Jungle Camp// tragen.
-=== - Proposal ===
+===== - Proposal =====
 Die Gruppe erarbeitet ein Proposal um die obigen Requirements umzusetzen. Das Proposal beinhaltet die folgenden zwei Teile:
-  * Design (als Markdown-Dokument in GitHub)
+=== Design ===
+Das Design wird als Markdown-Dokument auf Github gestellt. Es beinhaltet:
     * Aufteilung des Systems in **Komponenten**:
       * Server: Spiel-Management, Gameplay, Benutzeridentifizierung
@@ Zeile 98: / Zeile 103: @@
       * Vorgeschlagene Technologie / Plattform
       * ev. Abwägung von verschiedenen Möglichkeiten.
-  * Ausführungsplan
+=== Ausführungsplan ===
-    * Wie lässt sich die Umsetzung der Komponenten in **Tasks** aufteilen? Zum Beispiel:
+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.
-      * Git Repo einrichten und Projekt-Layout definieren.
-      * JSON-Schnittstelle für ein Game definieren.
+Gibt es Abhängigkeiten zwischen den Tasks? Wie gross sind die Tasks (1, 2, 3, 5 Stunden)?
-      * Game-Logik in Python implementieren.
-      * Einfache Game-Verwaltung mit Sessions implementieren.
+Beispiel-Tasks:
-      * ...
+  * Git Repo einrichten und Projekt-Layout definieren.
-    * Gibt es Abhängigkeiten zwischen den Tasks?
+  * JSON-Schnittstelle für ein Game definieren.
-    * Wie gross sind die Tasks (1, 2, 3, 5 Stunden)?
+  * Game-Logik in Python implementieren.
-    * Für jede Woche erstellen wir einen Milestone in Github und fügen die Tasks in den Milestone ein.
+  * Einfache Game-Verwaltung mit Sessions implementieren.
+  * ...