Softwaretechnik- und Softwarepraktikum 2013 - Umsetzung eines verteilten Monopoly-Spiels
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Softwaretechnik- und Softwarepraktikum 2013
Umsetzung eines verteilten Monopoly-Spiels
Lastenheft
Auftraggeber
Wilhelm Schäfer, Stefan Dziwok,
Marie Christin Platenius, Sebastian Lehrig
Fachgebiet Softwaretechnik, Heinz Nixdorf Institut
Fakultät für Elektrotechnik, Informatik und Mathematik
Universität Paderborn, Zukunftsmeile 1, 33102 Paderborn
Version 1.0
Paderborn, den 10. April 2013Inhaltsverzeichnis
1 Zielbestimmung 1
2 Produkteinsatz 2
2.1 Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Vorgaben an den Entwicklungsprozess . . . . . . . . . . . . . . . . . . . . . 2
2.3 Generelle Nutzung des Produktes . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4 Spielregeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4.1 Begriffsdefinitionen . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4.2 Ziel des Spiels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4.3 Spielelemente, Aufbau und Spielablauf . . . . . . . . . . . . . . . . 6
2.4.4 Arten von Feldern . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.5 Nicht Teil unserer Monopoly-Variante . . . . . . . . . . . . . . . . . 10
2.5 Anwendungsszenario: Praktikumsturnier . . . . . . . . . . . . . . . . . . . . 10
3 Produktfunktionen und -leistungen 12
3.1 Netzwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Spiel-Konfigurator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3 Spiel-Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.1 Start eines Spiels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.2 Spielverlauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.1 PC- und Smartphone-Beobachter (Beobachter-Client) . . . . . . . . 14
3.4.2 Smartphone-Spieler . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.3 KI-Spieler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
A Technische Vorgaben und Hilfestellungen 16
A.1 Allgemeine Richtlinien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
A.2 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
A.3 Technologien und Entwicklungswerkzeuge . . . . . . . . . . . . . . . . . . 16
A.4 Eclipse Modeling Framework (EMF) . . . . . . . . . . . . . . . . . . . . . . 17
A.5 Eclipse Graphical Editing Framework (GEF) und Graphiti . . . . . . . . . . 18
A.6 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
A.7 JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Zielbestimmung
Ein Großteil der Funktionen moderner technischer Systeme wird heutzutage durch Software
realisiert. Die stetig steigende Komplexität von Software aufgrund erhöhter Vernetzung und
steigender Anforderungen führt dabei zu neuen Herausforderungen bei der Softwareentwick-
lung. Die verteilte Realisierung der Softwarekomponenten stellt aufgrund des dadurch beding-
ten umfangreichen Kommunikationsverhaltens eine der Hauptursachen für steigende Kom-
plexität dar. Daher ist es wichtig, eine klare Trennung zwischen den Komponenten mittels
definierter Schnittstellen (Interfaces) zu schaffen, um die möglichen Kommunikationsverbin-
dungen einzuschränken.
Beispiele für komplexe verteilte Systeme sind Netzwerkspiele sowie sämtliche Peer-To-
Peer-Systeme oder Client-Server-Anwendungen. Hierzu zählen sowohl Massively Multi-
player Online Role-Playing Games (MMORPG) als auch einfachere netzwerkfähige Spiele
wie beispielsweise ein verteiltes Brettspiel.
Im diesjährigen Softwaretechnik- und Softwarepraktikum soll eine verteilte Anwendung
in Form einer netzwerkfähigen Monopoly-Variante entwickelt werden. Dabei sollen unter-
schiedliche Spielkonfigurationen ermöglicht werden, wie z.B. unterschiedliche Spielbretter.
Ein Server soll ein Spiel verwalten und die einzelnen Spielzüge überwachen, während unter-
schiedliche Clients sich an diesem Server anmelden und als Spieler oder Beobachter am Spiel
teilnehmen können. Spieler-Clients werden entweder von einem Menschen bedient oder durch
eine Künstliche Intelligenz (KI) gesteuert. Beobachter-Clients sind hingegen nur Zuschauer,
die den Spielablauf nicht aktiv beeinflussen können.
Abbildung 1 zeigt eine Situation in einem konventionellen Monopoly-Spiel. Das Spielbrett
besteht größtenteils aus Straßen, aber beinhaltet außerdem weitere Sonderfelder. Ziel des
Spiels ist es, durch den Kauf von Straßen und Häusern möglichst viel Geld zu erwirtschaften
und damit ein möglichst großes Vermögen zu erreichen. Unsere Variante von Monopoly soll
dem Originalspiel ähnlich sein, jedoch strategischer und somit weniger glücksabhängig.
Abbildung 1: Monopoly Beispielsituation (Quelle: http://www.hasbro.com)
Im nächsten Kapitel wird der Einsatz der Anwendung beschrieben und die Regeln des Spiels
festgelegt. Zudem wird auch eine Beschreibung der einzelnen verteilten Komponenten vorge-
nommen und ihre Aufgaben erläutert.
12 Produkteinsatz
2 Produkteinsatz
In diesem Kapitel wird beschrieben, welches Produkt bzw. welche einzelnen Produktkompo-
nenten im diesjährigen Praktikum zu erstellen sind und für welchen Einsatz sie vorgesehen
sind. Zunächst wird eine Übersicht über das gesamte Produkt (Abschnitt 2.1) gegeben. An-
schließend werden die Vorgaben an den Entwicklungsprozess definiert (Abschnitt 2.2) und die
generelle Nutzung des Produktes erklärt (Abschnitt 2.3). Danach werden die Spielregeln für
das Monopoly-Spiel festgelegt (Abschnitt 2.4). Zuletzt wird ein Anwendungsszenario eines
Spielablaufs (Abschnitt 2.5) beschrieben.
2.1 Übersicht
Mit dem zu entwickelnden Produkt soll es möglich sein, Monopoly1 über ein Netzwerk spielen
zu können. Dabei kommen PCs und Android-Devices zum Einsatz. Die Mitspieler können
dabei menschliche Spieler und KI-Spieler2 sein. Somit ist es auch möglich ein Spiel aus-
schließlich mit KI-Spielern durchzuführen.
Das Produkt besteht aus einem Server und mehreren Clients (siehe Abbildung 2). Der Ser-
ver besteht aus den Produktkomponenten Spiel-Engine und Spielkonfigurator. Für die Eingabe
einer konkreten Spielkonfiguration an die Spiel-Engine wird ein Konfigurationsinterface be-
nötigt. Clients werden in Beobachter- und Spieler-Clients unterteilt. Beobachter-Clients sind
die Produktkomponenten PC-Beobachter und Smartphone-Beobachter. Spieler-Clients sind
die Produktkomponenten Smartphone-Spieler (eine Smartphone-Anwendung für menschliche
Spieler) und KI-Spieler (ein PC-Client). Für die Interaktion zwischen Server und Clients sind
Server- und Client-Interfaces (für Beobachter und Spieler) notwendig.
Abhängig davon, ob Sie ein Softwaretechnikpraktikums-Team (SWTPra) oder ein Software-
praktikums-Team (SoPra) sind, müssen Sie unterschiedliche Produktkomponenten des Pro-
duktes selbst entwickeln. Die Interfaces zwischen den Produktkomponenten erstellen alle
Teams gemeinsam in einem zu bildenden Interface-Komitee. Da Sie außerdem einige Produkt-
komponenten im Verlauf des Projektes von anderen Teams erwerben, wird Ihr finales Produkt
mehr Produktkomponenten enthalten als Sie selbst programmieren. SWTPra-Teams geben
daher letztlich ein Produkt bestehend aus Spielkonfigurator, Spiel-Engine, PC-Beobachter,
Smartphone-Beobachter, Smartphone-Spieler und KI-Spieler ab. SoPra-Teams hingegen ge-
ben letztlich ein Produkt bestehend aus Spielkonfigurator, Spiel-Engine, PC-Beobachter, Smart-
phone-Beobachter und KI-Spieler ab.
2.2 Vorgaben an den Entwicklungsprozess
Wir erwarten von Ihnen, dass Sie Ihr Produkt entsprechend dem V-Modell entwickeln.
1
http://de.wikipedia.org/wiki/Monopoly
2
KI steht für Künstliche Intelligenz. Die Spielfigur wird somit ausschließlich vom Computer gespielt.
22.2 Vorgaben an den Entwicklungsprozess
Server
Spielkonfigurator Spiel-Engine
Netzwerk
Clients
PC- Smartphone- Smartphone- KI-Spieler
Beobachter Beobachter Spieler
SWTPra SoPra Interface-Komitee
Abbildung 2: Übersicht über das zu entwickelnde Produkt
Mit dem hier vorliegenden Lastenheft sind von unserer Seite alle Anforderungen definiert,
sodass Sie uns als erstes ein Angebot und eine Aufwandsschätzung machen können. Anschlie-
ßend erwarten wir von Ihnen ein Pflichtenheft in dem Sie definieren, wie und womit Sie unsere
Anforderungen umsetzen wollen. Sobald wir mit diesem einverstanden sind, erwarten wir,
dass Sie die von uns vorgegebenen Technologien (Android, JSON, EMF, ...) analysieren und
anschließend Ihr Produkt entwerfen. Analyse und Entwurf sollen dabei in einem gemeinsa-
men Dokument festgehalten werden.
Zum Entwurf zählen wir auch die Definition der Client- und Server-Interfaces sowie das
Interface zwischen dem Spielkonfigurator und der Spiel-Engine. An der Entwicklung dieser
Interfaces sind Sie durch Ihre Teilnahme an einem Interface-Komitee beteiligt. Das Interface-
Komitee wird aus je einen Interface-Beauftragten von jedem Team gebildet. Zu Beginn wäh-
len die Interface-Beauftragten einen Vorsitzenden, der das Komitee leitet. Entscheidungen
sind im Komitee nur gültig, wenn sich die Mehrheit dafür ausspricht. Enthaltungen sind hier-
bei möglich. Das Komitee wird durch den Programmierberater unterstützt. Alle Interfaces
müssen eine Woche vor der Abgabe des Analyse- und Entwurfsdokuments in einer (vorläufi-
gen) finalen Version definiert sein, sodass sich Ihr Dokument auf diese Version beziehen kann.
Falls während der Implementierung Änderungen an den Interfaces notwendig sind, muss sich
das Komitee erneut zusammenfinden. Vor dem Turnier wird eine Version 2.0 definiert, die alle
Teams in Ihrer Endabgabe unterstützen müssen.
32 Produkteinsatz Sind wir mit Ihrem Entwurf einverstanden, erwarten wir, dass Sie mit der Implementierung Ihrer Produktkomponenten beginnen. Während Ihrer Implementierungsphase wird eine Messe stattfinden, die zur Präsentation sowie zum Erwerb bzw. Herausgeben der bisher erstellen Produktkomponenten aller Teams dient. Wir erwarten, dass bis zur Messe bereits die Produkt- komponenten Spiel-Engine, Spielkonfigurator (nur SWTPra), PC-Beobachter (nur SWTPra) und Smartphone-Beobachter (nur SoPra) fertig gestellt sind. Sind Sie ein SWTPra-Team, erwarten wir von Ihnen, dass Sie die Produktkomponenten PC-Beobachter und Spielkonfigu- rator den SoPra-Teams zum kostenlosen Erwerb anbieten. Sind Sie ein SoPra-Team, erwar- ten wir von Ihnen, dass Sie Ihre Produktkomponente Smartphone-Beobachter den SWTPra- Teams zum kostenlosen Erwerb anbieten. Für die SoPra-Teams gilt, dass die beiden zu er- werbenden Produktkomponenten PC-Beobachter und Spielkonfigurator nicht vom gleichen SWTPra-Team stammen müssen. Nach der Messe erwarten wir von Ihnen, dass Sie die erworbenen Produktkomponenten in Ihr Produkt integrieren und diese Integration testen. Bezüglich Ihrer vertriebenen Produkt- komponenten erwarten wir, dass Sie schwerwiegende Fehler in der Software beheben und neue Versionen den Erwerbern zugänglich machen. Parallel zur Integration und zur Fehlerbe- hebung erwarten wir von Ihnen, dass Sie einen KI-Spieler entwickeln, der unsere Monopoly- Variante so erfolgreich wie möglich spielt. Sind Sie ein SWTPra-Team erwarten wir von Ihnen zusätzlich, dass Sie die Produktkomponente Smartphone-Spieler implementieren, wo- durch ein menschlicher Spieler unsere Monopoly-Variante mit dem Smartphone spielen kann. Wir empfehlen Ihnen hierbei die Weiterentwicklung des von Ihnen eingekauften Smartphone- Beobachters und keine vollständige Neuentwicklung. Nachdem Sie Ihr Produkt und alle dazugehörigen Dokumente fertig gestellt haben (hierzu zählt auch eine Webseite, auf der Sie Ihr Produkt und dessen Dokumente präsentieren), er- warten wir von Ihnen eine Abschlusspräsentation inklusive einer Live-Demonstration Ihres Produktes. Am Ende des Praktikums werden wir Sie und alle anderen Teams zu einem Turnier ein- laden. Ihr Team wird dabei durch Ihren entwickelten KI-Spieler vertreten sein. Durch einen noch festzulegenden Turniermodus und eine noch zu definierende Spielkonfiguration wird durch das Turnier der beste KI-Spieler ermittelt. Des Weiteren werden nach dem Turnier die SWTPra- und SoPra-Teams geehrt, die - unabhängig vom besten KI-Spieler - im Verlauf des Praktikums am besten waren. 2.3 Generelle Nutzung des Produktes Die beteiligten Produktkomponenten an einem Spiel sind ein Server und mindestens zwei aktiv teilnehmende Spieler-Clients, wobei es sich sowohl um menschliche Spieler, als auch um KI- Spieler handeln kann. Zusätzlich kann es eine beliebige Anzahl an Beobachtern geben, die das Spiel beobachten ohne darauf Einfluss nehmen zu können. Nachdem ein Benutzer in der Rolle des Ausrichters den Server startet, können sich andere Benutzer in der Rolle als Spieler oder Beobachter mit ihren Clients bei diesem registrieren, um entweder ein Spiel zu verfolgen, selbst zu spielen oder einen KI-Spieler antreten zu lassen. 4
2.4 Spielregeln
Ein PC-Benutzer kann auch Ausrichter und Spieler zugleich sein.
Die in einem Spiel verwendete Spielkonfiguration wird vor Beginn des Spiels vom Ausrich-
ter in der Spiel-Engine ausgewählt. Dazu kann der Ausrichter vom Server aus Spielkonfigura-
tionen laden, die zuvor mithilfe eines Spielkonfigurators erstellt wurden. Eine Konfiguration
der Spiel-Engine vom Client aus ist nicht gefordert. Eine Spielkonfiguration beinhaltet z.B.
die Beschaffenheit des Spielbretts (Anzahl und Art der Straßen) und die Auswahl der Spiel-
regeln (siehe Abschnitt 2.4). Ist die Spielkonfiguration geladen und die Mindestspieleranzahl
erreicht, muss der Ausrichter die Startreihenfolge der Spieler festlegen. Anschließend kann
der Ausrichter das Spiel starten.
Bevor das Anwendungsszenario Praktikumsturnier definiert wird, werden im folgenden
Abschnitt die Spielregeln definiert.
2.4 Spielregeln
Das Spiel Monopoly bietet viele Möglichkeiten für verschiedene Varianten. Unsere Variante
von Monopoly soll strategischer als das Originalspiel sein und somit weniger glücksabhängig.
In diesem Kapitel wird definiert, wie unsere Variante im Praktikum aussieht.
2.4.1 Begriffsdefinitionen
• Eine Spielkonfiguration enthält alle erforderlichen Daten über ein Spiel, um dieses zu
starten: Spielbrett (inkl. Spielfelder), Regeln und Spielelemente (Figuren, Geld, Stra-
ßenkarten, Häuser, Würfel bzw. Würfelkombinationen).
• Ein Spielbrett ist der Bereich, in dem jeder Spieler mit einer Figur vertreten ist. Das
Spielbrett besteht aus Feldern. Ein Feld hat immer exakt ein Vorgängerfeld und exakt
ein Nachfolgerfeld. Eine Figur steht immer auf einem Feld.
• Jeder Spieler wird durch eine Spielfigur repräsentiert. Zudem besitzt jeder Spieler bzw.
jede Spielfigur eine Bargeldsumme. Hat der Spieler am Ende seines Zuges eine negative
Bargeldsumme, so ist er bankrott und wird vom Spiel ausgeschlossen.
• Das Vermögen eines Spielers ergibt sich aus folgender Summe: Seine Bargeldsumme,
der Wert seiner Straßen und der Wert seiner Häuser. Der Wert einer Straße (der Stra-
ßenwert) entspricht 50 Prozent der Anschaffungskosten dieser Straße. Der Wert eines
Hauses (der Hauswert) entspricht 50 Prozent der Anschaffungskosten dieses Hauses.
• Die Bank besitzt unendlich viel Geld, sowie alle verfügbaren Straßen und Häuser, die
nicht von einem Spieler besessen werden.
• Ist der Spieler am Zug, muss er eine bestimmte Reihenfolge von Phasen ausführen.
Nicht alle Phasen müssen bzw. dürfen in jedem Zug ausgeführt werden. Haben alle
Spieler ihren Zug durchgeführt, so ist die Runde vorbei.
52 Produkteinsatz
• Betritt der Spieler ein Feld, kann dies ein Feldereignis auslösen. Dies kann z.B. bewir-
ken, dass er Geld zahlen muss, Geld erhält, auf ein anderes Feld wechseln muss oder
eine Straße kaufen kann.
• Die Steuerkasse sammelt alle Einnahmen, die alle Spieler durch das Abgeben von Steu-
ern (durch Betreten des Feldes Steuer oder durch das Freikaufen aus dem Gefändnis)
entrichtet haben. Sobald ein Spieler seinen Zug auf einem Frei-Parken-Feld beendet,
entnimmt er alle enthaltenen Steuern der Steuerkasse.
2.4.2 Ziel des Spiels
Ein Spieler kann das Spiel (je nach Spielkonfiguration) auf unterschiedliche Arten gewinnen:
• Er gewinnt, wenn er am Ende seines Zuges ein bestimmtes Vermögen erwirtschaftet
hat. Dieses Vermögensziel ist in der Spielkonfiguration definiert. Das Spiel ist sofort
gewonnen, auch wenn die Runde noch nicht beendet ist.
• Er gewinnt, wenn er der letzte verbliebene Spieler ist (alle anderen Spieler sind bank-
rott).
• Optional kann auch eine maximale Rundenanzahl definiert werden. Falls diese Run-
denanzahl überschritten ist, so ist das Spiel am Ende der Runde beendet und es gewinnt
der Spieler der das meiste Vermögen erwirtschaftet hat. In diesem Fall kann es somit
auch mehrere Gewinner geben, wenn mehrere Spieler am Ende der Runde das gleiche
Vermögen haben.
2.4.3 Spielelemente, Aufbau und Spielablauf
Die Spielelemente, der Aufbau und der Spielablauf sehen folgendermaßen aus:
2.4.3.1 Spielelemente
• 2-12 Spielfiguren (je Spieler eine; die konkrete Anzahl definiert die Spielkonfiguraton)
• 1 Bank (von der Spiel-Engine verwaltet) mit unendlich viel Geld
• Mehrere Felder (mind. das Startfeld, das Gefängnisfeld, das Gehe-Ins-Gefängnis-Feld
und ein Straßenfeld)
• 1 Steuerkasse zum Sammeln aller Steuerbeträge (von der Spiel-Engine verwaltet)
• Begrenzte Anzahl an Häusern (in Spielkonfiguration definiert)
• 2 klassische 6-Seiten-Würfel (W6-Würfel) bzw. 36 Würfelkombinationen
62.4 Spielregeln
2.4.3.2 Aufbauen
• Der Ausrichter wählt eine Spielkonfiguration.
• Die Spieler melden sich am Server bzw. an der Spiel-Engine an.
• Je Spieler wird eine Figur auf das Startfeld gesetzt.
• Die Reihenfolge der Spieler wird manuell vom Ausrichter bestimmt.
• Abhängig von der Reihenfolge erhalten die Spieler ihr Startkapital von der Bank (der
Betrag, den der erste Spieler erhält, ist durch die Spielkonfiguration definiert). Jeder
nachfolgende Spieler erhält einen zu definierenden Prozentsatz mehr als sein Vorgänger
(Standard: 10%).
• Die Spieler haben zu Beginn keine Straßen und somit auch keine Häuser.
2.4.3.3 Spielablauf
1. Der erste Spieler beginnt das Spiel.
2. Die Spieler sind entsprechend ihrer Reihenfolge am Zug. Wenn der letzte Spieler seinen
Zug beendet hat, ist der erste Spieler wieder dran. Spieler, die bankrott sind, können
keinen Zug mehr ausführen.
3. Phasen während eines Zuges
a) Falls der Spieler im Gefängnis ist, kann er sich frei kaufen. Wie das geht steht bei
den Erklärungen zum Gefängnisfeld.
b) Würfeln
• Es gibt zwei verschiedene Arten des Würfelns (vor Spielbeginn in der Spiel-
konfiguration festgelegt): ’Würfelkombination aussuchen’ und ’zufällig wür-
feln’
– Würfelart Würfelkombination aussuchen ist gewählt: Zu Beginn des Spiels
sind alle 36 Würfelkombinationen, die mit zwei W6-Würfeln erreicht
werden können, in der Würfelkombinationsliste verfügbar. Die Würfel-
kombinationsliste wird von der Spiel-Engine verwaltet. Es gibt nur eine
Würfelkombinationsliste je Spiel. Wenn ein Spieler würfeln muss, so
sucht er sich eine Würfelkombination aus der Liste aus. Die Spiel-Engine
löscht diese Kombination aus der Liste. Beim nächsten Würfeln steht die
Kombination nicht mehr zur Verfügung. Ist die letzte Würfelkombination
aus der Liste gelöscht, wird die Liste mit allen 36 Würfelkombinationen
wieder gefüllt.
72 Produkteinsatz
– Würfelart Zufällig Würfeln ist gewählt: Die Spiel-Engine wählt zufällig
eine der 36 Würfelkombinationen.
• Würfelt der Spieler einen Pasch, muss er noch einmal würfeln bzw. noch
einmal wählen. Es gilt hier zu beachten, dass das Ziehen der Figur nicht
bereits nach dem ersten Pasch stattfinden darf.
• Ein Spieler, der innerhalb eines Zuges zweimal einen Pasch würfelt bzw.
wählt, muss ins Gefängnis. Er wird daher auf das Gefängnisfeld gesetzt und
der Zug ist für ihn beendet.
c) Ziehen
• Der Spieler zieht die entsprechende Anzahl Felder des Würfelergebnis im
Uhrzeigersinn (falls er einen Pasch hatte, dann die Summe aus beiden Wür-
felergebnissen).
• Falls der Spieler am Startfeld vorbei zieht, erhält er den in der Spielkonfigu-
ration definierten Geldbetrag von der Bank. Alle anderen Felder haben beim
Ziehen keine Bedeutung.
d) Je nach Art des Feldes auf dem der Spieler landet (siehe Abschnitt 2.4.4) führt der
Spieler das Feldereignis dieses Feldes aus.
e) Der Spieler darf seine Häuser und Straßen verkaufen. Für jeden Hausverkauf und
für jeden Straßenverkauf erhält der Spieler 50 Prozent der jeweiligen Anschaf-
fungskosten zurück. Ihm wird somit der Straßenwert bzw. der Hauswert in Bar
ausgezahlt. Das Geld kommt von der Bank. Die Häuser bzw. die Straßen gehen
zurück an die Bank. Ein Verkauf an andere Spieler ist nicht möglich.
f) Der Spieler darf für seine Straßen Häuser kaufen (unabhängig davon ob er sich
grade auf der entsprechenden Straße befindet), falls er die Voraussetzungen (der
Spieler hat alle Straßen der gleichen Farbe; der Spieler besitzt genug Bargeld; die
Bank besitzt noch genügend Häuser) hierfür erfüllt hat. Der Anschaffungspreis für
ein Haus entspricht 50 Prozent des Anschaffungspreises der Straße (das Geld geht
an die Bank).
4. Nach jedem Zug
a) Die Spiel-Engine prüft, ob der Spieler bankrott ist und daher aus dem Spiel entfernt
werden muss.
b) Die Spiel-Engine prüft, ob eine Siegbedingung erfüllt ist. Wenn ja, wird das Spiel
beendet.
2.4.4 Arten von Feldern
Es gibt folgende Arten von Feldern:
82.4 Spielregeln
• Start: Der Spieler erhält einen bestimmten Betrag, wenn er an diesem Feld vorbeiläuft.
Wenn sein Zug auf diesem Feld endet, verdoppelt sich dieser Betrag. Das Feld existiert
nur einmal je Spielfeld.
• Gehe ins Gefängnis: Endet der Zug des Spielers auf diesem Feld, muss er in den
Gefängnisbereich des Gefängnisfeldes. Das Feld existiert mind. einmal je Spielfeld.
• Gefängnis:
– Das Feld ist zweigeteilt: Es gibt den Gefängnisbereich und den Besuchsbereich.
– Endet der Zug eines Spielers auf dem Gefängnisfeld, so ist er nur zu Besuch und
nichts weiteres passiert.
– Ist er durch ein anderes Ereignis (Gehe ins Gefängnis-Feld oder Doppel-Pasch)
ins Gefängnis gekommen, kann er sich aus dem Gefängnis frei kaufen oder die
nächsten zwei Runden aussetzen. Wenn er sich in der ersten Runde, die er im
Gefängnis ist, frei kaufen möchte, so bezahlt er die Hälfte des Betrages den man
erhält, wenn man über das Startfeld zieht. Eine Runde später ist es nur noch ein
Viertel des Preises. Nach zweimaligem Aussetzen kommt er kostenlos aus dem
Gefängnis. Der Verkauf von Straßen und Häuser ist für die Zeit möglich. Miete
einnehmen und Häuserkauf sind für die Zeit im Gefängnis nicht möglich. Das Feld
existiert nur einmal je Spielfeld.
• Straße:
– Jede Straße hat einen Namen, einen Anschaffungspreis und eine Farbe. Diese drei
Eigenschaften sind in der Spielkonfiguration definiert. Zudem besitzt die Straße
auch einen Straßenwert, der immer die Hälfte des Anschaffungspreises ist.
– Alle Straßen gehören initial der Bank. Eine Straße kann aber auch einem Spieler
gehören. Ein Spieler dessen Zug auf einer Straße endet, die noch keinem Spieler
gehört, kann diese für den Anschaffungspreis kaufen (das Geld geht an die Bank).
– Ein Spieler darf seine Straßen verkaufen
– Besitzt ein Spieler alle Straßen einer Farbe, darf er in jedem Zug jeweils ein Haus
auf jede dieser Straße bauen. Die maximale Häuseranzahl einer Straße ist in der
Spielkonfiguration definiert.
– Jede Straße hat einen Mietpreis, der 10 Prozent des Anschaffungspreises der Straße
entspricht, solange kein Haus auf der Straße gebaut ist. Mit jedem weiteren Haus
verdoppelt sich der absolute Mietpreis. Ein Spieler dessen Zug auf einer Straße
endet die einem Spieler gehört, muss Miete entsprechend des aktuellen Mietprei-
ses an den Besitzer zahlen. Die Miete muss nicht entrichtet werden, wenn der
Vermieter im Gefängnis sitzt.
92 Produkteinsatz
– Häuser können für Ihren Hauswert an die Bank verkauft werden. Straßen können
für Ihren Straßenwert an die Bank verkauft werden, wenn Sie ohne Häuser sind.
Ein Verkauf von Häusern und Straßen an andere Spieler ist nicht möglich.
• Steuer: Endet der Zug des Spielers auf diesem Feld, muss er die für dieses Feld festge-
legte Steuer bezahlen (die Steuer je Feld wird in der Spielkonfiguration definiert). Das
Geld erhält jedoch nicht die Bank, sondern es kommt in die Steuerkasse. Es braucht
kein Steuerfeld auf dem Spielfeld zu existieren.
• Gewinn: Endet der Zug des Spielers auf diesem Feld, erhält er den für dieses Feld
festgelegten Betrag von der Bank geschenkt (der Gewinn je Feld wird in der Spielkon-
figuration definiert). Es braucht kein Gewinnfeld auf dem Spielfeld zu existieren.
• Frei Parken: Endet der Zug des Spielers auf diesem Feld, erhält er alle Steuern, die
sich in der Steuerkasse befinden. Es braucht kein Frei-Parken-Feld auf dem Spielfeld
zu existieren.
2.4.5 Nicht Teil unserer Monopoly-Variante
Unter anderem sind folgende Bestandteile des Original-Monopoly nicht Teil unseres Spiels:
• Handel mit anderen Spielern (Geld, Straßen) ist nicht möglich.
• Kredite, Stundungen und Hypotheken sind nicht möglich.
• Eine gleichmäßige Haus-Bebauung der Straßen ist nicht gefordert.
• Folgende Felder sind nicht enthalten:
– Es gibt keine Ereignisfelder und somit auch keine Ereigniskarten.
– Es gibt keine Gemeinschaftsfelder und somit auch keine Gemeinschaftskarten.
– Es gibt keine Bahnhöfe.
– Es gibt kein Wasserwerk und kein Elektrizitätswerk.
2.5 Anwendungsszenario: Praktikumsturnier
Ein Anwendungsszenario für Ihr Produkt ist das Turnier (und dessen Vorbereitung), welches
am Ende des Praktikums stattfindet.
Am Turnier werden die von den Teams entwickelten KI-Spieler gegeneinander antreten.
Die Spiel-Engine für das Turnier wird entweder von uns selbst entwickelt oder eine Spiel-
Engine von einem der Teams sein. Ebenso verhält es sich mit der Visualisierung des Turniers.
Das Turnier kann von allen Turnierzuschauern zusätzlich mittels des Smartphone-Beobachters
bzw. des PC-Beobachters verfolgt werden.
102.5 Anwendungsszenario: Praktikumsturnier
Für die Spielkonfiguration des Turniers ist bisher nur festgelegt, dass die Würfelart „Wür-
felkombination aussuchen“ sein wird. Alle anderen Konfigurationen sind noch nicht festgelegt
bzw. werden nicht vor dem Turnier veröffentlicht. Sie sollten daher vor dem Turnier mit dem
Spielkonfigurator verschiedene Spielkonfigurationen anlegen, um Ihren KI-Spieler zu testen.
Zum Testen des KI-Spielers sollte das von Ihnen erstellte Produkt sehr hilfreich sein.
113 Produktfunktionen und -leistungen
3 Produktfunktionen und -leistungen
Die einzelnen Teile des Produktes müssen bestimmte Funktionen und Anforderungen erfüllen.
Dabei wird unterschieden zwischen verbindlichen und optionalen Anforderungen. Die ver-
bindlichen Anforderungen müssen von Ihnen erfüllt werden, die optionalen können freiwillig
umgesetzt werden. Sofern nicht anders angegeben, sollen von allen Produktkomponenten alle
in Abschnitt 2.4 beschriebenen Spielregeln berücksichtigt werden.
3.1 Netzwerk
• Verbindlich: Ihre Client-Server-Anbindung soll im lokalen Netzwerk (LAN) sowie via
Internet funktionieren.
3.2 Spiel-Konfigurator
• Verbindlich: Durch eine geeignete Oberfläche lässt sich das Spiel entsprechend der
Regeln konfigurieren (Häuseranzahl, Startkapital, Würfelart, ...).
• Verbindlich: Eine quadratische Spielfläche kann modelliert werden (Größe, Felder, ...).
• Optional: Zufällige Spielkonfigurationen können vorgeschlagen werden.
• Optional: Für die Erstellung der Turnierkonfiguration gibt es eine schnelle Möglichkeit,
ohne dass der Benutzer alle Regeln selbst einstellen muss.
3.3 Spiel-Engine
3.3.1 Start eines Spiels
• Verbindlich: Alle Clients werden von der Spiel-Engine verwaltet: Sie können sich an
der Spiel-Engine registrieren und werden entsprechend ihrer Rolle (Spieler oder Beob-
achter) behandelt. Es reicht aus, eine Registrierung nur zu erlauben während kein Spiel
läuft (wenn ein Spiel pausiert ist, wird es trotzdem als laufend erachtet).
• Verbindlich: Zum Starten eines Spiels muss der Spiel-Engine-Benutzer (der Ausrich-
ter) aus einer Liste registrierter Spieler mindestens zwei auswählen können, die gegen-
einander antreten. Zudem kann entweder durch Zufall oder durch eine explizite Aus-
wahl die Reihenfolge der Spieler bestimmt werden.
• Verbindlich: Auf einer Spiel-Engine darf zu einem Zeitpunkt immer nur höchstens ein
Spiel laufen. Es können keine parallel laufenden Spiele gestartet werden.
123.3 Spiel-Engine
3.3.2 Spielverlauf
• Verbindlich: Während des Spiels muss die Spiel-Engine den Spieler-Client, der am
Zug ist, auffordern, seine Phasen durchzuführen. Pro Phase schickt die Spiel-Engine
eine Aufforderung, die der Client mit einer entsprechenden Aktion beantworten muss.
Sofern diese Aktion gültig ist, wird sie ausgeführt.
• Verbindlich:
Die Spiel-Engine prüft bei jeder Aktion eines Clients die Einhaltung der Regeln (siehe
Abschnitt 2.4) und merkt sich Regelverstöße pro Client. Zu Regelverstößen gelten z.B.
folgende Fälle:
1. Ein Spieler versucht auf einer Straße ein Haus zu bauen, die ihm nicht gehört.
2. Ein Spieler versucht auf einer Straße ein Haus zu bauen, obwohl er nicht alle Stra-
ßen der zugehörigen Farbe besitzt.
3. Ein Spieler bezahlt einen vorgeschriebenen Geldbetrag nicht oder nur teilweise.
Auch die übrigen Clients werden über einen Regelverstoß informiert. Der Regelverstoß
wird selbstverständlich nicht vom Server ausgeführt.
• Verbindlich: Nach drei Regelverstößen eines Spielers in einem Spiel, wird dieser Spie-
ler von der Spiel-Engine vom Spiel ausgeschlossen. Hierüber werden alle Clients infor-
miert.
• Verbindlich: Der Benutzer kann vor dem Spielstart einen 5 Sekunden-Timeout der KI-
Spieler aktivieren. Führt ein KI-Spieler innerhalb dieser Zeit keine Aktion durch, wird
dieser automatisch aus dem Spiel genommen, was eine entsprechende Benachrichtigung
aller Clients (Spieler und Beobachter) zur Folge hat. Dasselbe gilt ebenfalls für sonstige
Anfragen der Spiel-Engine an die KI-Spieler.
• Optional: Die Spiel-Engine kann dem Benutzer mittels einer geeigneten Eingabemög-
lichkeit ermöglichen, die maximal erlaubte Dauer für die Aktionen eines KI-Spielers
oder sonstige Anfragen in einem Spiel festzulegen.
• Optional: Auch für menschliche Spieler (nicht nur für KI-Spieler) können Zeitbe-
schränkungen angegeben werden.
• Verbindlich: Nach jeder Spielaktion soll die Engine 1 Sekunde pausieren, sodass genug
Zeit für die Visualisierung der Aktion bleibt.
• Verbindlich: Nach jedem Zug soll die Engine zusätzlich 5 Sekunden pausieren, sodass
genug Zeit für die Visualisierung des Zuges bleibt.
• Optional: In der Engine kann vor Spielbeginn konfiguriert werden, wie lange nach
jeder Aktion und nach jedem Zug gewartet werden soll.
133 Produktfunktionen und -leistungen
• Verbindlich: Alle Clients werden über korrekte Aktionen und das daraus folgende Er-
gebnis informiert.
• Verbindlich: Ein Spiel lässt sich über die Benutzeroberfläche der Spiel-Engine pau-
sieren, fortsetzen und beenden. Bei einem manuellen Abbruch wird das Spiel nicht
gewertet. Die Clients werden über diese Statusänderungen in Kenntnis gesetzt.
• Verbindlich: Nach jeder Aktion überprüft die Spiel-Engine das Vorliegen der Bedin-
gungen für eine Niederlage eines Spielers. Ist dies der Fall, so wird dies jedem Client
mitgeteilt. Bleibt nur noch ein Spieler übrig, gewinnt dieser und die Spiel-Engine teilt
jedem Client das Ende des Spiels und den Gewinner mit.
• Optional: Alle in einem Spiel abgegebenen Aktionen und ihre Ergebnisse werden an-
gezeigt, z.B. in einer Liste.
3.4 Clients
• Verbindlich: Jeder Client soll über eine geeignete Oberfläche gestartet und beenden
werden können.
• Verbindlich: Jeder Client soll es ermöglichen, sich mit der Spiel-Engine zu verbinden
und sich bei dieser zu registrieren.
3.4.1 PC- und Smartphone-Beobachter (Beobachter-Client)
• Verbindlich: Der Beobachter-Client enthält die Anzeige des Spielbretts, eine visuali-
sierte Übersicht über die aktuell eingestellten Regeln und eine visualisierte Übersicht
über Spielinformationen, wie aktuelle Würfelkombination, Steuern in der Steuerkasse
und Spielstatus (aktiver Spieler, Gewinner des Spiels etc.). Für das Spielbrett werden
die Felder entsprechend ihrer Art visualisiert. Felder müssen weiterhin gesetzte Figuren
und gebaute Häuser anzeigen können. Zudem sollen auch Regelverstöße von Spielern
angezeigt werden.
• Verbindlich: Die Visualisierung eines Zuges soll beendet sein, bevor der nächste Zug
stattfindet.
• Optional: Würfeln und Figurbewegungen werden per Animation visualisiert.
• Optional: Eine Spielstatistik wird angezeigt (welcher Spieler hat noch wie viel Geld
und wie viele Häuser, wie war dies über den Spielverlauf hinweg, Zeit,...).
143.4 Clients
3.4.2 Smartphone-Spieler
• Verbindlich: Es gelten die gleichen Produktfunktionen wie bei den Beobachter-Clients.
• Verbindlich: Der Smartphone-Spieler muss es dem Benutzer ermöglichen, Aktionen
durchzuführen, sofern der Spieler am Zug ist.
• Verbindlich: Der Smartphone-Spieler darf keine ungültigen Aktionen an die Spiel-
Engine übermitteln (siehe Regeln).
3.4.3 KI-Spieler
• Verbindlich: Der KI-Spieler kann vom PC via Kommandozeile gestartet werden.
• Verbindlich: Beim Start des KI-Spielers wird ihm die IP-Adresse des Servers und der
Port mitgeteilt bei dem sich der KI-Spieler anmelden soll.
• Verbindlich: Der KI-Spieler enthält einen Algorithmus der die nächste Aktion berech-
net und an die Spiel-Engine weiter gibt. Für die Auswahl jeder Aktion stehen dem
KI-Spieler im Turnier maximal 5 Sekunden ab der entsprechenden Anfrage der Spiel-
Engine zur Verfügung.
• Verbindlich: Der KI-Spieler darf keine ungültigen Aktionen an die Spiel-Engine über-
mitteln (siehe Regeln).
• Optional: Der Benutzer kann mittels einer Oberfläche verschiedene Intelligenzstufen
oder andere Parameter einstellen oder einsehen. Die Algorithmen müssen dann aller-
dings auch ohne diese Oberfläche funktionieren können. Hinweis: Während des Tur-
niers können keine Einstellungen an den Algorithmen gemacht werden.
• Optional: Der KI-Spieler kann vom Smartphone aus gestartet werden durch eine sepa-
rate App.
• Optional: Der KI-Spieler wird in die Produktkomponente Smartphone-Spieler inte-
griert und kann von dieser aus gestartet werden. Während die KI spielt, kann der
Smartphone-Benutzer nicht in das Spiel eingreifen.
15A Technische Vorgaben und Hilfestellungen
A Technische Vorgaben und Hilfestellungen
Für die Entwicklung ist ein Abgabeplan vorgegeben, der auf der Webseite der Veranstaltung
veröffentlicht wird. Für die Dokumente stehen dort Vorlagen und Beispiele zur Verfügung.
Zu den gegebenen Deadlines müssen die jeweiligen Dokumente abgegeben werden, Verspä-
tungen werden sanktioniert.
A.1 Allgemeine Richtlinien
• Die Entwicklungssprache ist Englisch. Code und Codekommentare sind dementspre-
chend auf Englisch zu verfassen. Dokumente wie Pflichtenheft, Analyse- und Entwurfs-
dokument oder auch Protokolle können auf Deutsch verfasst werden.
• Codekommentare sollen im Javadoc-Format verfasst werden. Eine Javadoc-Dokumen-
tation des Codes ist Bestandteil der Endabgabe.
A.2 Interfaces
Um die Kompatibilität der Komponenten zu gewährleisten, werden von einem Interface-komitee
geeignete Interfaces für die Kommunikation zwischen den Komponenten entwickelt. Diese
werden in einem gesonderten Dokument beschrieben und eine Woche vor der Abgabe-Deadline
des Analyse- und Entwurfsdokumentes abgegeben.
A.3 Technologien und Entwicklungswerkzeuge
Eine technische Übersicht über die im Praktikum eingesetzten Entwicklungswerkzeuge und
Technologien ist in Abbildung 3 zu sehen.
Die Teilnehmer sollen im Rahmen des SoPra bzw. des SWTPra lernen, sich in ein größeres
Framework einzuarbeiten und sich dessen Vorteile zu Nutze zu machen. Alle Produktkom-
ponenten des Produktes sollen sich mit Hilfe von Eclipse erstellen lassen und sollen auf der
Sprache Java basieren. Die zu entwickelnden Produktkomponenten Spielkonfigurator und
PC-Beobachter sollen zudem als Plug-Ins für die Entwicklungsumgebung Eclipse (http:
//eclipse.org/pde) erstellt werden. Hingegen sollen der Smartphone-Beobachter und
der Smartphone-Spieler als Apps für Android (http://developer.android.com) er-
stellt werden.
Insbesondere Eclipse hat sich als Grundlage für größere Softwareprojekte bewährt und viele
Unternehmen arbeiten mit Software auf Eclipse-Basis, z.B. IBM. Der sichere Umgang mit
der Eclipse-Entwicklungsumgebung wird heutzutage in den meisten Unternehmen im Be-
reich Softwareentwicklung vorausgesetzt. Bezüglich des Smartphone-Marktes ist Android
mittlerweile das am meisten verbreitete Betriebssystem. Daher ist die Fähigkeit, die App-
Entwicklung von Android-Smartphones zu beherrschen, eine wichtige Fähigkeit auf dem Ar-
beitsmarkt.
16A.4 Eclipse Modeling Framework (EMF)
Server
Config
Spielkonfigurator (ecore)
Spiel-
Engine
IServer
Netzwerk
Clients IViewer IPlayer
PC- Smartphone- Smartphone-Spieler KI-Spieler
Beobachter Beobachter
Abbildung 3: Übersicht über die zu verwendenden Technologien und Entwicklungswerkzeuge
Zum Starten von Eclipse ist ein installiertes JDK (Java Development Kit) notwendig. Im
Softwaretechnikpraktikum ist Java SE 6 zu verwenden (Android-Apps werden derzeit haupt-
sächlich in Java 6 programmiert). Die zu verwendende Eclipse-Version ist Eclipse Juno
(4.2.1). Zudem wird die Android-Version 2.3.3 (API-Level 10) verwendet (kompatibel zu
über 90% der derzeitig verfügbaren Android-Geräte).
Abbildung 3 illustriert zudem die Stellen, an denen sich das Interface-Komitee auf Inter-
faces bzw. ein geeignetes Austauschformat einigen muss. Clients und Server nutzen die In-
terfaces IViewer, IPlayer und IServer. Zudem erlaubt der Spielkonfigurator, ein EMF-Modell
(siehe Abschnitt A.4) im ecore-Format auf der Festplatte zu speichern. Dieses Modell be-
schreibt die zum Spiel nötige Spielkonfiguration. Die Spiel-Engine kann diese Konfiguration
dann von der Festplatte laden. Die Erstellung eines Metamodells per EMF (zum Beschreiben
gültiger EMF-Modelle) ist somit ebenfalls Aufgabe des Interface-Komitees.
Um Zugriff auf die Repositories der Veranstaltung zu erhalten, wird ein SVN Client (z.B.
Tortoise SVN, http://tortoisesvn.tigris.org oder als Eclipse-Plugin Subver-
sive, http://eclipse.org/subversive) benötigt.
A.4 Eclipse Modeling Framework (EMF)
Als Ausgabe des Spielkonfigurators werden EMF (Eclipse Modeling Framework)-Modelle
verwendet (siehe http://eclipse.org/modeling/emf). Ein besonders gelungenes
17A Technische Vorgaben und Hilfestellungen Tutorial zum Erstellen von Metamodellen mit EMF ist unter http://www.vogella. com/articles/EclipseEMF/article.html zu finden. Ein Tutorial zum Speichern und Laden von EMF-Modellen ist zudem unter http://www.vogella.com/articles/ EclipseEMFPersistence/article.html beschrieben. A.5 Eclipse Graphical Editing Framework (GEF) und Graphiti Sowohl das Graphical Editing Framework (GEF) als auch Graphiti ermöglichen die Entwick- lung graphischer Editoren und anderer Visualisierungen für Eclipse-basierte Anwendungen, insbesondere für Eclipse-Plugins. GEF und Graphiti sehen eine Entwicklung vor, die dem Architekturmuster Model-View-Controller (MVC) folgt und unterstützen diese durch geeig- nete Erweiterungsstellen, wie beispielsweise Framework-Klassen für View-Objekte, die durch eigene Implementierungen spezialisiert werden können. Wir empfehlen die Visualisierungen des Spielbretts, der Figuren, etc. (PC-Beobachter, Spielkonfigurator), die im Rahmen des SWTPra entwickelt werden, mittels GEF oder Gra- phiti zu erstellen. Alternativ ist auch eine Lösung, die nur auf SWT (http://eclipse. org/swt), oder aber auf anderen Frameworks basiert in Ordnung, solange diese allen be- schriebenen Anforderungen entspricht und Sie Ihre Entscheidung ausführlich begründen. Für diese alternativen Lösungen bieten wir keine gezielte Programmierberatung oder Tutorien an. GEF bzw. Graphiti werden für Forschungsprototypen eingesetzt. Daher ist deren Kenntnis hilfreich für spätere SHK-Stellen und Abschlussarbeiten. Des Weiteren werden die Konzepte von GEF und Graphiti in der Klausur am Ende des Semesters als bekannt vorausgesetzt. In- formationen zu GEF finden sich unter: http://eclipse.org/gef. Informationen zu Graphiti finden sich unter: http://eclipse.org/graphiti. A.6 Android Für die Entwicklung empfiehlt sich das Eclipse-Plug-In ADT (http://developer.android. com/sdk/eclipse-adt.html). Dieses bietet auch einen Emulator zum Durchführen der Anwendung an. Die Kommunikation des Android-Clients mit dem Server soll über Sockets (java.net.Socket) realisiert werden. A.7 JSON Das Übertragungsformat zwischen dem Server und den Clients soll JSON sein. Wie in Ab- bildung 3 zu sehen, müssen durch das Interface-Komitee die Interfaces IServer, IViewer und IPlayer definiert werden. Um serverseitig JSON einfach parsen bzw. erzeugen zu können, kann die Java-Bibliothek Jackson verwendet werden. Diese wird z.B. bei Installation des Plug-Ins emf js (über den Eclipse Marketplace auffindbar) automatisch mit installiert. Die Verwendung wird z.B. unter http://wiki.fasterxml.com/JacksonInFiveMinutes beschrieben. 18
Sie können auch lesen
