Category Archives: SS12

Beschreibung des Kartenformats

Software Engineering I, SS12

Eine dem vorgegebenen Format entsprechende Karte, ist unter Summer.map zu finden. Hier noch die passende Grafik.

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:

### 
### SUMMER 
###

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).

map_summer.jpg

Hier wird der Name des zugehörigen Hintergrundbildes spezifiziert. Es muss sich um ein .jpg handeln.

SET_ALPHA_BACKGROUND_COLOR:OFF

Mit dieser Option kann eine Farbe definiert werden, mit der das eigene “Tile” während einem Spiel hervorgehoben werden soll

8;0 
9;0 
10;0
....

Zellen, auf denen keine Türme gebaut werden dürfen, werden mit x;y Koordinatenpaaren (Wichtig: Trennzeichen ist ein Semikolon) definiert. Die Reihenfolge ist frei wählbar.

5,15 
5,14 
6,14
...

Die Wegpunkte, auf denen sich die Creeps bewegen, werden mit x,y Koordinatenpaaren (Wichtig: Trennzeichen ist ein Komma) definiert. Die Reihenfolge ist bindend, d.h. das oberste Koordinatenpaar definiert den Einstiegspunkt und das unterste den Ausstiegspunkt aus dem Kartensegment.

Der Einfachheit halber gelten folgende Regeln:

  1. Aufeinander folgende Wegpunkte müssen dieselbe X oder Y-Koordinate besitzen außer
  2. Aufeinander folgende Wegpunkte liegen im 45° Winkel diagonal zueinander, d.h. 
    4,1
6,3

    ist ebenfalls erlaubt. Nicht zulässig wäre bspw.

    2,3
4,4

 

WICHTIG: Die für eine Karte spezifizierten Koordinaten beziehen sich auf das nicht rotierte Hintergrundbild. Betrachtet man beispielhaft folgende Karte:

Im Karteneditor wird IMMER das Kartensegment oben links erstellt bzw. bearbeitet. Die übrigen Segmente resultieren aus der Drehung des ursprünglichen Segmentes. Das bedeutet im Weiteren, dass die Startzelle, also der erste Wegpunkt, immer an dem unteren Kartenrand liegen muss und die Endzelle, also der letzte Wegpunkt immer am rechten Kartenrand und passend zum ersten Wegpunkt liegen muss. In dem Beispiel bedeutet das der erste Wegpunkt befindest sich auf 1,15, der letzte muss also bei 15,1 liegen. Damit kann sichergestellt werden, dass die Karten gerantiert drehbar und somit für 2-4 Spieler nutzbar sind.

 

Auswahl der Wegpunkte

 

Wegpunkte müssen nicht unbedingt direkt nebeneinander liegende Zellen beschreiben. Daher ist die Geschwindigkeit von Creeps auch nicht abhängig von Zellen, sondern von Wegpunkten, d.h. die Geschwindigkeit von Creeps wird in Wegpunkten pro Sekunde beschrieben.

Nehmen wir für folgende Beispiele an ein Creep schafft 1 Wegpunkt in 1 Sekunde:

Beispiel 1 mit folgenden 3 Wegpunkten:

2,10
2,11
2,12

Diese Wegpunkte liegen auch von ihren Zellen her direkt nebeneinander, d.h. der Creep läuft eine Sekunde lang von 2,10 nach 2,11 und eine Sekunde von 2,11 nach 2,12

Beispiel 2 mit folgenden 3 Wegpunkten:

2,5
2,11
2,12

Diese Wegpunkte liegen nicht direkt nebeneinander, so dass der Creep eine Sekunde lang von 2,5 nach 2,11 und eine Sekunde von 2,11 nach 2,12 läuft . Die erste Sekunde bewegt er sich also deutlich schneller, weil er viel mehr Zellen zu überwinden hat.

Beispiel 3 mit folgenden 3 Wegpunkten:

2,11
2,11
2,12

Diese Wegpunkte liegen wieder direkt nebeneinander, aber der erste Wegpunkt wurde verdoppelt. In diesem Fall bleibt der Creep eine Sekunde lang auf 2,11 stehen und läuft anschließend eine Sekunde von 2,11 nach 2,12

 

Mit diesen drei Alternativen lassen Karten erstellen, auf denen Creeps je nach Abschnitt unterschiedlich schnell unterwegs sein können.

 

CreepSmash Spielbeschreibung

Software Engineering I, SS12

Einleitung

CreepSmash ist ein Multiplayer Tower Defense Spiel. Jeder Spieler hat die Kontrolle über seinen eigenen Sektor und kann dort an bestimmten Stellen (abhängig von der Karte) Türme bauen. Seinen Gegnern kann er Creeps schicken, die dann durch deren Tower zerstört werden müssen. Schafft es ein gegnerischer Creep durch die eigenen Verteidigungslinien, verliert der Spieler 1 Leben. Sind alle 20 Leben aufgebraucht, verliert der Spieler.

