All posts by Andreas Koch

Seminar, SS14

These are the requirements and outline for writing a review:

  • Based on these review examples:
  • Reviewer information
    • Lastname,Firstname, Mail adress
  • Reviewers Experience
    • 1-5 (1 never heard about that before, 5 I’m an expert)
  • Rating
    • +3 to -3:
      • +3 = Strong accept
      • +2 = accept
      • +1 = weak accept
      •   0 = borderline (I don’t care, let the others decide)
      • -1 = weak reject
      • -2 = reject
      • -3 = strong reject
  • Evaluation
    • Short summary,
      • 3-4 sentences, approx. length of an abstract
    • Content:
      • some paragraphs (depends on length of paper), (bullet-point style is ok)
      • Understandable?
      • Enough (8-10 pages, more is ok)?
      • The paper should either provider a good overview OR should be focused on a dedicated subject.
    • Well written?
      • 1-2 sentences (depends on length of paper)
      • examples for bad phrases
    • Layout, format
      • 1 -2 sentence
  • Optional: Comments for the PC (will not be sent to the authors)
    • Some sentences
    • Things you want the program committee to know, e.g.

Detailed information will be given at the event on Monday, 13th of January 2014.

Important: Deadline for reviews is Friday, 27th of June, 11:59 p.m. Later submission will result in a deduction of points.

Software Engineering I, SS14

Ein Spielzug in Carcassonne läuft in drei Schritten ab:

  1. Karte ziehen
  2. Karte ausspielen
  3. Spielstein auslegen

Für jeden dieser drei Schritte gibt es jeweils einen eigenen Command. Der dritte Schritt kann alternativ mit END_TURN übersprungen werden.

Alle Änderungen am Datenmodell des Server, die diese Commands auslösen werden wie gewohnt über JSON Event an alle Teilnehmer eines Spiels übertragen. Im Folgenden soll verdeutlicht werden, wie ausgespielte Karten und Spielsteine lokalisiert werden können.

 

Wo und wie werden Karten angelegt?

Zu Beginn eines Zuges muss zuerst eine Karte gezogen werden. In diesem Beispiel wird eine Karte vom Typ A gezogen:

Single card A

 

 

 

 

 

 

 

Die hierzu verschickten Events sind vergleichbar zu folgendem:

  1. {“@ts”:”1402044757843″,”@src”:”Field@24640285″,”@prop”:”rotation”,”@nv”:”R0″}
  2. {“@ts”:”1402044757843″,”@src”:”Field@24640285″,”@prop”:”name”,”@nv”:”A”}
  3. {“@ts”:”1402044757843″,”@src”:”Field@24640285″,”@prop”:”meeplePositions”,”@nv”:”MeeplePosition@21e17c6d”}
  4. {“@ts”:”1402044757843″,”@src”:”Field@24640285″,”@prop”:”meeplePositions”,”@nv”:”MeeplePosition@5aafe97b”}
  5. {“@ts”:”1402044757843″,”@src”:”Field@24640285″,”@prop”:”meeplePositions”,”@nv”:”MeeplePosition@5309b8c0″}
  6. {“@ts”:”1402044757843″,”@src”:”MeeplePosition@21e17c6d”,”@prop”:”field”,”@nv”:”Field@24640285″}
  7. {“@ts”:”1402044757843″,”@src”:”MeeplePosition@21e17c6d”,”@prop”:”name”,”@nv”:”1″}
  8. {“@ts”:”1402044757843″,”@src”:”MeeplePosition@21e17c6d”,”@prop”:”meeple”}
  9. {“@ts”:”1402044757843″,”@src”:”MeeplePosition@5aafe97b”,”@prop”:”field”,”@nv”:”Field@24640285″}
  10. {“@ts”:”1402044757843″,”@src”:”MeeplePosition@5aafe97b”,”@prop”:”name”,”@nv”:”2″}
  11. {“@ts”:”1402044757843″,”@src”:”MeeplePosition@5aafe97b”,”@prop”:”meeple”}
  12. {“@ts”:”1402044757843″,”@src”:”MeeplePosition@5309b8c0″,”@prop”:”field”,”@nv”:”Field@24640285″}
  13. {“@ts”:”1402044757843″,”@src”:”MeeplePosition@5309b8c0″,”@prop”:”name”,”@nv”:”3″}
  14. {“@ts”:”1402044757843″,”@src”:”MeeplePosition@5309b8c0″,”@prop”:”meeple”}
  15. {“@ts”:”1402044757843″,”@src”:”Field@24640285″,”@prop”:”game”}
  16. {“@ts”:”1402044757845″,”@src”:”CarcassonneGame@35ba04f8″,”@prop”:”drawnCard”,”@nv”:”Field@24640285″}

