Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

--- scripting:tutorials:level1:debugging [2024/05/13 14:46] – fritz_98
+++ scripting:tutorials:level1:debugging [2024/05/16 09:01] (aktuell) – fritz_98
@@ Zeile 15: / Zeile 15: @@
 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 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.
+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 [[ scripting:tutorials:visual_studio#einrichten_der_skriptumgebung|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.
@@ Zeile 30: / Zeile 30: @@
 **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.
+----
 =====Der Debugger=====
 FIXME neue Debugger-Version incoming
+----
 =====Maptest durch Tester=====
-- Den ersten Test macht der Mapper selbst
+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.
+===Warum ist das Testen durch andere Spieler wichtig?===
+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:
+  - 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?
+  - 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?
+  - Wie sind Rohstoffe und Gegnerstärken balanciert? Gibt es Fallen für den Spieler, die für Frust sorgen? Ist die Mission fair gestaltet?
+===Wie wird ein Maptest organisiert?===
+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.
+===Wie viele Tester brauche ich?===
+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.
+----
-- Dabei hilft der Debugger, wenn was nicht läuft (Interface erklären)
+Beim Testen der Karte können viele verschiedene Fehler auftreten. Im nächsten Kapitel wollen wir diejenigen vorstellen, die besonders häufig auftreten.
-- Danach geht die Map zu den Testern (Ablauf schildern: Wie viele Tester, Versionierung, etc)
+[[ scripting:tutorials:level1:common_errors | Nächstes Kapitel: Häufige Fehler ]]\\
+[[ scripting:tutorials:level1:debugging | Zurück nach oben ]]