AOQML für Anfänger

Dieser Leitfaden für jene, die sich in der edlen Kunst der AOQML-Programmierung versuchen wollen, wurde nach bestem Wissen und Gewissen von Neonix erstellt und von etlichen weiteren fleißigen AOQML-Kundigen korrigiert und erweitert. Garantien für die Vollständigkeit oder Korrektheit gibt es nicht (dies ist ein Wiki ;) ). Wer will und kann, darf Fehler korrigieren und Unklarheiten beseitigen - aber bitte nicht verschlimmbessern!

Im folgenden wird die Erstellung einer einfachen Queste beschrieben. Zufallsbegegnungen haben einige Besonderheiten, die hier erklärt werden. Für etwas anspruchsvollere Verwendungen von aoqml gibt es (bald) AOQML für Fortgeschrittene.

AOQML-Tutorial

Den Editor benutzen

XML ist nicht so leicht lesbar, wie die Programmierer immer behaupten. Der AOQML-Editor erleichtert das Programmieren gerade für Einsteiger erheblich, da er einen geeigneten Rahmen bietet und zumindest einen Teil der üblichen Fehler im Vorfeld erkennen kann. Ladet ihn einfach herunter und speichert ihn in einem Ordner für eure eigenen Questen. Damit die nachfolgenden Schritte funktionieren braucht ihr Java in einer einigermaßen aktuellen Version. Diese könnt ihr hier herunterladen.

Ein Doppelklick öffnet ihn.

Das Feld "Quest" öffnet 3 Möglichkeiten: Man kann eine neue Quest anlegen, eine schon im Ordner vorhandene Quest laden oder durch Beenden den Editor schließen.

Wir müssen natürlich erst einmal eine erste Quest anlegen.

Gespeichert wird sie im entsprechenden Ordner, in dem auch der Editor ist. Natürlich benötigt sie einen Namen. Er sollte einfach und eindeutig sein und einen Hinweis auf den Inhalt bieten. Wir nennen die erste Quest fantasievoll testquest 01.

Die Queste wird jetzt als eigener Unterordner für die einzelnen Dateien in dem Questordner angelegt. Außerdem erscheint im Editor jetzt die grafische Übersicht über die einzelnen Dateien. Da wir noch keine Datei geschrieben haben ist auch noch keine zu sehen - außer der Datei start, die immer vorhanden sein muss und daher automatisch erstellt wird. Da sie noch nicht auf der Festplatte existiert, wird sie rot dargestellt.

Ein Doppelklick öffnet die Datei start.

Wenn man auf einem Netbook mit "kompaktem" Monitor arbeitet, so wie ich, kann es vom Platz her etwas eng werden... In dem Fall sollte man als erstes einige Leerzeilen unter </scene> setzen. Große Monitore sind deutlich von Vorteil. Man kann das Fenster verschieben und in der Größe verändern.

Die erste Szene schreiben

Nachdem die Szene "start" geöffnet ist, beginnen wir mit einer einfachen Queste.

Die Zeile <quest status="running"/> am Anfang steht nur in der Szene start, in den anderen ist sie nicht nötig. Die Zeile </scene> steht am Ende der Dateien (=Szenen), um diese zu schließen. Der restliche Code wird zwischen diese beiden Zeilen geschrieben.

Wir beginnen die Queste mit einem kleinen Einführungstext. Dazu schreiben wir zwischen die beiden Zeilen < p>. Der Editor erweitert dies sofort zu < p>< /p>. Hinweis: Das Leerzeichen zwischen < und p dient nur dazu, das Wiki zu überlisten - das würde sonst die Befehle interpretieren... Gilt auch im folgenden.

< p> öffnet die Textausgabe, < /p> schließt sie wieder. Den Text kann man direkt dazwischen schreiben. Er wird dann in der Quest als normaler Text ausgegeben. Wörtliche Rede von Charakteren wird zwischen < q></ q> geschrieben und dann automatisch kursiv und mit Anführungszeichen ausgegeben. Wir nehmen folgenden Text:

Gerade als du beim Wirt etwas zu Essen bestellen willst, fällt dein Blick auf einen Zettel an der Wand der Kneipe. Anders als die anderen Aushänge und Notizen, die schon von Kerzenruß und Staub vergilbt sind, scheint er ziemlich neu zu sein.

Wenn wir das so lassen, würde die Queste nur den Text anzeigen und keine weiteren Funktionen bieten. Der SC würde festhängen. Aber natürlich lassen wir sie nicht so! Stattdessen geben wir dem Spieler zwei Optionen vor, wie er weiter verfahren kann.

Dafür tippen wir erst einmal hinter dem < /p> Enter, um eine Zeile nach unten zu kommen, und geben dann < ul> ein, was sich wie gewohnt zu < ul>< /ul> verändert. Dieses < ul> sorgt dafür, das die geplanten Links in der Queste schön untereinander gezeigt werden, nicht hintereinander.

Um Platz zu haben setzen wir den Cursor zwischen die beiden Befehle und drücken drei mal Enter, dann die Taste <--. Jetzt haben wir zwischen den ul zwei freie Zeilen. Der Editor rückt automatisch alles ein, was wir dazwischen eingeben. Das vereinfacht die Übersicht erheblich, wenn wir größere Szenen schreiben.

In die beiden leeren Zeilen geben wir < li> ein. Das sorgt dafür, das die Optionslinks mit einem Aufzählungspunkt beginnen, was hübscher aussieht.

Wenn der | zwischen den Befehlen sitzt (so: < li>|< /li> ) klicken wir links auf die Taste <choice.../>. Dadurch wird automatisch der Befehl <choice target="">...</choice> eingefügt. Dieser Befehl erzeugt in der Queste dann den eigentlichen Link. Er muss zwischen beiden li eingefügt werden!

So leer würde der Link aber nur ... anzeigen - und, wenn man ihn anklickt, ins leere führen! Also müssen wir beide Befehle füllen. Zunächst einmal mit den Texten, die als anklickbarer Link angezeigt werden. Wir nehmen die beiden Texte "Desinteressiert wendest du dich deinem Essen zu." und "Das siehst du dir aus der Nähe an.". Sie ersetzen die ... .

Jetzt würde die Queste zwar die Texte als Links anzeigen, die würden aber immer noch ins leere führen. Also muss noch jeweils eine Zieldatei angegeben werden, und zwar zwischen die "". Da es noch keine Dateien außer start gibt, können wir uns die Namen frei aussuchen. Wir nehmen für die obere Option abbruch und für die untere zettel. Hinweis: Bitte klein schreiben, ä, ö, ü und ß vermeiden und _ statt Leerzeichen benutzen, sonst kann es Probleme geben!

Damit wäre die Datei "start" soweit fertig. Also klicken wir oben auf speichern. Dann schließen wir die Datei mit dem kleinen grauen x oben rechts (das große rote schließt den ganzen Editor). Jetzt sollte etwa folgendes zu sehen sein:

Szenen ordnen

Das Fenster kann man vergrößern, den Zoom benutzen und die Dateien hin und her ziehen, bis sie gut liegen. Es sollte übersichtlich sein, etwa so:

Die Funktion Explodieren sollte mit Vorsicht genossen werden, sie ordnen alle Szenen als Kreis an - was die Ordnung nicht unbedingt verbessert. Justieren hingegen ist nützlich, wenn man viele Szenen hat, denn dann wird die Ansicht neu zentriert. Die durchgehenden schwarzen Pfeile bedeuten, dass man von der Szene "start" zu den beiden anderen Szenen springen kann. Da sie noch leer sind, sind sie rot dargestellt. "start" hingegen ist grün, was bedeutet, das der Editor keine Fehler erkannt hat. Der dünne braune Rand bedeutet, dass die Queste in dieser Szene nicht beendet wurde. Achtung, ein roter Rand zeigt an, dass keine Folgeszene angegeben wurde und die Quest nicht explizit mit < quest status=.. beendet wurde. Dies bedeutet ein totes Ende an dem der SC festhängt. Derart gekennzeichnete Szenen dürfen im Livesystem nicht vorkommen!