Der Event in Zeile zwei verdeutlicht welche Art von Karte gerade gezogen wurde, in diesem Fall eine Karte vom Typ A. Alle Zuordnungen von Spielkarten und Name sind hier zu finden. Die Events in den Zeilen 7, 10 und 13 zeigen die Zuordnung eines Spielsteinposition-Objekts und seinem Namen. Bei Karten vom Typ A gibt es drei Positionen, 1 entspricht der Wiese, 2 dem Kloster und 3 der Straße.

Wird nun diese Karte südlich und um 180 Grad gedreht an der bereits liegenden Startkarte (Typ D) ausgespielt, folgen Events vergleichbar zu folgendem:

  1. {“@ts”:”1402044784348″,”@src”:”OrientationToFieldEntry@34592e88″,”@prop”:”key”,”@nv”:”SOUTH”}
  2. {“@ts”:”1402044784348″,”@src”:”OrientationToFieldEntry@34592e88″,”@prop”:”value”,”@nv”:”Field@24640285″}
  3. {“@ts”:”1402044784348″,”@src”:”Field@5e223ed2″,”@prop”:”neighbors”,”@nv”:”OrientationToFieldEntry@34592e88″}
  4. {“@ts”:”1402044784349″,”@src”:”OrientationToFieldEntry@6912610d”,”@prop”:”key”,”@nv”:”EAST”}
  5. {“@ts”:”1402044784349″,”@src”:”OrientationToFieldEntry@6912610d”,”@prop”:”value”,”@nv”:”Field@5e223ed2″}
  6. {“@ts”:”1402044784349″,”@src”:”Field@24640285″,”@prop”:”neighbors”,”@nv”:”OrientationToFieldEntry@6912610d”}
  7. {“@ts”:”1402044784350″,”@src”:”Field@24640285″,”@prop”:”game”,”@nv”:”CarcassonneGame@35ba04f8″}
  8. {“@ts”:”1402044784351″,”@src”:”Field@24640285″,”@prop”:”rotation”,”@nv”:”R180″,”@ov”:”R0″}
  9. {“@ts”:”1402044784351″,”@src”:”Field@24640285″,”@prop”:”name”,”@nv”:”A”}

Die Nachbar-Beziehung zwischen Feldern wird mit dem Hilfsobjekt OrientationToFieldEntry dargestellt. In diesem Beispiel wird in den Zeilen 1-3 gesendet, dass Feld Field@24640285 (Neues Feld) im Süden von Feld Field@5e223ed2 (Startfeld) angelegt wird. Die Zeilen 4-6 legen entsprechend die Rückrichtung an. Zeile 8 zeigt zudem die Rotation (R180) auf, in der das neue Feld angelegt wird.

Wird schließlich noch ein Spielstein auf die neue Karte gestellt, folgen Events ähnlich zu:

  1. {“@ts”:”1402045113008″,”@src”:”Meeple@46e3644a”,”@prop”:”meeplePosition”,”@nv”:”MeeplePosition@21e17c6d”}
  2. {“@ts”:”1402045113009″,”@src”:”MeeplePosition@21e17c6d”,”@prop”:”meeple”,”@nv”:”Meeple@46e3644a”}

Der Spielstein Meeple@46e3644a wird demnach auf die Position MeeplePosition@21e17c6d gestellt. Zeile 7 im ersten Eventblock zeigt, dass dies Position 1, also der Wiese, entspricht.

 

