Softwaretechnik- und Softwarepraktikum Lastenheft

Transkript

1 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, Paderborn Version 1.0 Paderborn, den 10. April 2013

2 Inhaltsverzeichnis 1 Zielbestimmung 1 2 Produkteinsatz Übersicht Vorgaben an den Entwicklungsprozess Generelle Nutzung des Produktes Spielregeln Begriffsdefinitionen Ziel des Spiels Spielelemente, Aufbau und Spielablauf Arten von Feldern Nicht Teil unserer Monopoly-Variante Anwendungsszenario: Praktikumsturnier Produktfunktionen und -leistungen Netzwerk Spiel-Konfigurator Spiel-Engine Start eines Spiels Spielverlauf Clients PC- und Smartphone-Beobachter (Beobachter-Client) Smartphone-Spieler KI-Spieler A Technische Vorgaben und Hilfestellungen 16 A.1 Allgemeine Richtlinien A.2 Interfaces A.3 Technologien und Entwicklungswerkzeuge A.4 Eclipse Modeling Framework (EMF) A.5 Eclipse Graphical Editing Framework (GEF) und Graphiti A.6 Android A.7 JSON

3 1 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 Softwareentwicklung. Die verteilte Realisierung der Softwarekomponenten stellt aufgrund des dadurch bedingten umfangreichen Kommunikationsverhaltens eine der Hauptursachen für steigende Komplexität dar. Daher ist es wichtig, eine klare Trennung zwischen den Komponenten mittels definierter Schnittstellen (Interfaces) zu schaffen, um die möglichen Kommunikationsverbindungen 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 Multiplayer 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 unterschiedliche Spielkonfigurationen ermöglicht werden, wie z.b. unterschiedliche Spielbretter. Ein Server soll ein Spiel verwalten und die einzelnen Spielzüge überwachen, während unterschiedliche 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: 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 vorgenommen und ihre Aufgaben erläutert. 1

4 2 Produkteinsatz 2 Produkteinsatz In diesem Kapitel wird beschrieben, welches Produkt bzw. welche einzelnen Produktkomponenten 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. Anschließ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, Monopoly 1 über ein Netzwerk spielen zu können. Dabei kommen PCs und Android-Devices zum Einsatz. Die Mitspieler können dabei menschliche Spieler und KI-Spieler 2 sein. Somit ist es auch möglich ein Spiel ausschließlich mit KI-Spielern durchzuführen. Das Produkt besteht aus einem Server und mehreren Clients (siehe Abbildung 2). Der Server besteht aus den Produktkomponenten Spiel-Engine und Spielkonfigurator. Für die Eingabe einer konkreten Spielkonfiguration an die Spiel-Engine wird ein Konfigurationsinterface benö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 Softwarepraktikums-Team (SoPra) sind, müssen Sie unterschiedliche Produktkomponenten des Produktes selbst entwickeln. Die Interfaces zwischen den Produktkomponenten erstellen alle Teams gemeinsam in einem zu bildenden Interface-Komitee. Da Sie außerdem einige Produktkomponenten 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 geben letztlich ein Produkt bestehend aus Spielkonfigurator, Spiel-Engine, PC-Beobachter, Smartphone-Beobachter und KI-Spieler ab. 2.2 Vorgaben an den Entwicklungsprozess Wir erwarten von Ihnen, dass Sie Ihr Produkt entsprechend dem V-Modell entwickeln KI steht für Künstliche Intelligenz. Die Spielfigur wird somit ausschließlich vom Computer gespielt. 2

5 2.2 Vorgaben an den Entwicklungsprozess Server Spielkonfigurator Spiel-Engine Netzwerk Clients PC- Beobachter Smartphone- Beobachter Smartphone- Spieler KI-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 gemeinsamen 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ählen 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 hierbei 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äufigen) 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. 3

6 2 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 Produktkomponenten 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 Spielkonfigurator den SoPra-Teams zum kostenlosen Erwerb anbieten. Sind Sie ein SoPra-Team, erwarten 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 erwerbenden 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 Produktkomponenten erwarten wir, dass Sie schwerwiegende Fehler in der Software beheben und neue Versionen den Erwerbern zugänglich machen. Parallel zur Integration und zur Fehlerbehebung 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, wodurch 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), erwarten 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 einladen. 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

7 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 Ausrichter in der Spiel-Engine ausgewählt. Dazu kann der Ausrichter vom Server aus Spielkonfigurationen 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 Spielregeln (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 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. 5

8 2 Produkteinsatz Betritt der Spieler ein Feld, kann dies ein Feldereignis auslösen. Dies kann z.b. bewirken, 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 Steuern (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 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 bankrott). Optional kann auch eine maximale Rundenanzahl definiert werden. Falls diese Rundenanzahl ü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 Spielelemente, Aufbau und Spielablauf Die Spielelemente, der Aufbau und der Spielablauf sehen folgendermaßen aus: 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 6

9 2.4 Spielregeln 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 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 Spielkonfiguration festgelegt): Würfelkombination aussuchen und zufällig würfeln 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ürfelkombinationsliste 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. 7

