Projekt 2: Azul

Im zweiten Projekt des SoPra25c soll das Brettspiel Azul als Kotlin-Anwendung unter Verwendung des BoardGameWork realisiert werden. Azul ist ein Legespiel, bei dem eine Wand mit bunten Fliesen (nach den portugiesischen Azulejos) nach bestimmten Mustern gefliest werden soll. Dabei gibt es Bonuspunkte für bestimmte Gruppen und Konstellationen, aber auch Minuspunkte für Fliesen, die man in Manufakturen zwar eingekauft hat, aber nicht verbauen konnte.

• Regeln
• Video by Rules Girl: How to Play Azul in 3 Minutes
• Azul bei BoardGameGeek

Das zu entwickelnde Programm soll den Spielablauf steuern und für die Einhaltung der Spielregeln sorgen. Zusätzliche Features, die nicht direkt auf den Spielregeln basieren, sollen umgesetzt werden:

• Die in den Regeln benannte Spielvariante mit der grauen Rückseite des Spieler-Boards muss nicht umgesetzt werden.
• In den Regeln ist der seltene Fall beschrieben, dass beim Befüllen der Factories nicht mehr genügend Tiles vorhanden sind, um alle Factories vollständig zu befüllen. Dort ist aber nicht geregelt, wie diese dann unvollständig befüllt werden sollen. Im Rahmen des SoPras haben wir uns darauf verständigt, dass zunächst die erste Factory mit 4 Tiles bestückt wird, dann die zweite, und so weiter, bis keine mehr vorhanden sind. Damit existiert nach Verteilung neben vollständig und gar nicht befüllten Factories ggf. eine Factory mit 1-3 Tiles.
• Die Reihenfolge der Spielenden soll vor Spielstart sowohl frei wählbar konfiguriert als auch randomisiert werden können.
• Das Spiel soll in zwei Modi unabhängig gespielt werden können (eine Mischung der beiden Modi ist nicht vorgesehen):
  • Die Spielenden wählen nacheinander und reihum am gleichen Bildschirm ihre Aktionen aus (Hotseat-Modus).
  • Die Spielenden spielen gegeneinander via Netzwerk unter Verwendung des BGW-Net-Moduls.
• Ein Spiel soll unterbrochen und gespeichert werden können, um es zu einem späteren Zeitpunkt (auch nach Neustart des Programms) fortzusetzen. Für Netzwerkspiele soll dieses Feature deaktiviert sein.
• Es sollen simulierte Mitspieler („Bots“) zur Verfügung stehen. Hierbei soll es einen einfachen Test-Bot geben, der z.B. nur randomisiert einen der möglichen Züge auswählt, sowie eine „richtige“ für das am Ende stattfindende Bot-Turnier. Es soll auch möglich sein, dass reine Bot-Spiele (also ohne menschliche Spielende) durchgeführt werden. Damit ein Zuschauen und Nachvollziehen der Züge möglich wird, soll die Simulationsgeschwindigkeit angepasst werden können.
• Die Bots dürfen beim Spielen keine Vorteile gegenüber einem menschlichen Spielenden ausnutzen.
• Kein Bot-Zug darf länger als 10 Sekunden benötigen.
• Um verschiedene Strategien studieren und ausprobieren zu können, soll das Spiel über eine Undo- und eine Redo-Funktion verfügen. Die Spielzüge sollen bis zum Spielstart zurückgenommen werden können. Für Netzwerkspiele soll dieses Feature deaktiviert sein.
• Jede Gruppe soll zu ihrem Spiel auch eine PDF-Anleitung beilegen, die beschreibt, wie das Spiel ausgeführt und bedient wird.

Am Ende des Projekts findet ein Turnier statt, bei dem die Bots der Gruppen in 1v1-Spielen über den Netzwerkmodus gegeneinander antreten. Hierbei ist zu beachten, dass das BOT-Turnier ausschließlich auf den Pool-Rechnern durchgeführt wird. Es darf kein eigener Rechner für das Turnier verwendet werden. Der genaue Ablauf des Turniers wird im Laufe des Projekts noch festgelegt.

Ein Bot-Zug darf dabei maximal 10 Sekunden Rechenzeit benötigen und muss regelkonform sein. Sollte eine Bot sich nicht an die Spielregeln halten (beabsichtigt oder unbeabsichtigt), wird die Gruppe vom Bot-Turnier ausgeschlossen.