Das ist das Projekt der „Copy Pasta“ Gruppe.
Leider ist es uns bis zur Deadline nicht gelungen, alle unsere Wünsche umzusetzen.
Trotzdem konnten wir ein funktionierendes und in sich stimmiges Spiel entwickeln.

Gruppenaufgaben

(Die Anforderungen entsprechen den Gruppenaufgaben in der ‚Praktikum.pdf‘ auf Relax.)

NIKI-Bot

Umsetzungen:

1. Der NikiBot erweitert die Player-Klasse.
2. Er überschreibt die würfeln Methode.
3. Dabei ermittelt er alle möglichen Züge und wählt zufällig einen davon aus.

Bot-Gegner

Umsetzungen:

1. Jeder Bot erweitert den NikiBot und überschreibt ebenfalls die würfeln Methode.
2. Alle möglichen Züge werden berechnet und jeweils mit einem Score bewertet.
3. Der Bot entscheidet sich für den Zug mit dem höchsten Score.
4. Die Bots verwenden unterschiedliche Gewichtungen bei der Bewertung der Züge.
5. Dadurch setzen sich die Scores unterschiedlich zusammen, was zu verschiedenem Spielverhalten führt.

Achievements

Umsetzungen:

1. Achievements werden in JSON-Dateien gespeichert.
2. Ein Handler lädt die Achievements beim Start des Spiels.
3. Er prüft, ob ein Achievement erreicht wurde und löst dann die entsprechende Aktion aus.
4. Wird ein Achievement erreicht, wird es in einer save Datei gespeichert.

Bot-Modi

Umsetzungen:

1. Zu Beginn des Spiels kann man auswählen, gegen welchen Bot man spielen möchte.
2. Anschließend kann man die Bots mit unterschiedlichen Gewichtungen auswählen.
3. Danach wird das Spiel gestartet.

Einzelaufgaben

Build Tool - Paul Schweizer

Anforderungen:

• Das Projekt wird über das Buildtool: Maven gesteuert.
• Später wird es durch eine ausführbare .jar Datei gestartet.

Umsetzungen:

1. Recherchiert, wie andere Projekte mit Maven/Gradle funktionieren.
2. Basierend auf der Dokumentation eine pom.xml für das Projekt erstellt.
3. Die pom.xml entsprechend dem Projekt angepasst.
4. Die Dependencies entsprechend den verwendeten Bibliotheken hinzugefügt.

Spectator Mode - Jan Roller

Hinweis:

Der Spectator-Modus funktioniert grundsätzlich, überschreibt aber das aktuelle Spiel.
Aus diesem Grund ist die Methode startSpectatorMode im GameController derzeit auskommentiert, um den Spielfluss und die Spielerinteraktionen nicht zu unterbrechen.

Anforderungen:

• Der Spectator Mode soll das Spielfeld übertragen in einem speraten Consolenfenster
• Die Eingaben der Nutzer sollten, nicht übertragen werden.

Umsetzungen:

1. Das Spielfeld soll über Threads in ein separates Konsolenfenster übertragen werden.
2. Die Konsole soll bei jedem neuen Aufruf gelöscht werden.
3. Sobald der Spielstatus GAME_OVER erreicht ist, wird das Konsolenfenster geschlossen.

Umsetzungen:

Board Editor - Henning Raudzis

Anforderungen:

• Der Nutzer soll im Hauptmenü die Möglichkeit haben, einen Editor-Modus zu starten.
• Der Nutzer muss durch Eingaben im Editor ein eigenes Spielbrett erstellen können.
• Der Nutzer muss normale Spielfelder, Startfelder, Zielfelder und Sperrsteine auf dem Spielbrett platzieren können.
• Der Editor-Modus muss nach jeder Aktion das aktuelle Board anzeigen.
• Der Editor-Modus muss über eine Undo Funktion verfügen, mit der die vorherige Aktion rückgängig gemacht werden kann.
• Das Spielbrett muss auf Spielbarkeit überprüft werden: Von jedem Startfeld muss ein Zielfeld erreicht werden können.
• Der Nutzer muss das Spielbrett unter frei wählbarem Namen speichern können.
• Gespeicherte Spielbretter sind lokal in Textformat in einem bestimmten Verzeichnis gespeichert.
• Gespeicherte Spielbretter enthalten Metadaten, wie einen Namen, die Größe, einen Autor und das Erstelldatum.
• Gespeicherte Spielbretter müssen geladen und im Spiel verwendet werden können.
• Gespeicherte Spielbretter müssen gelöscht werden können.
• Der Editor-Modus und das Laden von Spielbrettern müssen durch das vom Team gewählten Frontend bedienbar sein.
• Die Bedienung muss verständlich sein.

Umsetzungen:

1. Die Spielbretter sollten unabhängig vom Layout des Brettes vom GameBoardLoader geladen werden können.
2. Der Board Editor wurde in ein eigenes Package verschoben, um Separation of Concerns zu gewährleisten.
3. Der Editor wurde anschließend ins Menü integriert und bietet verschiedene aufrufbare Funktionen.
4. Zum Schluss wurde getestet, ob alles einwandfrei funktioniert.

Bot Erweiterung - Jens Jung

Anforderungen: Funktionale Anforderungen