Die Queste abbrechen

Wenden wir uns der Szene "abbruch" zu. Wir öffnen sie per Doppelklick. Der | wird oberhalb von </scene> platziert und dann auf <quest.../> geklickt. Zwischen die "" tippen wir "ended" ein. Damit endet die Queste hier ohne weitere Fisematenten. Man könnte auch noch einen Abschlusstext eingeben, aber das lassen wir erst einmal.

Außerdem müssen wir noch angeben, mit welcher Häufigkeit sich die Quest wiederholt. Dafür fügen wir zwischen " und / noch mit einem Leerzeichen frequency="selten" ein, damit die Quest (Überraschung:) selten auftritt. Man könnte auch "rar" angeben, damit sie noch seltener auftritt, oder "nie", damit sie nur einmal gespielt werden kann. Bei "oft" tritt sie sehr oft auf, ebenso, wenn man auf die Angabe der Häufigkeit verzichtet - was ziemlich nervig sein kann!

Wieder speichern wir. "abbruch" ist jetzt grün und hat einen dicken braunen Rand. Also ist die Szene korrekt geformt und die Queste endet hier. Pfeile zu anderen Szenen gibt es nicht.

Es gibt auch andere Möglichkeiten, eine Quest zu beenden, aber vorerst reicht ended völlig aus.

Has-Abfragen

Weiter geht es mit der Szene "zettel". Wir öffnen sie wie gehabt und bauen einen kleinen Text ein.

Aber kann der SC überhaupt lesen? Um das herauszufinden setzen wir eine neue Zeile unter den Text und klicken <has.../> an. Es erscheint wieder ein Befehls-Rohling, in dem allerdings mehr enthalten ist als wir gebrauchen können.

Da wir feststellen wollen, ob der SC das Talent "Imperiale Zeichen" beherrscht, löschen wir die Optionen item (= Gegenstand im Inventar), attribute und quality (= Rasse, Volk etc.) samt den |. Zwischen die "" setzen wir Imperiale Zeichen. Achtung, es ist wichtig, die korrekten Namen der Talente zu benutzen!

Damit wird jetzt festgestellt, ob das Talent überhaupt aktiviert wurde. Wir fügen aber hinter das zweite " noch min="1" ein. Damit wird festgestellt, ob das Talent auch mindestens mit dem Wert 1 oder höher erlernt wurde. Man könnte auch eine höhere Zahl abfragen, wenn es ein besonders komplizierter Text wäre.

Die Queste würde jetzt in orange etwa folgendes anzeigen: hat Imperiale Schrift >1. Da das optisch nicht sehr schön ist, verstecken wir die Anzeige, indem wir noch show="none" anfügen. Damit bleibt die Abfrage für den Spieler unsichtbar. So kann man auch Proben verstecken, wenn der Spieler nicht wissen soll, ob oder was geprobt wird.

Was und wie abgefragt wird steht fest - aber noch nicht, was das Ergebnis ist. Also fügen wir zunächst einmal zwischen <failure></failure> einen entsprechenden Text ein, damit der Spieler erfährt, dass sein SC die Schrift gar nicht beherrscht. Danach fügen wir per Klick auf <include...> in der nächsten Zeile eine direkte Weiterleitung zu "abbruch" ein, indem wir zwischen die "" das Ziel "abbruch" eintippen. Wenn der SC also nicht mindestens "Imperiale Zeichen" auf TaW 1 beherrscht, kann er den Zettel gar nicht lesen und die Queste bricht automatisch ab.

Wenn der SC aber die Fertigkeit beherrscht, steht noch nicht fest, ob er das Gekrakel auch entziffern kann. Dafür benutzen wir eine Probe.

Proben

Zwischen das <success></success> setzen wir per Klick auf <challenge...|> einen Rohling für eine Probe.

