Jochen Peketz war bis 2002 bei Piranha Bytes an der Entwicklung von ’Gothic’ beteiligt und arbeitet seit 2003 als Skripter beim deutschen Entwicklerstudio Phenomic Game Development. Mittlerweile ist er dort als Lead-Skripter beschäftigt und war für das Scripting von ’Spellforce: The Order of Dawn’, die ’Spellforce’-Add-ons sowie das Sequel ’Spellforce 2: Shadow of Wars’ zuständig. Zu seinen Aufgaben gehören hauptsächlich das Entwerfen und Skripten von Missionen und Abläufen auf Kampagnenkarten und die interne Koordination als stellvertretender Content Lead.

Was entwickelt eigentlich ein Skripter?

Ein Skripter setzt mit einer externen, z.B LUA, oder einer internen, firmeneigenen Skriptsprache Missionsdesigns um. Das geht bei einfachen Dingen los wie zum Beispiel: Wenn sich der Spieler an Ort X befindet, geht Tor Y auf – bis hin zu komplexen Schalterrätseln, die über verknüpfte Dialoge den Spieler zu einer Lösungsstrategie führen sollen. Wobei es immer auch Überschneidungen mit anderen Bereichen geben kann. Bei ’Spellforce’ gibt es Leveldesigner, die auch skripten. Cutscenes hängen auch stark mit Skripten zusammen und Missionsdesigns können, in Abstimmung mit der Story/dem Storywriter, auch von den Skriptern sein.

An welchen Stellen eines Spiels kommt der Spieler mit einem Skript in Berührung?

Das ist von Titel zu Titel sehr unterschiedlich: Bei Shootern werden z.B. häufig nur einzelne Ereignisse wie bestimmte Angriffe oder Begegnungen geskriptet. Das Angriffsverhalten selbst kommt aber vom Code. Bei Titeln wie ’Gothic’ ist es aber so, dass selbst komplexes Gegnerverhalten geskriptet ist. Ob und wie ein NPC darauf reagiert, dass der Spieler ein Schwert zieht, und ob das ganze in der Stadt oder auf dem flachen Land passiert usw., wird alles von Skripten bewertet und führt so zu entsprechenden Verhaltensmustern der NPCs. Genauso können Einheitenwerte von Code, von einer Datenbank oder eben von Skripten verwaltet werden. Deshalb kann man nicht so pauschal sagen, wo der Spieler mit Skripten in Kontakt kommt, da eigentlich jedes Spiel andere Einsatzorte und -möglichkeiten für Skripter bereithält.

Welche Möglichkeiten gibt es, Skripte einzusetzen?

Auch das hängt natürlich völlig davon ab, an welcher Stelle die Skripte in Spielabläufe eingreifen können/dürfen. Skripte sind ja nur eine Art dem Spiel zu sagen, was es tun soll. Wenn man beispielsweise als Spieler eine Figur markiert und per Mausklick in der Karte rumschickt, so ist das gleiche Verhalten prinzipiell auch per Skript möglich. Allerdings muss immer eine Anbindung an den Programmcode bestehen, der die Skriptbefehle so interpretiert, dass sie zum gewünschten Verhalten im Spiel führen. Dabei geht es von einfachen Befehlen, wie Figur A gehe zu Punkt B zu komplizierten Verhaltensweisen, wie Figur C: Immer wenn du untätig bist, gehst du zu Punkt D, haust dort Figur E, spielst dann eine spezielle Animation und einen Sound ab und gehst dann wieder zurück. Wobei das letzte Beispiel natürlich eher über verschieden verknüpfte Befehle laufen wird. Theoretisch wäre es aber möglich, dass Coder eine einzige Funktion zur Verfügung stellen, die genau das vorher beschriebene Verhalten zeigt. Da aber das Abspielen von Animationen auch an anderen Stellen nützlich sein kann, macht es mehr Sinn, einzelne Teile zur Verfügung zu haben, die dann im Skript beliebig kombinierbar sind. Wollte man im obigen Ablauf eine zweite Animation einfügen, wäre man mit einem Befehl, der das ganze Verhalten abbildet, schon aufgeschmissen. Hat man einen Befehl für die Animationen, führt man einfach zwei davon hintereinander aus und schon klappt es.

Letztlich ist also alles per Skript realisierbar, was der Spieler auf dem Bildschirm sehen kann aber nicht alles sinnvoll. Schon alleine weil Skripte interpretiert werden müssen und deshalb meistens langsamer laufen als reiner Quellcode. Mir bekannte Einsatzorte sind trotzdem weit gefächert: Vom Ansteuern und Parametrisieren von Partikeleffekten über Gegnerspawning bis hin zur kompletten KI sind nur einige Gebiete, die mir bekannt sind.

Welche Arbeitswerkzeuge benötigt ein Skripter?

In allen Fällen benötigt ein Skripter einen Texteditor (*Klugscheißmodus an* scribere (lat): schreiben *Klugscheiss off*), ob das nun Bordmittel eines Betriebssystems (Word Pad) oder mächtigere Lösungen sind, ist für das Ergebnis erst einmal egal. Für die Effektivität der Arbeit ist ein vernünftiger Texteditor aber enorm wichtig. Wir arbeiten hier bei Phenomic mit Ultra Edit. Das Programm stellt viele Hilfsmittel zur Verfügung, die einem die tägliche Arbeit leichter machen. Das fängt bei so Sachen wie automatisches Einrücken von Klammerebenen an und geht über Syntaxhighlighting (Einfärben bestimmter Schlüsselwörter in Farbe) bis hin zu Text- und Konvertiermacros. Mit Letzterem passen wir Dialoge an die Sprachlogik des Codes an.

