Softwaretechnikpraktikum WiSe 2023/2024

Umsetzung eines ”Dog“-Spiels

Product Vision & Vorgaben

Auftraggeber
Eric Bodden, Stefan Schott, Jonas Klauke
Fachgruppe Secure Software Engineering, Heinz Nixdorf Institut
Fakultät für Elektrotechnik, Informatik und Mathematik
Universität Paderborn, Fürstenallee 11, 33102 Paderborn

Version 1.0.0

Paderborn, den 10.10.2023

Inhaltsverzeichnis
1 Product Vision 1
1.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Nutzergruppen und Funktionalität . . . . . . . . . . . . . . . . . . . . . . . 1
1.2.1 Beobachter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2.2 Spieler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2.3 Ausrichter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Spielregeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Organisatorische & Technische Vorgaben 8

2.1 Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Ablauf des Praktikums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Protokoll-Komitee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Praktikumsturnier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 Technologien und Entwicklungswerkzeuge . . . . . . . . . . . . . . . . . . 11
 1 Product Vision

1 Product Vision
1.1 Einleitung
Wir, die Fachgruppe Secure Software Engineering beauftragen Sie mit der Entwicklung eines
Dog Spiels, welches als Software unter Mac OS X, Ubuntu, Windows und Android (Version
8.0 und höher) lauffähig ist. Dieses Dokument beschreibt unsere Wünsche an das zu entwi-
ckelnde Produkt und den Projektablauf.

1.2 Nutzergruppen und Funktionalität

In diesem Kapitel wird die gewünschte Funktionalität aus Benutzersicht beschrieben. Unter-
schieden wird zwischen Beobachtern, Spielern und Ausrichtern.

1.2.1 Beobachter
Beobachter nutzen einen Beobachter-Client, der sowohl für PC- als auch für Android-Geräte
verfügbar ist. Mit diesem Client melden sich Beobachter an einem Spielserver an, der sich so-
wohl im lokalen Netzwerk (LAN) als auch im Internet befinden kann. Auf einem Spielserver
können sich eine unbegrenzte Anzahl von Beobachtern anmelden. Nach erfolgter Anmeldung
können Beobachter übersichtlich erkennen, welche Spiele gerade laufen, in Kürze starten und
vor Kurzem beendet wurden. Aus dieser Übersicht heraus können Beobachter jedes der dort
gelisteten Spiele betreten, um das Spiel in Echtzeit nachzuverfolgen. Sämtliche für das Spiel
relevanten Aspekte sind sinnvoll erkennbar. Dazu gehören u.a. welcher Spieler gerade am
Zug ist, die verbleibende Bedenkzeit der Spieler, die gespielten Karten und die Positionen der
Spielfiguren. Bei Spielende werden die Beobachter über das Ergebnis des Spiels benachrich-
tigt. Beobachter haben keine Möglichkeit, das Spiel zu beeinflussen.

