Dokumentation Cluedo-ProtokollProtokoll Version 1.1

Sebastian Bschorer ∗

1. Juni 2015

Änderungen gegenüber früheren Versionen

• Nachrichten für den UDP-Handshake spezi�ziert (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 spezi�ziert.• 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 ver-

lässt.

1 Grundlagen

Die Daten werden über einen persistenten TCP-Stream übertragen. Der Port ist dabei nicht festge-legt. Das Protokoll verwendet einen Strom von JSON-Objekten, als Zeichensatz wird dabei UTF-8verwendet. Objekte müssen dabei so kodiert werden, dass sie selbst keine Zeilenwechsel enthalten(optionale Zeilenwechsel müssen weggelassen werden, in Zeichenketten verwenden Sie "\n"). EinZeilenwechsel darf ausschließlich als Trennsymbol für Objekte verwendet werden (gestalten Sie aberihren 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. Zeilen-wechsel müssen bei der Serialisierung weggelassen oder kodiert werden, so dass die Nachricht dannbeispielsweise 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 essich dabei um Version "1.1".Ihr Client soll mit jedem Server funktionieren, der dieses Protokoll korrekt implementiert. Ebenso sollihr Server (zumindest im Kompatibilitätsmodus) mit jedem Client spielbar sein. Insbesondere gilt diesfür die KI-Spieler.Eigene Erweiterungen können Sie gerne vornehmen, allerdings muss ihr Client und Server über einenKompatibilitä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 lie-fert. Das Betriebssystem kann die Nachrichten fragmentiert übertragen. Füllen Sie einen Pu�erso lange, bis die empfangene Nachricht ein vollständiges JSON-Objekt ergibt (ein korrekterServer sollte anschließend auch einen Zeilenwechsel senden).

• Die Verwendung von Bibliotheken wie JSON.org, Jackson, GSON, etc. hierfür ist sinnvoll. Kei-nesfalls sollte das Protokoll manuell per print erzeugt werden.

• Beachten Sie die UTF-8 Kodierung von Umlauten. Empfehlenswert ist es, Ihr gesamtes Projektin Eclipse als UTF-8 zu kon�gurieren, um Probleme mit Windows zu vermeiden (OSX und Linuxverwenden normalerweise bereits UTF-8).

4 Testserver

Sobald im Cip-Pool ein Testserver zur Verfügung gestellt wird, erscheinen hier nähere Informationendazu.

2

5 Verbindungsaufbau

5.1 UDP-Handshake

Um das Verbinden zu einem Server im lokalen Netz zu vereinfachen, soll es möglich sein, einen UDP-Handshake durchzuführen. Server und Client kommunizieren dabei über den Port 30303. Dieser istlaut IANA nicht zugewiesen und daher frei.Wenn ein UDP-Server gestartet wird, soll er sich mit folgender Nachricht über Broadcasts im Netz-werk 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 ein-gehenden 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 spezi�zierten Nachricht.Mit der IP-Adresse und dem TCP-Port kann ein Client anschließend eine TCP-Verbindung zum Serveraufbauen. Sind mehrere Server im lokalen Netz verfügbar, so kann der Client auswählen, zu welchemer sich verbinden möchte.Achtung: Die UDP-Broadcasts funktioniert nur im lokalen Netz. Ein Client sollte daher auch die Mög-lichkeit 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 indiesem Zustand nur auf die Nachricht "login" und sendet selbst keinerlei Nachrichten an diesenClient. 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 je-doch 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 un-terstü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 sowohlClient als auch Server haben. In der Basisversion des Protokolls müssen sowohl Client als auch Ser-ver 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 mo-mentan 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 Spielund 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 de�niert und besitzt (mit Ausnahme des Schwimmbads) den gleichenAufbau wie die älteren Brettspielversionen:

S

S S

WS

N

W

NN N

OWO

N

O

O

S

NO

S

W

Arbeitszimmer Eingangshalle Salon

Speisezimmer

KücheMusikzimmerWintergarten

Billardzimmer

Bibliothek

Schwimmbad

0

0

1

1

2

2

3

3

4

4

5

5

6

6

7

7

8

8

9

9

10

10

11

11

12

12

13

13

14

14

15

15

16

16

17

17

18

18

19

19

20

20

21

21

22

22

23

23

0 01 12 23 34 45 56 67 78 89 9

10 1011 1112 1213 1314 1415 1516 1617 1718 1819 1920 2021 2122 2223 2324 24

x-Achse

y-Ac

hse

5

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 de�niert:• Auf hellen Feldern können sich die Spiel�guren bewegen. Auf jedem dieser Felder darf sich

maximal eine Spiel�gur gleichzeitig be�nden.• Die sechs farbigen Felder bestimmen die Startpositionen der einzelnen Farben. Rot zum Bei-

spiel besitzt die Startposition (16, 0). Abgesehen davon handelt es sich bei Ihnen um reguläreSpielfelder.

• Die Felder mit dem Buchstaben darin symbolisieren eine Tür in einen Raum. Die vier Buch-staben N, O, S, W bestimmen die Himmelsausrichtung der Tür. Auf diesen Feldern dürfen sichbeliebig viele Spiel�guren be�nden.Das Arbeitszimmer kann beispielsweise nur von Süden aus, von (6, 4) → (6, 3) betreten wer-den. Die Felder (7, 3) und (6, 3) sind nicht benachbart.Landet eine Spiel�gur auf einer Tür, so hat sie den Raum betreten.

Räume an sich sind keine begehbaren Spielfelder, begrenzen aber durch ihre Anwesenheit das Spiel-feld. Ein Raum ist de�niert 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 kom-muniziert 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ürfenfolgende Werte angenommen werden:Personen:"red" Fräulein Gloria"yellow" Oberst von Gatow"white" Frau Weiß"green" Reverend Grün"blue" Baronin von Porz"purple" Professor Bloom

6

Wa�en:"dagger" Dolch"candlestick" Leuchter"revolver" Revolver"rope" Seil"pipe" Heizungsrohr"spanner" Rohrzange

Räume:

"hall" Eingangshalle"lounge" Salon"diningroom" Speisezimmer"kitchen" Küche"ballroom" Musikzimmer"conservatory" Wintergarten"billiard" Billardzimmer"library" Bibliothek"study" Arbeitszimmer"pool" Schwimmbad

Wird, wie unter 6.7 ein Array von Karten verlangt, so kann eine Karte entweder eine Person, eineWa�e 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 statt�nden.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 nullsein.

Spielerzustand

Der Spielerzustand gibt Aufschluss darüber, welche Aktion der Server von einem Spieler als näch-stes erwartet. Folgende Statusmeldungen sind spezi�ziert:"do nothing" Der Spieler wartet."roll dice" Der Spieler darf würfeln oder anklagen."roll dice or use secret passage" Der Spieler darf würfeln, den Geheimgang

benutzen oder anklagen."move" Der Spieler muss seine Figur bewegen."suspect" Der Spieler darf eine Verdächtigung äußern."disprove" Der Spieler muss auf eine Verdächtigung reagieren.

(Entweder widerlegen oder mitteilen,dass er nicht widerlegen kann.)

"end turn" 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, aufdem sich diese Person be�ndet. Sie hat diesen Aufbau:

{ "person" : Person, "field" : Feld }

6.9 Wa�enposition

Analog zu oben gibt eine Wa�enposition wieder, wo eine Wa�e auf dem Spielfeld liegt. Wichtig isthierbei aber, dass sich Wa�en nur in Räumen (also auf Türfeldern) be�nden 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 erfolgreichdurchgeführt werden konnte, so muss ein Fehler verschickt werden (Sie werden sich aber nicht daraufverlassen können, dass jeder Server die gleichen Meldungen verschickt). Hat eine Aktion weitereNachrichten zur Folge, so sollen erst die anderen Nachrichten verschickt werden, abschließend danneine "ok"-Nachricht:

{"type":"ok"}

Kommt es bei der Verarbeitung einer einkommenden Nachricht vom Client zu einem Fehlerfall, sosendet 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 Spielzugdurchführen will. Sie können nicht davon ausgehen, dass alle Server dieselben Fehlernachrichtenversenden.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" besitztund 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 Sieein Attribut "gameID" mit der Spielnummer hinzu. Ist eine Nachricht nur einen bestimmten Usergedacht, 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 verwen-det 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 einneues 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 sendetdaraufhin 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 gleich-zeitig.{

"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).Be�nden sich in einem Spiel keine Spieler mehr, so löscht der Server das Spiel und sendet an dieClients:

{"type":"game deleted","gameID":int}

8.5 Ein Spiel starten

Be�nden sich 3-6 Spieler im Spiel und jeder hat eine andere Farbe gewählt, so kann jeder beliebigedieser 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 er-halten 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 Spielerreihen-folge 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 diesemFall 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 alleSpieler 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 einStatusupdate. Diese Nachricht enthält den betre�enden Spieler und sein neuer Status. Für alle anderenSpieler 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 Zugetc.) zu steuern, insbesondere für KI-Spieler. Gültige Statusmeldungen hierfür sind im Abschnitt 6.7spezi�ziert. Insbesondere ist ein Status wie bspw. "roll dice" als Au�orderung zu sehen, den näch-sten 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 Spiel�gur bewegt, so sendet der Server die neue Position der Spiel�gur:

{"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 derVerdacht widerlegt werden, antwortet der Server mit dieser Nachricht:

{"type" : "disproved","gameID" : int,"nick" : String,"card" : Karte

}

"nick" ist in diesem Fall derjenige Spieler, der den Verdacht widerlegen konnte. Wichtig: Nur der-jenige, der die Verdächtigung geäußert hat, bekommt diese Karte zu sehen. Bei den übrigen Spielernfehlt 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 dieNachricht "game ended" an alle Spieler (vgl. 8.6).War die Anklage falsch, so scheidet der Spieler als aktiver Spieler aus. Der Server sendet daraufhindiese 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 Spiel�gur 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 Spielerfolgende 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 ausgesprochenwerden, in welchem sich die eigene Spiel�gur be�ndet).

15

10.5 Auf eine Verdächtigung reagieren

Wird man aufgefordert eine Verdächtigung zu widerlegen und kann sie auch widerlegen, so muss mandies 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-Au�agen, 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üs-

sen, können und dürfen Sie gerne weitere, eigene Spielmodi einbauen. Achten Sie darauf, dassdiese in den "expansions" erscheinen.

• Der Notizblock wird in diesem Protokoll mit keinem Wort erwähnt! Selbstverständlich sollendie Clients die Möglichkeit besitzen, sich auf einem „Block“ Notizen zu machen. Diese Notizenmü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.• Kon�gurieren Sie ihr Java-Projekt mit dem Zeichensatz UTF-8 (Projekteinstellungen). So ver-

meiden Sie Zeichensatzprobleme mit unterschiedlichen Betriebssystemen (Mac und Linux ver-wenden i.d.R. UTF-8, Windows die Windows-1252-Kodierung)

• Halten Sie sich an Java-Konventionen, insbesondere was Methoden-, Klassen-, Variablen- undKonstantennamen betri�t. Vermeiden Sie dabei Sonderzeichen.

• Verwenden Sie Konstanten für häu�ge 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 Siejvisualvm um herauszu�nden, wo ihr Programm zu viel Rechenzeit verbraucht.

17