Agenda/Message-Format-Brainstorm.md

+## Agenda / Fragen die es zu beantworten gilt
+
+* Wie verbinden sich 2 Spieler miteinander? Wer ist Server, wer ist Client? (Auswirkung auf Logik?)
+  * statisch / user entscheidet -> Host / Join buttons
+    * Vorteil: - einfach zu implementieren
+    * Nachteil: - nicht universell, man muss sich außerhalb des spiels einigen
+  * dynamisch / vor dem user verbergen? Wenn bei destination kein server, erstelle selber einen
+    * Vorteil: - der user bekommt nichts mit
+    * Nachteil: - komplizierter zu implementieren, was passiert wenn beide parteien einen ungünstigen zeitpunkt treffen und beide einen server erstellen
+* Welche Daten über das Spiel werden ausgetauscht? Grundlegende Logikfrage
+  * jede Partei verwaltet nur die minimal nötigen Infos (wo sind meine Schiffe, )
+    * Vorteil: - minimales wissen prinzip, jeder weiss nur was er wissen muss
+    * Nachteil - dataninkonsistenz möglich wenn protokoll nicht gut genug
+  * 1 dedizierte Server Partei welche alle Infos (schiffe positionen von beiden spielern) verwaltet
+    * Vorteil: - zentralisierte daten, dateninkonsistenz nicht möglich
+    * Nachteil - wer ist server? - vertrauensfrage
+
+## Brainstorm Messages Format
+
+Messages Aufbau Beispiel: "type; command; content"
+
+type bestimmt ob eine antwort erwartet wird oder nicht; command bestimmt um was für eine information es sich handelt; content ist der tatsächliche inhalt der information
+
+* types:
+  * request: es wird eine antwort erwartet
+  * response: dies ist eine antwort auf ein request
+  * info: erfordert keine antwort (viele meta-infos)
+* commands:
+  * shoot
+  * rdycheck
+  * forfeit
+  * status
+  * chatmsg
+  * semestercheck
+  * protocolcheck
+  * ...
+* content:
+  * bei shoot: koordiate
+  * bei chatmsg: nachricht
+  * bei readycheck: yes/no
+  * ...