1.2.2 Spieler
Spieler können menschliche Spieler und nichtmenschliche Spieler sein.
Menschliche Spieler nutzen einen Teilnehmer-Client, der ebenfalls für PC- als auch für
Android-Geräte verfügbar ist. Mit diesem Client melden sich menschliche Spieler analog wie
die Beobachter am Spielserver an. Nach erfolgter Anmeldung sehen sie, genau wie die Be-
obachter, die gerade laufenden Spiele, die in Kürze startenden Spiele und die vor Kurzem
beendeten Spiele. Sie können einem Spiel als Beobachter beitreten oder einem noch nicht ge-
starteten Spiel als Teilnehmer beitreten. Alternativ können sie auch vom Spielserver einem
Spiel als Teilnehmer zugeordnet werden. Wenn menschliche Spieler einem Spiel als Teilneh-
mer angehören, können sie Spielzüge ausführen.
Nichtmenschliche Spieler sind Programme, die anstelle eines menschlichen Spielers Spiel-
züge berechnen und ausführen. Ein solches Programm heißt Engine-Teilnehmer. Engine-Teil-
nehmer können auf dem PC via Kommandozeile gestartet werden (z.B. durch Aufruf einer

1
 1 Product Vision

Jar-Datei) und funktionieren ohne grafische Oberfläche. Beim Aufruf wird die IP-Adresse und
der Port des Servers mitgeteilt, bei dem sich angemeldet werden soll. Der Engine-Teilnehmer
enthält einen Algorithmus, der den nächsten Spielzug berechnet und dem Spielserver mitteilt.
Genau dann, wenn ein Teilnehmer in einem Spiel am Zug ist, kann dieser einen gültigen Zug
ausführen. Der Spielserver prüft, ob der Zug des Spielers den Spielregeln entspricht. Die Kon-
sequenz eines ungültigen Zugs ist konfigurierbar. Alle Spieler werden vom Server über jede
gültige Spielaktion informiert. Nach jeder Spielrunde und auch auf Nachfrage durch Clients
teilt der Server den aktuellen Punktestand mit. Der Spielserver erkennt auch das Spielende,
legt das Ergebnis fest und teilt die Beendigung des Spiels und das Ergebnis den betreffenden
Clients mit.
Spieler haben eine festgelegte Bedenkzeit zur Ausführung eines Spielzugs. Die Bedenkzeit
eines Spielers beginnt abzulaufen sobald der Spieler am Zug ist. Die Bedenkzeit wird pro
Spiel am Server festgelegt und ist für alle Teilnehmer gleich.
Ein ungültiger Zug wird nicht durchgeführt und wird bestraft. Überschreitet ein Spieler seine
Bedenkzeit, wird der Zug als ungültig gewertet und bestraft. Die Kontrolle der Bedenkzeit
obliegt dem Server. Clients erfahren auf Nachfrage die ihnen verbleibende Bedenkzeit vom
Server.

1.2.3 Ausrichter
Ausrichter starten, konfigurieren und bedienen den Spielserver. Folgende Parameter können
Ausrichter am Spielserver mindestens konfigurieren:

• Die Anzahl der Mitspieler.

• Die Größe des Spielfelds.
• Die Anzahl der Spielfiguren je Spieler.
• Die Anzahl und Positionen der ”Karte ziehen“-Felder.
• Die Anzahl an Karten, welche jeder Spieler zur Beginn der Runde erhält.
• Die Startreihenfolge der Spieler. Diese kann optional auch zufällig sein.
• Die Bedenkzeit pro Spielzug.
• Die Zeit für die Visualisierung eines Spielzugs.
• Die Konsequenzen für einen regelwidrigen Spielzug. Zur Auswahl stehen: Ausschluss
von der aktuellen Runde, Ausschluss vom Spiel (Kick). Beim Ausschluss vom Spiel
werden die Spielfiguren vom Spielfeld entfernt.
• Die maximale Spieldauer (Zeit).
• Die maximale Anzahl an Gesamtzügen.

Eine einmalig erstellte Spiel-Konfiguration ist wiederverwendbar. Hierzu kann die Konfigu-
ration in einem vom Protokoll-Komitee definierten Format gespeichert werden. Der Ausrichter

2
 1 Product Vision

kann eine Konfiguration in einer Datei speichern und bei Bedarf aus einer Datei laden. Der
Ausrichter kann jedes Spiel unabhängig von den anderen Spielen konfigurieren. Zum Erstel-
len, Laden und Speichern von Konfigurationen nutzt der Ausrichter eine grafische Oberfläche,
die vom Spieleserver bereitgestellt wird.
Nachdem der Ausrichter den Spielserver gestartet hat, können sich andere Nutzer als Teil-
nehmer oder Beobachter mit ihren Clients anmelden. Aus der Liste angemeldeter Teilnehmer
kann der Ausrichter die Teilnehmer für verschiedene Spiele auswählen. Der Ausrichter kann
entweder selbst oder durch fairen Zufall festlegen in welcher Reihenfolge die Teilnehmer zie-
hen und welcher Teilnehmer zuerst am Zug ist. Der Ausrichter kann ein Spiel starten, pau-
sieren, fortsetzen und abbrechen. Bei Abbruch des Spiels entscheidet der Ausrichter über die
Wertung des Spiels.
Zur Verwaltung von Turnieren kann der Ausrichter eine Menge von nacheinander auszufüh-
renden Spielen planen und ausführen. Um den Überblick während eines Turniers zu wahren,
zeigt die Oberfläche des Spielservers die Ergebnisse der abgelaufenen Spiele und die aktuelle
Rangfolge der Spieler an. Jeder Spieler muss sich aktiv bei dem Turnier anmelden. Der Aus-
richter bestimmt einige dieser Spieler zu einem Spiel, fügt diese dem Spiel hinzu und führt
das gesamte Spiel durch. Die erhaltenen Punkte werden in der Lobby angezeigt, in welcher
sich auch die anderen angemeldeten Spieler befinden.

