Der AOQML-Editor ist nun so weit, dass ihn ein größeres Publikum testen kann. Voraussetzungen sind Grundkenntnisse in XML und eine Java Laufzeitinstallation.

Mutige vor!

Mehr Infos findet ihr hier: AOQML-Editor

Mehr zu AOQML, der Quest-Modellierungssprache hier: AOQML

Viel Spaß!

Ein Beispielquest ist nicht verkehrt und das Antamar-Tutorial bietet einen schönen Wiedererkennungseffekt. Allerdings ist es auch relativ groß, es ist dennoch an diesen Beitrag angehangen.

Ich muss euch an dieser Stelle mal ein ganz ganz dickes Lob und ein noch grösseres Dankeschön aussprechen. Mit diesem Editor erstellt man komplexe Quests in Windeseile und man kann sich so auf den Inhalt konzentrieren und muss sich nicht mit technischem Brimborium auseinandersetzen. Das wäre für die einen zwar keine Hürde, aber die grosse Masse der Questschreiberlinge wird erst mit diesem tollen Editor erreicht. Deshalb: Spitzenklasse!

Danke euch beiden.

Ich habe zwar schon zwe Quests mit einem normalen editor geschrieben, mich aber noch nicht an ein geplantes Projekt heran getraut. Ich werde gleich damit anFangen und den Editor auf herz und Nieren prüfen.

Schade nur, dass der Wettbewerb schon vorbei ist.

psst.... der kommt bald wieder.

Sieht super aus.
Werde ich die Tage mal ausgiebig testen.

So, ich habe denn mal meinen seinerzeitigen Wettbewerbsbeitrag rausgekramt. (Ist auch schon wieder ein 3/4 Jahr her. Wie die Zeit rast... Leider ist die Queste so D$Alastig, dass ich sie wohl nicht erneut einreichen/just4fun umschreiben kann. )

Natürlich ließ sich meine Queste mit dem Editor nicht ohne Weiteres öffnen. Stattdessen stürzte er leider sang- und klanglos ab. Die alten Dateien waren in ANSI codiert, was ich dann erst mal ändern musste. Schön wäre eine Fehlermeldung gewesen. Zumindest sollte das mit der Codierung in die FAQ.

Ich habe die Queste in Unterordnern organisiert. Der Editor verhält sich aber nicht so, wie ich es erwartet hätte (muss nicht falsch sein ). Z.B.: "start" führt zu "ordner/eins" (das zeigt der Editor richtig an); "eins" soll zu (ebenfalls in "ordner" liegendem) "zwei" führen. Da wir schon in "ordner" sind, habe ich nur den relativen Pfad "zwei" angegeben, was der Editor aber als nicht existente Datei anmahnt. Die Beschreibung bei Include ließ mich aber auf die relative Behandlung von Pfaden schließen.

Thema Include noch mal: Die Datei wird als nicht wohlgeformt angemeckert. Ist sie auch nicht. Muss sie es sein? Ich dachte das ist einfach Text, der in das Haupt-XML-Dokument (in die Szene) eingebettet wird. Ich hab dort halt mehrere parallele Randoms...

Und auch im Include habe ich <quest status="ended"/> eingebaut. Dadurch haben die entsprechenden aufrufenden Szenen aber einen "dicken Rand" erhalten, was ja wohl DeadEnd bedeutet.


Auf jeden Fall ein tolles Teil der Editor! Wahrscheinlich bin ich nur nicht firm genug in AOQML (und hätte also den Wettbewerb nicht gewonnen ).

proser hat geschrieben:Natürlich ließ sich meine Queste mit dem Editor nicht ohne Weiteres öffnen. Stattdessen stürzte er leider sang- und klanglos ab. Die alten Dateien waren in ANSI codiert, was ich dann erst mal ändern musste. Schön wäre eine Fehlermeldung gewesen. Zumindest sollte das mit der Codierung in die FAQ.

Dafür ist der Beta-Test ja da. Dass eine Fehlermeldung gekommen wäre, bekommen wir natürlich nicht hin, gibt keine Zeitmagie auf Erden. Aber in der 1.0 sollten wir das hinbekommen

proser hat geschrieben:Ich habe die Queste in Unterordnern organisiert. Der Editor verhält sich aber nicht so, wie ich es erwartet hätte (muss nicht falsch sein ). Z.B.: "start" führt zu "ordner/eins" (das zeigt der Editor richtig an); "eins" soll zu (ebenfalls in "ordner" liegendem) "zwei" führen. Da wir schon in "ordner" sind, habe ich nur den relativen Pfad "zwei" angegeben, was der Editor aber als nicht existente Datei anmahnt.

