Diskussion:Testserver
Wochenendprojekt entdeckt ;-) Ich schätze, dass ich die Start-Quest ebenfalls etwas umschreiben werde in dem Zuge. Ansonsten wird hier die Kampfsuite verlinkt und kurz näher auf die Zusatzfunktionen eingegangen. --Gelezion (Diskussion) 16:34, 18. Mai 2017 (CEST)
Die hier? Datei:Kampf-Testsuite.zip --Christian.cvk (Diskussion) 17:40, 18. Mai 2017 (CEST)
Antamar lebt durch die ständige Weiterentwicklung der Gemeinschaft. Für die Entwicklung von Zufallsbegegnungen und Questen steht den Erstellern eine nahezu exakte Kopie der realen Welt zur Verfügung. Der sogenannte Testserver. Die Kopie unterscheidet sich besonders dadurch vom Spielsystem, dass man selbst Inhalte aufspielen und direkt testen kann. Zusätzlich werden geplante Veränderungen am System, oder Einzelheiten zuvor hier aufgespielt, um die Verträglichkeit sicherzustellen.
Inhaltsverzeichnis
Wo finde ich das Testsystem?
Der Testserver hat eine eigenständige URL, unter der er aufgerufen wird. Sie lautet: http://spiel.antamar.org/Antamar_quest/login.php Wichtig ist dabei, dass man sich nicht direkt mit seinen Logindaten vom Spielserver einloggen kann, sondern erneut registrieren muss. Dabei ist es aber möglich die selbe E-Mailadresse, als auch Benutzernamen zu wählen.
Angemeldet und was nun?
Das Testsystem ist wirklich kaum anders als das Spiel. Nur in gewissen Details zeigen sich die entscheidenen Änderungen. Hier darf man sich so viele Helden unter einem Zugang anlegen wie man lustig ist. Wer also schon immer eine eigene Vier-Helden-Gruppe alleine in die Schlacht, oder eher wohl zum Austesten von Questen und GZB, hat hier nun die einmalige Gelegenheit dazu.
Erste Schritte zum Testen
Wir beginnen nun damit, dass wir unter Heldenwahl - Neuen Helden erstellen uns den gewünschten Testhelden erstellen. Für bestimmte Tests ist es wichtig, dass man eine gewisse Profession, ein bestimmtes Volk, oder andere besondere Anforderungen, welche auf der Wiki-Seite entsprechend vermerkt sind, erfüllen muss. Für's Erste nehmen wir aber erst einmal den ersten Archetyp, den man uns anbietet. Der Stammeskrieger der Aivarunen wird entsprechend ausgewählt und mit ohne weitere Beachtung der Möglichkeiten einfach mit einem Generatornamen und unveränderten Werten erstellt.
Klick und da haben wir sie - Unsere erste Quest
Wir schauen uns die Seite zunächst einmal genauer an. Wie wir feststellen finden wir oben unter dem Kopfbanner direkt ein paar Informationen, die wir sonst nicht sehen: Quest: quests/Tutorialquest Szene: start Interne Zeit: xx:yy:abba HH:MM:SS Während die interne Zeit eher für absolute Könner an Informationen liefert kann man aber mit den ersten beiden Zeilen schon viel anfangen. Wir erfahren, dass wir uns in der Quest mit dem Namen "Tutorialquest" befinden und zwar genauer in der Szene "start". Diese Information hilft zum Beispiel, wenn man später beim Testen gezielt immer die selbe Abfolge kontrollieren will. Denn welcher Autor schreibt denn schon den Szenennamen im Klartext in den AOQML-Befehl? Wir klicken uns nun einmal frei durch diese erste Quest und achten dabei beiläufig darauf in welcher Szene wir uns gerade befinden. Zum Abschluß erhalten wir auch hier die Frage, ob wir denn nach Thelassa mitreisen wollen. Nein, das wollen wir nicht, wir können nämlich eh immer überall hin - solange man den Namen des Ziels schreiben kann ;-).
Die kleine Textbox unten rechts
Vermutlich wird es schon aufgefallen sein: Unter der rechten Übersicht gibt es eine Eingabeoption die mit "Teleport" betitelt wird. Als Stammeskrieger der Aivarunen stehen wir derzeit irgendwo im sonst eher für Anfänger ungeeignetem Aivarunenland. Nichts wie weg hier also. Nächste Station: SanA Wir geben entsprechend den vollständigen Namen, so wie er auch im normalen Spiel verwendet wird, als unsere gewünschte Destination ein: Alt-Heroida (San Aurecciani-Hafen) Einen Tastendruck auf die Eingabetaste später stehen wir also schon an der Kaimauer der schönen Hafenanlage im Reich Alena D'Amantes.
Im Zuge von Testreihen kommt es immer wieder vor, dass man zum nächsten Questteil reisen muss. Da man aber testen können soll und nicht NB und ZB genießen kann man mit dieser praktischen Funktion sich entsprechend direkt an sein Ziel begeben.
Die erste Zufallsbegegnung
So schnell wie das Licht können wir nun reisen, doch wie testet man nun, ob eine geschriebene Zufallsbegegnung auch wirklich so funktioniert wie man sich das denkt? Wir wählen aus dem linken Menü den ebenfalls neuen Punkt Questupload aus und wählen dort aus, dass wir nun eine Zufallsbegegnung testen möchten. Wir sehen nun vor uns ein großes Eingabefeld mit der Überschrift "AOQML-Code:" In dieses Feld kopieren wir nun folgende Zeilen.
<?xml version="1.0" encoding="UTF-8"?>
<scene xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="https://eisentrutz.antamar.eu/aoqml.xsd">
<set attribute="EP" inc="1000" />
</scene>
Unter dem Eingabefeld erhalten wir zusätzliche Möglichkeiten, wo genau wir die ZB, deren Text wir soeben vorgaben, testen möchten. In diesem Fall ist es uns zum Glück egal, sodass wir die Gelegenheit nutzen und direkt vom Hafen aus auch mit dem Schiff weiterreisen, oder faul nichts ändern und eine Fußreise begehen. Einen Klick später befindet sich unser Held auch schon bereits mit dem ausgewählten Fortbewegungsmittel auf Reisen und viel wichtiger. Wir erhalten unseren ersten Erfahrungspunkte.
Neunhundertund?!
Wer nun aufgefasst hat, wird gesehen haben, dass im Code der ZB als Argument ein increase="1000" steht. Die Ausgabe im Spiel zeigt jedoch nur:
Reisetag 1: LE (40) AU (50) ER (0) Wunden (0) EP (6048)
Atlan:
Erfahrung: 959 EP
Diese Diskrepanz steckt im System und nennt sich degressive Erfahrungsverteilung. Einfach ausgedrückt bekommt der weniger, der eh schon viel hat. Ist für's richtige Spiel interessant und wichtig zu beachten, wenn man die EP-Vergabe in Questen kontrolliert!
Den Falschspieler enttarnen
Kommen wir nun zu einem weiteren Beispiel, um die Besonderheiten kennenzulernen. Wir kopieren folgenden Code wieder in die Eingabemaske und schicken sie los.
<?xml version="1.0" encoding="UTF-8"?>
<scene xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="https://eisentrutz.antamar.eu/aoqml.xsd">
<set name="zufall1" val="$[3W6]" "/> <!-- Durch die Notation 1 ... 6 wird das System einen zufälligen Wert zwischen Eins und Eintausend auswählen -->
<set name="zufall2" val="20...30" show="none/>
<p>Du triffst auf dem Weg durch die Stadt einen jungen Bekannten wieder.</p>
<p>Wie eigentlich immer wollt ihr eine Runde würfeln und setzt euch dazu an das nächstbeste tischähnliche Ding, welches ihr auftreiben könnt und beginnt.</p>
<p>Du verlierst. In einer Tour und bestimmt das fünfhundertachtundsiebzigste Mal in Folge verlierst du.</p>
<q>Du Betrüger! Deine Ansagen sind alle falsch</q> brüllst du los.
<p>Dein Bekannter schaut dich fragend an und hebt seinen Würfelbecher. Tatsache, da liegen sie: Volle <eval><fetch name="zufall1"/>+<fetch name="zufall2"/></eval> Punkte.</p>
<p>Damit hat er eindeutig mehr als du; denn unter deinem Würfelbecher liegen lediglich <fetch name="zufall1"/> Augen.</p>
<p>Ihr würfelt wieder und wieder und wieder. Immer hat dein Bekannter mehr als du zu vermelden.</p>
</scene>
Fügen wir nun also diesen Code in das Eingabefeld zum Zufallsbegegnungstest ein und schauen auf die Ausgabe. Das ganze wiederholen wir zwei, drei Mal und können munter feststellen, dass wir irgendeinen Wert würfeln, während unser fiktiver Gegenspieler immer mehr hat so rund 20 bis 30 mehr hat. Gut, das ist nun ein sehr gestelltes Beispiel, schließlich könnte man auch schon einfach show="none" aus dem Set-Befehl nehmen und würde es direkt sehen.
Besonderheiten des Testserver
Var-dump
Var-dump ist eine wichtige Funktion für den Test von Questen. Nur mit dieser Funktion können wir uns zu beliebigen Zeitpunkten innerhalb eines Ablaufs den Inhalt beliebiger Variablen anschauen und somit prüfen. Wir werden also nun den Befehl in die obige Begegnung einsetzen, um so vom System direkt den Wert den Wert von zufall2 zu erfahren.
<?xml version="1.0" encoding="UTF-8"?>
<scene xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="https://eisentrutz.antamar.eu/aoqml.xsd">
<set name="zufall1" val="$[3W6]"/> <!-- Durch die Notation 1 ... 6 wird das System einen zufälligen Wert zwischen Eins und Eintausend auswählen -->
<set name="zufall2" val="20...30" show="none"/>
<p>Du triffst auf dem Weg durch die Stadt einen jungen Bekannten wieder.</p>
<p>Wie eigentlich immer wollt ihr eine Runde würfeln und setzt euch dazu an das nächstbeste tischähnliche Ding, welches ihr auftreiben könnt und beginnt.</p>
<p>Du verlierst. In einer Tour und bestimmt das fünfhundertachtundsiebzigste Mal in Folge verlierst du.</p>
<q>Du Betrüger! Deine Ansagen sind alle falsch</q><p> brüllst du los.</p>
<p>Dein Bekannter schaut dich fragend an und hebt seinen Würfelbecher. Tatsache, da liegen sie: Volle <eval><fetch name="zufall1"/>+<fetch name="zufall2"/></eval> Punkte.</p>
<p>Damit hat er eindeutig mehr als du; denn unter deinem Würfelbecher liegen lediglich <fetch name="zufall1"/> Augen.</p>
<p>Ihr würfelt wieder und wieder und wieder. Immer hat dein Bekannter mehr als du zu vermelden.</p>
<var-dump scene="false" quest="true" />
</scene>
Die genaue Verwendung der Funktion Var-dump kann man sich hier auf der Wikiseite durchlesen. Die größte Schwierigkeit besteht meist darin die fehlerhafte Stelle durch beständiges einfügen des passenden Var-dump-Befehls einzugrenzen, um schlußendlich den Fehler beseitigen zu können.
In unserem Beispiel können wir nun entsprechend direkt ablesen: Wie bereits (unschön) im Lauftext vermerkt hat zufall1 seinen Wert, aber viel wichiger. Den ansonsten unsichtbaren Wert von zufall2 können wir nun ebenfalls direkt herausfinden. Wichtig bei der Suche nach Fehlern bei Variablen sind unter Anderem:
- exakte Übereinstimmung des Namen (Groß- und Kleinschreibung, eventuelle Interpunktionen, Laufziffern)
- existiert die Variable überhaupt zu diesem Zeitpunkten
- beinhaltet die Variable einen unerwarteten Wert - welchen Inhalt erwartet man bei einer Variable überhaupt
- Verändert sich in der derzeitigen Szene der Variableninhalt können auch mehrere var-dump-Befehle eingebaut werden
- werden Szenen über Include eingebunden
Debug
Nachdem wir nun einen exklusiven Befehl für die Testumgebung kennenlernten kommen wir nun zu einer weiteren Besonderheit. Durch die Maskierung mittels
<debug> <!-- Hier steht zum Beispiel die Vergabe von anschließend benötigten Waren --> </debug>
besitzt man zum Beispiel die Möglichkeit eigene Var-dump-Ausgaben einzubinden; benötigte Waren für den nächsten Abschnitt zur Verfügung stellen, oder vielleicht auch nur als Autor dem korrierenden Gegenüber zusätzliche Informationen zum Inhalt/Ablauf/Verhalten geben. Auch wenn man auf dem Testserver sich beliebige Mengen von Waren entweder kaufen, oder einfach direkt via take zuschieben kann aus der Warenliste, so gibt es dennoch vielreichende Möglichkeiten zum Einsatz von debug.
Result=""
Wer sich schon einmal mit AOQML beschäftigt hat wird sicherlich auch die Proben kennen. Was wäre Abenteurer&Ordenskrieger nur ohne sie?! Doch wie schafft man es nun bitte sicher mit dem aivarunischen Stammeskrieger sicher einem Zwergischen Uhrmachermeister die kleinsten Teilchen einzusetzen mit einer Fingerfertigkeit von Maximal 18? Die Antwort ist ziemlich einfach - Wir geben dem System zusätzlich zur Probe vor, welches Ergebnis wir testen wollen.
<?xml version="1.0" encoding="UTF-8"?>
<scene xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="https://eisentrutz.antamar.eu/aoqml.xsd">
<p>Ein Vöglein fliegt an dir vorbei und du bekommst Lust mit ihm zu singen...</p>
<challenge talent="Singen" mod="5" result="-3">
<success>
<p>Schön wie ein Sängerknabe trällerst du mit dem Vogel im Einklang.</p>
</success>
<failure>
<p>Schräg wie eine verbogene, singende Säge jaulst du, dass die Fische heute Tiefflug üben.</p>
</failure>
</scene>
Haben wir schließlich ausreichend die armen NSC gequält ändern wir entsprechend zum Beispiel auf result="3" und erfreuen die Welt an der Alternative.
Testen neuer Kampffeatures
Bevor neue Features ins Spiel gelangen, werden sie oft schon am Testserver implementiert, um Spielern die Möglichkeit zu geben sie zu testen und Feedback abzugeben. Insbesondere bei neuen Kampffeatures ist es essentiell, dass sie am Testserver gründlich ausprobiert werden, damit es später im Spiel zu keinen Balancing-Problemen kommt. Entsprechend ist eine hohe Beteiligung wünschenswert. Und als Spieler ist es natürlich sinnvoller, Kritik vor der Implementierung loszuwerden, da sie dann viel eher berücksichtigt wird. Abgesehen davon ist das Testen auch eine gute Möglichkeit, das Kampfsystem besser kennen zu lernen und verschiedene Kämpfertypen auszuprobieren.
