Projekt 2: Blokus

Im zweiten Projekt des SoPra26a soll das Brettspiel Blokus als Kotlin-Anwendung unter Verwendung des BoardGameWork realisiert werden.

Blokus ist ein abstraktes Strategiespiel, bei dem die Spieler*innen versuchen, so viele Teile wie möglich auf das Brett zu legen und die meiste Fläche zu bedecken. Die Teile haben verschiedene Formen und Farben. Die Teile derselben Farbe dürfen sich nicht an den Außenkanten berühren, sondern müssen über die Ecken verbunden sein. Das Spiel ist einfach zu verstehen für Anfänger, aber eine echte Herausforderung für Profis.

• Official Instructions (english)
• Blokus bei spielregeln-spielanleitungen.de (deutsch)
• Blokus bei BoardGameGeek (english)
• Regeln zu Blokus - Spielanleitung von spielregeln-spielanleitungen.de (Video deutsch)
• How to Play Blokus (With 2, 3, or 4 players) by Brimley Games (Video english)

Für die Implementierung ist allein das englische Regelwerkdokument (Official Instructions) ausschlaggebend.

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:

• Das Spiel ist gemäß der offiziellen Regeln (Official Instructions (english)) zu implementieren.
• Die Namen der Spieler*innen müssen angegeben werden und eindeutig sein.
• Die Farben und Reihenfolge der Spielenden soll vor Spielstart sowohl frei wählbar konfiguriert als auch randomisiert werden können.
• Die erweiterten Regeln Advanced Scoring (Zusatzpunkte für alle abgelegten Teile + Endteil) müssen umgesetzt werden.
• Das Spiel soll in zwei Modi unabhängig gespielt werden können (Mischung der beiden Modi ist nicht vorgesehen):
  • Die Spieler*innen wählen nacheinander und reihum am gleichen Bildschirm ihre Aktionen aus (Hotseat-Modus).
  • Die Spieler*innen spielen gegeneinander via Netzwerk unter Verwendung des BGW-Net Moduls.
• 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. Die Undo-Funktion muss alle Spielzüge so weit zurücknehmen, bis der aktuelle Spieler wieder am Zug ist oder der Beginn des Spiels erreicht wurde. Die Redo-Funktion soll jedoch die Spielzüge der einzelnen Spielenden wiederholen. Für Netzwerkspiele soll dieses Feature deaktiviert sein.
• 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. Wenn ein Spiel gespeichert und dann zu einem späteren Zeitpunkt geladen wird, soll die bereits gespielte History weiter vorhanden sein, d.h. Undo und Redo sollen genau so funktionieren wie bei einem nicht unterbrochenen Spiel.
• 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 einen „richtigen“ 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.
  • Kein Bot-Zug darf länger als 10 Sekunden benötigen. Ein „Zug“ ist dabei die Zeitspanne in der der Bot am Zug ist.
• Jede Gruppe soll zu ihrem Spiel auch eine PDF-Anleitung beilegen, die beschreibt, wie das Spiel der Gruppe ausgeführt und bedient wird.

Im SoPra 26a sollen folgende Varianten implementiert werden:

• Die vier-Spielenden-Variante aus den Regeln
• Die drei-Spielenden-Variante aus den Regeln
• Eine zwei-Spielenden-Variante mit jeweils zwei Farben pro Spieler*in nach den Regeln
• Eine zwei-Spielenden-Variante mit zwei Farben und einem Brett von 14×14 (Einschränkungen siehe unten)

• Wenn mindestens ein Stein auf das Brett im Rahmen eines Zuges gelegt werden kann, muss dies auch erfolgen. Ein „freiwilliges“ Passen ist nicht möglich.
• Zu Beginn eines Spiels muss jede*r Spieler*in ihren/seinen ersten Stein in eine freie Ecke legen. Die freie Ecke kann dabei beliebig gewählt werden.
• Steine können gedreht und gespiegelt werden, bevor sie auf dem Brett platziert werden.
• Es kann mehrere Gewinner*innen geben, wenn z.B. zwei Spieler*innen 20 Punkte erreicht haben.
• Die Reihenfolge bzw. die Farbenfolge, in der gespielt wird, kann in der 4-Spielenden-Variante frei gewählt werden. Die Spieler*innen sind nacheinander an der Reihe. In den 2- bzw. 3-Spielenden-Varianten sind die Reihenfolgen der Farben dagegen festgelegt (Blau → Gelb → Rot → Grün), damit die Spieler*innen abwechselnd an der Reihe sind, bzw. die übrig gebliebenen Farben von allen anderen Spieler*innen abwechselnd gespielt wird.
• Beim 2-Spielenden-Spiel mit einem 14×14-Feld darf jede*r Spieler*in nur eine Ecke verwenden und nicht noch an einer zweiten Ecke starten.
• Beim 2-Spielenden-Spiel werden die Advanced Scoring-Regeln in dem Sinne umgesetzt, dass die beiden Spieler*innen einzeln betrachtet werden und entsprechend individuell die Sonderpunkte erhalten können und die Punkte dann zum Schluss zusammengerechnet werden.
• Wenn im 3-Spielenden-Spiel nur noch der/die geteilte Spieler*in Züge durchführen kann, kann das Spiel vorzeitig beendet und gewertet werden.

Alle noch nicht angelegten Plättchen aller Spieler*innen sind für alle Spieler*innen einsehbar.

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 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.