Ist ein Bug. Auch etwas für die 1.0. So richtig gute (optische) Unterstützung für Unterordner wird es aber wohl erst in der 3. 0 oder so geben. Für die 2.0 sind wir ja schon voll mit Featurs.

proser hat geschrieben:Thema Include noch mal: Die Datei wird als nicht wohlgeformt angemeckert. Ist sie auch nicht. Muss sie es sein? Ich dachte das ist einfach Text, der in das Haupt-XML-Dokument (in die Szene) eingebettet wird. Ich hab dort halt mehrere parallele Randoms...

Ohne Wohlformung geht's nicht, keinen Chance dann mit akzeptablem Aufwand den Rest der Syntax zu prüfen. Was genau meinst du mit "parallelen Randoms"? Meist sind <p>...</p> das Problem, weil man sie mit Steuerelementen verkreuzen will, was leider in XML nicht geht.

proser hat geschrieben:Und auch im Include habe ich <quest status="ended"/> eingebaut. Dadurch haben die entsprechenden aufrufenden Szenen aber einen "dicken Rand" erhalten, was ja wohl DeadEnd bedeutet.

Dicker brauner Rand ist reguläre End-Szene, ROTER Rand ist Dead-End. Allerdings werden auch noch nicht alle Dead-Ends erkannt, nämlich wenn nur einzelne Zweige tot enden. Das ist auch kein Thema für die 1.0.

Es ist aber in der Tat recht heftig, wenn Queste, die nicht mit dem AOQML Editor geschrieben wurden, damit nachbearbeiten will. Vieles macht man gar nicht erst, wenn man ein Quest gleich mit dem Editor erstellt. Ich habe mich da auch durch etliche durchgekämpft, und kann das nachvollziehen. Nun, das Problem wird es wohl bald kaum noch geben, da neue Queste gleich mit dem AOQML-Editor angefangen werden.

Danke für die schnelle Antwort!

Lowlander hat geschrieben:

proser hat geschrieben:Ich habe die Queste in Unterordnern organisiert. Der Editor verhält sich aber nicht so, wie ich es erwartet hätte (muss nicht falsch sein ). Z.B.: "start" führt zu "ordner/eins" (das zeigt der Editor richtig an); "eins" soll zu (ebenfalls in "ordner" liegendem) "zwei" führen. Da wir schon in "ordner" sind, habe ich nur den relativen Pfad "zwei" angegeben, was der Editor aber als nicht existente Datei anmahnt.

Ist ein Bug. Auch etwas für die 1.0. So richtig gute (optische) Unterstützung für Unterordner wird es aber wohl erst in der 3. 0 oder so geben. Für die 2.0 sind wir ja schon voll mit Featurs.

Dank des Editors sind Unterordner auch nicht mehr so wichtig, finde ich. Ich hab meine Queste schon umgebaut.

Lowlander hat geschrieben:

proser hat geschrieben:Thema Include noch mal: Die Datei wird als nicht wohlgeformt angemeckert. Ist sie auch nicht. Muss sie es sein? Ich dachte das ist einfach Text, der in das Haupt-XML-Dokument (in die Szene) eingebettet wird. Ich hab dort halt mehrere parallele Randoms...

Ohne Wohlformung geht's nicht, keinen Chance dann mit akzeptablem Aufwand den Rest der Syntax zu prüfen. Was genau meinst du mit "parallelen Randoms"? Meist sind <p>...</p> das Problem, weil man sie mit Steuerelementen verkreuzen will, was leider in XML nicht geht.

Muss denn eine Include-Datei wohlgeformt sein, oder kann man die Fehlermeldung ignorieren? Meine sieht ungefähr so aus:

Code: Alles auswählen

<random>
  Waffe2 wählen
</random>
<random>
  Waffe2 wählen
</random>
<fight>
</fight>


Lowlander hat geschrieben:

proser hat geschrieben:Und auch im Include habe ich <quest status="ended"/> eingebaut. Dadurch haben die entsprechenden aufrufenden Szenen aber einen "dicken Rand" erhalten, was ja wohl DeadEnd bedeutet.

Dicker brauner Rand ist reguläre End-Szene, ROTER Rand ist Dead-End. ...

Hatte ich falsch verstanden. Sorry!

proser hat geschrieben:Muss denn eine Include-Datei wohlgeformt sein, oder kann man die Fehlermeldung ignorieren? Meine sieht ungefähr so aus:

Code: Alles auswählen

<random>
  Waffe2 wählen
</random>
<random>
  Waffe2 wählen
</random>
<fight>
</fight>


