All posts by Andreas Koch

Software Engineering I, SS15

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
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 jeder Spieler ein Startfeld gewählt hat.
LEAVE_GAME keiner {"@action":"LEAVE_GAME"} Verlässt das aktuelle Spiel.
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 audienceerlaubt 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 verschicktaudience: ALL, recipient:leer -> Nachricht wird an alle User im Spiel geschickt
audience: ALL, recipient:nicht leer-> Nachricht wird nicht verschicktaudience: USER, recipient:leer -> Nachricht wird nicht verschickt
audience: USER, recipient:username -> Nachricht wird an user username verschicktaudience: TEAM, recipient:leer -> Nachricht wird an das eigene Team geschickt
audience: TEAM, recipient:teamname -> Nachricht wird an das Team teamname verschicktEvents, 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
CHANGE_USER_COLOR color {"@action":"CHANGE_USER_COLOR","properties":{"entry":{"key":"color","value":"FFFF00"}}} Ändert die Userfarbe.
CHOOSE_FIELD field {"@action":"CHOOSE_FIELD","properties":{"entry":{"key":"field","value":"Field@1a3b6f"}}} Wählt das Startfeld aus. field muss eine ID sein.
CREATE_DEFENSE defensetype, cell {"@action":"CREATE_DEFENSE","properties":{"entry":{"key":"defensetype","value":"SWASH"},"entry":{"key":"cell","value":"Cell@d54a23"}}} Baut eine Verteidigungsanlage des Typs defensetype auf der Zelle cell.
CHANGE_DEFENSE defense, action {"@action":"CHANGE_DEFENSE","properties":{"entry":{"key":"defense","value":"Defense@d43b23"},"entry":{"key":"action","value":"SELL"}}} Die Verteidigungsanlage defense kann mit diesem Command angepasst werden. Es stehen folgende zwei Werte für action  zur Auswahl:SELL – Die Verteidigungsanlage wird verkauft. Der Verkauf bringt 75% des Kaufpreises ein. Es können nur eigene Verteidigungsanlage verkauft werden.

UPGRADE – Wertet die Verteidigungsanlage um ein Level auf, wenn möglich.

CHANGE_DEFENSE_STRATEGY defense, strategy {"@action":"CHANGE_DEFENSE_STRATEGY","properties":{"entry":{"key":"defense","value":"Defense@5974b827"}, "entry":{"key":"strategy","value":"FASTEST"}}} Wechselt die Strategie der Verteidigungsanlage mit der ID defense auf die Strategie strategy. Es stehen folgende Strategien zur Auswahl:
CLOSEST, FASTEST, STRONGEST, FARTHEST, WEAKEST
CREATE_ZOMBIE zombietype {"@action":"CREATE_ZOMBIE","properties":{"entry":{"key":"zombietype","value":"CHASER"}}} Erzeugt einen Zombie des Typs zombietype

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.

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

Software Engineering I, SS15

Im folgenden ein Beispiel, was “method body lines of code” aus den Bewertungskriterien bedeutet. Aus diesen 55 Zeilen der Klasse fließen 12 Zeilen in die Bewertung ein. Da ausschließlich Methodenrümpfe gezählt werden, fallen alle Importe, Felddeklarationen usw. raus. Innerhalb der Methodenrümpfe werden zudem alle Kommentare, sowie öffnende und schließende Klammern nicht gezählt.

Count Example

Software Engineering I, SS15

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 MAPS
    • LIST USERS
    • LIST GAMES
    • CREATE GAME <gamename> -maxPlayers <count> (-map <mapname>)? (-testgame)?
    • JOIN GAME <gamename> (-visitor [true|false])?
    • MSG (ALL | ( ( USER | TEAM ) <recipient> ) )? <message>
    • UPLOAD MAP
    • DOWNLOAD MAP <mapname>
    • CREATE TESTPLAYER
      Beispiel:

      SE1-Server 1.0, Timeout set to 600000ms
      login admin ******
      USER NICK=admin 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, CHANGE PASSWORD, 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
Seminar, WS1415

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 Tuesday, 13th of January 2015.

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

Software Engineering I, SS14

Liebe SE 1 Teilnehmer,

es ist geschafft. Die Veranstaltung ist offiziell beendet und die Noten sind in Arbeit, doch wie jedes Jahr wollen wir alle natürlich sehen, was nach 16 Wochen Entwicklungszeit bei euren Projekten herausgekommen ist. Der Termin für unser Abschlussturnier steht fest:

SE 1 Abschlussturnier am Freitag den 26.09.2014, 14 Uhr, Labor des Fachgebiets Software Engineering

Sofern wir wie jedes Jahr einen Sponsor finden, wird es ein paar Getränke und einen Pokal für die Sieger geben.

Bis dann,
Andreas & Lennert

Software Engineering I, Software Engineering II, SS14

Leider sind bei dem Ausfall der SE1-VM auch einige der Git-Repositories betroffen. Das sollte ausschließlich die Teams C, E, F und G betreffen. Eine serverseitige Wiederherstellung ist vermutlich nur mit mehr Aufwand und nicht verlustfrei möglich. Aber da bei Git jeder das komplette Repository geklont hat ist eine Wiederherstellung in ein neues Repository, was ich für die betroffenen Teams angelegt habe, deutlich einfacher. Dazu sollten die betroffenen Teams folgende Schritte durchführen:

  1. Findet heraus, wer im Team als letztes gepusht hat.
  2. Die betreffende Person selektiert in Sourcetree das Repository (1) und wählt Eigenschaften (2)
    git1
  3. Zuerst das Remote origin wählen (1) und auf Bearbeiten klicken (2)
    git2
  4. Bei der URL die 2 an der markierten Stelle einfügen
    git3
    git4
  5. Nun zweimal mit Ok bestätigen
  6. Das Repository in das neue Remote pushen
  7. Wenn das erledigt ist, sollten alle anderen Teammitglieder die Schritte 2 – 5 ebenfalls durchführen und sollten anschließend problemlos pullen und pushen können.
Software Engineering I, SS14

Zum Anlegen, Auslesen, Ändern und Löschen von Achievements gibt es ab Version 1.0.4 vier neue Klartext-Commands:

  1. CREATE ACHIEVEMENT
  2. DELETE ACHIEVEMENT
  3. LIST ACHIEVEMENTS
  4. UPDATE ACHIEVEMENT

Die genaue Nutzung der Befehle kann über den HELP command erfragt werden.

Zur Zeit unterstützt der Server in Version 1.0.4 drei Verschiedene Achievement-Arten:

  1. You have NUMBER of your meeples in  COMPARE NUMBER TYPE
  2. You have all played meeples in  COMPARE NUMBER TYPE
  3. You have received TYPE with COMPARE NUMBER points

Diese können in Zukunft noch ausgebaut werden. Alle groß geschriebenen Worte sind Platzhalter für Variablen:

  • NUMBER: Gültig sind positive, ganzzahlige  Zahlen
  • COMPARE: Gültig hierfür  sind ‘more than’, ‘less than’ und ‘exactly’
  • TYPE: Gültig hierfür sind die Feldtypen: ‘meadow’, ‘city’, ‘abbey’ und ‘road’

Ein gültiges Beispiel für jede der Achievement-Arten wäre demnach:

  1. You have 5 of your meeples in  more than 1 abbey
  2. You have all played meeples in more than 2 city
  3. You have received abbey with less than 20 points