Ungetestete Maps sind nie fehlerfrei. Daher müssen sie wiederholt durchgespielt und auf Fehler geprüft werden. In früheren Testphasen übernimmt das der Mapper selbst, während er in der Regel bei der späten Testphase von weiteren Testern unterstützt wird.

Wenn du deine Map testest und einen Fehler entdeckst, sind einige Schritte notwendig, bis du den nächsten Versuch starten kannst:

1. Das Spiel beenden
2. Das Skript modifizieren
3. Die Kartendatei neu abspeichern
4. Das Spiel erneut öffnen und die Map starten

Insbesondere der letzte Schritt kann die Testphase sehr zäh machen, da die Ladezeiten sich schnell addieren.

Mit einem kleinen Trick können die Ladezeiten für Änderungen im Skript aber übersprungen werden. Das Ziel ist, das Skript beim Kartenstart von einer externen Datei auf der Festplatte zu laden, die nicht Teil der Kartendatei ist. Dadurch wird das Skript jedes Mal beim Klick auf Karte neu starten neu geladen, sodass ein Neustart des Spiels überflüssig wird und die Ladezeiten wegfallen.

Damit das funktioniert, sind zwei Schritte notwendig. Zuerst muss dein Skript außerhalb der Mapdatei im .lua-Format abliegen. Wie im Tutorial zur Einrichtung der Skriptumgebung wählen wir C:\Scripts\ als Speicherort. Unsere Skriptdatei soll den Namen mapscript.lua tragen, also lautet der vollständige Pfad zur Datei C:\Scripts\mapscript.lua. Achte darauf, dass deine Skriptdatei nicht das Sonderzeichen NUL ganz am Ende enthält! Das passiert, wenn du das Skript mit Exportiere Skript… aus dem Editor exportierst.

Im zweiten Schritt ersetzen wir die Skriptinhalte der Mapdatei mit einer einzigen Zeile:

Script.Load( "C:\\Scripts\\mapscript.lua" )

Sonst darf das Skript der Mapdatei nichts enthalten.

Hinweis: Die doppelten Backslashes kommen daher, dass ein einzelner Backslash eine Escape Sequence einleitet (vgl. den Tutorial-Abschnitt zu Strings). Sie sind daher notwendig, um den Dateipfad angeben zu können.

Schließe den Skripteditor des Mapeditors mit einem Klick auf Skript → Beenden, nicht über das X im oberen rechten Eck! Die Map lädt nun bei Spielstart immer die aktuelle Version des Skripts, das im angegebenen Dateipfad liegt.

Wichtig: Das bedeutet auch, dass die Map so nicht funktioniert, wenn du sie mit anderen teilen willst, weil bei anderen das Skript nicht abliegt. Damit du die Karte weitergeben kannst, musst du im Skript-Editor des Mapeditors im Menü Skript → Importiere Skript… wählen und das Skript so der Mapdatei wieder zufügen.

neue Debugger-Version incoming

Bevor du deine Karte an Tester weiter gibst, solltest du sie zuerst selbst ausgiebig testen und mindestens 1 mal vollständig durchgespielt haben. Dadurch ist sichergestellt, dass die Tester die Karte ebenfalls vollständig durchspielen und begutachten können.

Als Mapper fällt es sehr schwer, aus der eigenen Rolle auszubrechen. Man weiß durch den eigens entworfenen und programmierten Ablauf ganz genau, was zu tun ist und ist sehr dazu geneigt, die Map so zu spielen, wie sie gedacht ist. Man kennt alle Fallstricke (z.B. welche Aktion das Erscheinen eines Gegners auslöst) und kann sich entsprechend darauf vorbereiten.

Wenn unabhängige Tester die Map spielen, geht es um folgende Fragen:

1. Was kann ein Spieler machen, mit dem der Mapper nicht gerechnet hat? Stört das den Ablauf des Skripts, entsteht ein unfairer Vorteil/Nachteil oder verhindert das sogar das Erreichen der Siegmeldung?
2. Sind alle Aufgaben verständlich genug kommuniziert? Muss der Spieler rätseln, was er als nächstes zu tun hat? Stößt er beim Ausprobieren auf Teile der Map/Quest, die für ihn zu dem Zeitpunkt noch nicht zugänglich sein sollen?
3. Wie sind Rohstoffe und Gegnerstärken balanciert? Gibt es Fallen für den Spieler, die für Frust sorgen? Ist die Mission fair gestaltet?

In der Regel durchläuft eine Map mehrere Testrunden. Erstelle für die erste Runde nach den eigenen Tests eine spielbare Version deiner Karte. Vergiss nicht, das Skript zurück in die Mapdatei zu importieren, falls du es ausgelagert hattest! Speichere diese Mapdatei unter einem Namen ab, der sie unmissverständlich als erste Testversion kennzeichnet, zum Beispiel Kartenname_Testversion1.s5x. Jeder deiner Tester bekommt die gleiche Version.

Das hat folgenden Grund: Wenn einer deiner Tester auf einen Fehler stößt, musst du unbedingt die Version der Karte auffinden können, die er gespielt hat. Andernfalls wird es für dich sehr schwierig werden, den Fehler zu finden. Oft ist es auch nützlich, den letzten Speicherstand eines Testers zu laden, um einen Fehler zu reproduzieren. Dazu muss die Mapversion kompatibel sein.

Erst nachdem alle deine Tester einen Testbericht gegeben haben, solltest du sie zusammenfassen und anhand der Erfahrungen Änderungen planen und umsetzen. Möglicherweise widersprechen sich die Meinungen deiner Tester (z.B. wegen unterschiedlicher Vorlieben für Kämpfe, Ressourcenverteilung, etc). Da musst du dann eine Mitte finden, die dir gefällt. Auch bei Skriptfehlern ist es unabdingbar, auf alle Testergebnisse zu warten, weil du sonst u.U. an der falschen Stelle Korrekturen ansetzt (beispielsweise können mehrere Fehler im Questablauf durch eine einzige Stelle im Skript verursacht werden. Wenn du zu voreilig einen Fix für einen gefundenen Fehler ansetzt, könnte der andere davon unberührt bleiben. Das führt zu unübersichtlichem Code).

Sobald du das Feedback der Tester umgesetzt hast, erstelle eine neue Version, wieder mit eindeutigem Namen, z.B. Kartenname_Testversion2.s5x und prüfe sie selbst zuerst auf Fehler. Danach schickst du sie an alle Tester für die zweite Runde. Damit deine Tester gezielt auf die Änderungen achten können, erstelle eine Liste mit allen Fixes, die du vorgenommen hast, und lege sie der Testversion bei.

Dieser Vorgang von Test → neue Testversion → Test … wird so lange wiederholt, bis du aufgrund der Testberichte beschließt, die Map zu veröffentlichen. Die veröffentlichte Version sollte die jüngste Testversion sein.

Die Anzahl der Tester ist stark von der Komplexität deiner Karte abhängig. Einfache Maps wie unsere Beispielkarte sollte mit zwei Testern gut auskommen. Für Karten mit vielen Quests und eventuell verzweigten Abläufen sollten 5-7 Tester drüber schauen, um eine weitestgehend fehlerfreie Lauffähigkeit zu gewährleisten.

Selten wird eine Karte komplett fehlerfrei sein. Die Maptests sollen aber dafür sorgen, dass jeder Spieler die Mission mit so wenigen Problemen wie möglich beenden kann.

Beim Testen der Karte können viele verschiedene Fehler auftreten. Im nächsten Kapitel wollen wir diejenigen vorstellen, die besonders häufig auftreten.

Nächstes Kapitel: Häufige Fehler
Zurück nach oben