Dokumentation Cluedo-Protokoll Protokoll Version 1.1 Sebastian Bschorer ∗ 1. Juni 2015 Änderungen gegenüber früheren Versionen • Nachrichten für den UDP-Handshake spezifiziert (vgl. 5.1). • Würfelwurf unter 9.2 als Array von zwei Würfeln festgelegt. • In der Spielerinfo wird die Kartenanzahl und die Spielfeldposition nicht mehr übergeben. • Stattdessen gibt es eine neue Version der Spielinfo (vgl. 6.6). • Tritt ein Zuschauer einem Spiel bei, erhält er eine Spielinfo-Nachricht (vgl. 8.3). • Der Aufbau einer "moved"-Nachricht wurde umgeschrieben. (vgl. 9.3) • Der Typ von "jsonID" unter 7.1 wurde als positive Ganzzahl spezifiziert. • Ein Client kann in demselben Spiel nicht Spieler und Zuschauer gleichzeitig sein. • Es wurde festgelegt, dass der Server ein Spiel beendet, falls ein Spieler das Spiel vorzeitig verlässt. 1 Grundlagen Die Daten werden über einen persistenten TCP-Stream übertragen. Der Port ist dabei nicht festgelegt. Das Protokoll verwendet einen Strom von JSON-Objekten, als Zeichensatz wird dabei UTF-8 verwendet. Objekte müssen dabei so kodiert werden, dass sie selbst keine Zeilenwechsel enthalten (optionale Zeilenwechsel müssen weggelassen werden, in Zeichenketten verwenden Sie "\n"). Ein Zeilenwechsel darf ausschließlich als Trennsymbol für Objekte verwendet werden (gestalten Sie aber ihren Parser hierfür möglichst tolerant, damit er auch mit fehlerhaften Nachrichten umgehen kann). Nach jedem Objekt müssen Sie einen Zeilenwechsel schicken. Unterschiedliche Nachrichtentypen sind durch sogenannte Wrapper-Objekte modelliert. Ein Objekt darf dabei stets nur eine Nachricht enthalten. ∗ Basierend auf dem Catan-Protokoll von Erich Schubert und Johannes Lohrer, WiSe 14/15 1 Die allgemeine Form einer Nachricht sieht folgendermaßen aus: { "type" : String, "Attribut" : "Wert", "2. Attribut" : "Wert" } Statt einem primitiven "Wert" können hier jedoch auch komplexere JSON-Objekte auftreten. Zeilenwechsel müssen bei der Serialisierung weggelassen oder kodiert werden, so dass die Nachricht dann beispielsweise wie folgt verschickt wird: {"type":String, "Attribut":"Wert","2. Attribut":"Wert"} 2 Kompatibilität Ihre Implementierung braucht nur die neueste Protokollversion unterstützen. Momentan handelt es sich dabei um Version "1.1". Ihr Client soll mit jedem Server funktionieren, der dieses Protokoll korrekt implementiert. Ebenso soll ihr Server (zumindest im Kompatibilitätsmodus) mit jedem Client spielbar sein. Insbesondere gilt dies für die KI-Spieler. Eigene Erweiterungen können Sie gerne vornehmen, allerdings muss ihr Client und Server über einen Kompatibilitätsmodus verfügen, der Interoperabilität gewährleistet. 3 Hinweise zu JSON • Verlassen Sie sich nicht darauf, dass ein einzelner read() Aufruf die vollständige Nachricht liefert. Das Betriebssystem kann die Nachrichten fragmentiert übertragen. Füllen Sie einen Puffer so lange, bis die empfangene Nachricht ein vollständiges JSON-Objekt ergibt (ein korrekter Server sollte anschließend auch einen Zeilenwechsel senden). • Die Verwendung von Bibliotheken wie JSON.org, Jackson, GSON, etc. hierfür ist sinnvoll. Keinesfalls sollte das Protokoll manuell per print erzeugt werden. • Beachten Sie die UTF-8 Kodierung von Umlauten. Empfehlenswert ist es, Ihr gesamtes Projekt in Eclipse als UTF-8 zu konfigurieren, um Probleme mit Windows zu vermeiden (OSX und Linux verwenden normalerweise bereits UTF-8). 4 Testserver Sobald im Cip-Pool ein Testserver zur Verfügung gestellt wird, erscheinen hier nähere Informationen dazu. 2 5 Verbindungsaufbau 5.1 UDP-Handshake Um das Verbinden zu einem Server im lokalen Netz zu vereinfachen, soll es möglich sein, einen UDPHandshake durchzuführen. Server und Client kommunizieren dabei über den Port 30303. Dieser ist laut IANA nicht zugewiesen und daher frei. Wenn ein UDP-Server gestartet wird, soll er sich mit folgender Nachricht über Broadcasts im Netzwerk bemerkbar machen: {"type":"udp server","group":String,"tcp port":int} Bei "group" handelt es sich dabei um den Gruppennamen. Laufende Clients können diese Nachricht über UDP empfangen und erhalten dadurch den "tcp port" für die TCP-Verbindung zum Server. (Dieser muss sich vom UDP-Port unterscheiden!) Die dazugehörige IP kann der Client aus dem eingehenden Datenpaket auslesen. Wird ein Client gestartet, kann er mittels folgender Nachricht nach Servern im lokalen Netz suchen: {"type":"udp client","group":String} Ein Server, der diese Nachricht empfängt, antwortet mit der bereits oben spezifizierten Nachricht. Mit der IP-Adresse und dem TCP-Port kann ein Client anschließend eine TCP-Verbindung zum Server aufbauen. Sind mehrere Server im lokalen Netz verfügbar, so kann der Client auswählen, zu welchem er sich verbinden möchte. Achtung: Die UDP-Broadcasts funktioniert nur im lokalen Netz. Ein Client sollte daher auch die Möglichkeit haben, IP-Adresse des Servers sowie den Port manuell einzugeben. 5.2 Login am Server Steht die TCP-Verbindung, so ist der Client zunächst noch nicht angemeldet. Der Server reagiert in diesem Zustand nur auf die Nachricht "login" und sendet selbst keinerlei Nachrichten an diesen Client. Eine "login" ist nach folgendem Schema aufgebaut: { "type" : "login", "nick" : String, "group" : String, "version" : "1.1", "expansions" : [ String ] } "nick" repräsentiert den Benutzername. Er darf jedes beliebige UTF-8-Zeichen enthalten, muss jedoch mindestens drei Zeichen lang sein. Bei "group" wird der Gruppenname erwartet. Bei "version" handelt es sich um die Protokollversionsnummer und wird als String repräsentiert. "expansions" enthält ein Array aller Erweiterungen, die der Client beherrscht. Werden keine Erweiterungen unterstützt, so kann dieser Eintrag in der Nachricht fehlen. Beispielhaft könnte eine login-Nachricht so 3 aussehen: { "type" : "login", "nick" : "Sepp", "group" : "TestendeTentakel", "version" : "1.1", "expansions" : [ "Chat", "HyperHyperFeature" ] } War der Login erfolgreich, so antwortet der Server diesem Client mit einer "login successful"Nachricht. { "type" : "login successful", "expansions" : [ String ], "nick array" : [ String ], "game array" : [ SpielInfo ] } Die Nachricht enthält als "expansions" die maximale Teilmenge der Fähigkeiten enthält, die sowohl Client als auch Server haben. In der Basisversion des Protokolls müssen sowohl Client als auch Server mindestens eine Chat-Fähigkeit haben, welche mit dem Namen "Chat" bezeichnet wird (vgl. 7.2). Die Nachricht besitzt ein String-Array, welches die Nutzernamen aller angemeldeten Clients enthält. Außerdem wird ein Array aus Spielinfos mit dieser Nachricht übertragen. Dieses Array soll alle momentan verfügbare Spiele des Servers enthalten. Der Aufbau einer Spielinfo ist unter 6.6 erklärt. Alle anderen angemeldeten Clients erhalten vom Server eine Nachricht der Form: {"type":"user added","nick":String} Wird ein Client beendet, sollte er sich beim Server abmelden mittels: {"type":"disconnect"} Bevor die Socket-Verbindung abgebrochen wird, reagiert der Server mit einem abschließenden: {"type":"disconnected","message":String} Alle anderen Clients werden darüber informiert: {"type":"user left","nick":String} Sollte es laufende Spiele geben, denen dieser Client beigetreten war, so beendet der Server das Spiel und schickt an alle Clients eine "game ended"-Nachricht (vgl. 8.6). 4 6 Objekte Nachrichten können verschiedene Objekte enthalten. Diese werden als JSON-Objekte übertragen. 6.1 Spielfeld Das Spielfeld ist folgendermaßen definiert und besitzt (mit Ausnahme des Schwimmbads) den gleichen Aufbau wie die älteren Brettspielversionen: y-Achse x-Achse 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 Eingangshalle Arbeitszimmer Salon S W S S S Bibliothek N O N O S Schwimmbad N W Billardzimmer W Speisezimmer S O N N N O Wintergarten W O Musikzimmer Küche 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 5 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 6.2 Felder Jedes Quadrat repräsentiert ein begehbares Feld und wird als ein Objekt mit einer "x"- und einer "y"-Koordinate repräsentiert: {"x" : 15, "y" : 16} Folgende Feldertypen sind definiert: • Auf hellen Feldern können sich die Spielfiguren bewegen. Auf jedem dieser Felder darf sich maximal eine Spielfigur gleichzeitig befinden. • Die sechs farbigen Felder bestimmen die Startpositionen der einzelnen Farben. Rot zum Beispiel besitzt die Startposition (16, 0). Abgesehen davon handelt es sich bei Ihnen um reguläre Spielfelder. • Die Felder mit dem Buchstaben darin symbolisieren eine Tür in einen Raum. Die vier Buchstaben N, O, S, W bestimmen die Himmelsausrichtung der Tür. Auf diesen Feldern dürfen sich beliebig viele Spielfiguren befinden. Das Arbeitszimmer kann beispielsweise nur von Süden aus, von (6, 4) → (6, 3) betreten werden. Die Felder (7, 3) und (6, 3) sind nicht benachbart. Landet eine Spielfigur auf einer Tür, so hat sie den Raum betreten. Räume an sich sind keine begehbaren Spielfelder, begrenzen aber durch ihre Anwesenheit das Spielfeld. Ein Raum ist definiert durch die Menge der Türen, die in diesen Raum führen. Der Spielfeldaufbau (samt Startpositionen) ist statisch und muss daher nicht über das Netzwerk kommuniziert werden. 6.3 Farben Es werden im Grundspiel sechs verschieden Farben unterstützt. In Nachrichten mit dem Attribut "color" darf die Farbe eine der folgenden Werte annehmen: "red", "yellow", "white", "green", "blue" oder "purple". 6.4 Karten Es wird zwischen drei Kartentypen unterschieden: person, weapon und room. Im Grundspiel dürfen folgende Werte angenommen werden: Personen: "red" "yellow" "white" "green" "blue" "purple" Fräulein Gloria Oberst von Gatow Frau Weiß Reverend Grün Baronin von Porz Professor Bloom 6 Waffen: "dagger" "candlestick" "revolver" "rope" "pipe" "spanner" Dolch Leuchter Revolver Seil Heizungsrohr Rohrzange Räume: "hall" "lounge" "diningroom" "kitchen" "ballroom" "conservatory" "billiard" "library" "study" "pool" Eingangshalle Salon Speisezimmer Küche Musikzimmer Wintergarten Billardzimmer Bibliothek Arbeitszimmer Schwimmbad Wird, wie unter 6.7 ein Array von Karten verlangt, so kann eine Karte entweder eine Person, eine Waffe oder ein Raum sein. 6.5 Aussagen Aussagen, wie sie bei Verdächtigungen und Anklagen verwendet werden, haben folgende Form: { "person" : Person, "weapon" : Waffe, "room" : Raum } Das Schwimmbad oder "pool" spielt eine Sonderrolle. In diesem Raum kann kein Mord stattfinden. Daher darf er auch nicht in einer Aussage auftauchen. 6.6 Spielinfo Eine Spielinfo soll den aktuellen Zustand über ein Spiel enthalten. Sie hat folgenden Aufbau: { "gameID" : int, "gamestate" : Spielzustand, "players" : [ Spielerinfo ], "watchers" : [ String ], "person positions" : [ Personenposition ] "weapon positions" : [ Waffenposition ] } 7 Spielzustand Der Spielzustand darf einen der Werte "not started", "started" oder "ended" annehmen. watchers enthält ein Array aus Nicknames derjeniger Clients, die diesem Spiel zuschauen. 6.7 Spielerinfo Die Informationen über einen Spieler sehen folgendermaßen aus: { "nick" : String, "color" : Farbe, "playerstate" : Spielerzustand } Wenn das Spiel noch nicht gestartet wurde, kann das Attribut "playerstate" auch fehlen oder null sein. Spielerzustand Der Spielerzustand gibt Aufschluss darüber, welche Aktion der Server von einem Spieler als nächstes erwartet. Folgende Statusmeldungen sind spezifiziert: "do nothing" "roll dice" "roll dice or use secret passage" "move" "suspect" "disprove" "end turn" Der Spieler wartet. Der Spieler darf würfeln oder anklagen. Der Spieler darf würfeln, den Geheimgang benutzen oder anklagen. Der Spieler muss seine Figur bewegen. Der Spieler darf eine Verdächtigung äußern. Der Spieler muss auf eine Verdächtigung reagieren. (Entweder widerlegen oder mitteilen, dass er nicht widerlegen kann.) Der Spieler darf anklagen oder den Spielzug beenden. 6.8 Personenposition Das Unwort Personenposition beschreibt nichts anderes als das Tupel aus Person und dem Feld, auf dem sich diese Person befindet. Sie hat diesen Aufbau: { "person" : Person, "field" : Feld } 6.9 Waffenposition Analog zu oben gibt eine Waffenposition wieder, wo eine Waffe auf dem Spielfeld liegt. Wichtig ist hierbei aber, dass sich Waffen nur in Räumen (also auf Türfeldern) befinden können. { "weapon" : Waffe, "field" : Feld } 8 7 Allgemeine Nachrichten 7.1 Bestätigungen und Fehler Der Server muss jede Aktion des Clients bestätigen. Wenn eine Aktion des Spielers nicht erfolgreich durchgeführt werden konnte, so muss ein Fehler verschickt werden (Sie werden sich aber nicht darauf verlassen können, dass jeder Server die gleichen Meldungen verschickt). Hat eine Aktion weitere Nachrichten zur Folge, so sollen erst die anderen Nachrichten verschickt werden, abschließend dann eine "ok"-Nachricht: {"type":"ok"} Kommt es bei der Verarbeitung einer einkommenden Nachricht vom Client zu einem Fehlerfall, so sendet der Server eine Nachricht vom Typ "error" an diesen Client zurück: {"type":"error","message":"..."} Diese Fehlermeldung werden zum Beispiel auch versandt, wenn ein Spieler einen ungültigen Spielzug durchführen will. Sie können nicht davon ausgehen, dass alle Server dieselben Fehlernachrichten versenden. Jeder beliebigen Nachricht an den Server kann ein Attribut "jsonID" vom Typ int beigefügt werden, wobei es sich dabei um einen positiven Wert handeln muss. Der Server verwertet diese ID nicht. Wenn sie allerdings in einer ankommenden Nachricht vorhanden ist, wird sie in einer "ok"- oder "error"-Nachricht als Attribut wieder an den Client zurückgeschickt. 7.2 Chat Jeder Server muss mindestens eine Chat-Erweiterung implementieren, die den Namen "Chat" besitzt und in den ""expansions" (vgl.5) aufgeführt wird. Um eine Chat-Nachricht an die Mitspieler zu senden verwenden Sie folgende Nachricht: {"type":"chat","message":String,"timestamp":Zeitstempel} Soll eine Nachricht nicht an alle, sondern nur an ein bestimmtes Spiel gesendet werden fügen Sie ein Attribut "gameID" mit der Spielnummer hinzu. Ist eine Nachricht nur einen bestimmten User gedacht, fügen Sie ein Attribut "nick" mit dem Nickname hinzu. Schickt ein Client eine Chatnachricht, so wird diese vom Server verteilt. { "type" : "chat", "sender" : String, "message" : String, "timestamp" : Zeitstempel } Verschickt der Server eine Chatnachricht, so fehlt das Attribut "sender". Für den Zeitstempel soll die String-Repräsentation eines java.time.LocalDateTime-Objekts verwendet werden, das die Form besitzt: "2015-04-08T15:16:23.42" 9 8 Konfiguration und Spielstart 8.1 Ein Spiel starten Der Server soll die Möglichkeit bieten, beliebig viele Spiele parallel verwalten zu können. Um ein neues Spiel zu erstellen, schickt der Client die Nachricht: { "type" : "create game", "color" : Farbe } Der Client tritt dem Spiel dabei gleichzeitig als Spieler mit der Farbe "color" bei. Der Server sendet daraufhin an alle Clients die Nachricht { "type" : "game created", "gameID" : int, "player" : SpielerInfo } 8.2 Einem Spiel als Spieler beitreten Anschließend können Clients folgendermaßen bei diesem Spiel beitreten: { "type" : "join game", "gameID" : int, "color" : Farbe } Der Server sendet daraufhin an alle Clients: { "type" : "player added", "gameID" : int, "player" : SpielerInfo } 8.3 Einem (laufenden) Spiel als Zuschauer beitreten Man kann einem Spiel auch als Zuschauer beitreten. Allerdings nicht als Spieler und Zuschauer gleichzeitig. { "type" : "watch game", "gameID" : int } 10 Der Server sendet daraufhin an alle Clients: { "type" : "watcher added", "gameID" : int, "nick" : String } Der neu zuschauende Spieler erhält anschließend noch eine Spielinfo: { "type" : "gameinfo", "game" : Spielinfo } 8.4 Ein Spiel verlassen Zuschauer und/oder Spieler können ein Spiel verlassen mit: {"type":"leave game","gameID":int} Daraufhin sendet der Server an alle Clients: { "type" : "left game", "gameID" : int, "nick" : String } Verlässt ein Spieler ein laufendes Spiel, beendet der Server dieses und schickt an alle Clients eine "game ended"-Nachricht (vgl. 8.6). Befinden sich in einem Spiel keine Spieler mehr, so löscht der Server das Spiel und sendet an die Clients: {"type":"game deleted","gameID":int} 8.5 Ein Spiel starten Befinden sich 3-6 Spieler im Spiel und jeder hat eine andere Farbe gewählt, so kann jeder beliebige dieser Spieler das Spiel starten mit: {"type":"start game","gameID":int} Im Erfolgsfall startet der Server das Spiel. Dabei wird jedem Spieler mitgeteilt, welche Karten er erhalten hat, z.B.: { "type" : "player_cards", "gameID" : int, "cards" : [ "ballroom", "purple", "kitchen", "diningroom", "candlestick", "white" ] } 11 Anschließend schickt der Server an alle Spieler (und Zuschauer) die Nachricht: { "type" : "game started", "gameID" : int, "gamestate" : "started", "order" : [ "Josephine", "Sepp", "Sams" ] } Wichtig dabei ist, dass die Liste "order" vom Server gemischt wurde und ab sofort die Spielerreihenfolge festlegt. Der Spieler, der den ersten Spielzug beginnt, erhält abschließend einen Statusupdate: { "type" : "stateupdate", "gameID" : int, "nick" : String, "playerstate" : Spielerzustand } 8.6 Spielende Das Spiel endet, sobald ein Spieler erfolgreich Anklage erhoben hat. Der Server versendet in diesem Fall folgende Nachricht: { "type" : "game ended", "gameID" : int, "nick" : String, "statement" : Aussage } "nick" ist dabei der Name des Gewinners. Die Aussage enthält die Lösung des Spiels. Haben alle Spieler falsche Anklage erhoben oder endet das Spiel vorzeitig, so wird eine ebenfalls "game ended"Nachricht verschickt, allerdings fehlt in dieser dann der "nick". 12 9 Nachrichten des Servers im Spiel 9.1 Statusupdate eines Spielers Wenn sich der Zustand eines Spielers ändert (beispielsweise er am Zug ist), so sendet der Server ein Statusupdate. Diese Nachricht enthält den betreffenden Spieler und sein neuer Status. Für alle anderen Spieler gilt ab dem Moment "do nothing". { "type" : "stateupdate", "gameID" : int, "nick" : String, "playerstate" : Spielerzustand } Diese Nachricht soll vom Server dazu genutzt werden, den allgemeinen Spielablauf (wer ist am Zug etc.) zu steuern, insbesondere für KI-Spieler. Gültige Statusmeldungen hierfür sind im Abschnitt 6.7 spezifiziert. Insbesondere ist ein Status wie bspw. "roll dice" als Aufforderung zu sehen, den nächsten Zug zu machen. 9.2 Würfeln Hat ein Spieler gewürfelt, so sendet der Server das Ergebnis. { "type" : "dice result", "gameID" : int, "result" : [ 3, 5 ] } 9.3 Spielfigur bewegen Hat ein Spieler seine Spielfigur bewegt, so sendet der Server die neue Position der Spielfigur: { "type" : "moved", "gameID" : int, "person position" : Personenposition } Falls der Spieler das Schwimmbad betreten hat, erhält er die Nachricht: { "type" : "poolcards", "cards" : [ Karte ] } 13 9.4 Verdacht geäußert Hat ein Spieler einen Verdacht geäußert, teilt der Server diesen an alle mit: { "type" : "suspicion", "gameID" : int, "statement" : Aussage } Anschließend fragt der Server den Spieler links vom aktiven Spieler mittels Statusupdate "disprove", ob er die Verdächtigung widerlegen kann. Dieser muss daraufhin antworten (vgl. 10.5). Konnte der Verdacht widerlegt werden, antwortet der Server mit dieser Nachricht: { "type" : "gameID" "nick" : "card" : "disproved", : int, String, Karte } "nick" ist in diesem Fall derjenige Spieler, der den Verdacht widerlegen konnte. Wichtig: Nur derjenige, der die Verdächtigung geäußert hat, bekommt diese Karte zu sehen. Bei den übrigen Spielern fehlt das Attribut "card". Konnte der gefragte Spieler den Verdacht nicht widerlegen, frägt der Server reihum den nächsten. Falls niemand den Verdacht widerlegen konnte, sendet der Server eine Nachricht im Format: { "type" : "no disprove", "gameID" : int } Abschließend erhält der aktive Spieler einen entsprechenden Spielerzustand. 9.5 Anklage erhoben Hat ein Spieler Anklage erhoben und lag dabei richtig, so endet das Spiel und der Server schickt die Nachricht "game ended" an alle Spieler (vgl. 8.6). War die Anklage falsch, so scheidet der Spieler als aktiver Spieler aus. Der Server sendet daraufhin diese Nachricht an alle Spieler: { "type" : "wrong accusation", "gameID" : int, "statement" : Aussage } 14 10 Nachrichten eines Spielers im Spiel 10.1 Würfeln Um zu Würfeln, sendet der Spieler folgende Nachricht: { "type" : "roll dice", "gameID" : int } 10.2 Spielfigur bewegen Um die eigene Spielfigur zu bewegen, wird an den Server folgende Nachricht geschickt: { "type" : "move", "gameID" : int, "field" : Feld } 10.3 Geheimgang nutzen Um den Geheimgang zu nutzen um in gegenüberliegende Räume zu gelangen, sendet der Spieler folgende Nachricht: { "type" : "secret passage", "gameID" : int } 10.4 Verdächtigung äußern Äußert der Spieler eine Verdächtigung, so hat eine entsprechende Nachricht an den Server diese Form: { "type" : "suspect", "gameID" : int, "statement" : Aussage } Da der Raum implizit durch die Position des Spielers abgeleitet werden kann, kann das Attribut "room" in diesem Statement fehlen. (Nach Regel darf ein Verdacht nur in dem Raum ausgesprochen werden, in welchem sich die eigene Spielfigur befindet). 15 10.5 Auf eine Verdächtigung reagieren Wird man aufgefordert eine Verdächtigung zu widerlegen und kann sie auch widerlegen, so muss man dies auch. Eine Nachricht hat dann diese Form: { "type" : "disprove", "gameID" : int, "card" : Karte } Kann eine Verdächtigung nicht widerlegt werden, so fehlt das Attribut "card". 10.6 Spielzug beenden Der Spielzug kann beendet werden mit der Nachricht: {"type":"end turn","gameID":int} 10.7 Anklagen Eine Anklage wird folgendermaßen codiert: { "type" : "accuse", "gameID" : int, "statement" : Aussage } Anklagen sind an keinen Raum gebunden, daher darf hier (im Gegensatz zur Verdächtigung) "room" als Argument nicht fehlen. 16 11 Hinweise Hinweise zu den Spielregeln: • Es gibt verschiedene Cluedo-Auflagen, die sich teilweise in ihren Regeln unterscheiden. Für dieses Protokoll verwenden Sie die Anleitung, die Sie ebenfalls erhalten haben. • Auch wenn die Regeln in der Grundversion bindend sind und so auch umgesetzt werden müssen, können und dürfen Sie gerne weitere, eigene Spielmodi einbauen. Achten Sie darauf, dass diese in den "expansions" erscheinen. • Der Notizblock wird in diesem Protokoll mit keinem Wort erwähnt! Selbstverständlich sollen die Clients die Möglichkeit besitzen, sich auf einem „Block“ Notizen zu machen. Diese Notizen müssen aber nicht an den Server übermittelt werden. Hinweise zur Umsetzung in Java: • Verwenden sie für JSON eine der vielen Bibliotheken, wie bspw. org.json, GSON oder Jackson. • Konfigurieren Sie ihr Java-Projekt mit dem Zeichensatz UTF-8 (Projekteinstellungen). So vermeiden Sie Zeichensatzprobleme mit unterschiedlichen Betriebssystemen (Mac und Linux verwenden i.d.R. UTF-8, Windows die Windows-1252-Kodierung) • Halten Sie sich an Java-Konventionen, insbesondere was Methoden-, Klassen-, Variablen- und Konstantennamen betrifft. Vermeiden Sie dabei Sonderzeichen. • Verwenden Sie Konstanten für häufige Zeichenketten, insbesondere für das Protokoll. • Beobachten Sie ihre Systemlast. Wenn ihr Spiel eine moderne CPU zu 100% auslastet, haben Sie eine fehlerhafte Schleife (Endlosschleife?) irgendwo in Ihrem Programm. Verwenden Sie jvisualvm um herauszufinden, wo ihr Programm zu viel Rechenzeit verbraucht. 17
© Copyright 2024 ExpyDoc