1.3 Spielregeln
Die Regeln des Spiels sind folgendermaßen definiert:

• An einem Spiel nehmen 2 bis 6 Spieler teil.

• Jeder Spieler hat mindestens eine Spielfigur.

• Das Spielfeld besteht aus normalen Feldern, ”Karte ziehen“-Feldern, Startfeldern und
Hausfeldern.

• Jeder Spieler verfügt über ein Startfeld.

• Es existieren für jeden Spieler individuelle Hausfelder, welche der Anzahl der jeweiligen
Spielfiguren entsprechen.

• Ein Hausfeld ist mit dem jeweiligen Startfeld des Spielers verbunden.

• Alle weiteren Hausfelder eines Spielers sind direkt in einer Kette verbunden und haben
maximal zwei Verbindungen.

• Hausfelder haben keine weiteren Verbindungen zum Spielfeld.

• Alle normalen Felder, ”Karte ziehen“-Felder und Startfelder sind in einem Kreis ver-
bunden.

3
 1 Product Vision

• Jedes normale Feld und “Karte ziehen”-Feld ist genau mit zwei weiteren Feldern ver-
bunden.

• Jedes Startfeld ist mit drei Feldern verbunden, davon ist eines ein Hausfeld.

• Startfelder von unterschiedlichen Spielern sind jeweils gleichmäßig und im Uhrzeiger-

sinn in konfigurierter Zugreihenfolge auf dem Spielfeld verteilt.

• Es existieren ein Kartenstapel und ein Ablagestapel.

• Ein Spiel besteht aus mehreren Runden.

• Zum Start einer Runde erhalten alle Spieler die konfigurierte Anzahl an Karten vom
Kartenstapel.

• Es gibt einen konfigurierten Startspieler, welcher die Runde startet.

• Sobald ein Spieler an der Reihe ist, muss dieser eine Karte spielen.

• Die gespielte Karte bestimmt, ob und wie eine eigene Spielfigur gezogen werden muss.

• Kann ein Spieler keine Karte spielen, scheidet der Spieler für diese Runde aus, muss
alle seine Karten auf den Ablagestapel ablegen und darf bis zum Beginn der nächsten
Runde keine Karten mehr spielen.

• Eine Runde ist beendet, sobald alle Spieler keine Karten mehr auf der Hand haben.
Dann beginnt eine neue Runde, alle Spieler erhalten wieder die konfigurierte Anzahl an
Karten und der Startspieler ist der in der Zugreihenfolge nächste Spieler zum vorherigen
Startspieler.

• Auf die Hausfelder eines Spielers dürfen nur die jeweils eigenen Figuren ziehen.

• Jeder Spieler darf nur seine eigenen Spielfiguren ziehen.

• Auf normale Felder, ”Karte ziehen“-Felder und Startfelder dürfen alle Spielfiguren zie-
hen.

• Alle Spielfiguren befinden sich zum Start eines Spiels auf der jeweiligen ”Bank“ des
Spielers.

• Auf jedem Spielfeld darf sich nur eine Spielfigur gleichzeitig befinden.

• Wird eine Spielfigur auf ein bereits belegtes Feld gezogen, wird die vorher auf dem Feld
befindliche Spielfigur in die Bank des jeweiligen Spielers zurückgesetzt.

• Andere Spielfiguren dürfen beim Ziehen übersprungen werden. (Das übersprungene

Feld wird beim Zug mitgezählt)

4
 1 Product Vision

