Softwaretechnik- und Softwarepraktikum 2016 - Umsetzung eines verteilten Quarto-Spiels
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Softwaretechnik- und Softwarepraktikum 2016
Umsetzung eines verteilten Quarto-Spiels
Lastenheft
Auftraggeber
Eric Bodden, Christopher Gerking,
Johannes Geismann, Philipp Schubert
Fachgruppe Softwaretechnik, Heinz Nixdorf Institut
Fakulät für Elektrotechnik, Informatik und Mathematik
Universität Paderborn, Zukunftsmeile 1, 33102 Paderborn
Version 1.0.1
Paderborn, den 14. April 2016Inhaltsverzeichnis
1 Zielbestimmung 1
2 Produkteinsatz 3
2.1 Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Vorgaben an den Entwicklungsprozess . . . . . . . . . . . . . . . . . . . . . 3
2.3 Generelle Nutzung des Produktes . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Spielregeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4.1 Spielvorbereitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4.2 Spielverlauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.3 Spielende . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5 Anwendungsszenario: Praktikumsturnier . . . . . . . . . . . . . . . . . . . . 8
3 Produktfunktionen und -leistungen 9
3.1 Netzwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Spielkonfigurator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Spiel-Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.1 Start eines Spiels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.2 Spielverlauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.3 Turnierorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4.1 PC- und Smartphone-Beobachter . . . . . . . . . . . . . . . . . . . 11
3.4.2 Smartphone-Teilnehmer . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4.3 KI-Teilnehmer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
A Technische Vorgaben und Hilfestellungen 13
A.1 Allgemeine Richtlinien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
A.2 Technologien und Entwicklungswerkzeuge . . . . . . . . . . . . . . . . . . 13
A.3 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
A.4 Eclipse Modeling Framework (EMF) . . . . . . . . . . . . . . . . . . . . . . 14
A.5 Frameworks zur Erstellung grafischer Editoren . . . . . . . . . . . . . . . . 15
A.6 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
A.7 JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Inhaltsverzeichnis
Changelog
Version 1.0.1
Abschnitt 2.4.2 Die Berechnung der maximal möglichen Anzahl von Spielsteinen wurde
korrigiert.
II1 Zielbestimmung
Ein Großteil der Funktionen moderner technischer Systeme wird durch Software realisiert.
Die steigende Komplexität von Software aufgrund erhöhter Vernetzung und steigender Anfor-
derungen führt dabei zu neuen Herausforderungen bei der Softwareentwicklung. Die verteilte
Realisierung der Softwarekomponenten stellt aufgrund des umfangreichen Kommunikations-
verhaltens 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, über die die Komponenten kommunizieren können. Beispiele für komplexe verteil-
te Systeme sind sämtliche Peer-To-Peer-Systeme oder Client-Server-Anwendungen, wie bei-
spielsweise verteilte, netzwerkfähige Strategiespiele.
Im diesjährigen Softwaretechnik- und Softwarepraktikum soll eine verteilte Anwendung in
Form eines erweiterten, netzwerkfähigen Quarto-Spiels1 entwickelt werden. Ein Server soll
ein Spiel verwalten und die einzelnen Spielzüge überwachen, während unterschiedliche Cli-
ents als Teilnehmer oder Beobachter am Spiel teilnehmen können. Teilnehmer-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. Außerdem sollen unterschiedliche Spielkonfigurationen ermöglicht werden.
Abbildung 1 zeigt eine beispielhafte Situation des Quarto-Spiels. Das Spielfeld besteht aus
einem Raster von Teilfeldern. Zwei Spieler setzen abwechselnd einen Spielstein auf das Spiel-
feld, der vom jeweiligen Gegenspieler ausgewählt wurde. Ziel des Spiels ist es eine Reihe
vorgegebener Länge mit einem gemeinsamen Merkmal, wie Form, Farbe, Muster oder Größe
zu erreichen.
Abbildung 1: Quarto-Beispielsituation nach zehn Zügen.
Im Gegensatz zum Originalspiel, welches ein 4x4-Spielfeld mit 16 Spielsteinen vorsieht,
soll die implementierte Quarto-Version die Möglichkeit bieten, die Größe des Spielfelds sowie
Anzahl und Aussehen der Spielsteine zu konfigurieren.
1
https://de.wikipedia.org/wiki/Quarto!
11 Zielbestimmung Dieses Dokument definiert alle Anforderungen an das zu entwickelnde Produkt. Zunächst werden in Kapitel 2 der Einsatz des Produktes beschrieben und die Regeln des Spiels fest- gelegt. Zudem wird eine Beschreibung der einzelnen verteilten Komponenten vorgenommen und die Aufgabe jeder Komponente erläutert. In Kapitel 3 werden verbindliche sowie optio- nale Funktionen und Anforderungen definiert. Als letztes werden in Anhang A technische Vorgaben erläutert und zu verwendende Technologien kurz beschrieben. 2
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 Quarto-
Spielregeln festgelegt (Abschnitt 2.4). Zuletzt wird ein Anwendungsszenario (Abschnitt 2.5)
beschrieben.
2.1 Übersicht
Mit dem zu entwickelnden Produkt soll es möglich sein, Quarto über ein Netzwerk spielen
zu können. Dabei kommen PCs und Android-Devices zum Einsatz. Die Teilnehmer (im Fol-
genden auch Spieler genannt) in diesem Spiel können dabei menschliche Teilnehmer oder
KI-Teilnehmer2 sein. Es ist auch möglich, ein Spiel ausschließlich mit KI-Teilnehmern durch-
zuführen.
Das Produkt besteht aus einem Server und mehreren Clients (siehe Abbildung 2). Der Ser-
ver besteht aus den Produktkomponenten Spielkonfigurator und Spiel-Engine. Der Spielkonfi-
gurator bietet für die Eingabe einer konkreten Spielkonfiguration ein Konfigurationsinterface
an. Die erstellte Spielkonfiguration kann von der Spielengine geladen werden. Clients werden
in Beobachter- und Teilnehmer-Clients unterteilt. Die Produktkomponenten PC-Beobachter
und Smartphone-Beobachter sind Beobachter-Clients, während es sich bei den Produktkom-
ponenten Smartphone-Teilnehmer (eine Smartphone-Anwendung für menschliche Teilneh-
mer) sowie KI-Teilnehmer (ein PC-Client) um Teilnehmer-Clients handelt. Für die Interak-
tion zwischen Server und Clients sind festgelegte Interfaces (für Beobachter und Teilnehmer)
notwendig.
Abhängig davon, ob Sie am Softwaretechnikpraktikum (SWTPra) oder Softwarepraktikum
(SoPra) teilnehmen, müssen Sie unterschiedliche Komponenten des Produktes selbst entwi-
ckeln. Die Interfaces zwischen den Produktkomponenten werden von allen Teams gemein-
sam in einem zu bildenden Interface-Komitee erstellt. Da Sie außerdem einige Produktkom-
ponenten im Verlauf des Projektes von anderen Teams erwerben, wird Ihr finales Produkt
mehr Produktkomponenten enthalten als Sie selbst programmieren: Das von SWTPra- und
SoPra-Teams abzugebende Produkt besteht jeweils aus Spielkonfigurator, Spiel-Engine, PC-
Beobachter, Smartphone-Beobachter und KI-Teilnehmer. SWTPra-Teams geben zusätzlich
einen Smartphone-Teilnehmer ab.
2.2 Vorgaben an den Entwicklungsprozess
Wir erwarten von Ihnen, dass Sie Ihr Produkt entsprechend dem V-Modell entwickeln.
2
Künstliche Intelligenz: Die Spielzüge werden ausschließlich vom Computer durchgeführt.
32 Produkteinsatz
Server
Spielkonfigurator Spiel-Engine
M
Netzwerk
Clients
PC- Smartphone- Smartphone- KI-
Beobachter Beobachter Teilnehmer Teilnehmer
M M
Legende:
entwickelt im entwickelt im entwickelt im M auf Messe
SWTPra SoPra Interface-Komitee gehandelt
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 inklusive einer Aufwandsschätzung machen können. An-
schließ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 gemein-
samen Dokument festgehalten werden.
Zum Entwurf zählen wir auch entsprechende Verweise auf das Interface-Dokument, das die
Definition der Client- und Server-Interfaces sowie das Interface zwischen dem Spielkonfigu-
rator und der Spiel-Engine festlegt. An der Entwicklung und Dokumentation dieser Interfaces
sind Sie durch Ihre Teilnahme an einem Interface-Komitee beteiligt. Das Interface-Komitee
wird aus je einem Interface-Beauftragten aus 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ög-
lich. 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) fina-
len Version definiert sein, sodass sich Ihr Dokument auf diese Version beziehen kann. Falls
während der Implementierung Änderungen an den Interfaces notwendig werden, muss sich
das Komitee erneut zusammenfinden und eine neue Version definieren.
42.3 Generelle Nutzung des Produktes
Sind wir mit Ihrem Entwurf einverstanden, erwarten wir, dass Sie mit der Implementie-
rung Ihrer Produktkomponenten beginnen. Während Ihrer Implementierungsphase wird eine
Messe stattfinden, die zur Präsentation sowie zum Erwerb bzw. Herausgeben der bisher er-
stellten Produktkomponenten aller Teams dient. Wir erwarten, dass bis zur Messe bereits die
Produktkomponenten Spiel-Engine (SWTPra und SoPra), 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.
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
den Erwerbern neue Versionen zugänglich machen. Parallel zur Integration und zur Fehlerbe-
hebung erwarten wir von Ihnen, dass Sie einen KI-Teilnehmer entwickeln, der unser Quarto
regelkonform spielt. Im Hinblick auf das Praktikumsturnier empfiehlt sich die Umsetzung ei-
ner möglichst erfolgsversprechenden Spielstrategie. Sind Sie ein SWTPra-Team, erwarten wir
von Ihnen zusätzlich, dass Sie die Produktkomponente Smartphone-Teilnehmer implementie-
ren, wodurch ein menschlicher Teilnehmer 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, erwarten
wir von Ihnen eine Abschlusspräsentation inklusive einer Live-Demonstration Ihres Produk-
tes. Zu der Endabgabe zählt auch eine Webseite, auf der Sie Ihr Produkt und dessen Doku-
mente präsentieren (eine Facebook-Seite genügt nicht!).
Am Ende des Praktikums werden wir Sie und alle anderen Teams zu einem Turnier einla-
den. Ihr Team wird dabei durch Ihren entwickelten KI-Teilnehmer vertreten sein. Durch einen
noch festzulegenden Turniermodus wird durch das Turnier der beste KI-Teilnehmer ermittelt.
Zusätzlich werden nach dem Turnier die SWTPra- und SoPra-Teams geehrt, die – unabhängig
vom besten KI-Teilnehmer– im Verlauf des Praktikums die besten Leistungen gezeigt haben.
2.3 Generelle Nutzung des Produktes
Die an einem Spiel beteiligten Produktkomponenten sind ein Server und zwei Teilnehmer-
Clients, wobei es sich sowohl um menschliche Teilnehmer, als auch um KI-Teilnehmer han-
deln kann. Zusätzlich kann es eine beliebige Anzahl an Beobachtern geben, die das Spiel
beobachten ohne darauf Einfluss nehmen zu können.
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 Spielfeldes und der Spielsteine (siehe Abschnitt 2.4).
52 Produkteinsatz
Nachdem der Ausrichters den die Spielengine auf dem Server gestartet hat, können sich
andere Benutzer in der Rolle des Teilnehmers oder des Beobachters mit ihren Clients bei die-
sem registrieren. Sie können dann entweder ein Spiel verfolgen, selbst spielen oder einen KI-
Teilnehmer antreten lassen. Ein PC-Benutzer kann auch Ausrichter und Beobachter zugleich
sein.
Ist die Spielkonfiguration geladen und sind beide Teilnehmer anwesend, muss der Aus-
richter den beginnenden Teilnehmer festlegen. Anschließend kann der Ausrichter das Spiel
starten.
2.4 Spielregeln
In diesem Kapitel wird definiert, welche Spielregeln für Quarto vorausgesetzt sind. Bei Quarto
setzen zwei Spieler abwechselnd Spielsteine auf ein Spielfeld, die sich in bis zu vier Merk-
malen unterscheiden können. Ziel des Spiels ist es, eine Reihe einer bestimmten Länge von
Spielsteinen zu erzeugen, die wenigstens ein identisches Merkmal haben. Der Spieler, der eine
solche Reihe vervollständigt, gewinnt das Spiel. Die Spiele werden auf einem quadratischen,
rasterförmigen Spielfeld ausgetragen, welches aus einzelnen Teilfeldern besteht.
2.4.1 Spielvorbereitung
Quarto besteht aus einem Spielfeld, auf das die Steine gesetzt werden und einem Steinlager,
das alle noch nicht gespielten Steine enthält. Die Anzahl der Spielsteine hängt von Anzahl und
Ausprägung der Merkmale ab. Die Spielsteine des zu entwickelnden Quarto-Spiels sollen sich
in vier Merkmalen unterscheiden können:
• Form
• Farbe
• Muster
• Größe
Jedes Merkmal soll bis zu vier Varianten haben können. Außerdem soll festgelegt werden
können, wie oft jeder Spielstein im Spiel vorhanden ist. Dabei soll jeder Stein mindestens
einmal und höchstens vier mal vorhanden sein können. Insgesamt kann es also maximal
4 Formen * 4 Farben * 4 Muster * 4 Größen * 4 Ausprägungen pro Stein =1024 Steine
geben.
Die Größe des Spielfelds und des Steinlagers hängt von der Anzahl der Spielsteine ab:
Die Anzahl der Teilfelder des Spielfelds und der Felder des Steinlagers entsprechen jeweils
der Anzahl der Spielsteine. Das Quarto-Spielfeld soll quadratisch sein. Sollte die Anzahl der
62.4 Spielregeln
Spielsteine keine Quadratzahl sein, wird das Spielfeld mit nicht bespielbaren Teilfeldern auf-
gefüllt, bis ein quadratisches Spielfeld möglich ist. Diese nicht bespielbaren Teilfelder sol-
len während der Spielfeld-Konfiguration frei verteilbar sein. Abbildung 3 zeigt ein Quarto-
Spielfeld mit insgesamt 25 Teilfeldern. Gemäß den angegebenen Ausprägungen der Spiel-
steinmerkmale, gibt es aber nur 3 * 2 * 2 * 1 * 2 = 24 Spielsteine. Demnach wird zusätzlich
ein nicht bespielbares Teilfeld (orange) benötigt.
Abbildung 3: Exemplarisches Spielfeld mit 24 bespielbaren und einem nicht bespielbaren
Teilfeld.
Weiterhin soll die Länge einer Gewinnreihe vor dem Spiel festgelegt werden. Dabei soll be-
achtet werden, dass nur tatsächlich mögliche Längen (basierend auf der Größe des Spielfeldes)
eingestellt werden können. Im Beispiel in Abbildung 3 ist die maximale Länge 5.
2.4.2 Spielverlauf
Beide Spieler führen abwechselnd Spielzüge durch. Ein Spielzug besteht aus den folgenden
zwei Aktionen:
1. Setzen: Der Spieler setzt den als nächsten zu spielenden Spielstein auf das Spielfeld.
Dabei kann der Spielstein auf jedes freie Teilfeld des Spielfelds gesetzt werden. Ein
Spielfeld gilt als frei, wenn es bespielbar ist und noch keinen Spielstein enthält.
2. Wählen: Der Spieler wählt einen Spielstein aus dem Spiellager als nächsten vom Gegner
zu spielenden Spielstein aus.
Da zu Beginn des Spiels alle Spielsteine im Spiellager sind und kein Stein als nächster zu
spielender Spielstein gewählt ist, beschränkt sich der erste Spielzug des beginnenden Spielers
auf die zweite Aktion.
72 Produkteinsatz
2.4.3 Spielende
Das Spiel endet, wenn das Spielfeld wenigstens eine Gewinnreihe enthält oder alle Spielstei-
ne gesetzt sind. Eine Gewinnreihe ist eine Folge einer bestimmten Länge von benachbarten
Spielsteinen, die wenigstens ein identisches Merkmal haben. Gewinnreihen können vertikal,
horizontal oder diagonal auf dem Spielfeld sein. Gewinnreihen gehen nicht über Teilfelder
hinaus, die nicht bespielbar sind.
Abbildung 4 zeigt eine Spielsituation nach 14 Zügen. Das Spielfeld enthält zwei Gewinn-
reihen der Länge 4: Von unten links nach oben rechts basierend auf der Farbe der Spielsteine.
Und von links nach rechts (zweite Zeile von unten) basierend auf der Form der Spielsteine.
Abbildung 4: Exemplarisches Spielfeld mit zwei Gewinnreihen.
Es gewinnt der Spieler, der die Gewinnreihe vervollständigt hat, also den letzten Stein auf
das Spielfeld gesetzt hat um die Reihe zu erzeugen. Sind alle Spielsteine gesetzt und liegt
keine Gewinnreihe vor, wird das Spiel als unentschieden gewertet.
2.5 Anwendungsszenario: Praktikumsturnier
Ein Anwendungsszenario für Ihr Produkt ist das Turnier (und dessen Vorbereitung), welches
am Ende des Praktikums stattfindet.
Im Turnier werden die von den Teams entwickelten KI-Teilnehmer 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.
Die Konfiguration(en) des Spielfelds für das Turnier werden vor dem Turnier nicht veröf-
fentlicht. Sie sollten daher vor dem Turnier mit dem Spielkonfigurator verschiedene Spielkon-
figurationen anlegen, um Ihren KI-Teilnehmer zu testen.
83 Produktfunktionen und -leistungen
Die einzelnen Teile des Produktes müssen bestimmte Funktionen und Anforderungen erfül-
len. Dabei wird unterschieden zwischen verbindlichen und optionalen Anforderungen. Die
verbindlichen Anforderungen müssen von Ihnen erfüllt werden, die optionalen können frei-
willig umgesetzt werden. Auch weitere, selbst erdachte Features sind denkbar. Sofern nicht
anders angegeben, sollen alle in Abschnitt 2.4 beschriebenen Spielregeln von allen Produkt-
komponenten berücksichtigt werden.
3.1 Netzwerk
• Verbindlich: Ihre Client-Server-Anbindung soll im lokalen Netzwerk (LAN) sowie via
Internet funktionieren.
3.2 Spielkonfigurator
• Verbindlich: Durch eine geeignete Oberfläche lassen sich Spielkonfigurationen erstel-
len, die alle in Abschnitt 2.4 genannten Konfigurationsparameter abdecken. Konfigura-
tionsparameter sind insbesondere:
– Anzahl möglicher Formen der Spielsteine
– Anzahl möglicher Farben der Spielsteine
– Anzahl möglicher Muster der Spielsteine
– Anzahl möglicher Größen der Spielsteine
– Ausprägung der Spielsteine (wie oft ist jede Spielsteinart im Spiel)
– Länge einer Gewinnreihe
– Platzierung nicht bespielbarer Teilfelder
– Maximale Zeit pro Spielzug für KI-Teilnehmer
– Verzögerungszeit, die nach jedem Zug genutzt wird, um eine Visualisierung zu
ermöglichen
• Optional: Auch für menschliche Teilnehmer (nicht nur für KI-Teilnehmer) können Zeit-
beschränkungen angegeben werden.
• Verbindlich: Die Spielkonfigurationen sollen in dem im Interface-Komitee abgespro-
chenen Format abspeicherbar sein.
• Optional: Bereits erstellte Spielkonfigurationen können geladen und modifiziert wer-
den.
• Optional: Zufällige Spielkonfigurationen können vorgeschlagen werden.
93 Produktfunktionen und -leistungen
3.3 Spiel-Engine
Die Anforderungen an die Spiel-Engine wurden übersichtshalber in drei Bereiche unterteilt:
Start eines Spiels (3.3.1), Spielverlauf (3.3.2) und Turnierorganisation (3.3.3).
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: Vor dem Starten eines Spiels muss der Spiel-Engine-Benutzer (der Aus-
richter) aus einer Liste registrierter Teilnehmer zwei auswählen können, die gegenein-
ander antreten. Zudem kann entweder durch Zufall oder durch eine explizite Auswahl
bestimmt werden, welcher Teilnehmer zuerst am Zug ist.
• Verbindlich: Vor dem Starten eines Spiels muss der Spiel-Engine-Benutzer eine Spiel-
konfiguration (siehe Abschnitt 3.2) laden.
3.3.2 Spielverlauf
• Verbindlich: Während des Spiels muss die Spiel-Engine den Teilnehmer-Client, der am
Zug ist, auffordern, seine Aktionen durchzuführen. Sofern eine Aktion gültig ist (siehe
Spielregeln in Abschnitt 2.4), wird sie ausgeführt, andernfalls wird der Teilnehmer dis-
qualifiziert und der gegnerische Teilnehmer gewinnt.
• Verbindlich: Nach der Aufforderung der Spiel-Engine hat der Teilnehmer-Client ei-
ne in der Spielkonfiguration festgelegte Zeitspanne seine Aktionen durchzuführen (an
die Spiel-Engine zu senden). Ist in der Spielkonfiguration kein Zeitlimit für menschli-
che Teilnehmer festgelegt, hat dieser beliebig lange Zeit seine Aktionen durchzuführen.
Ist die Antwort des Teilnehmer-Clients nicht innerhalb der festgelegten Zeitspanne bei
der Spiel-Engine eingegangen, wird der Teilnehmer disqualifiziert und der gegnerische
Teilnehmer gewinnt.
• Verbindlich: Nach jedem Spielzug soll die Engine eine in der Konfiguration festgelegte
Zeit pausieren, sodass genug Zeit für die Visualisierung der Aktion bleibt.
• Verbindlich: Alle Clients werden über den Spielzustand nach Ablauf eines Spielzugs
informiert.
• Verbindlich: Ein Spiel lässt sich über die Benutzeroberfläche der Spiel-Engine pausie-
ren, fortsetzen und abbrechen. Bei einem solchen manuellen Abbruch wird das Spiel als
103.4 Clients
unentschieden gewertet. Die Clients werden über diese Statusänderungen in Kenntnis
gesetzt.
• Verbindlich: Nach jeder Runde überprüft die Spiel-Engine das Vorliegen der Bedingun-
gen für das Spielende. Ist dies der Fall, so wird dies (und falls vorhanden der jeweilige
Gewinner) jedem Client mitgeteilt.
• Optional: Alle in einem Spiel abgegebenen Aktionen und ihre Ergebnisse werden an-
gezeigt bzw. in eine Log-Datei geschrieben.
3.3.3 Turnierorganisation
• Verbindlich: Es soll eine Menge von nacheinander auszuführenden Spielen geplant und
ausgeführt werden können.
• Optional: Die Ausgänge der bisher ausgeführten Spiele sollen in einer Übersicht ange-
zeigt werden.
• Optional: Abhängig von den Ausgängen der bisher ausgeführten Spiele soll eine (evtl.
vom Ausrichter konfigurierbare) Rangliste angezeigt werden.
3.4 Clients
• Verbindlich: Jeder Client soll über eine geeignete Oberfläche gestartet und beendet
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
• Verbindlich: Der Beobachter-Client zeigt das Spielfelds inkl. Teilfeldern, Spielsteinla-
ger, dem nächsten zu spielenden Stein und des gerade aktiven Spielers an. Außerdem
enthält der Beobachter-Client eine visualisierte Übersicht über die aktuell eingestellten
Regeln und den Spielstatus.
• Verbindlich: Der Beobachter-Client kann alle Spielsteine gemäß ihrer Merkmalausprä-
gungen in einer geeigneten Darstellung anzeigen.
• Verbindlich: Die Visualisierung eines Zuges soll beendet sein, bevor der nächste Zug
stattfindet.
• Verbindlich: Ist ein Spiel beendet, wird der Spielausgang angezeigt, d.h. Gewinner und
Verlierer bzw. “unentschieden”, falls es keinen Gewinner gibt.
113 Produktfunktionen und -leistungen
• Optional: Ist ein Spiel beendet, werden zusätzlich die Gewinnreihen hervorgehoben,
falls vorhanden.
• Optional: Spielaktionen werden per Animation visualisiert.
3.4.2 Smartphone-Teilnehmer
• Verbindlich: Es gelten die gleichen Produktanforderungen wie bei den Beobachter-
Clients.
• Verbindlich: Der Smartphone-Teilnehmer muss es dem Benutzer ermöglichen, Aktio-
nen durchzuführen, sofern der Teilnehmer am Zug ist.
3.4.3 KI-Teilnehmer
• Verbindlich: Der KI-Teilnehmer kann vom PC via Kommandozeile gestartet werden
(z.B. durch Aufruf einer Jar-Datei).
• Verbindlich: Beim Start des KI-Teilnehmers wird ihm die IP-Adresse des Servers und
der Port mitgeteilt bei dem sich der KI-Teilnehmer anmelden soll.
• Verbindlich: Der KI-Teilnehmer enthält einen Algorithmus, der den nächsten Spielzug
berechnet und an die Spiel-Engine weitergibt. Für die Auswahl des Spielzugs steht dem
KI-Teilnehmer ab der entsprechenden Anfrage der Spiel-Engine die in der Spielkonfi-
guration eingestellte Zeit zur Verfügung.
• Optional: Der Benutzer kann mittels einer Oberfläche verschiedene Intelligenzstufen
oder andere Parameter einstellen. 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 vorgenommen werden.
• Optional: Der KI-Teilnehmer kann vom Smartphone aus durch eine separate App gest-
artet werden.
• Optional: Der KI-Teilnehmer wird in die Produktkomponente Smartphone-Teilnehmer
integriert und kann von dieser aus gestartet werden. Während die KI spielt, kann der
Smartphone-Benutzer nicht in das Spiel eingreifen.
12A 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 Technologien und Entwicklungswerkzeuge
Eine technische Übersicht über die im Praktikum eingesetzten Entwicklungswerkzeuge und
Technologien ist in Abbildung 5 zu sehen.
Die Teilnehmer sollen im Rahmen des SoPra bzw. des SWTPra lernen, sich in ein größe-
res Framework einzuarbeiten und sich dessen Vorteile zu Nutze zu machen. Alle Produkt-
komponenten des Produktes sollen sich mit Hilfe von Eclipse entwickeln lassen und auf der
Sprache Java basieren. Die zu entwickelnden Produktkomponenten Spielkonfigurator und PC-
Beobachter sollen zudem als Plug-Ins für die Entwicklungsumgebung Eclipse3 erstellt wer-
den. Hingegen sollen der Smartphone-Beobachter und der Smartphone-Teilnehmer als Apps
für Android4 erstellt werden.
Insbesondere Eclipse hat sich als Grundlage für größere Softwareprojekte bewährt und vie-
le 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 Andro-
id mittlerweile das meistverbreitete Betriebssystem. Daher ist die Fähigkeit zur Entwicklung
von Android-Apps eine wichtige Fähigkeit, um auf dem Arbeitsmarkt zu bestehen.
Zur Entwicklung mit Eclipse ist ein installiertes JDK (Java Development Kit) notwendig.
Die entwickelten Komponenten müssen kompatibel zu Java SE 8 sowie Android 4.4.x (KitKat,
API-Level 19) sein. Die zu verwendende Eclipse-Version ist Mars SR2 (4.5.2).
Um Zugriff auf das Git-Repository einer Gruppe zu erhalten, wird ein Git-Client benötigt.
Git-Clients mit GUI sind zum Beispiel SourceTree5 oder das Eclipse-Plugin EGit6 .
3
http://eclipse.org/pde
4
http://developer.android.com
5
https://www.sourcetreeapp.com/
6
http://www.eclipse.org/egit/
13A Technische Vorgaben und Hilfestellungen
Server
Spielkonfigurator Spiel-
Engine
Netzwerk
Clients
PC- Smartphone- Smartphone- KI-
Beobachter Beobachter Teilnehmer Teilnehmer
Abbildung 5: Übersicht über die zu verwendenden Technologien und Entwicklungswerkzeuge
A.3 Interfaces
Um die Kompatibilität der Komponenten zu gewährleisten, werden von einem Komitee geeig-
nete Interfaces für die Kommunikation zwischen den Komponenten entwickelt. Diese werden
vom Interface-Komitee in einem gesonderten Dokument beschrieben und vor einer gesondert
ausgewiesenen Deadline abgegeben.
Abbildung 5 illustriert die Stellen, an denen sich das Interface-Komitee auf Interfaces bzw.
ein geeignetes Austauschformat einigen muss. Der Spielkonfigurator speichert ein EMF-Modell
(siehe Abschnitt A.4) im ecore-Format. Dieses Modell beschreibt die zum Spiel nötige Spiel-
konfiguration. Die Spiel-Engine kann diese Konfiguration dann von der Festplatte laden. Cli-
ents und Server tauschen ihre Daten ebenfalls in Form von EMF-Modellen aus (mithilfe von
JSON, siehe Abschnitt A.7). Die Erstellung von Metamodellen per EMF (zum Beschreiben
gültiger EMF-Modelle) ist somit Hauptaufgabe des Interface-Komitees.
A.4 Eclipse Modeling Framework (EMF)
Als Ausgabe des Spielkonfigurators, sowie zur Interaktion zwischen Server und Clients, wer-
den Modelle auf Basis des Eclipse Modeling Frameworks7 (EMF) verwendet. Eine Anlei-
tung zum Erstellen von Metamodellen mit EMF existiert online8 . Ein Tutorial zum Speichern
und Laden von EMF-Modellen ist online9 sowie im EMF Developer Guide in der Eclipse-
Dokumentation10 verfügbar.
7
http://eclipse.org/modeling/emf
8
http://eclipse.org/ecoretools/doc/index.html
9
http://www.vogella.com/articles/EclipseEMFPersistence/article.html
10
http://help.eclipse.org/luna
14A.5 Frameworks zur Erstellung grafischer Editoren
A.5 Frameworks zur Erstellung grafischer Editoren
Sowohl das Graphical Editing Framework11 (GEF) als auch Graphiti12 ermöglichen die Ent-
wicklung grafischer Editoren und anderer Visualisierungen für Eclipse-basierte Anwendun-
gen, insbesondere im Rahmen von Eclipse-Plugins. GEF und Graphiti sehen eine Entwicklung
vor, die dem Architekturmuster Model-View-Controller (MVC) folgt und unterstützen diese
durch geeignete Extension Points, wie beispielsweise Framework-Klassen für View-Objekte,
die durch eigene Implementierungen spezialisiert werden können.
Wir empfehlen, die Visualisierung des Spielfelds und seiner Elemente, die im Rahmen des
SWTPra entwickelt werden (PC-Beobachter, Spielkonfigurator), mittels GEF oder Graphiti zu
erstellen. Alternativ ist auch eine Lösung, die nur auf SWT13 oder 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 geziel-
te Programmierberatung an.
GEF bzw. Graphiti werden nicht nur für viele Forschungsprototypen, sondern auch in Un-
ternehmen eingesetzt. Daher ist deren Kenntnis hilfreich für spätere SHK-Stellen, Abschluss-
arbeiten und auch Jobs außerhalb der Universität. Des Weiteren werden die Konzepte von GEF
und Graphiti in der Klausur am Ende des Semesters als bekannt vorausgesetzt.
A.6 Android
Für die Entwicklung empfehlen sich das Eclipse-Plug-In ADT14 bzw. die IDE Android Stu-
dio15 . ADT hat sich für den Einsatz im SWTPra/SoPra bewährt. 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. Um EMF-
Modelle in Form von JSON auszutauschen, ist die Nutzung des Plug-Ins emfjson16 vorgege-
ben. Um serverseitig JSON einfach parsen bzw. erzeugen zu können, verwendet emfjson die
Java-Bibliothek Jackson. Die Verwendung von Jackson wird online17 beschrieben.
11
http://eclipse.org/gef
12
http://eclipse.org/graphiti
13
http://eclipse.org/swt
14
http://developer.android.com/sdk/eclipse-adt.html
15
https://developer.android.com/sdk
16
http://emfjson.org
17
http://wiki.fasterxml.com/JacksonInFiveMinutes
15Sie können auch lesen