• FR-1.1 Das System muss einen Bot Editor bereitstellen, der es Spielern ermöglicht, einen benutzerdefinierten Bot zu erstellen
• FR-1.2 Der Bot Editor muss über das vom Team gewählte Frontend bedienbar sein
• FR-1.3 Das System muss Spieler nach der gewünschten Gewichtung der Bot-Entscheidungskriterien fragen
• FR-1.4 Die Gewichtungsparameter müssen aus dem vom Team gewählten Frontend ausgelesen werden können
• FR-1.5 Das System muss einen neuen Bot mit den eingegebenen Kriterien erstellen
• FR-1.6 Spieler müssen gegen den erstellten benutzerdefinierten Bot spielen können

Nicht-funktionale Anforderungen

• NFR-1.1 Die Benutzereingabe über das vom Team gewählte Frontend muss intuitiv und verständlich sein
• NFR-1.2 Ungültige Eingaben müssen abgefangen und dem Benutzer gemeldet werden

2. WEIGHTCHANGER KLASSE

Funktionale Anforderungen

• FR-2.1 Eine WeightChanger Klasse muss implementiert werden
• FR-2.2 Die WeightChanger Klasse muss objektorientiert vom bisherigen Bot abgegrenzt sein
• FR-2.3 Die Bot-Entscheidungskriterien müssen nach jeder Spielereingabe neu gewichtet werden
• FR-2.4 Der Bot muss seine Spielweise dynamisch an den aktuellen Spielstand anpassen
• FR-2.5 Bei unverändertem Spielstand (z.B. wenn Gegner aussetzen muss) ist eine Gewichtungsänderung optional

Nicht-funktionale Anforderungen

• NFR-2.1 Die WeightChanger Klasse muss klar strukturiert und wartbar sein
• NFR-2.2 Die dynamische Anpassung muss performant erfolgen (ohne merkliche Verzögerung)

3. RUBBERBANDING-MECHANISMUS

Funktionale Anforderungen

• FR-3.1 Ein Rubberbanding-System muss für Bots implementiert werden
• FR-3.2 Das System muss erkennen, wenn ein Bot weit hinter einem Spieler zurückliegt
• FR-3.3 Bei Rückstand muss der Bot einen "besseren" Würfel erhalten
• FR-3.4 Der Bot darf bestimmte niedrige Würfelwerte (z.B. 1 oder 2) nicht mehr würfeln, bis er aufgeholt hat
• FR-3.5 Das Rubberbanding muss insbesondere bei 1v1-Spielen gegen einen Bot funktionieren

Nicht-funktionale Anforderungen

• NFR-3.1 Das Rubberbanding muss das Spiel spannender machen
• NFR-3.2 Die Verbesserung des Würfels muss ausgewogen sein (nicht zu stark/schwach)
• NFR-3.3 Der Mechanismus muss fair und nachvollziehbar sein

4. ALLGEMEINE ANFORDERUNGEN

Technische Anforderungen

• TR-4.1 Alle neuen Komponenten müssen in die bestehende Spielarchitektur integriert werden
• TR-4.2 Die Implementierung muss objektorientierte Prinzipien befolgen
• TR-4.3 Der Code muss gut dokumentiert und testbar sein

Qualitätsanforderungen

• QR-4.1 Die Bot-Erweiterungen müssen die Spielerfahrung verbessern
• QR-4.2 Das System muss stabil und fehlerfrei funktionieren
• QR-4.3 Die Performance des Spiels darf nicht beeinträchtigt werden

5. ABGRENZUNG

Was ist Teil des Projekts

• Bot Editor mit Frontend-Eingabe
• WeightChanger Klasse für dynamische Anpassung
• Rubberbanding-Mechanismus

Was ist nicht Teil des Projekts

• Speicherung/Laden von Bot-Konfigurationen
• Multiplayer-spezifische Rubberbanding-Features

Umsetzungen:

1. Bot-Editor wurde hinzugefügt, der dem Nutzer Erklärungen zur Bedienung liefert.
2. Der Nutzer wird aufgefordert, die Gewichtungen der Bot-Gegner einzugeben.
3. Es wurde ein Rubberbanding Feature implementiert, inklusive einer Abfrage, ob dieses aktiviert werden soll.
4. Immer wenn ein Bot mit aktiviertem Rubberbanding agiert, wird durch verschiedene Aktionen überprüft, ob das Rubberbanding ausgelöst werden soll.
5. Damit die Bots auf das Spielerverhalten reagieren können, werden die Gewichtungen der Bots während des Spiels dynamisch angepasst.
6. Zum Schluss wurde getestet, ob alles einwandfrei funktioniert.

Projektmangement - Marc Falkenburger

Anforderungen:

• Zu allen Aufgaben (Gruppen- & Einzelaufgaben) werden Anforderungen und Akzeptanzkriterien definiert.
• Der Projektfortschritt wird geplant und überwacht.

Umsetzungen:

1. Termine vereinbart, um bestimmte Aufgaben gemeinsam zu erledigen.
2. Branches zusammengeführt und anderen Hilfestellung leistet.
3. Hilfreiche Utility Funktionen geschrieben, die allgemein im Projekt unterstützen.
4. Die README.md verfasst sowie das Git-Repository und die Assets gepflegt.