Category Archives: Software Engineering I

Hinweis zum JSON Protokoll

Software Engineering I

In der Google Group kam die Frage nach “invalidem” JSON auf: Invalides JSON senden?. JSON Bibliotheken verwenden statt der folgenden Darstellung

Action Keys Beispiel Bemerkung
MESSAGE message, (audience)?, (recipient)? {"@action":"MESSAGE","properties":{"entry":{"key":"message","value":"Hallo"},"entry":{"key":"audience","value":"USER"},"entry":{"key":"recipient","value":"zenobios"}}} Verschickt eine Nachricht an alle oder den angegebenen User/Team. Der Parameter audience erlaubt folgende Werte:ALL, USER, TEAM.

Folgende Kombinationen von audience und recipient sind möglich:

  • audience: leer, recipient:leer -> Nachricht wird an alle User im Spiel geschickt
  • audience: leer, recipient:nicht leer -> Nachricht wird nicht verschickt
  • audience: ALL, recipient:leer -> Nachricht wird an alle User im Spiel geschickt
  • audience: ALL, recipient:nicht leer-> Nachricht wird nicht verschickt
  • audience: USER, recipient:leer -> Nachricht wird nicht verschickt
  • audience: USER, recipient:username -> Nachricht wird an user username verschickt
  • audience: TEAM, recipient:leer -> Nachricht wird an das eigene Team geschickt
  • audience: TEAM, recipient:teamname -> Nachricht wird an das Team teamname verschickt

Events, die durch diesen Command ausgelöst werden übergeben die Art der Message mit, um im Client eine Unterscheidung durchführen zu können. Mögliche Werte sind:ERROR, MESSAGE, PUBLIC_MESSAGE, USER_MESSAGE, TEAM_MESSAGE

in der Regel die Darstellung

Action Keys Beispiel Bemerkung
MESSAGE message, (audience)?, (recipient)? {“@action”:”MESSAGE”,”@id”:”0″,”properties”:{“entry”:[{"key":"message","value":"Hallo"},{"key":"audience","value":"USER"},{"key":"recipient","value":"zenobios"}]}} Verschickt eine Nachricht an alle oder den angegebenen User/Team. Der Parameter audience erlaubt folgende Werte:ALL, USER, TEAM.

Folgende Kombinationen von audience und recipient sind möglich:

  • audience: leer, recipient:leer -> Nachricht wird an alle User im Spiel geschickt
  • audience: leer, recipient:nicht leer -> Nachricht wird nicht verschickt
  • audience: ALL, recipient:leer -> Nachricht wird an alle User im Spiel geschickt
  • audience: ALL, recipient:nicht leer-> Nachricht wird nicht verschickt
  • audience: USER, recipient:leer -> Nachricht wird nicht verschickt
  • audience: USER, recipient:username -> Nachricht wird an user username verschickt
  • audience: TEAM, recipient:leer -> Nachricht wird an das eigene Team geschickt
  • audience: TEAM, recipient:teamname -> Nachricht wird an das Team teamname verschickt

Events, die durch diesen Command ausgelöst werden übergeben die Art der Message mit, um im Client eine Unterscheidung durchführen zu können. Mögliche Werte sind:ERROR, MESSAGE, PUBLIC_MESSAGE, USER_MESSAGE, TEAM_MESSAGE

Die vom Server verwendete JSON Bibliothek Jersey versteht beide Formate! Dennoch wurde das Beispiel in der Beschreibung vom Serverprotokoll angepasst!

Gruß,
Andreas

Einheitliche und automatische Formatierung des Quelltextes

Software Engineering I, SS13

Da es doch nun mehrfach zu Rückfragen bzgl. des “Stehlens” von Quelltext (durch Formatierung) gekommen ist, hier eine Möglichkeit dieses Problem zumindest teilweise in den Griff zu bekommen.

