Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

Link zu der Vergleichsansicht

Beide Seiten, vorherige Überarbeitung Vorherige Überarbeitung
Nächste Überarbeitung		 Vorherige Überarbeitung
ef_informatik:game-server_block [2021-08-31 07:48] – [3.2 Technische Vorgaben] hofef_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 ====== ====== 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: Die Umsetzung folgt der Entwicklung in einer Software-Firma:
Zeile 34: Zeile 33:
 ===== - Requirements ===== ===== - 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 ==== ==== - Spielbeschrieb ====
Zeile 50: 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. 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. Kollidieren zwei Affen oder ein Affe und der Dickicht, verringert sich die Lebensenergie ebenfalls, die Affen bleiben auf ihrem Feld stehen.
Zeile 72: Zeile 71:
 === - Server === === - Server ===
 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]]). 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.   * 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...).   * Es werden verschiedene Spielfelder unterstützt (default, Testumgebung, Schwierigkeitsgrade...).
   * Ein Spiel soll von bis zu 50 Clients gleichzeitig gespielt werden können.   * 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 === === - Client ===
Zeile 83: Zeile 83:
     * Die Steuerung soll über Tastatureingabe erfolgen.     * Die Steuerung soll über Tastatureingabe erfolgen.
   * Eine Visualisierung als Web-App, die das gesamte Spielfeld abbildet, um Spiele live verfolgen zu können.   * 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: 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**:     * Aufteilung des Systems in **Komponenten**:
       * Server: Spiel-Management, Gameplay, Benutzeridentifizierung       * Server: Spiel-Management, Gameplay, Benutzeridentifizierung
Zeile 102: Zeile 103:
       * Vorgeschlagene Technologie / Plattform       * Vorgeschlagene Technologie / Plattform
       * ev. Abwägung von verschiedenen Möglichkeiten.       * ev. Abwägung von verschiedenen Möglichkeiten.
-  * Ausführungsplan (als Issues in Github) +=== 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. 
 +  * ...
  
  
  • ef_informatik/game-server_block.1630396099.txt.gz
  • Zuletzt geändert: 2021-08-31 07:48
  • von hof