• Steht eine eigene Spielfigur auf dem eigenen Startfeld darf diese nicht übersprungen
oder geschlagen werden. (Die Spielfigur blockiert fremde und eigene Spielfiguren vom
vorankommen)
• Auch dürfen keine eigenen Figuren von der Bank aufs Spielfeld gesetzt werden, wenn
eine eigene Spielfigur das Startfeld besetzt.
• Spielfiguren, welche auf Hausfeldern stehen, sind gesichert und dürfen nicht geschlagen
oder übersprungen werden.
• Eine Spielfigur darf nicht direkt vom eignen Startfeld auf Hausfelder ziehen.
• Das Haus darf nur vorwärts betreten werden. (Die Spielfigur muss somit hinter dem
Startfeld stehen, um ins Haus ziehen zu dürfen)
• Das Startfeld wird beim Ziehen ins Haus mitgezählt.
• Kann eine Figur durch eine gespielte Karte nicht ins Haus gezogen werden, so muss
diese am Haus vorbeigehen und eine neue Laufrunde starten.
• Es gibt normale Karten und Spezialkarten.
• Der Wert einer Karte definiert die Anzahl an Schritten welche eine beliebige eigene
Spielfigur vorwärts gezogen werden muss.
• Normale Karten haben einen Wert von 2, 3, 5, 6, 8, 9, 10 oder 12.
• Es gibt folgende Spezialkarten:
– Startkarte 1: Hat entweder einen Wert von 13 oder kann genutzt werden um eine
eigene Spielfigur von der Bank auf das eigene Startfeld zu setzen.
– Startkarte 2: Hat entweder einen Wert von 1 oder 11 (Spieler kann den Wert beim
Ausspielen auswählen) oder kann genutzt werden um eine eigene Spielfigur von
der Bank auf das eigene Startfeld zu setzen.
– 1-7 Karte: Hat einen Wert zwischen 1 und 7 (1 und 7 inklusive), welcher der Spie-
ler beim Ausspielen auswählen kann.
– +/-4 Karte: Nach dem Ausspielen dieser Karte kann der Spieler eine Spielfigur
entweder 4 Felder vorwärts oder rückwärts ziehen.
– Magnetkarte: Diese Karte hat keinen Wert. Beim Ausspielen wird eine beliebige
ausgewählte nicht gesicherte eigene Spielfigur ein Feld vor die nächste Figur in
Laufrichtung auf dem Feld (nicht im Haus) gezogen.
– Tauschkarte: Diese Karte hat keinen Wert. Beim Ausspielen wird ein beliebige
nicht gesicherte eigene Spielfigur mit einer beliebigen nicht gesicherten gegneri-
schen Spielfigur getauscht. Es dürfen sich weder die eigenen noch die gegnerische
Spielfigur auf dem jeweiligen eigenen Startfeld befinden.

5
 1 Product Vision

– Kopierkarte: Die letzte ausgespielte Karte, welche keine Kopierkarte war, wird ko-
piert und ausgeführt. War die zuletzt ausgeführte Karte eine Spezialkarte, darf sich
der Spieler, welcher die Kopierkarte ausgeführt hat, den Effekt der Spezialkarte
aussuchen. (Diese Karte kann nicht zu Beginn einer Runde gespielt werden)

• Das Kartendeck besteht aus:

– 7 × Normalkarte 2
– 7 × Normalkarte 3
– 7 × Normalkarte 5
– 7 × Normalkarte 6
– 7 × Normalkarte 8
– 7 × Normalkarte 9
– 7 × Normalkarte 10
– 7 × Normalkarte 12
– 10 × Startkarte 1
– 10 × Startkarte 2
– 7 × +/-4 Karte
– 7 × 1-7 Karte
– 6 × Magnetkarte
– 7 × Tauschkarte
– 7 × Kopierkarte

• Zu Beginn des Spiels befinden sich alle Karten zufällig gemischt auf dem Kartenstapel.

• Ausgespielte Karten werden auf den Ablagestapel gelegt.

• Befinden sich vor Beginn einer Runde nicht genug Karten auf dem Kartenstapel, so
dass alle Spieler die konfigurierte Anzahl an Karten auf die Hand bekommen können,
so werden der Karten- und Ablagestapel zusammengeführt und neu gemischt.