Da die Probe auf ein Talent gewürfelt wird, entfernen wir quality und setzen wieder Imperiale Zeichen zwischen die "". Außerdem können wir die Probe modifizieren, indem wir bei mod="" +X oder -Y eingeben. Der Zettel ist einfach zu lesen, daher setzen wir +0 ein. Dann folgen wieder zwei Texte für Erfolg und Misserfolg. Ein Misserfolg führt zur Szene abbruch, bei einem Erfolg hingegen gibt es nach dem Text wieder zwei Links als Auswahl.

Als Belohnung für den misslungenen Versuch, den Zettel zu lesen, soll es aber ein Bisschen Erfahrung geben - immerhin zeigt der Misserfolg, dass der SC dringend Übung nötig hat... Dafür setzen wir durch die Taste set <set name|mark|attribute=""/> zwischen die Zeilen und löschen name und mark (wird später erklärt). Zwischen die "" tippen wir EP ein, um die Erfahrung des SC zu verändern. Dahinter kommt ein Leerzeichen und dann inc="1" (inc = erhöhen, dec = senken). Hinweis: Seit neuestem ist auch bei aoqml die Degression wirksam, das heißt, höherstufige SC werden den EP nur mit geringer Wahrscheinlichkeit erhalten.

Nach dem Speichern haben wir 3 korrekte Szenen und eine weitere leere, die gefüllt werden muss. Die gepunkteten Pfeile werden durch das include erzeugt. Das bedeutet, dass die entsprechenden Szenen im Spiel dann direkt untereinander gezeigt werden. Da abbruch leer ist, fällt das aber nicht weiter auf.

Variable setzen und Zeit verstreichen lassen

Normalerweise vergeht die Zeit in einer Quest genau so schnell, wie der Spieler sich hindurch klicken kann. Manchmal muss der SC aber innerhalb einer Queste einige Stunden, Tage oder gar Monate mit etwas verbringen, dass ihn von anderen Tätigkeiten abhält - Reisen, Arbeit, Gefangenschaft... Eine Möglichkeit, dieses Verstreichen der Zeit zu simulieren, wird jetzt dargestellt. Zunächst einmal lassen wir den Wirt erklären, dass der Auftraggeber seine Kaninchenzucht einige Wegstunden außerhalb der Stadt betreibt.

Dann speichern wir eine Variable ein, die nach einiger Zeit verschwindet. Dafür klicken wir unter dem Text store.

Das Expire beschreibt, wann die Variable sich selbst löscht. 5d bedeutet nach 5 Antamartagen oder 15 Minuten Realzeit. Wir ändern es in 3h, also 30 Sekunden Realzeit. Es werden nur h und d als Zeiteinheiten akzeptiert, für längere Zeiten dann also viele Tage. Wenn man auf das expire verzichtet, bleibt die Variable ewig bestehen! Das ist manchmal sinnvoll, wenn man eine permanente Veränderung speichern will, meist ist es aber sinnvoller, die Variablen nach einiger Zeit verschwinden zu lassen.

Als Inhalt hat die Variable derzeit nur ... , was nicht sehr aussagekräftig ist. Man kann hier fast beliebige Texte einspeichern, insbesonder auch andere AOQML-Befehle sowie HTML-Formatierungen. Enthaltene Befehle werden auch umgehend ausgeführt, so dass das Ergebnis der Befehle in der Variable steht. Das ist zum Beispiel paraktisch, will man einen ganzen Absatz mit wörtlicher Rede () speichern.

Eine Variable hat immer einen Scope, einen Gültigkeitsbereich. Es gibt scene, quest, hero, dungeon und global. Standardmäßig wird der scope quest benutzt, dieser muss als einziger nicht explizit angegeben. Im Regelfall ist dies der gewünschte scope und nur in seltenen Fällen wird zu einem anderen gegriffen, sie tauchen auch eher im "Fortgeschrittenen"-AOQML auf. Bei dem scope hero muss in jedem Fall auf einen eindeutigen Namen geachtet werden, z.B. Autor_ZB-Name_meineVariable.

Am Ende setzen wir noch ein choice darunter, dass zur nächsten Szene führt.

