Projekt 2

Im zweiten Projekt des SoPra25d soll das Kartenspiel Faraway als Kotlin-Anwendung unter Verwendung des BoardGameWork realisiert werden.

Faraway ist ein taktisches Kartenspiel, in dem die Spieler:innen das geheimnisvolle Land Alula erkunden. Durch geschicktes Ausspielen und Anordnen von Regionskarten entstehen neue Ziele und Wertungen – doch Punkte gibt es erst auf dem Rückweg, wo kluge Planung belohnt wird.

• Regeln + Bewertungsbeispiel (deutsch)
• Regeln (english)
• Faraway bei BoardGameGeek
• Erklärvideo (englisch)

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 zu implementieren. Bei Widersprüchen sind die deutschen Regeln maßgeblich.
• Anders als in den Regeln beschrieben sollen die Handkarten und die Nachziehstapel offen liegen und von den Spielenden eingesehen werden dürfen. Eine Spielrunde verläuft abweichend zu den Regeln wie folgt:
  • Die Spielenden wählen reihum eine Karte aus, die gespielt werden soll. Die gewählte Karte ist nicht öffentlich, bis alle Spielenden eine Karte gewählt haben und diese aufgedeckt werden. In der GUI darf die gewählte Karte für die anderen Spielenden nicht angezeigt werden. Ein Bot darf die Information über die gewählte Karte der Mitspielenden nicht verwenden.
  • Sobald alle Spielenden ihre Karte gewählt haben werden diese gleichzeitig ausgespielt.
  • Die Reihenfolge der Erkundungszeiten der gewählten Karten bestimmen (aufsteigend) die neue Spielendenreihenfolge.
  • Die Spielenden sind reihum nach der neuen Reihenfolge noch einmal am Zug:
    • Jede/r Spielende mit aufsteigender Erkundungszeit zieht Heiligtümer vom Nachziehstapel nach, wählt genau eins aus und spielt es sofort aus. Die übrigen Heiligtümer werden in der Nachziehreihenfolge wieder unter den Nachziehstapel gelegt.
    • Dann zieht der/die Spielende eine Karte aus der Mitte und nimmt diese auf die Hand. In der letzten Runde wird dieser Schritt übersprungen.
    • Nun ist der/die nächste Spieler/in am Zug.
  • Die in der Mitte verbliebene Regionenkarte wird aus dem Spiel entfernt und die Mitte wird vom Nachziehstapel nachgelegt.
• Die „Fortgeschrittene Variante“ (mit 5 Startkarten) des Spiels soll auch implementiert werden werden und kann beim Spielstart an- oder ausgeschaltet werden.
• Die Startreihenfolge der Spielenden soll vor Spielstart sowohl frei wählbar konfiguriert als auch randomisiert werden können.
  • Zur Unterscheidung der Spielenden muss mindestens ein Name konfiguriert 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.
• Beim Spielstart werden die Regionskarten in 3 bzw. 5 Runden reihum verteilt. Bei der Variante wählen die Spieler:innen gemäß Spieler:innenreihenfolge ihre 3 Handkarten aus.
• Am Ende des Spiels soll die Wertung ähnlich zum Wertungsblock des Originalspiels aufgeschlüsselt werden und ein:e Gewinner:in angezeigt werden.
• 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.
• 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.
• 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 (insbesondere „Heiligtum wählen“ und „Regionskarte Nachziehen“ dürfen *zusammen* nur 10 Sekunden dauern).
• Jede Gruppe soll zu ihrem Spiel auch eine PDF-Anleitung beilegen, die beschreibt, wie das Spiel der Gruppe ausgeführt und bedient wird.

Die Datei enthält alle notwendigen Informationen zu den im Spiel verfügbaren Spielkarten, die für die Implementierung des Spiels benötigt werden.

Im Datensatz findet ihr ein Array mit allen Regionskarten sowie Sanctuary-Karten. Die 68 Regionskarten haben dabei die IDs `0` bis `67`, die 45 Sanctuary-Karten die IDs `68` bis `112`. Jede Karte wird durch ein JSON-Objekt beschrieben, das die folgenden Attribute enthält:

{
  "id": Int,
  "sanctuary": Boolean,
  "biome": "none" | "blue" | "green" | "yellow" | "red",
  "time": {
      "night": Boolean,
      "duration": Int
  },
  "wonders": {
      "mineral": Int,
      "animal": Int,
      "plant": Int,
  },
  "clue": Boolean,
  "quest": {
      "fame": Int,
      "prerequisites": {
          "mineral": Int,
          "animal": Int,
          "plant": Int
      },
      "types": ["clue" | "night" | "wonders_animal" | "wonders_mineral" | "wonders_plant" |
          "biome_blue" | "biome_green" | "biome_yellow" | "biome_red" | "biome_all"]
  } | null
}

Das Array `quest.types` beinhaltet die möglichen Aufgabenarten, die für die Karte relevant sind. Eine Karte kann mehrere Aufgabenarten haben (z.B. `biome_yellow` und `biome_blue`) und zählt wie im Bewertungsbeispiel beschrieben. Wenn das Array leer ist, hat die Karte keine Aufgabenarten und der Fame wird immer angerechnet, sobald die Voraussetzungen erfüllt sind.

Sollte eine Karte keine Aufgabe haben, ist das Attribut `quest` gleich `null`.

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.