Hallo Teams,

am kommenden Donnerstag den 25.11.2010 wird der MLM Server in der Zeit von ca. 07.00 – 09.00 Uhr aufgrund von Wartungsarbeiten nicht verfügbar sein.

Soeben ist ein weiterer Kalender auf der Hauptseite zu SE1 online gegangen. Dort findet ihr die Sprint/Release Planung für das ganze Semester sowie wichtige Deadlines und Termine. Beachtet, dass am Ende von jedem Release eine Präsentation gegenüber den Kunden geplant ist. Die Präsentation muss innerhalb des angegebenen Zeitraums gehalten werden!

Wir haben bei allen Deadline Terminen in den Termindetails Empfehlungen der Kunden hinterlegt, wie weit das Projekt bei den Teams fortgeschritten sein sollte. Dabei handelt es sich lediglich um eine Empfehlung!

Von Zeit zur Zeit wird der Mega Lo Mania aktualisiert.

• Die aktuelle Server Version wird euch beim Einloggen mitgeteilt.
• Größere Änderungen von einem Server Release zum Nächsten könnt ihr mit dem CHANGELOG Kommando nachvollziehen.
• Nutzt das HELP Kommando!

Hier noch einige wichtige Hinweise zur Organisation von SE1:

• Es gibt seit letzter Woche feste Betreuer! Jedes Team hat also einen festen Ansprechpartner. Fragen werden vom Scrum Master an euren Betreuer gestellt. Zur Übersicht hier nochmal die Team -> Betreuer Übersicht:
  

  Team	Betreuer
  A	Christoph Eickhoff
  B	Dennis Kroll
  C	Florian Heerdegen
  D	Ingo Witzky
  E	Marcel Hahn
  F	Stefan Lindl
  G	Stephan Göbel
  H	Tobias George

• Wollt ihr im Labor arbeiten müsst ihr euch bei eurem Betreuer per Mail anmelden. Die ist nötig, damit euer Betreuer eine Bewertung bzgl. Team- und Individualzeit vornehmen kann.
• Am Ende eures Aufenthalts im Labor, könnt ihr eure Bewertung beim Betreuer erfragen.
• Ab jetzt bekommt der Scrum Master des Teams 1x pro Woche eine Übersicht über die Bewertung von Team- und Individualzeit von eurem Betreuer per Mail.

Auf der Hauptseite zur Veranstaltung finden sich am Ende ein FAQ zu den Themen “Mega Lo Mania” und “Agilo”. Diese FAQ wird je nach Bedarf erweitert. Habt also zunächst einen Blick darauf, bevor ihr euren Betreuer fragt!

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 4000
kann man mit HELP eine Liste aller verfügbaren Befehle abrufen.
Besonders hervorzuheben sind

• REGISTER USER <username> <email> <password> um neue Benutzer zu registrieren,
• LOGIN <username> <password> um sich einzuloggen,
• LIST GAMES um eine Liste der Spiele abzurufen und
• JOIN GAME <gamename> um einem Spiel beizutreten.

Um einen Timeout zu vermeiden sollte vom Client in regelmäßigen abständen ein NOOP geschickt werden.

Jedes erfolgreiche Kommando wird vom Server mit einem OK beendet. Fehler werden mit einer Zeile beantwortet die mit ERROR beginnt.

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.

Eine liste der möglichen Commands und ihrer Properties wird später an dieser Stelle nachgereicht…

Allgemeines

Im Folgenden handelt es sich um Informationen zum Mega Lo Mania Server in der Version v0.1. Hierbei handelt es sich um den aktuellen Stand der Serverimplementierung. Im Laufe des Semesters kann es zu (kleineren) Änderungen im Server kommen. Insbesondere das Game Balancing könnte hiervon betroffen sein.

Generell verhält sich die Spielsimulation ähnlich der bereits in der Vorlesung gezeigten Version von Mega Lo Mania.

Simulation

Die Simulation macht alle 1000ms einen Step. Ein Step beinhaltet nacheinander die folgenden Schritte:

1. Bevölkerungswachstum
2. Resourcen sammeln
3. Inventions erforschen
4. Tower bauen
5. Kampf