Ja, auch includes werden separat interpretiert, und ihr Ergebnis (HTML) wird in das Ergebnis der includenden Szene eingefügt. Includes sind also keine textuellen Einfügungen auf XML-Ebene. So etwas könnte man evtl. auch noch als neues Feature einbauen, wenn sich da ein großer Bedarf ergibt. Aber das wären dann eher keine Tags sondern eine Art Processing-Instruction. Tags kömen zu zu spät, dann wäre ja die includende-Szene schon interpretiert und könnte durch die includes nicht mehr vevollständigt werden. XML und seine fertigen Werkzeuge erleichtern uns viel, machen die Entwicklung schnell - aber XML hat seine Grenzen.

Selbst die AOQML-Engine erwartet wohlgeformte Dokumente, auch Includes. Bei Hauptszenen kommt sonst "... kann nicht geladen werden" und bei Includes irgendeine Exception (bis vor kurzem bei letzterem gar nichts, das war ein Bug).

Du müsstest also <scene>...</scene> drum herum setzen, dann geht's. Da man auch ganze Hauptscenen includen kann, und es inhaltlich auch keinen Unterschied gibt, gibt es beim Top-Level-Tag da keine Unterscheidung.

Okay, danke!

Bei

Code: Alles auswählen

<challenge talent="Klettern" name="ProbeNr1"/>

meckert der Editor mit "cvc-complex-type.3.2.2: Attribute 'name' is not allowed to appear in element 'challenge'." Laut Challenge sollte das aber gehen.


Bei

Code: Alles auswählen

<fight>
    <rivals>
        <npc npcid="123" name="Bla" gender="male" weapon="${waffe_id}" />
...

bin ich mit nicht sicher, ob man eine Variable (siehe Besondere Werte) benutzen kann. Der Editor sagt jedenfalls "cvc-pattern-valid: Value '${waffe_id}' is not facet-valid with respect to pattern '(\d+)(( )?\|( )?\d+)*' for type 'idType'."

Bin bisher vom Editor begeistert, der hilft es einem Wirklich seine Szenen zu verwalten und schlägt auch leider noch häufig genug zu recht Alarm, wenn was nicht stimmt.

Nun habe ich noch einen kleinen Wunsch aus Bequemlichkeit. Wäre es möglich irgendenen Text einzufärben oder farbig zu hinterlegen, damit ich gleich sehe, dass ich da noch was arbeiten will?

Wie gesagt ist eher ein Bequemlichkeitsfeature.

Danke für die Hinweise!

proser hat geschrieben:Bei

Code: Alles auswählen

<challenge talent="Klettern" name="ProbeNr1"/>

meckert der Editor mit "cvc-complex-type.3.2.2: Attribute 'name' is not allowed to appear in element 'challenge'." Laut Challenge sollte das aber gehen.

yep, wird auch zur 1.0 in das XML Schema eingebaut

proser hat geschrieben:Bei

Code: Alles auswählen

<fight>
    <rivals>
        <npc npcid="123" name="Bla" gender="male" weapon="${waffe_id}" />
...

bin ich mit nicht sicher, ob man eine Variable (siehe Besondere Werte) benutzen kann. Der Editor sagt jedenfalls "cvc-pattern-valid: Value '${waffe_id}' is not facet-valid with respect to pattern '(\d+)(( )?\|( )?\d+)*' for type 'idType'."

ja, kann man, kommt auch noch in das XMl Schema.

Askaian hat geschrieben:Bin bisher vom Editor begeistert, der hilft es einem Wirklich seine Szenen zu verwalten und schlägt auch leider noch häufig genug zu recht Alarm, wenn was nicht stimmt.

hier bitte konkret - besonders gut wäre es, eine Szene mit all solchen Sache zuzsammenzustellen, evtl im Wiki

Askaian hat geschrieben:Nun habe ich noch einen kleinen Wunsch aus Bequemlichkeit. Wäre es möglich irgendenen Text einzufärben oder farbig zu hinterlegen, damit ich gleich sehe, dass ich da noch was arbeiten will?

Wie gesagt ist eher ein Bequemlichkeitsfeature.

Du meinst in einer Szene oder für eine Scene? Ich mache es meist mit <todo>Hier sollte noch...</todo> (todo= to do, engl. für noch zu tun). Da es das Element nicht gibt, bleibt der Node gelb. Oder mit <!-- TODO: hier sollte besser ...-->, falls es so schon läuft, aber man noch was verbessern will, z.B. sobald die Engine das kann. Zur 1.0 gibt es aber keine neuen Features im Java-Code, nur Bugfixes und Erweiterungen des XML Schemas.