• Landet die Spielfigur eines Spielers während seines eigenen Zuges auf einem ”Karte
ziehen“-Feld, so darf er eine Karte vom Kartenstapel auf die Hand nehmen. Hierbei ist
es egal, wie die Spielfigur auf dem Feld landet.

• Sobald der Kartenstapel leer ist, werden alle Karten vom Ablagestapel neu gemischt
und auf den Kartenstapel gelegt.

• Eine Karte kann nur ausgespielt werden, wenn es eine eigene Spielfigur gibt, welche die
entsprechende Anzahl an Schritten gezogen werden kann.

6
 1 Product Vision

• Das Spiel ist beendet, sobald ein Spieler alle eigenen Spielfiguren ins Haus gezogen hat.
(Der Spieler hat dann gewonnen)

• Wird das Spiel abgebrochen oder ist das Zeit/Zug-Limit erreicht, gewinnt der Spieler,
welcher zuerst die meisten Spielfiguren ins Haus gezogen hat.

• Die übrige Gewinnreihenfolge wird danach bestimmt, welcher Spieler zuerst mehr Spiel-
figuren ins Haus gezogen hat.

• Sollten mehrere Spieler keine Spielfigur im Haus haben, so werden ihre Platzierungen
zufällig ermittelt.

7
 2 Organisatorische & Technische Vorgaben

2 Organisatorische & Technische Vorgaben

In diesem Kapitel wird beschrieben, welche organisatorischen und technischen Vorgaben wir
als Auftraggeber an Sie während des Praktikums stellen.

2.1 Deliverables
Im Rahmen des Softwaretechnikpraktikum (SWTPra) entwickeln Sie, entsprechend der Pro-
duct Vision (Kapitel 1), ein netzwerkfähiges ”Dog“-Spiel inklusive entsprechender Clients
für PC und Android. Während des Praktikums wird im zugehörigen PANDA-Kurs der Veran-
staltung ein Abgabeplan veröffentlicht1 . Grundlegende Informationen werden zusätzlich auf
unserer Webseite veröffentlicht 2 . Entsprechend dem veröffentlichten Abgabeplan sind zu den
gegebenen Deadlines folgende Dokumente bzw. Implementierungen abzugeben:

• Angebot
• Product Backlog
• Quality-Assurance-Dokument
• Protokoll-Dokument
• DevOps-Dokument
• Endabgabe: Stundenzettel, Meetingprotokolle, Präsentation, Implementierung, Test-Report

Verspätete Abgaben werden sanktioniert. Sämtliche abzugebenden Dokumente müssen auf

Deutsch verfasst werden. Details zum Inhalt der Abgaben finden Sie im zugehörigen Panda-
Kurs der Veranstaltung. Der Code selbst und Codekommentare werden auf Englisch verfasst.
Es wird zwei Arten von Teams geben: DS und SD. Gruppen mit geraden Nummern sind
DS-Teams, während Gruppen mit ungeraden Nummern SD-Teams sind. Abhängig davon, in
welchem Team Sie sind, sind unterschiedliche Komponenten zu entwickeln. Da Sie außerdem
einige Komponenten im Verlauf des Projektes von anderen Teams erwerben und erweitern,
wird Ihr finales Produkt folgende Komponenten enthalten:

• Das von allen Gruppen abzugebende Produkt besteht jeweils aus Spielserver, und Engine-
Teilnehmer.

• DS-Teams geben zusätzlich einen PC-Beobachter und einen Smartphone-Teilnehmer

ab.

• SD-Teams geben zusätzlich einen Smartphone-Beobachter und PC-Teilnehmer ab.

1
https://panda.uni-paderborn.de/
2
https://www.hni.uni-paderborn.de/sse/lehre/swtpra/

8
 2 Organisatorische & Technische Vorgaben

Eine zusammenfassende Übersicht über die Bestandteile des zu liefernden Produkts finden Sie
in Abbildung 1.
Um die Kompatibilität zwischen den Komponenten verschiedener Teams zu gewährleisten,
wird das Kommunikationsprotokoll gemeinschaftlich von allen Teams in einem Protokoll-
Komitee spezifiziert. Mehr dazu im Abschnitt 2.3.