Zu jedem dieser Schritte folgt die Erläuterung des  genauen Ablaufs und etwaiger Berechnungsgrundlagen.

1. Bevölkerungswachstum

Generell:

• Bevölkerungswachstum erst ab 2 Menschen
• Die maximale Bevölkerungsanzahl pro Tower beträgt 500 Seit Server Version 1.0.5 wurde diese Beschränkung aufgehoben!
• Je mehr Menschen sich Tower befinden, desto schneller vermehrt sich die Bevölkerung 😉

Befinden sich 2 Menschen im Tower, werden 30 Sekunden benötigt um einen weiteren Menschen zu zeugen. Bei 4 Menschen werden entsprechend 15 Sekunden benötigt.

2. Resourcen sammeln

Generell:

• Es gibt Resourcen, die automatisch aufgesammelt werden und Resourcen für die eine Mine/Tagebau benötigt wird. Die Geschwindigkeit in der Resourcen abgebaut werden, unterscheidet sich zwischen diesen beiden Typen
  • Automatisch aufgesammelte Resourcen: Anzahl der Menschen im Tower.
  • Resourcen die eine Mine/Tagebau erfordern: Anzahl der Menschen in der Mine/Tagebau.

Die folgende Tabelle gibt Informationen darüber, welche Resourcen automatisch aufgesammelt werden und für welche eine Mine/Tagebau benötigt wird. Zudem wird die Anzahl der gesammelten Resourcen pro Step (1000ms) angegeben:

3. Inventions erforschen

Generell:

• Es kann immer nur an einer Invention gleichzeitig geforscht werden. Soll an einer neuen Invention geforscht werden während bereits eine andere läuft, so wird die erste Forschung abgebrochen
• Welches Design für eine Invention verwendet wird, entscheidet der Server (siehe Erklärung “Bestes Design”)
• Die zum erforschen einer Invention benötigte Zeit hängt von folgenden Faktoren ab:
  1. Der momentanen Epoche des Sectors sowie der Epoche der Invention. Je größer die Differenz zwischen diesen beiden Epochen, desto mehr Zeit wird benötigt
  2. Ist das für die Invention gewählte Design “ergonomicallyTerrific”, halbiert sich der in Schritt 1 errechnete Faktor.

Bestes Design

Das beste Design wird wie folgt ermittelt:

1. Aus allen für eine Invention möglichen Design die entfernen, für die gerade zu wenig Resourcen im Tower verfügbar sind
2. Die übrigen Designs nach der Anzahl der benötigten Resourcen sortieren. Hierbei wird KEINE Rücksicht auf die Art der Resource genommen sondern nur die Menge berücksichtigt.
3. Das erste Design in der sortierten Liste ist das beste Design.

Berechnung einer Invention

1. Initialisierung:
   1. Berechnung der Epochen Differenz: Diff = EpochOfSector – EpochOfInvention
   2. Berechnung des Invention Faktors:
      

      Diff	Faktor
      3	40
      2	60
      1	80
      0	100
      -1	120
      -2	140
      -3	160

      Falls das Diff mehr als 3 Epochen beträgt, wird der Faktor auf 30 (>3) bzw. 170 (<-3) begrenzt.

   3. Das beste Design ermitteln
   4. Falls das Design “ergonomicallyTerrific” ist, wird der in Schritt 2 berechnete Faktor halbiert.
2. Bei jedem Step:
   1. Workprogress berechnen: workProgress = AnzahlInventors / factor
   2. Progress der Invention um berechneten Progress erhöhen
   3. Falls der Progress =1 ist die Erforschung abgeschlossen

4. Tower bauen

Generell:

• Befindet sich eine Army auf auf einem leeren Sector, fängt diese automatisch an einen Tower zu bauen
• Je mehr Menschen sich auf einem Sector befinden, desto schneller wird der Tower gebaut
• Ist der Bau fertiggestellt, werden alle Armeen in den Tower verschoben und die Waffen im Waffenlager (Storage) deponiert
• Der Fertigstellungsgrad ist ein Wert 0 <= x <= 1

Berechnung: buildProgress = workpower / 1000