Des Weiteren wird häufig, eigentlich immer, ein Editor benötigt. Im Editor bekommen die Figuren, Objekte, Landschaftsmarken etc. Bezeichner, so genannte Tags, mit denen sie dann in den Skripten angesprochen werden. Wenn man dem Spiel nicht sagt, dass Figur A auch wirklich Ulrich heißt, woher soll es diese Information sonst holen? Außerdem gibt es in Editoren wichtige Information für die Erstellung von Skripten. Einheitenposition, -typ und vieles mehr werden im Editor dargestellt und verwaltet.

Dies sind die beiden wichtigsten Bestandteile einer Entwicklungsumgebung. Trotzdem gibt es noch weitere. Auf jeden Fall braucht man auch Debuggingmöglichkeiten, um so Fehlern auf die Spur zu kommen. Es gibt aber viele Möglichkeiten so etwas umzusetzen. So kann man einfach bestimmte Variablen in ein Textfile dumpen oder während der Laufzeit den Skriptcode parsen, um herauszubekommen, warum das Skript partout nicht das gewünschte Verhalten zeigt.

Ein weiteres wichtiges Tool, welches aber nicht nur der Skripter sondern das ganze Team benötigt, ist eine Versionsverwaltungssoftware (wir setzen hier für ’Spellforce’ Perforce ein, beliebt ist aber auch Alienbrain von NXN), damit werden die Änderungen an Grafiken, Code und Skripten verfolgt und es gibt einen zentralen Server auf dem immer eine laufende Version des Spiels mit den neuesten Daten verwaltet und den einzelnen Clients zur Verfügung gestellt wird.

Außerdem müssen natürlich Bugs gefunden und verwaltet werden. Dafür setzen wir Bugzilla ein. Hier wird festgehalten, wer für welchen Fehler zuständig ist und ihn fixen muss, wer den Fehler gefunden hat, wer später nochmal drüber gucken muss, ob der Fix auch wirklich funktioniert. Mit dieser Software werden aber auch Reproduktionsschritte für bestimmte Fehler festgehalten oder log-Dateien und Savegames, die bei der Fehlersuche helfen können.

Wie benennst du die einzelnen Arbeitsschritte im Bereich des Skriptens vom Konzept über Produktion bis zur Fertigstellung des Spiels?

Feste Namen für die Phasen haben sich bei uns nicht eingebürgert, es gibt aber natürlich Abläufe, die sich wiederholen und die bestimmte Arbeiten beinhalten.

Allerdings muss man dort zwischen komplett neuen Spielen (z.B ’Spellforce: The Order of Dawn’) und Add-ons (z.B. ’The Breath of Winter’) klar unterscheiden. Bei Add-ons ist die Planung natürlich bei weitem nicht so umfangreich wie bei dem ersten Spiel. Dort muss man ja auch wissen, was die Skriptsprache an Möglichkeiten bereitstellen muss, wo die Schnittstellen mit dem Editor sind, was die Programmierer im gegebenen Zeitrahmen zur Verfügung stellen können usw. Das alles fällt bei einem Add-on zum großen Teil weg, da es ja eine Basis gibt, die schon funktioniert, und im Normalfall nur noch für Spezialaufgaben neue Skriptbefehle nötig sind.

Zu Beginn steht natürlich eine Planungsphase; was soll auf den Maps passieren? Wie lange sollen sie dauern? Welche Gegner sind zu erwarten? Welche Dinge sind mit der Skriptsprache und ihren Befehlen überhaupt umsetzbar etc.? Daran schließt sich dann schon bald die Umsetzung der Skripte an. Dafür muss von den Leveldesignern ein, zumindest von der Grundgeometrie fertig gestellter, Level zur Verfügung gestellt werden. Bugfixing ist eigentlich keine Phase in dem Sinne, sondern muss die ganze Entwicklungszeit über auch gemacht werden. Trotzdem gewinnt es aber selbstverständlich zum Projektende hin immer mehr an Bedeutung, da die Abläufe im Großen und Ganzen so sind, wie sie sein sollen. Aber Kleinigkeiten, die unschön sind, müssen noch entfernt werden, z.B. wenn der Ork den Zwerg einfach nicht angreifen will. In solchen Fällen könnte der Spieler die Karte zwar zu Ende spielen, würde sich aber wundern warum zwei Feinde friedlich nebeneinander stehen. Solche Fehler müssen natürlich entfernt werden.

Ebenso wird das Balancing zum Projektende hin immer wichtiger. Das besteht ja nicht nur aus Werten für die Einheiten, die bei uns aus der Datenbank kommen, sondern auch darin, die richtigen Gegnermengen zum richtigen Zeitpunkt an der richtigen Stelle auftauchen zu lassen. Eine Aufgabe, die zumindest teilweise auch von Skripten übernommen wird.

Jochen, vielen Dank für deine detaillierten Informationen.