How-To: Code-Formatierungstemplate setzen und beim Speichern automatisch anwenden

  1. Stellt sicher, dass alle Teammitglieder das gleiche Formatter Template benutzen.

    Eclipse Formatter Preference

  2. Aktiviert das automatische Formatieren des Quellcodes beim Speichern:

    Eclipse Save Action Preference

Hilfe zu Datenmodell

Software Engineering I

Als kleine Hilfe zum Verständnis des Datenmodells auf dem Server eine kurze Erklärung zu den Verbindungen zwischen den Feldern:

Jedes Feld ist auf dem Server ein Objekt des Typs “Field”.
Die Verbindung zwischen drei Feldern, also die Stelle an der bspw. Siedlungen gebaut werden, werden bei uns über ein Objekt des Typs “Intersection” abgebildet. Ein solche Objekt kennt über die “fields”-Referenz die drei angrenzenden Felder.
Die Verbindung zwischen zwei Feldern, also die Stelle an der Straßen gebaut werden, werden bei uns über zwei Objekte des Typs “Border” abgebildet. Für jedes Feld existiert ein eigenes Border-Objekt. Zusammengehörige Objekte werden über die bidirektionale Assoziation “connectedTo” verknüpft.
Die gerade beschriebene Struktur ist auch in folgendem Bild noch einmal visualisiert.

Siedler

Siedler von Catan Kartenformat

Software Engineering I, SS13

Eine dem vorgegebenen Format entsprechende Karte, ist unter Balanced zu finden. Die dazu passende Karte findet ihr auch hier auf Seite 2.

HINWEIS: Um sicherzustellen, dass eure selbst erstellten Karten auch mit unserem Server kompatibel sind, solltet ihr euch genau an das vorgegebene Format halten.

Die einzelnen Fragmente haben folgende Bedeutung:

### 
### BALANCED
###

Hier wird der Name der Karte spezifiziert.

# VERSION
VERSION: 1

Hier wird die Version der Karte bestimmt.

# OWNER
OWNER: SE

Hier ist der Besitzer der Karte zu finden (Team).

 

Um die einzelnen Felder des Spielfeldes zu spezifizieren, müssen sie zeilenweise nach folgendem Muster aufgeführt werden:

# {id};{type};{rotation};({direction},{id};)+

Mit folgendem Beispiel werden die einzelnen Bestandteile erklärt:

1;WATER;0;SE,3;S,5;SW,2;
  • 1 ist die {id} des Feldes. Jedes Feld muss eine eigene ID besitzen. Ob diese aus einer oder mehrerer Zahlen oder Buchstaben besteht ist hierbei freigestellt. Sonderzeichen sind nicht erlaubt. Im Anschluss an die {id} muss ein ; folgen.
  • WATER ist der Typ des Feldes. Im Anschluss an den {type} muss ein ; folgen. Folgende Typen sind zulässig:
    • PASTURE
    • HILL
    • MOUNTAIN
    • FIELD
    • FOREST
    • DESERT
    • WATER
    • PORT_3TO1
    • PORT_LUMBER
    • PORT_ORE
    • PORT_BRICK
    • PORT_WOOL
    • PORT_GRAIN
    • BARBARIAN_START
    • BARBARIAN_END
  •  0 ist die Drehung des Feldes. Dieser Wert ist ausschließlich bei den verschiedenen Häfen und bei den Feldern des Barbaren relevant. Bei allen übrigen sollte dieser Wert auf 0 gesetzt werden.
  • S,5;SW,2; beschreibt die Nachbarn dieses Feldes. Dazu werden komma-separierte Paare von Himmelsrichtung und {id} des dort anliegenden Feldes mittels ; voneinander getrennt.
    • Erlaubte Himmelsrichtungen: N, NW, SW, S, SE, NR
    • Felder müssen immer gegenseitig aufeinander Verweisen um eine valide Karte zu ergeben, d.h. in der Definition für das Feld mit der {id} 5, muss bei den Nachbarn N,1 aufgeführt werden.