5. Kampf

Generell:

• Ein Kampf findet immer dann statt, wenn
  • Sich (mindestens) zwei Armeen auf einem Sector befinden, deren Teams verschieden sind
  • Sich (mindestens) eine Armee auf einem Sector befindet, der bereits mit Gebäuden eines anderen Teams bebaut ist
• Folgende Waffen gibt es grundsätzlich:
  

  Waffe	Typ	Epoche	Schaden	Anzahl nötiger Soldaten	Luftwaffe
  Rock	Weapon	9500 BC	1	1	nein
  Stick	Defense	9500 BC	3	1	nein
  Shield	Shield	9500 BC	–	–	–
  Catapult	Weapon	3000 BC	2	1	nein
  Spear	Defense	3000 BC	6	1	nein
  Shield	Shield	3000 BC	–	–	–
  Pike	Weapon	100 AD	4	1	nein
  Bow and Arrow	Defense	100 AD	12	1	nein
  Shield	Shield	100 AD	–	–	–
  Longbow	Weapon	900 AD	8	1	nein
  Cauldron	Defense	900 AD	24	1	nein
  Shield	Shield	900 AD	–	–	–
  Giant Catapult	Weapon	1400 AD	16	2	nein
  Crossbow	Defense	1400 AD	48	2	nein
  Shield	Shield	1400 AD	–	–	–
  Cannon	Weapon	1850 AD	32	3	nein
  Musket	Defense	1850 AD	96	3	nein
  Shield	Shield	1850 AD	–	–	–
  Biplane	Weapon	1915 AD	64	2	ja
  Machine Gun	Defense	1915 AD	192	2	nein
  Shield	Shield	1915 AD	–	–	–
  Jet Fighter	Weapon	1945 AD	128	3	ja
  Bazooka	Defense	1945 AD	384	2	nein
  Shield	Shield	1945 AD	–	–	–
  Nuke	Weapon	1980 AD	–	–	nein
  Nuclear deterrent	Defense	1980 AD	–	–	nein
  Shield	Shield	1980 AD	–	–	–
  Flying Saucer	Weapon	2001 AD	512	10	ja
  SDI Laser	Defense	2001 AD	1536	10	nein
  Shield	Shield	2001 AD	–	–	–

Die Berechnung der Kämpfe läuft wie folgt ab:

1. Für alle Armeen eines Teams die Kampfstärke berechnen. Die stärke einer (oder mehrerer) Armeen hängt von der benutzten Waffe ab.
   • singleArmyStrength = waffenSchaden * (anzahlSoldaten / nötigeAnzahlSoldatenFürWaffe)
   • totalArmyStrength = SummeDerEinzelnenArmeenStärke
2. Zunächst Kampf der Armeen untereinander berechnen:
   1. Sterberate einer Armee berechnen. Sei at1 eine Armee von Team 1,  at2 eine Armee von Team 2, at1_deathrate die Sterberate von at1 und at2_deathrate die Sterberate von at2.at1_deathrate = at2_totalArmyStrength / at1_totalArmyStrength
   2. Anzahl der kills bei jeder Armee berechnen.
      • Falls eine Armee keine Einheiten verlieren würde (deathrate zu gering), Zufall entscheiden lassen, ob doch 1 Einheit stirbt.
      • Andernfalls entspricht die deathrate der Anzahl der kills. Falls mehrere Armeen eines Teams anwesend sind, werden die kills gleichmäßig über die Armeen verteilt.
3. Gebäudeschaden berechnen
   1. Kampfstärke von Verteidigern auf Gebäuden berechnen (siehe hierzu Schritt 1).
   2. damageToBuilding = enemy_totalArmyStrenght – defender_totalArmyStrength
   3. Betragen die hitPoints eines Gebäudes 0, so wird dieses Gebäude zerstört
      

Wie bereits in der letzten Vorlesung erläutert, ist bei SCRUM der Product Owner für den Informationsaustausch zwischen Kunde und Team verantwortlich. Aus diesem Grund genügt es, wenn sich der Product Owner eines Teams mit den Kunden trifft. Dies erleichtert auch die Terminfindung enorm.