Software Engineering I, SS14

Der Server spricht generell ein zeilenbasiertes String Protokoll. Daher kann man eine telnet Verbindung benutzen um das Protokoll zu erkunden. Nach dem öffnen einer Konsole und der Eingabe von

 telnet se1.cs.uni-kassel.de 5000

kann man mit HELP eine Liste aller verfügbaren Befehle abrufen.

Allgemeine Informationen

  • Um sich beim Server anzumelden, benötigt man zunächst einen eigenen Login. Dieser ist identisch mit eurem Jira-Login.
  • Jedes erfolgreiche Kommando wird vom Server mit einem OK beendet. Fehler werden mit einer Zeile beantwortet die mit ERROR beginnt.
  • Der Server kommuniziert durch zwei verschiedene Protokollarten:
    • “Klartextprotokoll”: Bei einloggen und in der Lobby verwendet der Server ein simples “Klartextprotokoll” um mit seinen Clients zu kommunizieren.
    • JSON-Protokoll: Nach einem erfolgreichen JOIN GAME Kommando das mit OK bestätigt wurde wechselt der Server in ein JSON basiertes Protokoll, bei dem er JSON codierte Events verschickt und JSON codierte Commands erwartet.
  • Um einen Timeout zu vermeiden sollte vom Client in regelmäßigen Abständen ein NOOP geschickt werden.

Klartextprotokoll

Sobald man eine Verbindung zum Server aufgebaut hat, kommuniziert dieser mit einem simplen Klartextprotokoll mit dem Client. Nicht alle Befehle sind überall verfügbar. Eine genaue Auflistung inkl. Gruppierung der Befehle liefert der HELP Befehl. Hier eine Übersicht über die verschiedenen Befehle:

  • Immer:
    • HELP <command>
    • NOOP
  • Nach der Begrüßung vom Server:
    • LOGIN (<login>|<email>) <password>
    • LOGOUT
  • Nach dem Anmelden:
    • LIST USERS
    • LIST GAMES
    • CREATE GAME <gamename> -maxPlayers <count> (-testgame)?
    • JOIN GAME <gamename> (-visitor [true|false])?
    • MSG (ALL | ( ( USER | TEAM ) <recipient> ) )? <message>
    • CREATE TESTPLAYER
      Beispiel:

      SE1-Server 1.0, Timeout set to 3600000ms
      login akoch ******
      USER NICK=akoch EMAIL=andreas.koch@cs.uni-kassel.de ROLE=SE
      TEAM NAME=SE ID=3fb6101e
      OK
      help
      Available commands after greeting: LOGIN, LOGOUT
      User commands: ID, LIST USERS
      Game management: LIST MAPS, CREATE GAME, LIST GAMES, JOIN GAME, UPLOAD MAP, DOWNLOAD MAP
      Team management: LIST TEAMS
      Other commands: CREATE TESTPLAYER, MSG, CHANGELOG, UPLOAD MAP, NOOP, HELP
      send 'HELP <command>' for details
      a successfull command will be acknowledged with an 'OK' line
      an unsuccessfull command will be acknowledged with an 'ERROR' line
      OK
      help create testplayer
      Creates a temporary user e.g. for testing purposes. This user exists at least for 24h hours or until the next server restart
      Usage: "CREATE TESTPLAYER"
      OK
      create testplayer
      TEMPORARY USER NICK=tempUser0 PASSWORD=ys8ufm
      OK

JSON Protokoll

Das Ingame JSON Protokoll kennt in Serverrichtung Commands und in Clientrichtung Events.

Commands

Die Commands müssen mindestens ein action Attribut enthalten welches folgende Werte annehmen kann (keys in Klammern sind optional):