Der Spieler, der am Längsten durchhält, gewinnt!

Spielablauf

  • Um an CreepSmash teilzunehmen, muss zunächst in der Lobby ein Spiel erzeugt werden: 
    CREATE GAME <gamename> -players <count> (-map <mapname>)? (-testgame)?

    Der Spielname kann frei gewählt werden. Optional kann die gewünschte Karte angegeben und festgelegt werden, ob es sich bei dem Spiel im ein Testspiel handelt. Bei Testspielen bekommt jeder Spieler 100 Leben und hat eine “Balance” (sozusagen der Kontostand des Spielers) von 100000. Bei normalen Spielen hat jeder Spieler 20 Leben und eine “Balance” von 200.

  • Einem erzeugten Spiel können andere Spieler beitreten:JOIN GAME <gamename> (Siehe Command Beschreibung)
  • Nachdem einem Spiel beigetreten wurde, wechselt der Server in das JSON Protokoll. Als nächstes muss der Startsektor gewählt werden:CHOOSE_TILE (Siehe Command Beschreibung)
  • Sobald man bereit ist, kann das Spiel gestartet werden:START_GAME  (Siehe Command Beschreibung). Das Spiel wird erst gestartet, wenn alle am Spiel teilnehmenden Spieler einen Startsektor gewählt haben!
  • Die Spielsimulation startet und jeder Spieler bekommt die initiale Spielwelt sowie regelmäßig Updates in Form von Events über die aktuelle Spielsituation zugeschickt. Nun sollte man durch geschicktes Aussenden von Creeps und Bauen von Towern versuchen, seine Gegner zur Strecke zu bringen.
  • Jeder Spieler hat ein regelmäßiges Einkommen, mit dem er Tüme und Creeps finanzieren kann. Alle 15 Sekunden bekommt er sein aktuelles “Income” auf sein “Balance” aufaddiert. Das “Income” kann nur gesteigert werden, indem man seinen Gegnern Creeps schickt. Dabei gilt: Je stärker der Creep umso stärker steigt das Income. Der Schlüssel zum Sieg liegt daher in einer gesunden Mischung von Offensive und Defensive.

Spielelemente

In diesem Abschnitt soll ein Überblick über die in CreepSmash vorkommenden Spielelemente gegeben werden.

Karten

Jeder Spieler spielt auf einer 16 x 16 Felder großen Karte. Jedes dieser Felder besitzt einen der folgenden drei Zustände:

  • NONE (Hier kann kein Tower gebaut werden und kein Creep kann diese Zelle betreten)
  • TOWER (Hier können Tower gebaut werden, jedoch kann kein Creep diese Zelle betreten)
  • WALKABLE (Weg für Creeps, hier kann kein Tower gebaut werden)

Jede Karte wird über eine Startzelle betreten und über eine Endzelle verlassen. Zudem besitzt jede Karte ein Hintergrundbild. Ein komplettes Spiel entsteht dann durch jeweilige 90° Drehung der Karte. Beim Design einer Karte ist es also wichtig, dass die Start- und Endzelle so gelegt wird, dass nach einer 90° Drehung die Startzelle der gedrehten Karte an die Endzelle der ersten Karte grenzt.

Ein Beispiel eines Spiels ist in folgendem Screenshot zu sehen:

Hier ist gerade ein 3-Spieler Spiel zu sehen. Die Startzelle von Spieler 1 befindet sich unten links, die Endzelle oben rechts. Durch 90° Drehung der Karte wird das Spielfeld von Spieler 2 erstellt. Die Endzelle von Spieler 1 grenzt nun also an die Startzelle von Spieler 2.

Creeps

Hier gibt es eine Übersicht über alle verfügbaren Creeps sowie deren Charakteristik.  “Price” zeigt die Kosten zum Kauf eines Creeps, diese werden von der eigenen “Balance” abgezogen. “Health” gibt die Lebenspunkte an. “Speed” gibt die Geschwindigkeit in Wegpunkten pro Sekunde an. “Income” beschreibt den Wert, der auf den “Income” Wert des Spielers aufaddiert wird. “Bounty” gibt die Belohnung an, wenn ein Creep zur Strecke gebracht wird.

Creep Price Health Speed Income Bounty
Mercury 50 300 1.4 5 5
Mako 100 700 1.3 10 10
Fast Nova 250 1400 1.6 25 25
Large Manta 500 3500 1.0 50 50
Demeter 1000 7000 1.2 90 90
Ray 2000 14000 1.3 180 180
Speedy Raider 4000 30000 1.8 360 360
Big Toucan 8000 80000 1.2 720 720
Vulture 15000 140000 1.4 1200 1200
Shark 25000 250000 1.5 2000 2000
Racing Mamba 40000 500000 2.0 3200 3200
Huge Titan 60000 1200000 1.3 4800 4800
Zeus 100000 1500000 1.3 7000 7000
Phoenix 200000 2500000 1.6 14000 14000
Express Raptor 400000 6000000 2.8 28000 28000
Fat Colossus 1000000 15000000 1.4 56000 56000