In der nächsten Szene (weg) lesen wir am Anfang per has aus, ob die Variable noch vorhanden ist. Dafür löschen wir item|talent|attribute|quality und geben mark ein, zwischen die "" den Namen der Variablen (ist wie gesagt eigentlich veraltet, wird aber vom Editor als richtig erkannt und funktioniert auch noch - name funktioniert auch, wird vom Editor aber (noch) als falsch bemängelt...). Wenn die Variable noch da ist, dann geben wir einen hinhaltenden Text aus und einen Link, der wiederum zur Szene weg führt. Egal wie oft der Spieler klickt - so lange die Variable noch besteht, kommt er also nicht weiter! Erst wenn die Variable erloschen ist, geht es für den SC weiter.

Die Namen und Inhalte von Variablen müssen unbedingt fehlerfrei übertragen und immer genau gleich benutzt werden! Viele Fehler in Questen beruhen darauf, dass eine Variable anders gespeichert als abgefragt wird. Am besten, man nutzt copy&paste. Dies ist im Editor nur über Strg+C (kopieren) und Strg+V (einfügen) möglich, nicht per Rechtsklick.

Random

Immer nur die selben Texte in einer Queste oder Zufallsbegegnung auszugeben wäre langweilig. Es gibt aber eine einfache Möglichkeit, sie zu variieren. Dafür ersetzen wir den einfachen Text durch eine Zufallsauswahl per Taste Random.

In die <case>...</case> kann man an Stelle der ... jeweils einen Text eingeben, oder auch eine andere Befehlszeile. Man kann auch beliebig viele case untereinander setzen. Uns sollen 3 mehr als genügen. Dafür kopieren wir einfach eine case-Zeile und ersetzen dadurch die ... . Dann fügen wir jeweils einen kleinen Text ein. Die < p>< /p> nicht vergessen!

Die Wahrscheinlichkeit ist für jedes case gleich (auch wenn es im Spiel oft ganz anders erscheint...). Um die Wahrscheinlichkeiten per Random gezielter zu verteilen, kann man einfach häufig vorkommende case-Zeilen kopieren und mehrfach einfügen.

Es gibt auch noch andere Möglichkeiten der Zufallsverteilung, aber dazu später.

Die Wahl der Taktik

Eigentlich hat es weniger mit aoqml als vielmehr mit den Grundlagen der Questgestaltung zu tun, aber da die Stelle gerade günstig ist, hier ein wichtiger Hinweis:

Gib dem Spieler wenn möglich immer die Wahl, wie er seinen SC führen will! Es ist einfach und bequem für den Questschreiber, nur einen möglichen Handlungsverlauf einzubauen. Aber für den Spieler ist es eine unschöne Einengung. Natürlich kann kein Questschreiber alle Lösungswege, die einem Spieler einfallen mögen, vorher in seine Questen einbauen. Schon 2 oder 3 Optionen erhöhen den Arbeitsaufwand enorm! Aber es lohnt den Aufwand. Zumindest bei drohenden Kämpfen sollte es immer die Möglichkeit geben, auch einen oder zwei friedliche Wege zu versuchen. Für die Testquest bieten wir dem Spieler 3 Optionen an: Kämpfen, Heimlichkeit oder Verhandeln.

Kämpfe

Allen vorherigen Beteuerungen zum Trotz geht es jetzt dennoch direkt zum Kampf. Nach dem erklärenden Text stapft unser Held direkt auf die beiden Gegner zu und beginnt einen Kampf. Dafür wird per Taste fight zunächst einmal der Rohling erzeugt.

Verbündete hat der SC nicht, also wird der ganze Bereich <friends> gelöscht. Da wir zwei Gegner haben, wird einfach die Zeile <npc npcid="" name="" gender="" escape=""/> kopiert und ersetzt die ... . Bei nur einem Gegner reicht eine Zeile, bei mehr Gegner entsprechend mehr.