10 2 Produkteinsatz c) Ziehen 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. Der Spieler zieht die entsprechende Anzahl Felder des Würfelergebnis im Uhrzeigersinn (falls er einen Pasch hatte, dann die Summe aus beiden Würfelergebnissen). Falls der Spieler am Startfeld vorbei zieht, erhält er den in der Spielkonfiguration 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 Anschaffungskosten 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 Arten von Feldern Es gibt folgende Arten von Feldern: 8

11 2.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: Straße: 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. 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 Mietpreises an den Besitzer zahlen. Die Miete muss nicht entrichtet werden, wenn der Vermieter im Gefängnis sitzt. 9

12 2 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 festgelegte 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 Spielkonfiguration 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 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. 10

13 2.5 Anwendungsszenario: Praktikumsturnier Für die Spielkonfiguration des Turniers ist bisher nur festgelegt, dass die Würfelart Würfelkombination 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. 11

14 3 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 verbindlichen 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 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 Beobachter) 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 Ausrichter) aus einer Liste registrierter Spieler mindestens zwei auswählen können, die gegeneinander antreten. Zudem kann entweder durch Zufall oder durch eine explizite Auswahl 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. 12

15 3.3 Spiel-Engine 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 Spieler von der Spiel-Engine vom Spiel ausgeschlossen. Hierüber werden alle Clients informiert. 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öglichkeit 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 Zeitbeschrä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. 13

16 3 Produktfunktionen und -leistungen Verbindlich: Alle Clients werden über korrekte Aktionen und das daraus folgende Ergebnis informiert. Verbindlich: Ein Spiel lässt sich über die Benutzeroberfläche der Spiel-Engine pausieren, 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 Bedingungen 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 angezeigt, 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 PC- und Smartphone-Beobachter (Beobachter-Client) Verbindlich: Der Beobachter-Client enthält die Anzeige des Spielbretts, eine visualisierte Ü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,...). 14

17 3.4 Clients 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) 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 berechnet 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 übermitteln (siehe Regeln). Optional: Der Benutzer kann mittels einer Oberfläche verschiedene Intelligenzstufen oder andere Parameter einstellen oder einsehen. Die Algorithmen müssen dann allerdings auch ohne diese Oberfläche funktionieren können. Hinweis: Während des Turniers können keine Einstellungen an den Algorithmen gemacht werden. Optional: Der KI-Spieler kann vom Smartphone aus gestartet werden durch eine separate App. Optional: Der KI-Spieler wird in die Produktkomponente Smartphone-Spieler integriert und kann von dieser aus gestartet werden. Während die KI spielt, kann der Smartphone-Benutzer nicht in das Spiel eingreifen. 15

18 A 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 dementsprechend auf Englisch zu verfassen. Dokumente wie Pflichtenheft, Analyse- und Entwurfsdokument oder auch Protokolle können auf Deutsch verfasst werden. Codekommentare sollen im Javadoc-Format verfasst werden. Eine Javadoc-Dokumentation 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 Produktkomponenten 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 ( erstellt 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 Bereich 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 Arbeitsmarkt. 16

19 A.4 Eclipse Modeling Framework (EMF) Server Spielkonfigurator Config (ecore) Spiel- Engine IServer Netzwerk Clients IViewer IPlayer PC- Beobachter Smartphone- Beobachter Smartphone-Spieler KI-Spieler 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 hauptsächlich in Java 6 programmiert). Die zu verwendende Eclipse-Version ist Eclipse Juno (4.2.1). Zudem wird die Android-Version (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 Interfaces bzw. ein geeignetes Austauschformat einigen muss. Clients und Server nutzen die Interfaces 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 beschreibt 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, oder als Eclipse-Plugin Subversive, benötigt. A.4 Eclipse Modeling Framework (EMF) Als Ausgabe des Spielkonfigurators werden EMF (Eclipse Modeling Framework)-Modelle verwendet (siehe Ein besonders gelungenes 17

20 A Technische Vorgaben und Hilfestellungen Tutorial zum Erstellen von Metamodellen mit EMF ist unter com/articles/eclipseemf/article.html zu finden. Ein Tutorial zum Speichern und Laden von EMF-Modellen ist zudem unter 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 Entwicklung 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 geeignete 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 Graphiti zu erstellen. Alternativ ist auch eine Lösung, die nur auf SWT ( org/swt), oder aber auf anderen Frameworks basiert in Ordnung, solange diese allen beschriebenen 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. Informationen zu GEF finden sich unter: Informationen zu Graphiti finden sich unter: A.6 Android Für die Entwicklung empfiehlt sich das Eclipse-Plug-In ADT ( 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 Abbildung 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 beschrieben. 18