Blue Moon Fans

PC-Spiel - Umsetzung einer Game engine
Ruwenzori - Mi 24 Aug, 2005 09:06
Titel: Umsetzung einer Game engine
Ich löse das Thema mal aus dem anderen Thread heraus. Es hat dort nichts zu suchen und ist wichtig genug, einen eigenen Ordner zu bekommen.

VanKurt hat folgendes geschrieben:
Zusammen mit einem Freund habe ich schonmal eine PC Umsetzung gebastelt, die allerdings nbie fertig wurde...das Problem war die ganzen Sonderfunktionen auf ein übersichtliches, flexibles System zu bringen, dass einen korrekten (und ist ganz schön kompliziert!) Spielfluss garantiert.

[...]

BTW: Was wäre denn ein vernünftiges System um die Sonderregeln zu implementieren? Das bereitet mir immernoch Kopfzerbrechen Wink


KivasFajo hat folgendes geschrieben:
@VanKurt: Du hast eine wirklich wichtige Frage gestellt, denn auch ich habe schon länger die Vermutung, dass der Ansatz von Themi - alle Karten mehr oder weniger hart codiert zu implementieren - nicht gerade der beste Ansatz war.
Um die dynamischen Aspekte von Blue Moon (z.B. die Wechselwirkung von SFs) in den Griff zu bekommen, müsste man den Ablauf eines Spielzuges präziser definieren als im Regelheft und dabei auch alle Zeitpunkte und Arten von SF-Wirkung feststellen. Daraus müsste man dann eine abstrahierte Definition einer Karte ableiten.
Aus meiner Sicht ist eine PC-Umsetzung nur dann machbar, wenn man mit einer Engine Kartendefinitionen auswertet.
Ruwenzori - Mi 24 Aug, 2005 09:28
Titel:
Meine Vorstellung dazu wäre gewesen, ein transientes Control-Objekt zu definieren, das jede Menge IsXxxxxx Booleans hat, die vom Spiel je nach Spielzustand verwaltet werden - oder noch besser, jeweils gemäß dem aktuellen Spielzustand kalkuliert werden. Dazu noch ein paar Properties, die den aktuellen Spielzustand beschreiben. Dann müssen in jeder Phase des KI-Zuges wie auch des menschlichen Spielers (zur Prüfung auf Zulässigkeit seiner Handlungen) jede Menge Prüfungen anhand dieser Zustandsbeschreiber ablaufen. Eine Codierung auf Kartenebene kann ich mir nicht als zielführend vorstellen. Da muss ein Abstraktionslayer draufgesetzt werden.

Dieses Control Objekt kann dann auch fröhlich herumgereicht werden, beispielsweise an die KI-Plugins, die man ans Spiel andocken können soll (den Ansatz von Themi fand ich genial), diese verändern ganz nach ihrem Gusto die definierten Schnittstellen-Props und geben es zurück.

also grobes Beispiel:
Property FightElement As StringList(,F,E) // Fire, Earth. Wird beim ersten "Stärke ansagen" gesetzt
Property MyStrength As Integer
Property YourStrength As Integer
Property MyNumberOfStorms As Integer[Calculated]
Property YourNumberOfStorms As Integer[Calculated]
Property MyLaughingGasIsActive As Boolean // Lachgas doch als Karte, weil es spez. Bedeutung als Einzelkarte hat
Property YourLaughingGasIsActive As Boolean
Property MySupportForbidden As Boolean
Property YourSupportForbidden As Boolean
Property MySupportIgnored As Boolean
Property YourSupportIgnored As Boolean
Property MyHandcards As CollectionOfObjects
Property MyHandcardNumber As Integer[Calculated]
usw. usf.

Das Objektmodell dafür ist vorhersehbar recht komplex, auch das Phasenmodell des Spielablaufs, aber ganz sicher lösbar.

Ich halte übrigens nichts von dem Ansatz, erstmal draufloszuprogrammieren und dann zu sehen, wie man die Abläufe hinbekommt ... Erst muss das Objektmodell und die Interaktionen des Spiels komplett theoretisch stehen, dann gehts ans Codieren.
ErzEngel - Mi 24 Aug, 2005 11:13
Titel:
Na dann weiß ich ja schon einen Urlauber, der ca. 3,5 Wochen Zeit hat, sich dieses Objektmodell mal durchzuplanen. Smile
CaptNeo - So 28 Aug, 2005 17:24
Titel:
Hallo,
nachdem VanKurt und ich jetzt die Erfahrung mit dem ersten Umsetzungsversuch haben, würde ich mich für eine dynamische Stack-Architektur aussprechen.
D.h. am Anfang jeder Runde wird ein Stack mit je einem "Layer" pro Speilphase angelegt. Jedes Layer besitzt ähnlich wie von Ruwenzori skizziert mehrere Attribute, die die erlaubten Zugmöglichkeiten speichern.
Die Layer sind zu Spielbeginn mit Standard-Werten initialisiert. z.B.:

Stack:
-->Top
Layer(Zugbeginn)
Layer(Aktionen)
Layer(Rückzug)
...
Layer(Nachziehen)
Layer(Zugende)
-->EOS

Das Element Layer(Aktionen) enthält z.B. Flags, die anzeigen, dass eine Anführeraktion, ein Einfluss oder eine Drachenkarte gespielt werden darf, oder eine Karte mit Abwurfsymbol getauscht werden kann.

Wird jetzt zum Beispiel eine Anführeraktion "Gedankensturm" gespielt, werden alle diese Flags auf False gesetzt, da eine dieser Aktionen durchgeführt wurde und im Layer(Unterstützung) das Attribut für die Anzahl der spielbaren Karten auf "Infinite" gesetzt.

Ähnlich kann auch bei einer Karte, die permanentere Wirkungen hat (z.B. Unterstützungen) das aktuelle Kampf-Template so geändert werden, dass direkt zu Rundenbeginn die richtigen Standard-Optionen gesetzt werden.

Wird eine aktive Karte mit permanenten Effekten abgeworfen, muss bei dieser Implementierung jedoch dieser Regelstack komplett neu berechnet werden (sollte aber nicht zu aufwändig sein), indem ein Algorithmus die verbliebenen aktiven Karten alle der Reihe nach erneut auf ein Standard-Layer-Set anwendet.

Dieses Layermodell erlaubt auch das Einfügen von irregulären "Spielphasen" wie "bis Zugende xyz tun", indem ein entsprechendes Layer vor das Layer(Zugende) eingefügt wird.

Ver- und Gebote bzgl. bestimmten (gerade-/ungerade, Symbole, Sonderfunktionen etc.) Karten kann man etweder flexibel implementieren, indem man für jeden Spieler ein abstraktes Array mit diesen Klassen anlegt und in jeder Karte die Zugehörigkeit speichert, oder mit einem 300bit großen Boolen-Array Hard-coden. HIer weiß ich nicht, was effektiv aufwendiger ist. Falls noch einmal neue Karten herauskommen sollten, dann ist der erste Ansatz flexibeler.
CaptNeo - Mo 05 Sep, 2005 10:58
Titel:
Hallo nochmal,
habe ich am WE krankheitsbedingt (also auf die Couch gefesselt) in Ruhe mit den Sonderfunktionen von Blue Moon auseinandergesetzt.
Inzwischen glaube ich, "Grund" in die Sache bringen zu können. Es scheint klar definierbare Typen von Sonderfunktionen zu geben:
- Modifikatoren (Die Werte von Karten werden verändert)
- Ignorationen (Katen oder deren Attribute werden temporär ausgeblendet)
- Konditionen (Ausspielbedingungen bei Mutanten und Tutu)
- Handlungen (Ich darf, Du musst)
- Noch weitere (können aber je nach Abstraktion und Implementation zu den ersteren zählen)
Die Implementation dieser flexiblen Regeln scheint mir ein klarer Fall von Action-Listener-Modell zu sein (auch wenn ich sowas prinzipiell nicht so gut leiden kann/wenig Erfahrung habe).
Außerdem habe ich jetzt eine rund zweiseitige Definition den von mir angedachten Layer-Modells. Mal schauen was draus wird...
Ruwenzori - Do 22 Sep, 2005 23:06
Titel:
Klingt gut.

Wie gesagt, wenn Hilfe benötigt wird (z.B. beim Gegenlesen des Modells oder so), Bescheid sagen. Ich helfe gern mit, wenns Sinn macht.
CaptNeo - Fr 23 Sep, 2005 16:11
Titel:
@ Ruwenzori
Hast du C++-Erfahrung? Ich muss die Tage mit VanKurt sowieso per Mail verkehren. Wir haben die Visual Studio 2005 Beta 2 als IDE gewählt. Wir könnten noch eine helfende Hand bei der Multiplayer-Umsetzung benötigen.
Ruwenzori - Fr 23 Sep, 2005 20:54
Titel:
CaptNeo hat folgendes geschrieben:
@ Ruwenzori
Hast du C++-Erfahrung?

Nein, leider nicht.
Alle Zeiten sind GMT + 1 Stunde
Powered by phpBB2 Plus and Kostenloses Forum based on phpBB