Dann müssen wir die Gegner entsprechend programmieren. Zunächst einmal benötigen wir geeignete IDs, die wir aus dieser NPC Liste entnehmen. Sie ist leider nicht auf dem neuesten Stand, und die genauen Werte sind auch nicht angegeben. Die Namen sind aber meist ein guter Hinweis auf die Art und Stärke des Gegners. Benötigt man speziellere Gegner, kann man per Forum oder PN einen Programmierer oder Helfer mit Datenbankzugriff bitten, einen entsprechenden Gegner zu erstellen oder aus der Liste auszusuchen. Uns reichen unerfahene Wegelagerer (ID 4) aus.

Die Namen der NSC lassen sich auch ändern. Wir nennen sie einfach Abgerissener Bandit und Verkommener Bandit. So merken die Spieler nicht, dass es sich um Standart-NSC handelt.

Per gender="female" könnte man die NSC auch weiblich machen. Wir verzichten und löschen einfach das gender="".

Dafür fügen wir jeweils ein weapon="" ein und suchen uns aus der Waffenliste (leider auch nicht ganz vollständig oder aktuell...) geeignete billige Waffen aus: Beil (198) und Keule (1071). ansonsten würden die NSC die jeweiligen Standartwaffe erhalten (in diesem Fall Säbel). Wenn man die NSC nicht kennt kann man so einfach die verwendeten Waffen an die geplante Beute anpassen. Man muss nur etwas aufpassen, das man geeignete Waffen verwendet, die auch zu den Fähigkeiten der NSC passen. Bewährte Questschreiber erhalten auch Zugriff auf die entsprechenden detaillierten Listen, die aber nicht einfach im Wiki veröffentlicht werden sollen.

Das escape="" löschen wir (Editor veraltet...). Dafür setzen wir oben hinter fight ein escape="true" ein. Damit kann der SC normal aus dem Kampf fliehen. Ein escape="false" hingegen würde das verhindern, z.B. weil die NSC ihm den Rückweg abschneiden, beritten sind oder einen Bogenschützen haben, der den Flüchtling in den Rücken schießen würde.

Jetzt muss nur noch das jeweilige gewünschte Ergegnis zwischen die Befehle victory (SC hat gewonnen), escape (SC ist geflohen) und defeat (SC wurde besiegt) einbauen. Man kann es direkt in der Szene einbauen, oder per include zu einer weiteren Szene überleiten, die dann direkt unter dem Kampfergebnis dargestellt wird. Für den Spieler macht es keinen Unterschied, für den Schreiber kann es die Übersicht vereinfachen. Wir leiten zu entsprechenden Szenen um, die einzeln erklärt werden.

Man kann bei den Gegner auch per surrender-below="10" festlegen, dass sie bei weniger als 10 LP fliehen (die Zahl lässt sich beliebig ändern). Wir verzichten erst einmal, da aoqml leider nicht unterscheiden kann, ob Gegner geflohen sind oder besiegt wurden.

Für den Fall, das der SC besiegt wird, muss man sich noch eine Erklärung aus den Fingern saugen, warum er dennoch überlebt - bei Antamar sind SC (noch) unsterblich...

Leider erkennt auch hier der Editor die Angabe escape="true" bei fight als falsch, auch wenn sie korrekt ist. Das wird sicher bald geändert...

Den SC ausplündern

Gehen wir mal davon aus, dass der SC besiegt wird. Die Banditen rauben ihn aus und lassen ihn, schwer verletzt, liegen. Mittels <set attribute="cash" val="0"/> leeren wir seine Taschen, er hat keinen Gulden mehr. Per <drop item="*20%"/> nehmen wir ihm ca. 20% seines Gepäcks ab (wobei das ganze noch von anderen Faktoren abhängig ist), die Zahl ist wieder einmal variabel (1 bis 100%). <drop item="_Waffen"/> nimmt ihm Waffe und ggf. Schild weg.

Immerhin, einige EP gönnen wir ihm dennoch. Er hat sich ja redlich bemüht...

Getragene Kleider, Rüstungsteile und Schmuckstücken kann man den SC noch nicht wegnehmen. Das erspart uns viele nackte SC...

