Am Beginn der Entwicklung unseres Clients haben wir uns Gedanken darüber gemacht wie das Dateiformat sein sollte, das der Client später schreiben und jetzt lesen können sollte.
Eine der ersten Grundgedanken war, dass es leicht verständlich sein sollte, damit man bei der Entwicklung der Einleselogik Zeit spare. Es sollte auch nicht allein für Maschinen lesbar sein, da somit "jeder" die Möglichkeit habe Änderungen mit einem einfachen Editor vorzunehmen. Ein Kernschwerpunkt waren für uns auch die Themen Erweiterbarkeit und Zukunftssicherheit.
Am Ende ist ein xml-basierendes Format herausgekommen, das durch Grundvereinbarungen dem Entwickler eine einfache Handhabung mit verschiedenen Versionen von verschiedenen Herausgeben ermöglicht, auch wenn seine Applikation selbst nicht alle Formate benutzen kann. Die unterschiedlichen Formate können manuell mit jedem gängigen Texteditor oder spezialisierten XML-Editor gelesen und bearbeitet werden. Die größte Erleichterung vor dem Einlesen der Datei ist die Möglichkeit XML anhand von XSD zu prüfen.
Dieses Format basiert auf dem Grundkonzept eines handgeschriebenen Kifus. Es werden die Spieler und ihre gesetzten Steine protokolliert.
Ein Grund hierfür ist, dass naturgemäß ein Stein eine Farbe hat. Weiterhin ermöglicht diese Eigenschaft ein mehrfarbiges Spiel oder gar ein einfarbiges Spiel zu speichern, das von einem Player auch als solches automatisch erkannt wird. Die PlayerId ist jedoch die entscheidende Information, um den Zug einem Spieler zuordnet.
Ein Leitsatz der Softwareentwicklung heißt, dass man nichts speichern solle, was berechnet werden könne. In diesem Fall haben wir ganz bewusst diesen berechenbaren Wert gespeichert, damit ein Player nicht erst das Spiel durchspielen muss, um das Ergebnis auszugeben. Kurz: Ein paar Bit Speichermehr zu Gunsten der Prozessoraktivität.
Ein Pass ist ganz einfach zu speichern. Ihr lasst in einem Move-Element die Eigentschaften X und Y (optional auch Color) weg. Hier ein Beispiel: <move playerId="0" />
Ein Spiel wird bekanntlich auf zwei Arten beendet. Eine Variante ist, dass beide Spieler hintereinander passen und wie ein Pass gespeichert wird, ist bereits beschrieben. Die andere Möglichkeit ein Spiel zu beenden ist, wenn ein Spieler kapituliert. Eine Aufgabe wird gespeichert durch die Kombination zweier Informationen. Zum einen wird dem aufgebenden Spieler eine "-1" in seine Points geschrieben und zum anderen ist sein letzter Zug formal ein Pass.
Der einzige Unterschied zu GoFans 1.1 ist, dass Gofans 1.2 die Folgezüge in den aktuellen Zug verschachtelt werden. Damit sollen Varianten ermöglicht werden.
Dieses Format ist ist eine Erweiterung des Formates GoFans 1.1. Wir haben dieses Format entworfen, um unnötige Rechenoperationen einzusparen, die beispielsweise beim Abspielen immer wieder vollzogen werden müssen, ohne dass es eine Änderung des Ergebnisses ergibt.
Es sind die Removes. Ein Remove ist das Entfernen eines Steins vom Brett. Steine werden nur vom Brett entfernt, wenn sie geschlagen worden sind. Mit dieser simplen Erweiterung unseres 1.1-Formates werden beim Abspielen Algorithmen zum Finden geschlagener Steine überflüssig. Gerade damit der Player diese Suchalgorithmen gezielt meidet, muss 2.1 von 1.1 unterscheidbar sein.
Der einzige Unterschied zu GoFans 1.1 ist, dass Gofans 1.2 die Folgezüge in den aktuellen Zug verschachtelt werden. Damit sollen Varianten ermöglicht werden.
Wenn ihr lusst bekommen habt, eines der im Formatindex gelistetes Format in eurer Applikation zu verwenden, dann findet ihr im Folgenden weitere Informationen.
Wenn ihr euren eigenen Player oder Recorder entwickelt und das Grundkonzept dieses xml-basierten Formats benutzen wollt, dann empfehlen wir euch folgende Vorgehensweise beim Import einer Spieldatei:
- Prüfen der Spieldatei auf Vorhandensein
- Prüfen der Spieldatei anhand des Standard.xsd (auslesbar aus dem Formatindex)
- Auslesen des Formatherausgebers (Publisher) und der Formatversion (Version) aus der Spieldatei
- Prüfen der Spieldatei anhand der passenden XSD-Datei unter Verwendung von Herausgeber und Version (auslesbar aus dem Formatindex)
- Auslesen der Spieldaten, wenn das Format von der Applikation unterstützt wird oder Weiterverarbeitung der gesammelten Informationen und Benutzerrückmeldung
Wir haben uns extra einen Datenbankexperten aus Erlangen für dieses Thema geholt. Überraschenderweise und doch nicht so überraschend ist ein Tabelle herausgekommen, die sich wie folgt aufbaut. Sie deckt die Anforderungen ab, die das Grundformat des XML-Spielformates stellt:
ID: Identifkation eines Spiels
Publisher: Der in der Datei eingetragene Herausgeber des Spielformates (Pflichtfeld im XML-Grundformat)
Version: Die in der Datei eingetragene Spielformatsversion (Pflichtfeld im XML-Grundformat)
Header: Der gesamte XML-Knoten "Header" (Im Header herausgeberspezifische nformationen gehen nicht verloren)
Body: Der gesamte XML-Knoten "Body" (Im Header herausgeberspezifische nformationen gehen nicht verloren)
Mit dieser Struktur wird vermieden, dass Änderungen an der Datenbankstruktur beim Erscheinen neuer Formatsversionen oder bei der Verarbeitung von neuen Herausgeber erforderlich werden.