Server
Konfiguration Spiel-Server

Netzwerk

Clients
PC- Smartphone- PC- Smartphone- Engine-
Beobachter Beobachter Teilnehmer Teilnehmer Teilnehmer

M M

Legende:
entwickelt durch entwickelt durch entwickelt im M auf Messe
Gruppe DS Gruppe SD Protokoll-Komitee gehandelt

Abbildung 1: Übersicht über das zu entwickelnde Produkt

2.2 Ablauf des Praktikums

Nach Abgabe Ihres Angebots, Product Backlog und des Quality Assurance Dokuments, star-
ten Sie mit der Umsetzung des Produkts (Implementierung, Testen, Dokumentation, Sprint
Planung, etc.). In der Rolle des Kunden behalten wir es uns vor ggf. eine Überarbeitung des
Angebots, Product Backlogs, oder Quality-Assurance-Dokuments vor dem Start der Umset-
zung zu verlangen.
Während der Umsetzungsphase wird eine Messe stattfinden, die zur Präsentation sowie zum
Erwerb bzw. Veräußerung der bisher erstellten Komponenten aller Teams dient.

• Als SD-Team bieten sie den entwickelten Smartphone-Beobachter den DS-Teams zum
kostenlosen Erwerb an.

9
 2 Organisatorische & Technische Vorgaben

• Als DS-Team bieten sie den entwickelten PC-Beobachter den SD-Teams zum kostenlo-
ses Erwerb an.
• Alle Teams präsentieren außerdem den aktuellen Stand aller weiteren Softwareprodukte
wie Server und Engine-Teilnehmer.
Zusätzlich zur Implementierung stellen Sie dem erwerbenden Team Ihr DevOps-Dokument
bereit, das die Konfiguration und Inbetriebnahme der betreffenden Komponenten beschreibt.
Auch nach der Messe liegt es in Ihrer Pflicht Support für die vertriebenen Komponenten zu
leisten, indem Sie Fehler in Ihrer Software beheben und den Erwerbern neue Versionen zu-
gänglich machen.
Um ein komplettes Produkt zu erhalten, integrieren Sie die auf der Messe erworbenen Kom-
ponenten in Ihre bisherige Implementierung. Wir empfehlen allen Teams die Weiterentwick-
lung des von Ihnen eingekauften Beobachters zu einem Teilnehmer und keine vollständige
Neuentwicklung.
Nach Fertigstellung Ihres Produkts und der dazugehörigen Dokumente, präsentieren Sie Ihr
Produkt in einer Abschlusspräsentation inklusive einer Live-Demonstration.
Am Ende des Praktikums werden wir ein Turnier veranstalten, in dem die Engine-Teilnehmer
der Teams gegeneinander antreten. Durch einen noch festzulegenden Turniermodus wird im
Turnier der beste Engine-Teilnehmer ermittelt.

2.3 Protokoll-Komitee
Um die Kompatibilität der von unterschiedlichen Teams entwickelten Clients und Server zu
gewährleisten, wird ein geeignetes Kommunikationsprotokoll von Ihnen in einem Protokoll-
Komitee entwickelt. Hierzu entsendet jedes Team einen Protokoll-Beauftragten in das Protokoll-
Komitee. In der ersten Sitzung des Protokoll-Komitees wählen die Protokoll-Beauftragten
einen Vorsitzenden, der das Komitee leitet. Entscheidungen des Komitee müssen mit absolu-
ter Mehrheit beschlossen werden. Enthaltungen sind hierbei nicht möglich. Jede Gruppe muss
also an jedem Entscheidungsprozess teilnehmen. Mutwilliges Enthalten einer Gruppe führt
zu Punktabzug für die gesamte Gruppe. Das Komitee wird durch den Programmierbetreuer
unterstützt.
Die Entscheidungen des Protokoll-Komitees und das Protokoll selbst werden durch das
Komitee in einem gesonderten Protokoll-Dokument festgehalten und zu einer separat ausge-
wiesenen Deadline abgegeben. Das festgehaltenen Protokoll dient als Grundlage der Imple-
mentierungen aller Teams, um deren Kompatibilität untereinander zu gewährleisten. Sollten
während der Implementierung Änderungen am Protokoll notwendig werden, trifft sich das
Komitee erneut und veröffentlicht eine neue Version des Protokolls und Dokuments.