Beute vergeben

Viel angenehmer ist es für die SC natürlich, sich die Taschen mit Beute zu füllen!

<set attribute="cash" inc="100...300"/> erhöht den Bargeldbestand des Helden um 100 bis 300 Groschen. Die Zahlen lassen sich beliebig ändern. Lässt man die ... weg und gibt nur eine Zahl ein, erhält der SC einen Festbetrag.

<take item="Beil"/> gibt dem SC ein Beil. Man sollte die Beutewaffen in Art und Zahl an die Art und Zahl der Gegner anpassen - wer mit einer teuren Waffe kämpft, sollte auch genau diese als Beute hinterlassen (sofern sie nicht irgendwie verloren oder zu Bruch geht)!

Auch ein Random ist immer nett, um die Auswahl der Sekundärbeute zu vergrößern. <take item="Wolldecke" count="2"/> gibt dem SC 2 Wolldecken statt einer. Die Zahl lässt sich beliebig ändern und auch X...Y wäre möglich. Achtung: Immer den genauen Namen der Ware oder alternativ die ID mit einem # davor verwenden, zu finden in Aktuelle Warenliste! Na ja, nicht immer aktuell oder vollständig...

Die Queste testen

Tja, das wäre es erst einmal. Die restlichen Pfade können mit den bereits beschriebenen Mitteln programmiert werden. Am Ende sieht die ganze Quest dann in etwa so aus:

Bild 40 (wenn fertig...)

Bevor man die Quest aber implementieren lässt, sollte man sie vorher noch einmal testen! Dazu muss man zunächst in der Testumgebung Testserver einen Test-SC erstellen. Diesen kann man per maßgeschneiderter Queste mit Geld, Ausrüstung und EP versorgen und dann steigern. Hier ist so eine:

Link kommt noch...

Anschließend öffnet man den Ordner für die Quest, markiert alle darin befindlichen Dateien und macht (wenn man winzip oder ein ähnliches Programm hat) daraus ein .zip .

Dieses kann man dann in der Testumgebung mittels questupload --> durchsuchen --> entsprechende datei.zip anklicken --> hochladen.

Dann per Quest starten die Quest starten und mit dem Test-SC testen. Entsprechende Fehler sind meist leicht erkennbar, manchmal auch schwerer. Falls der SC hängt, einfach die Quest deaktivieren (wenn das mal im Spiel so einfach wäre...).

Die Queste implementieren lassen

Nachdem die Queste geschrieben und getestet wurde, muss sie nur noch kontrolliert und implementiert werden. Dazu meldet euch im Forum oder stellt sie ins Wiki oder schickt eine PN an einen geeigneten Programmierer. Der wird dann, wenn er Zeit hat, noch einen Blick hinein werfen, Fehler korrigieren, ggf. bestimmte Details abklären und irgendwann die Queste implementieren. Je nach dem dauert das einige Stunden bis Tage.

Der Schreiber muss auch festlegen, wo, wann und wie oft die Queste auftritt. Inzwischen können Questen nicht nur in Kneipen und Läden sowie in der Stadt auftreten, sondern auch auf Reisen, auf Schiffen, an festen Orten oder gar durch das Anklicken eines Gegenstandes. All der Alkohol, der getrunken werden kann, die Fackeln, Tabaksdosen und Katzen sind im Grunde genommen einfach nur an Gegenstände gebundene Questen.

AOQML für Fortgeschrittene

Mit der oben stehenden Anleitung sollte es möglich sein, einfache Questen zu programmieren. Wer mehr Optionen benotigt, der findet sie beim AOQML-Manual. Auch die Seite AOQML enthält nützliche Links. Außerdem werde ich nach und nach in AOQML für Fortgeschrittene weitere Tipps Tricks für AOQML vorstellen.

Solltet ihr irgendwelche Probleme haben, meldet euch im Forum! Es ist eigentlich fast immer jemand da, der neuen Questschreibern helfen kann.

Viel Spaß beim Programmieren - ich freue mich schon auf eure Questen!

Neonix