Hier entsteht eine PHP5-Programmbibliothek, mit der Zufallsbegegnungen (ZB) für das DSA-basierte Browser-Spiel Antamar in XML programmiert werden können. Wenn dieses in Antamar integriert wäre, könnte Externe neue Zufallsbegegnungen entwickeln, die sofort in Antamar lauffähig wären, ohne dass das A-Team (die Antamar-Entwickler) die Idee erst in PHP umsetzen müssten. Anders als eine externe Entwicklung in PHP, ist der Funktionsumfang aber derart beschränkt, so dass das A-Team weitestgehend die Kontrolle behält, insbesondere kein Programm-Code eingeführt werden kann, der die Sicherheit des Antamar-Systems gefährden würde.
Ausprobiert werden kann dieses System hier (derzeit leider offline).
Das Grundprinzip ist: Texte zwischen den Tags werden grundsätzlich, d.h. ggf. unter den durch die Tags bestimmten Umgebunsbedinungen, ausgegeben, also dem Spieler angezeigt. Alle Texte, die vom Programm ausgewertet werden, sind also als Attribute angegeben. Auch diese werden ggf. ausgegeben, aber eben erst nach einer Bearbeitung durch den ZB-XML-Player. Mit anderen Worten: Steuerwerte befinden sich niemals zwischen den Tags.
Bisher sind folgende XML-Tags implementiert:
In genau eine <scene>...</scene>-Folge eingeschlossen wird die Zufallsbegegnung programmiert. Dieses muss das einzige XML-Tag auf oberster Ebene sein.
Später werden in den Attributen dieses XML-Tags Angaben darüber gemacht werden können, wo die ZB passt (z.B. 'im Gebirge') und wen sie betreffen kann (z.B. 'männliche Krieger'). Diese Attribute würden dann vom Antamar-System ausgewertet werden können, um passende ZB zu finden.
Das Grundgerüst einer ZB sieht damit so aus:
<?xml version="1.0" encoding="UTF-8"?> <scene> ... </scene>
Mit diesem Tag wird die dedizierte Ausführung eines Quests beendet. Das Attribut status steuert, ob das Quest nicht zuende gespielt wurde und damit wiederholt werden sollte ("ended") oder ob es zuende gespielt wurde und damit von diesem Helden nicht (so bald) wiederholt werden sollte ("finished").
Der Wert "pending" bedeutet, dass das Quest nach Erfüllung bestimmter Bedingungen (z.B. einem bestimmten Ort angekommen, bestimmte Gegenstände erworben etc.) fortgeführt werden soll. Dieses Feature ist für Midi-Quests und noch nicht implementiert.
Mit diesen XML-Tags kann eine Zufalls-Auswahl gemacht werden. Alle Varianten werden in eine <random>...</random>-Folge eingeschlossen und in je einer <case>...</case>-Folge zusammengefasst.
Sollen zufällig die Worte 'Rondra' oder 'Praios' ausgewählt werden, dann schreibt man das so:
<random> <case>Rondra</case> <case>Praios</case> </random>
Statt einfacher Worte zwischen den case-Tags können auch XHTML-Tags und weitere der hier aufgezählten XML-Tags für ZB-Aktionen dort eingefügt werden.
Mit dem Attribut 'count' kann angegeben werden, wieviele der case-Knoten ausgwählt werden sollen.
Mit dem has-Tag kann überprüft werden, ob ein Character ein Talent oder einen Gegestand hat. Dabei sind die folgenden Attribtute möglich:
Für die Auswertung siehe <success>...</success> unter <challenge>.
Mit dem challenge-Tag werden Eigenschafts- und Talentproben gewürfelt. Dabei sind die folgenden Attribtute möglich:
Für die Auswertung stehen derzeit folgende Möglichkeiten zur Verfügung:
Zwischen diesen beiden XML-Tags wird formuliert, was bei gelungener Probe geschieht. Hier kann Text, XHTML oder auch weitere der hier genannten XML-Tags stehen.
Mit den Attributen 'min' und 'max' kann ein Bereich angegeben werden, um zu unterscheiden, wie gut der Erfolg war.
Zwischen diesen beiden XML-Tags wird formuliert, was bei misslungener Probe geschieht. Auch hier kann Text, XHTML oder auch weitere der hier genannten XML-Tags stehen.
Mit den Attributen 'min' und 'max' kann ein Bereich angegeben werden, um zu unterscheiden, wie schlecht der Misserfolg war. Achtung: Es werden hier negative Zahlen verglichen, nicht Absolutwerte!
Dieses XML-Tag soll bedeuten, dass der Held zum letzten Ort an dem er war, zurückkehren muss. Es erzeugt keine sichtbar Ausgabe, sondern wirkt nur intern.
Dieses XML-Tag soll bedeuten, dass der Held auf seiner Reise verzögert wird. Die Verzögerung wird mit dem Attribut 'hours' in Stunden in-game-Zeit angegeben. Es erzeugt keine sichtbar Ausgabe, sondern wirkt nur intern.
Das get-Tag ermöglicht das Anzeigen von Werten des Helden wie "AP" oder "cash", Eigenschaften wie "MU" oder "KL" sowie Talentwerten, aber auch seiner Rasse, Kultur etc.
Welcher Wert angezeigt werden soll, wird im Attribute 'attribute' angegeben. Geplant sind auch Modifikatoren z.B. für den Kasus oder das Geschlecht.
Implementiert sind derzeit:
Das set-Tag ermöglicht das Ändern von Werten wie "LEP", "AUP" oder "AP". Welcher Wert gesetzt werden soll, wird im Attribute 'attribute' angegeben. Der Wert kann gesetzt ('value="..."'), erhöht ('increment="..."') oder verringert ('decrement="..."') werden.
Gesetzt werden können derzeit: 'AP' (wirkt auf AP-Gesamt+Guthaben), 'cash' und 'fame' sowie die Eigenschaften 'MU', 'KL' etc.
Die Tags take und drop ermöglichen es, dem Helden Ausrüstungsgegenstände zu geben bzw. wegzunehmen. Mögliche Attribute sind:
Wenn das take- bzw. drop-Tag keinen Inhalt hat, wird die Anzahl und Bezeichnung des Gegenstandes ausgegeben. Falls ein Inhalt vorhanden ist, wird nur dieser ausgewertet und ausgegeben.
Das retain-Tag speichert seinen Inhalt unausgewertet als Skript unter dem als Attribut 'name' angegebenen Namen. Dieser Inhalt kann dann später mit dem replay-Tag abgespielt werden.
Das replay-Tag spielt die unter dem als Attribut 'name' angegebenen Namen abgespeicherte Aktionsfolge ab. Das Speicher muss zuvor mit dem retain-Tag erfolgt sein. Auch ein mehrmaliges Abspielen ist möglich.
Das store-Tag speichert seinen (ausgewerteten) Inhalt persistent, z.B. zwischen verchiedenen Schritten eines Quests. Das Attribut 'name' gibt dabei an, unter welchem Namen es gespeichert werden soll. Der Inhalt selbst wird an dieser Stelle nicht ausgegeben.
Das fetch-Tag ruft derart gespeicherte Inhalte wieder ab. Auch dabei wird das Attribut 'name' zum identifizieren verwendet. Sollte kein Inhalt unter diesem Namen gespeichert sein, und nur dann, wird der Inhalt des fetch-Tags ausgewertet, sozusagen als Default.
(Die Dummy-Implementation für den Context verwendet die Client-IP-Nummer zur Identifikation des Users. Das ist sehr ungenau, so dass es zu Fehlern kommen kann, falls mehrere Benutzer dieselbe IP-Nummer verwenden (insbes. bei Proxies, z.B. mit AOL) oder sich die IP-Nummer zwischen zwei Zugriffen ändert (Neuvergabe einer dynamischen IP-Nummer bei Dial-In-Zugängen). Antamar wird hier sein Session-System verwenden, so dass solche Fehler dann nicht auftreten können.)
(Mit dieser Definition bin ich noch nicht zufrieden, weil sie nicht alle Möglichkeiten zulässt, z.B. nicht dass einige Gegner geflohen, und andere getötet sind. Auch Gefangennahme fehlt noch.)
Das fight-Tag ermöglicht zusammen mit seinen sub-Tags das durchführen von Kämpfen. Es werden nach dem Kampf jeweils alle passenden Ergebnis-Zweige durchlaufen. Die Sub-Tags sind:
Mit den Attributen 'race', 'level' (0... für einen absoluten Level, +1... bzw. -1... für einen Level relativ zum Helden-Level) und 'name' sowie 'escape-below' kann der Non-Player-Character definiert werden. Der konkrete Character wird dann mit diesen Werten per Zufall erzeugt.
Hierbei kann mit den Attributen 'escaped' und 'dead' je mit Semikolon getrennte Liste von Namen der Gegner aufgeführt werden, die in dem Kampf gefallen bzw. geflohen sind. Der Zweig wird nur ausgeführt, wenn alle Bedinungen passen.
Das switch-Tag vergleicht ein Attribut mit einer Liste von Werten. Der Zweit mit dem passenden Wert wird ausgeführt. Beispiel:
<switch attribute='gender'> <case value='female'>Ein junger Mann</case> <else>Eine junge Frau</else> </switch>
Das choice-Tag ist für Queste und gibt dem Spieler eine Wahlmöglichkeit. Mit dem Attribut 'target' kann angegeben werden, bei welchem Quest-Schritt (ZB) es weiter gehen soll. Praktisch entspricht dies einem speziellen Link.
Die im im target-Attribut adressierte Szene wird relativ zum Verzeichnis des aktuellen Skriptes und ohne die Extension ('xml') angegeben. die Angabe von Unterverzeichnissen ist möglich, ebenso '../', um wieder ein Verzeichnis hoch zu gehen.
In diesem Tag kann kann mit dem Attribut 'target' ein weiterer Scriptname angegeben werden, welches direkt an dieser Stelle eingefügt und ausgeführt wird. Dies ist insbesondere für Queste praktisch, da vir verschiedenen Ausgängen sonst oft entweder Texte kopiert werden müssten oder die Szenen kurz vor dem tatsächlichen Ende nur noch ein einziges choice-Tag hätten.
Die Ziel-Szene im target-Attribut wird relativ zum Verzeichnis des aktuellen Skriptes und ohne die Extension ('xml') angegeben. die Angabe von Unterverzeichnissen ist möglich, ebenso '../', um wieder ein Verzeichnis hoch zu gehen.
Weitere Möglichkeiten werden auf Anfrage folgen.
XHTML-Tags und Texte können an jeder Stelle eingefügt werden, solange das Skript wohlgeformtes XML bleibt. Diese werden, ggf. inklusive ihrer Attribute 1:1 ausgegeben. XHTML sollte aber sparsam verwendet werden und das CSS-Design von Antamar berücksichtigen.