2.4 Praktikumsturnier
Am Ende des Praktikums findet ein Turnier statt, in dem die von den Teams entwickelten
Engine-Teilnehmer gegeneinander antreten. Der Server für das Turnier wird entweder von den

10
 2 Organisatorische & Technische Vorgaben

Auftraggebern gestellt oder es wird ein von den Teams entwickelter Spielserver ausgewählt.
Bei der Auswahl des PC-Beobachters für das Turnier wird analog verfahren. Die Konfigurati-
on für das Turnier wird erst beim Turnier selbst bekannt gegeben. Daher empfiehlt es sich vor
dem Turnier Ihren Engine-Teilnehmer mit verschiedenen Konfigurationen zu testen.

2.5 Technologien und Entwicklungswerkzeuge

Die Implementierung erfolgt unter Benutzung der Programmiersprache Java. Das fertige Pro-
dukt soll unter der aktuellsten Version von Java SE 11 lauffähig sein. Die Android-Apps sollen
ab Android 8.0 (API-Level 26) lauffähig sein.

Das Kommunikationsprotokoll zwischen Server und Clients sowie das Dateiformat zur
Speicherung der Konfiguration werden auf der Grundlage von JSON umgesetzt. Für die Kon-
vertierung zwischen Java Objekten und JSON, empfehlen wir Ihnen, Gson3 zu benutzen.

Zur Entwicklung und Versionsverwaltung im Team werden innerhalb des Praktikums die
GitLab https://git.cs.upb.de/ Server der Universität genutzt4 . Hierzu werden von
uns Git-Repositories für die einzelnen Gruppen angelegt. Um Zugriff auf das Git-Repository
einer Gruppe zu erhalten, wird ein Git-Client benötigt. Git-Clients mit GUI sind zum Beispiel
GitKraken5 , TortoiseGit6 oder SourceTree7 .

Zur Anfertigung des Product Backlogs ist das Issue Board des GitLab-Repositories einzu-
setzen.

Um verlässliche und reproduzierbare Builds Ihres entwickelten Produkts und der einzelnen
Komponenten zu realisieren, werden Sie die Build-Systeme Maven bzw. Gradle einsetzen.
Einführungen zu Maven 8 und Gradle 9 finden Sie unter den angegebenen Adressen. Zusätzlich
können Sie sich bei Fragen und Problemen an die Programmierbetreuung wenden.

Optional

Zusätzlich zu den Git-Repositories bietet die Universität Paderborn mit GitLab CI ein System
zur kontinuierlichen Integration Ihrer Implementierung. Mithilfe von GitLab CI kann bspw.

3
https://github.com/google/gson
4
Sie können dem Repository erst hinzugefügt werden, nachdem Sie sich zum ersten mal eingeloggt haben.
5
https://www.gitkraken.com/
6
https://tortoisegit.org/
7
https://www.sourcetreeapp.com/
8
https://maven.apache.org/guides/getting-started/maven-in-five-minutes.
html
9
http://www.vogella.com/tutorials/Gradle/article.html

11
 2 Organisatorische & Technische Vorgaben

bei pushes in den main-branch automatisiert der Build-Prozess und die Testausführung ange-
stoßen werden. Somit bietet es Ihnen die Möglichkeit bei jedem push automatisiert Ihren Code
zu bauen, zu testen, und bei fehlerhaften Commits sofort Benachrichtigungen per E-Mail zu
erhalten. Dies hilft Ihnen bei der kontinuierlichen Qualitätskontrolle und Koordination. Da
Sie in dieser Veranstaltung entsprechend Scrum nach jedem Sprint ein inkrementelles Produkt
Artefakt entwickeln, können Sie diese mit GitLab CI kontinuierlich bauen und testen. Hilfe zu
GitLab CI finden Sie unter https://docs.gitlab.com/ee/ci/. Zusätzlich können
Sie sich bei Fragen und Problemen an den Programmierberater wenden.

12