Schickt ein Spieler einen Creep, startet der Creep bei der Startzelle des im Uhrzeigersinn nächsten Spielers. Schafft der Gegner es, den Creep zur Strecke zu bringen, erhält dieser den für den Creep ausgeschriebenen “Bounty”. Schafft der Gegner dies nicht, betritt der Creep automatisch die Karte des nächsten Spielers. Bei einem 2-Spieler Spiel, startet der Creep dann sofort wieder beim Gegner, d.h. selbst ausgesandte Creeps betreten NICHT die eigene Karte.

Tower

Im Folgenden eine Übersicht aller Tower. Hier eine Erläuterung einiger Attribute:

  • Cooldown: Gibt die Zeit in ms an, die der Tower zum erneuten Feuern benötigt.
  • Color: Visualisiert das Towerlevel
  • Range: Die Reichweite des Towers in Anzahl Zellen
  • Slowrate: Gibt den Faktor an, um den Einheiten verlangsamt werden
  • Slowtime: Gibt die Dauer des Sloweffects in ms an
  • Splash radius: Gibt den Radius in Anzahl Zellen an
  • Splash damage reduction: Gibt an, um wieviel Prozent der Schaden am äußersten Rand des “Splash radius” reduziert wird, d.h. beschießt ein Turm mit Splash-Fähigkeit einen Creep, bekommen alle Creeps in dessen Umgebung ebenfalls Schaden. Dabei gilt: Je näher sich ein Creep am ursprünglich beschossenen Creep befindet, desto mehr Schaden bekommt er.
Tower Description Level Price Cooldown (ms) Color Range Damage Slowrate Slowtime(ms) Splash radius Splash damage reduction
Basictower – 1 50 650 00ff00 1.75 25 – – – –
Basictower – 2 100 650 0000ff 2.0 50 – – – –
Basictower – 3 1000 650 ff0000 2.25 250 – – – –
Basictower – 4 3000 650 ffc800 2.5 1000 – – – –
Slowtower slows targetslows target 1 100 750 00ff00 1.75 25 0.3 2000 – –
Slowtower slows targetslows target 2 200 800 0000ff 2.25 50 0.35 2000 – –
Slowtower slows targetslows target 3 400 850 ff0000 2.5 75 0.45 2500 – –
Slowtower slows multiple targetsslows multiple targets 4 3000 900 ffc800 2.5 100 0.5 2500 1.25 0.7
Splashtower attacks multiple targetsattacks multiple targets 1 250 750 00ff00 2.0 50 – – 1.75 0.7
Splashtower attacks multiple targetsattacks multiple targets 2 750 600 0000ff 2.25 200 – – 1.75 0.7
Splashtower attacks multiple targetsattacks multiple targets 3 3000 500 ff0000 2.75 400 – – 1.75 0.6
Splashtower attacks multiple targetsattacks multiple targets 4 7500 500 ffc800 3.0 1100 – – 1.75 0.5
Rockettower attacks multiple targetsattacks multiple targets 1 1000 3750 00ff00 2.5 1000 – – 1.25 0.8
Rockettower attacks multiple targetsattacks multiple targets 2 3000 3750 0000ff 3.0 2500 – – 1.25 0.8
Rockettower attacks multiple targetsattacks multiple targets 3 7500 3250 ff0000 3.5 7500 – – 1.5 0.7
Rockettower attacks multiple targetsattacks multiple targets 4 15000 3000 ffc800 4.0 15000 – – 1.75 0.6
Speedtower – 1 1000 450 00ff00 2.5 225 – – – –
Speedtower – 2 3000 350 0000ff 2.75 450 – – – –
Speedtower – 3 7500 250 ff0000 3.0 1100 – – – –
Speedtower – 4 15000 150 ffc800 3.25 1800 – – – –
Ultimatetower – 1 20000 5000 00ff00 5.0 25000 – – – –
Ultimatetower – 2 50000 2500 ffc800 7.5 40000 – – – –

Befehle

Eine genaue Auflistung aller möglichen Befehle ist hier zu finden:  Command Beschreibung. Falls ein Befehl nicht korrekt ausgeführt werden kann, bekommt der Spieler eine Fehlermeldung vom Server. Typische Fehler sind:

  • Befehl existiert nicht
  • Syntax ist nicht korrekt. Es könnten z.B. nötige Parameter fehlen.
  • Befehl ist nicht ausführbar. Beispiele:
    • Vorraussetzungen sind nicht erfüllt
    • Es wird versucht einen gegnerischen Tower zu verkaufen
    • …