Action Keys Beispiel Bemerkung
CHANGE_USER_COLOR color {"@action":"CHANGE_USER_COLOR","properties":{"entry":{"key":"color","value":"FFFF00"}}} Ändert die Userfarbe.
DRAW_CARD keiner {"@action":"DRAW_CARD"} Zieht eine Karte.
PLACE_CARD neighbor, orientation, rotation {"@action":"PLACE_CARD","properties":{"entry":[{"key":"neighbor","value":"Field@b2d54e6"},{"key":"orientation","value":"NORTH"},{"key":"rotation","value":"R90"}]}} Legt die zuletzt gezogene Karte neben der spezifizierten Karte (neighbor) an die gewünschte Seite (orientation) mit der gewünschten Rotation (rotation) aus.
Für orientation sind folgende Werte möglich: NORTH, EAST, SOUTH, WEST
Für rotation sind folgende Werte möglich: R0, R90, R180, R270
PLACE_MEEPLE id, position {"@action":"PLACE_MEEPLE","properties":{"entry":[{"key":"meeple","value":"Meeple@c4e732d"},{"key":"position","value":"1"}]}} Stellt einen eigenen Spielstein (meeple) auf der gerade ausgelegten Karte an die gewünschte Position (position).
END_TURN keiner {"@action":"END_TURN"} Beendet den aktuellen Zug.
LEAVE_GAME keiner {"@action":"LEAVE_GAME"} Verlässt das aktuelle Spiel.
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

NOOP keiner {"@action":"NOOP"} Command der in regelmäßigen Abständen abgeschickt werden kann, um die Verbindung aufrecht zu erhalten.
START_GAME keiner {"@action":"START_GAME"} Startet das Spiel, wenn genügend Spieler angemeldet sind.

Events

Der Server schickt Events in der Form

{"@ts":"1336475335153","@src":"User@a4d93e3","@prop":"nickname","@nv":"akoch"}

In diesem Fall wurde zum Timestamp 1336475335153 von der source User@a4d93e3 die property nickname auf akoch (new value) geändert.
Wer sich die Events vom Server genauer anschaut wird feststellen, dass Werte die null sind in JSON wegoptimiert werden. In diesem Beispiel fehlt z.B. die Property @ov.

Nicht alle Events stehen für Modelländerungen. Während eines Spiel sendet der Server euch auch Events, auf die ihr reagieren müsst. So gibt es OK und ERROR Events, die euch zusätzliche Informationen geben oder euch auffordern mit dem Server zu interagieren.

OK Events, die eine Reaktion von euch erfordern sind wie folgt aufgebaut: {“@ts”:”1372946132672″,”@src”:”SERVER”,”@prop”:”USER_MESSAGE”,”@nv”:”OK – {type} – {message}”}. Es gibt zudem auch OK Events, die rein informellen Charakter haben und erfolgreich ausgeführte Commands bestätigen

ERROR Events sind immer wie folgt aufgebaut: {“@ts”:”1372946132685″,”@src”:”SERVER”,”@prop”:”USER_MESSAGE”,”@nv”:”ERROR: {type} – {message}”}

Auf welchen {type} ihr wie reagieren müsst, findet ihr oben in der Tabelle. Der Parameter {message} wird nicht immer mitgesendet.

Empfangt ihr beispielsweise ein Event wie

{"@ts":"1372946132672","@src":"SERVER","@prop":"USER_MESSAGE","@nv":"OK - drawCard"}

erwartet der Server ein DRAW_CARD command von euch

Tipp: Das nötige Datenmodell lässt sich größtenteils aus dem Eventstream ableiten.

Compiler Construction, WS1314

Auf Grund des Umfangs der Aufgabe 3 ist die Abgabefrist für Compilerbau um eine Woche verlängert worden.

Tipp: Falls ihr bspw. bei Ausdrücken, die if-Bedingungen oder while-schleifen vergleichbar zu “x=0 while x<10 {x=x+1 15+3} x” enthalten, Probleme mit der Stackhöhe bekommt, versucht erstmal innerhalb der Blöcke (von if-Bedingungen oder while-schleifen) ohne expressions zu arbeiten, d.h. Ausdrücke vergleichbar zu”x=0 y=1 while x<10 {x=x+1 y=y+3} y” auswerten zu können.