Category Archives: WS1011
Das Ingame JSON Protokoll kennt, wie bereits aus dem Chatprotokoll bekannt, 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 |
|---|---|---|---|
CHOOSE_SECTOR |
sector |
{"@action":"CHOOSE_SECTOR","properties":{"entry":{"key":"sector","value":"Sector@1a3b6f"}}} |
Wählt den Startsektor aus. sector muss eine ID sein. |
START_GAME |
keiner | {"@action":"START_GAME"} |
Startet das spiel wenn jeder Spieler einen Startsektor gewählt hat. |
LEAVE_GAME |
keiner | {"@action":"LEAVE_GAME"} |
Verlässt das aktuelle Spiel. |
TRANSFER_MEN |
source, target, amount |
{"@action":"TRANSFER_MEN","properties":{"entry":{"key":"source","value":"Tower@1a3b6f"},"entry":{"key":"target","value":"Invention@b54ddf"},"entry":{"key":"amount","value":"12"}}} |
Transferiert amount Men von einem Ort zum anderen, solange es keine Armee betrifft. source und target erwarten die ID eines Towers, einer Invention oder einer Resouorce |
CREATE_ARMY |
tower, amount, (weapon), (target) |
{"@action":"CREATE_ARMY","properties":{"entry":{"key":"tower","value":"Tower@1a3b6f"},"entry":{"key":"weapon","value":"Invention@b54ddf"},"entry":{"key":"amount","value":"12"},"entry":{"key":"target","value":"Sector@1a3b6f"}}} |
Erzeug mit amount men aus dem per ID angegebenen tower eine neue Army. Die Army wird mit der per ID angegebenen weapon ausgerüstet, wenn genügend waffen im tower verfügbar sind, oder erstellt werden können. Als target kommen per ID angegebene Turrets oder angrenzende Sectoren in Frage. |
MOVE_ARMY |
army, target |
{"@action":"MOVE_ARMY","properties":{"entry":{"key":"army","value":"Army@d54a23"},"entry":{"key":"target","value":"Sector@1a3b6f"}}} |
Versetzt die army an das angegebene target, welches ein Tower oder ein Sector sein kann. |
RESEARCH |
tower, invention |
{"@action":"RESEARCH","properties":{"entry":{"key":"tower","value":"Tower@123abc"},"entry":{"key":"invention","value":"Invention@f45a3b"}}} |
Erforscht die per ID angegebene invention im per ID angegebenen tower. Es wird ein Research-Objekt erzeugt, dem per TRANSFER_MEN noch Forscher zugewiesen werden müssen. |
MESSAGE |
message, (audience), (recipient) |
{"@action":"MESSAGE","properties":{"entry":{"key":"message","value":"Hallo"},"entry":{"key":"audience","value":"USER"},"entry":{"key":"recipient","value":"jfd"}}} |
Siehe Chatprotokoll. |
Weitere Commands werden folgen 😉
Events
Der Server schickt Events in der Form
{"@ts":"199027638079229","@src":"Player@1f8882e","@prop":"name","@nv":"jfd","@ov":"jdr"}
In diesem Fall wurde zum Timestamp 199027638079229 von der source Player@1f8882e die property name von jdr (old value) auf jfd (new value) geändert.
Wer sich die Events vom Server genauer anschaut wird feststellen, dass Werte die null sind in JSON wegoptimiert werden.
Tipp: Das nötige Datenmodell lässt sich größtenteils aus dem Eventstream ableiten.
Um die Kommunikation mit den Gruppen zu verbessern findet ihr ab sofort einen Bugtracker für den Server unter https://tracsvn.cs.uni-kassel.de/trac/mlm/report/1
Wenn ihr dort Bugs eintragt können Andy und ich entsprechend koordiniert reagieren. Ihr könnt auch gerne “enhancements” eintragen, aber wir können aus Zeitgründen natürlich nicht versprechen das wir davon etwas einbauen.
Hi Teams,
auch bei dem zweiten Release sollen wieder Kundengespräche geführt werden. Um eine grobe Vorstellung vom Inhalt der jeweiligen (und somit auch des zweiten ;)) Releases zu bekommen, sind bei den Deadline Terminen im Releasekalender kurze Notizen hinterlegt. Für das 1. Kundengespräch im zweiten Release solltet ihr also einen Blick in den Kalender werfen, euch grob die Features überlegen und im Gespräch mit den Kunden genauer herausbekommen, was sie von euch wollen. Daraufhin könnt ihr dann das Product Backlog füllen.
Viel Erfolg für das zweite Release!
Wir haben euch ein kleines Dokument zusammengestellt, dass euch Tipps an die Hand geben soll, wie ihr eure Präsentation aufbauen und halten könnt. Das Ergebnis findet ihr unter folgendem Link:
PS: Dieses Dokument soll euch eine Hilfe sein und kein Regelwerk darstellen auf Grund dessen wir die Präsentation bewerten. Die Erfahrung hat nur gezeigt, dass die meisten Studenten wenig erfahren sind, wie man Präsentationen richtig erstellt und v.a. sich darstellt. (Anmerkungen gerne an smu{@}cs.uni-kassel.de)
Der Mega Lo Mania Server wird aufgrund einer geplanten Serverwartung wie folgt nicht erreichbar sein:
Montag den 06.12.2010, ca 11-12 Uhr
Das Lobby Chat Protokoll wird in der Online Hilfe des MLM Servers beschrieben. Allerdings wechselt das Protokoll nach einem JOIN GAME in einen JSON Dialekt. Um dort Nachrichten zu verschicken müssen die Nachrichten folgendermaßen formatiert sein:
{"@action":"MESSAGE","properties":{"entry":{"key":"message","value":"Hallo"},"entry":{"key":"audience","value":"USER"},"entry":{"key":"recipient","value":"jfd"}}} oder
{"@action":"MESSAGE","properties":{"entry":{"key":"message","value":"Hi"}}}
- Die action die ausgeführt werden soll heißt
MESSAGE - In den properties muss mindestens ein key value Paar für
messageenthalten sein - Optional: ein key value Paar für
audience(ALL,USERoderTEAM) undrecipientfür den nickname des Users bzw den Teamnamen.
Nachrichten ohne recipient bzw. an ALL werden an alle Spieler im aktuellen Spiel / in der Lobby gesendet. An User oder Teams adressierte Chatnachrichten werden immer zugestellt, d.h. es ist möglich aus der Lobby mit MSG USER fred "Wie läufts?" mit dem User fred in Kontakt zu treten, obwohl er sich in einem Spiel befindet.
Wie bereits in der Vorlesung angekündigt, müssen alle Teams einen Code Coverage Report im Agilo verlinken. Ihr solltet eine Testabdeckung von ca 2/3 (also 66%) erreichen. Wir empfehlen euch EclEmma.