CreepSmash Server Protokoll v1.0.0

Software Engineering I, SS12

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. Diesen bekommt ihr von eurem Betreuer beim nächsten Treffen.
  • 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>
  • Nach der Begrüßung vom Server:
    • LOGIN (<login>|<email>) <password>
    • LOGOUT
  • Nach dem Anmelden:
    • LIST MAPS
    • LIST USERS
    • LIST GAMES
    • CREATE GAME <gamename> -players <count> (-map <mapname>)? (-testgame)?
    • JOIN GAME <gamename> (-visitor [true|false])?
    • MSG (ALL | ( ( USER | TEAM ) <recipient> ) )? <message>
    • CHANGE PASSWORD <newPassword> <newPassword>
    • UPLOAD MAP
    • DOWNLOAD MAP <mapname>
    • CREATE TESTPLAYER

      Beispiel:

      SE1 CreepSmash-Server 1.0, Timeout set to 600000ms
login zenobios ******
USER NICK=zenobios EMAIL=andreas.scharf@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

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 Starttile 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 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
CHANGE_USER_COLOR color {"@action":"CHANGE_USER_COLOR","properties":{"entry":{"key":"color","value":"FFFF00"}}} Ändert die Userfarbe.
CHOOSE_TILE tile {"@action":"CHOOSE_TILE","properties":{"entry":{"key":"tile","value":"Tile@1a3b6f"}}} Wählt das Starttile aus. tile muss eine ID sein.
CREATE_TOWER towertype, cell {"@action":"CREATE_TOWER","properties":{"entry":{"key":"towertype","value":"ROCKET"},"entry":{"key":"cell","value":"Cell@d54a23"}}} Baut einen Tower des Typs towertype auf der Zelle cell.
SELL_TOWER tower {"@action":"SELL_TOWER","properties":{"entry":{"key":"tower","value":"Tower@d43b23"}}} Der Tower tower wird verkauft. Der Verkauf bringt 75% des ursprünglichen Towerpreises ein. Es können nur eigene Tower verkauft werden.
UPGRADE_TOWER tower, level {"@action":"UPGRADE_TOWER","properties":{"entry":{"key":"tower","value":"Tower@d54a23"},"entry":{"key":"level","value":"2"}}} Wertet den Tower tower auf Level level auf.
CHANGE_TOWER_STRATEGY tower, strategy {"@action":"CHANGE_TOWER_STRATEGY","properties":{"entry":{"key":"tower","value":"Tower@5974b827"}, "entry":{"key":"strategy","value":"FASTEST"}}} Wechselt die Strategie von Tower tower auf die Strategie strategy. Es stehen folgende Strategien zur Auswahl:
CLOSEST, FASTEST, STRONGEST, FARTHEST, WEAKEST
CREATE_CREEP creeptype {"@action":"CREATE_CREEP","properties":{"entry":{"key":"creeptype","value":"RACING_MAMBA"}}} Erzeugt einen Creep vom Typ creeptype

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.

About individual- and teamtime

Software Engineering I, SS12

About individual- and team time

  • 50% individual- and 50% team effort, where
    • The individual effort is
      • 25% team commitment
      • 15% role (perception of the role you had in the scrum process during the release)
      • 10% individual time
    • The team effort is
      • 40% assessment of the releases (4 releases, each 10%)
      • 10% team time

What is individual and team time? What is important for the presentation and how do we assess the preception of your different roles? Here are the answers:

  • Individual and team time
    • At least one hour of each individual and team time to get a 4.0.
    • Two hours of each individual and team time to get a 1.0.
    • At the end of each weekly meeting you will get an assessment in the range (-2,…,+2) which will be summarized at the end of SE1 and build your individual/team grade.
    • Individual time
      • Starts counting if at least two team members start working on the project (two because we want to boost pair programming) in the SE lab.
      • Team commitment means your behavior within the team i.e. if you were available only physically or if you do your best to push your team forward.
    • Team time
      • Starts counting if at least 75% of the team comes together in the SE lab and start working on the project.
      • Team time also counts into individual time!
  • Roles
    • Dependent on the role you had within a release, we will asses as follows
      • Scrum Master
        • “The scrum master has to ensure that the team has everything it needs to get the work done.”
        • Writes (together with the PO)  the release documenation
        • Contacts the SE experts and arranges the weekly meetings
        • We will asses how you did this job!
      • Product owner
        • Maintains the Agilo instance and writes “User Stories”.
        • Writes (together with the SM)  the release documenation
        • Prioritizes the tasks in the product backlog
        • We will asses how you did this job by having a look at your agilo.
      • Developer
        • We will have a look at the Agilo burndown charts to get a picture what you did