Thomas Seufert war für das Leveldesign und als Programmierer für das MMORPG ’Face of Mankind’ veranwortlich. Zuvor sammelte er Erfahrungen in der Qualitätssicherungsabteilung für ’AquaNox2: Revelation’ und als Leveldesigner für ’Unreal Tournament’. Derzeit widmet sich Thomas seinem Informatikstudium und möchte danach wieder als Entwickler tätig sein. Besonders der technische Bereich wie beispielsweise Game-Engines und Grafikprogrammierung ziehen derzeit sein Interesse an.

Was macht eigentlich ein Leveldesigner genau?

Der Leveldesigner ist – kurz gesagt – für das Design, die Erstellung, die Optimierung und das Balancing der Spielwelt verantwortlich. Die Spielwelt wird im Allgemeinen in verschiedene Abschnitte unterteilt, die man auch Level oder Zonen nennt. Jedes Level setzt sich aus der Geometrie, Beleuchtung, Models, Materialien, Objekten, Scripts, Soundeffekten und Musik zusammen. Der Leveldesigner hat die Aufgabe, all diese Inhalte in Symbiose zu bringen. Je nach Projekt und Fähigkeit kann auch Modelling, Texturerstellung und Scripting zu den Aufgaben eines Leveldesigners gehören.

Welche Werkzeuge benutzt du für diese Arbeit?

Primär kommt ein Level-Editor zum Einsatz, in dem der Inhalt der Spielwelt zusammengesetzt wird. Bis vor kurzem fand die Erstellung der Level-Geometrie fast ausschließlich im Level-Editor statt. Mit zunehmender Komplexität und Details der Level-Geometrie werden jedoch immer öfter zusätzlich Modelling-Programme verwendet. Diese Programme sind besonders auf die Arbeit mit detaillierter Geometrie zugeschnitten und eignen sich deshalb hervorragend für die Gestaltung von Models und Animationen. Im Level-Editor werden diese Models, manchmal auch „Prefabs“ genannt, importiert und dann zu einer Spielwelt zusammengesetzt, ähnlich wie bei einem Lego-Baukasten.

Neben der Geometrie benötigt eine Spielwelt auch Materialien, gewissermaßen die Tapete an den Wänden. Die hierfür benötigten Texturen werden in einem Bildverarbeitungsprogramm erstellt und in den Level-Editor geladen. Dort werden Sie dann der Level-Geometrie zugewiesen. Neben Texturen finden heute auch Pixel-Shader immer mehr Verwendung. Pixel-Shader sind kleine Programme für Grafikchips, die Texturen, Farben- und Beleuchtungsinformationen kombinieren. Außerdem wird im Level-Editor auch die Beleuchtung gesetzt, bei der man mit Schattenwürfen und Farbwahl viel zur Atmosphäre beitragen kann.

Viele Level-Editoren bieten die Möglichkeit zur Einbindung von Scripts. In diesen, meist einfachen Programmen, wird ein Teil der Spiellogik oder Zwischensequenzen gescriptet. Daneben bieten die meisten Level-Editoren auch die Möglichkeiten, Soundeffekte und Musik in einem Level einzubinden. Für Konzeptzeichnungen und Raumaufteilungen ist „Pen & Paper“ natürlich nicht zu ersetzen.

Was bedeutet das Leveldesign für das Spiel?

Ein schlechtes Leveldesign kann ein Spiel total ruinieren. Ein gutes Leveldesign kann aber auch über ein schlechtes Gameplay hinwegtäuschen. Zumindest in den ersten Spielminuten. Die Bedeutung ist stark abhängig vom Spiel und dessen Genre. Tendenziell kann man jedoch sagen, je aufwendiger das Spiel ist und je mehr Spielinhalte es gibt, desto wichtiger das Leveldesign.

Welche Faktoren bzw. Vorgaben eines Spiels sind wichtig für deine Überlegungen für das Leveldesign?

Wichtig sind zunächst der Stil und die Umgebung des Levels. Es muss am Schluss alles zusammenpassen, sonst ist der Eindruck dahin, sich in einer eigenständigen und isolierten Welt zu befinden. Auch Dinge, die wir aus dem täglichen Leben kennen, können in angepasster Form in Spielwelten verwendet werden. Das erhöht die Glaubwürdigkeit der Spielwelt.

Daneben müssen auch technische Aspekte berücksichtigt werden. Wie detailliert dürfen die Models werden? Wieviele Charaktere können gleichzeitig dargestellt werden, ohne dass die Framerate einbricht? Konsolen haben tendenziell eher wenig Speicher. Aus diesem Grund müssen Texturen vielleicht in niedrigerer Auflösung erstellt werden oder durch geschickte Verfahren komprimiert werden. Eventuell braucht man auch mehrere Auflösungen für unterschiedliche Plattformen.

Erfordern verschiedene Genres ein jeweils angepasstes Leveldesign?

Definitiv. Ein Level für einen Shooter wird nach anderen Gesichtspunkten erstellt als beispielsweise ein Level für ein Adventure-Spiel. Bei einem Fast-Pace-Shooter legt man wert auf Levels die einen „Flow“ haben und man nicht an jeder Ecke hängen bleibt oder in Sackgassen läuft. Bei Adventure-Spielen ist es vielleicht wichtiger, eine atemberaubende Atmosphäre zu zaubern, um den Spieler in seinen Bann zu ziehen. Je nach Genre muss man also den Fokus auf einzelne Spielelemente und -inhalte anpassen.

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

Im ersten Arbeitsschritt geht es um das Design des Levels. Es gilt zunächst herauszufinden, welchen Stil das Level haben soll. Soll es ein vom Rost zerfressener Industriekomplex werden oder vielleicht eine futuristische Raumstation?

Hier sind Konzeptzeichnungen äußerst hilfreich. Hat man diese Entscheidung getroffen, beginnt man mit dem Entwurf der Raum- oder Gebietaufteilung, dem Floor-Plan. Man teilt einen Bereich in kleinere Bereiche auf. Man stellt sich diesen Ort vor und notiert sich besonders markante Merkmale, die an einem solchen Ort vorkommen. Jeder Teilbereich soll später eine Funktion haben und sich optisch vom Rest unterscheiden, wobei aber der Grundstil beibehalten werden muss. Jeder Teilbereich wird erneut unterteilt, bis das Level in überschaubare Teile zerlegt ist.

Nun beginnt man mit der Umsetzung im Level-Editor. Dabei baut man zunächst die Grundstruktur ohne Details und Texturen. Eventuell muss man mittels Scriptsprache nun einige Abläufe programmieren. Anschließend kann man mit den ersten Gameplay-Tests beginnen und sich folgende Fragen stellen: Macht der Level Spaß? Ist der Schwierigkeitsgrad angemessen? Was muss verändert werden, falls das nicht der Fall ist? Entsprechend müssen jetzt Floor-Plan und Grundstruktur angepasst werden, bis der Level auch wirklich den gewünschten Fun-Faktor erreicht hat. Erst dann fängt man an, Details einzubauen, Materialien zu erstellen und Soundeffekte zu verteilen. In den meisten Fällen sind aber nicht alle Bausteine zu Beginn vorhanden, so dass man manche Models, Objekte oder Soundeffekte erst sehr spät einbauen kann.

Oft kommt es vor, dass die Performance in Bereichen der Spielwelt stark abfällt. Hier ist vielleicht die Geometrie zu aufwendig oder man kann viel zu weit sehen und es muss dementsprechend viel dargestellt werden. Hier muss mit geeigneten Mitteln optimiert werden, so dass die Framerate möglichst konstant bleibt. Manchmal können hier Probleme auch von Programmierern gelöst werden.

Thomas, vielen Dank für deine Informationen!

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.

Steffen Unger ist beim Berliner Spieleentwicklungskombinat als Lead 3D-Artist beschäftigt. Aufgefallen ist das Grafikertalent früher, als er mit dem Animago Award ausgezeichnet wurde. Zur Zeit arbeiten er und SEK an der Fertigstellung des Echtzeit-Strategiespiels ’Paraworld’.

Welche Überlegungen stellen sich für einen Grafiker zu Entwicklungsbeginn?

Zuerst einmal sollte man wissen, in welchen Limits man sich bewegen darf. Was kann die Engine, was darf ich und was darf ich nicht? Natürlich kann sich das im Laufe der Zeit ändern. Aber wenn man sich ein Stück weit daran hält, ist eine Erweiterung nach oben, wenn überhaupt, ja nur ein zeitliches Problem. Innerhalb dieses technischen Rahmens sollte man, bevor die Produktion richtig losgeht, anfangen zu testen, viel testen, um später nicht über die eigenen Fehler stolpern zu müssen. Leider ist das heutzutage noch nicht wirklich der Produktionsalltag, was dazu führen kann, dass im Nachhinein viel nachgebessert und/oder sogar völlig neu gemacht werden muss.

Aber aus jeder Produktion lernt man ja dazu. Gerade neuere Techniken lassen sich anfangs ja nur schwer mit einplanen. Eine Pipeline später dahingehend umzubauen, ist kein allzu leichtes Unterfangen, aber mit ausreichender Planung ist das zu bewältigen. Um das Ganze mal zusammenzufassen: Man sollte, bevor die eigentliche Produktion losgeht, erst einmal die Grenzen ausloten und viel testen, um mögliche Schwachstellen im Konzept schnell vorhersehen zu können.

Fertigst du Konzeptgrafiken an? Gibt es noch Papier und Bleistift? Oder gehören die sogenannten Artworks nicht zu deinen Aufgaben?

Ja tue ich, in den meisten Fällen aber eher schnelle Tests und Kritzeleien, für ausgefeilte Konzepte fehlt mir meistens die Zeit. Ich mache diese entweder auf einem kleinen Block, den ich immer dabei habe oder, was eher der Normalfall ist, direkt am Rechner. Aber wir hatten bei ’Paraworld’ einige Konzeptzeichner, die sich ausschließlich damit befasst haben.

Also ich kann jetzt nur von mir und der Grafikpipeline im SEK berichten, andere Studios mögen das anders machen. Für die 2D-Grafiken und Texturen benutzen wir Photoshop und zBrush. Für die 3D-Grafiken greifen wir auf 3dsmax für die Modelle und zBrush und Claytools für die Normalmaps zurück. Außerdem nutzen wir einige für unsere Ansprüche hergestellte Tools, die uns das Arbeiten mit der Engine deutlich erleichtern. Sei dies nun ein eigener Polygoncounter oder der Modelviewer, mit dem man sich die Modelle in der Engine ansehen kann, ohne vorher das Spiel zu laden oder irgendwelche Scripte erstellen zu müssen.

Welche Vorgaben erhält ein Grafiker bezüglich des Aussehens des Spiels von den Entwicklern?

Wir Grafiker sind doch auch die Entwickler des Spiels. Solange die Grafiker nicht in einem externen Studio sitzen, kommt das Aussehen natürlich in erster Linie von uns. Da bin ich glücklich einem inzwischen sehr gut zusammen funktionierenden Team anzugehören. Wir haben weitestgehend Einfluss auf das Aussehen des Spiels, natürlich immer in Rücksprache mit unserem Artdirector.

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

Also über die ganze Produktion hinweg wären das: Preproduction, Conception, Production, Revision, Polishing und Finalizing. Dass das nicht immer in der Produtkion genau nach Fahrplan geht, sollte jedem klar sein. Viele Ideen kommen erst im Laufe des Spiels dazu und werden dann umgesetzt. Anhand eines Models sieht der Ablauf in etwa so aus:

Idee einer Einheit, die sich das Gameplay ausgedacht hat. Diese Idee wird dann dem Konzeptzeichner, dem dazugehörigen 3D-Grafiker und dem Texturierer, also all den Leuten die direkt mit der Produktion dieser Einheiten beschäftigt sind, vorgetragen. Diese 3 Parteien und der Artdirector setzen sich dann zusammen und überlegen, wie das aussehen könnte. Dann macht der Konzeptzeichner viele unterschiedliche Entwürfe, um zu schauen, in welche Richtung es gehen kann. Zu diesem Zeitpunkt darf es keinerlei Restriktionen geben; ein gutes Design kann nur aufblühen, wenn der Konzeptzeichner innerhalb des vom Gameplay vorgetragen Rahmens machen kann, was er will.

Danach geht der Entwurf zum 3D-Grafiker, der sich dann überlegen muss, wie er mit den vorgegebenen Grenzen haushaltet und diese effizient ausnutzt. Sobald das Model gebaut ist, werden diesem Texturkoordinaten zugewiesen. Dann geht das Model zum Texturierer, der es anmalt. Danach geht es erst mal in die Animation. Und wenn all dies getan ist, geht das Model zwecks Level of Detail, also entfernungsabhängiger Optimierung des Models, zurück an den 3D-Grafiker. Danach wird das Model vom Scripter in die Engine eingebaut und man kann sie sich zum ersten Mal im Spiel ansehen.

Steffen, vielen Dank für die Informationen!

Ein Spiel und sein Konzept entstehen beileibe nicht in fünf Minuten und im Gehirn nur eines Einzelnen. Teamarbeit wird besonders in der täglichen Arbeit von Entwicklerstudios groß geschrieben. Spezialisten verschiedenster Bereiche arbeiten zusammen an der Konzeption und Entwicklung eines neuen Titels. Und über dem ganzen Projekt steht in der Regel ein Publisher, der teilweise Unsummen in die Entwicklung investiert. Wir sind einmal der Frage nachgegangen, was alles passieren muss, bis eine Spielidee erste konkrete Formen annimmt.

Planung und Konzeption
Bevor überhaupt von einem Konzept für ein Spiel gesprochen werden kann, muss sich die Idee für ein neues Spiel an grundlegenden Ansprüchen messen lassen: Ein ungestörter Spielablauf mit einem Anfang und einem Ende, Sieg- bzw. Niederlage-Bedingungen, Gameplay, physikalische Bedingungen der Umgebung, Kollisionsabfragen sowie Überlegungen zur künstlichen Intelligenz eventueller Gegner. Welcher Sound und welche Musik passen zu dieser Art von Spiel am Besten? Nicht zu vergessen natürlich die unbegrenzten Möglichkeiten bei der Entscheidung über das Aussehen des Spiels und der Präsentation seiner Inhalte in grafischer wie filmischer Hinsicht. Sobald an ein Ende des Spiels gedacht werden kann, stellt sich außerdem die Frage einer begleitenden Geschichte. Das ist die kreative Seite. Um auch auf dem Konto später einen finanziellen Erfolg zu erzielen, spielen daneben wirtschaftliche Überlegungen eine ebenso wichtige Rolle: Welche Trends bestimmen zur Zeit das Geschäft? Was will der Markt sehen? Und vor allem: Was will der Markt nicht mehr sehen? Kosten spielen verständlicherweise auch bei der Entwicklung von Spielen eine große Rolle. So werden in Zusammenarbeit mit dem Publisher erste Kalkulationen erstellt, die in der Konzeptionsphase eine Einschätzung über den mittelfristig zu erwartenden personellen Aufwand geben sollen.

Am Anfang war das Wort
Ein gutes Spielkonzept wird deshalb die Punkte Vorstellung und Beschreibung der Idee, die Key-Features, das Genre und die angepeilten Plattformen enthalten. Tausend Dinge und noch viel mehr, über die sich Entwickler noch vor dem ersten sichtbaren Pixel auf dem Monitor also im Klaren sein müssen, denn sie werden vom zahlenden Spieler als Selbstverständlichkeit erwartet. Um da noch den Durchblick zu behalten und damit die Einfälle und Prozesse festgehalten werden können, setzen Entwickler die so genannten Design Documents ein. Ähnlich wie ein Skript in anderen Branchen wie Verlagen, Film- und TV-Produktionen stehen hier getreu der Idee genaue Anweisungen für jeden an der Entwicklung eines Spiels Beteiligten. Manche Entwickler vergleichen dieses Dokument gerne mit der Bibel. Der Produzent hält darin seine Vorstellungen über das neue Spiel fest. Der Lead-Designer sorgt für die kreative Umsetzung der Vorstellungen und pflegt die Ergebnisse seines Teams in das Design Document ein, damit der Rest der Mannschaft immer auf dem Laufenden bleibt, was gerade zu tun ist.

Unter der Regie der Design Documents
Im Idealfall handelt es sich dabei also um ein feingegliedertes Textdokument, das alle Beteiligten mit Informationen und dem Stand der Dinge versorgt. Außerdem geht daraus hervor, was noch in Angriff genommen werden muss. Im Design Document sind so beispielsweise die großen Kapitel wie Spielkonzept, Story, KI, Kollisionsabfrage, Leveldesign, Musik, verwendete Steuerungsperipherie und die Art des Spieler-Interfaces beschrieben. Diese Kapitel werden in der Regel mit den gleichen Fragestellungen untergliedert: Wer ist dafür zuständig? Was sind die Ziele? Welche Probleme könnten bei der Realisierung des betreffenden Features entstehen? Welche Lösungsvorschläge stehen dafür schon zur Verfügung? Wie soll es überhaupt aussehen und umgesetzt werden?

Und nicht zuletzt wie sich dieses bestimmte Feature auf alle anderen Bestandteile der Entwicklung auswirken könnte. „Im Falle von ’Paraworld’ waren das Farbstudien zu den Landschaften, Völkern usw., die ganz zu Beginn des Projekts in der Pre-Production durch den Art-Director angefertigt worden waren“, so der Lead 3D-Artist Steffen Unger vom Berliner Spieleentwicklungskombinat (SEK) über die im Design Document festgelegten grafischen Vorgaben.

Vor der Produktion
Steht das Team fest und weiß jedes Mitglied, was es zu tun hat, steht dem Produktionsprozess fast nichts mehr im Weg. Mögliche auftretende Entwicklungsverzögerungen oder zukünftige Kürzungen der Featureliste aus Zeitgründen sind zu diesem Zeitpunkt noch nicht eingerechnet, da es sich nach wie vor um ein niedergeschriebenes aber schon arbeitsfähiges Konzept handelt. Nimmt das neue Spiel langsam Gestalt an, werden erste Ergebnisse sichtbar, ergibt sich wieder eine unglaubliche Fülle an neuen Fragen und Problemen: Stimmt die sich abzeichnende Spielzeit oder wird sie möglicherweise zu kurz oder zu lang? Die Spielzeit ist für die Akzeptanz bei Spielern ein nicht unerheblicher Faktor, da diese hier sehr kritisch den Wert des ausgegebenen Geldes mit der Spielzeit des Produkts in Beziehung setzen. Ganz zu schweigen von der Einschätzung des Wiederspielbarkeitsfaktors und Wartezeiten etwa beim Ladevorgang. Ebenso wirkt sich der angepeilte Schwierigkeitsgrad auf die verbrachte Zeit und den Spaß mit dem Titel direkt aus: Ist das Spiel zu schwierig oder zu einfach? Benötigt der Spieler Minuten, Stunden oder Tage zum Erreichen des Ziels? Einen ersten in die Produktion einrechenbaren Wert liefern dazu die Tester der Qualitätssicherungsabteilung.

Vom Entwurf bis zum Polieren
Jedes an der Entwicklung eines Spiels beteiligte Mitglied greift auf für seinen Fachbereich spezifische Werkzeuge zur Realisierung der vom jeweils verantwortlichen Chef-Entwickler festgelegten Vorstellungen zurück. Die Grafiker versuchen, den angestrebten Look des Spiels zu erschaffen.

Das Gameplay nimmt dabei Entscheidenden Einfluss auf den grafischen Stil: „Eine Figur in einem Ego-Shooter wird anders gestaltet werden als eine Einheit in einem RTS, wobei nicht etwa nur die Anzahl der Polygone eine Rolle spielt, sondern auch die visuelle Lesbarkeit der Form bei starker Verkleinerung etc.“, wie der Lead-Artist Daniel Lieske von Ascaron die Überlegungen dazu erklärt. Obwohl Artworks als eine entscheidende Hilfe zur Entwicklung der grafischen Präsentation des Titels dienen, wird besonders aus Kostengründen an den Konzeptzeichnungen als erstes gespart, was Daniel Lieske sehr bedauert.

Der Lead-Skripter von Phenomic Game Development, Jochen Peketz, der bei Titeln wie ’Spellforce’, den dazugehörigen Add-ons sowie ’Spellforce 2: Shadow of Wars’ die Missionen und Kampagnenabläufe umsetzte, stellt wieder ganz andere, auf seinen Bereich bezogene Überlegungen zum Konzept an: „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?“ An anderer Stelle im Studio schreiben Autoren dazu an der Story, die den Spieler während des Voranschreitens nach erfolgreich absolvierten Missionen die Veränderungen plausibel erscheinen lässt. Dabei achten sie während der Entwicklung jedoch darauf, dass beispielsweise nicht unnötig lange Dialoge den Spielspaß bremsen. Ein Leveldesigner wiederum lässt sich anfangs hingegen oft von Konzeptzeichnungen inspirieren, denn jedes Setting und Genre erfordert verständlicherweise ein eigenes Design der Spielwelt, wie der Level-Designer und Programmierer Thomas Seufert diesen Entscheidungsprozess erklärt. Komponisten wie Jason Hayes (’World of WarCraft’) suchen schon sehr früh das Gespräch mit allen beteiligten Entwicklern. Bevor sie auch nur die erste Note aufgeschrieben haben, können sie so schon im Voraus Entscheidungen darüber treffen, wie die Musik in das Spiel später eingebunden werden soll.

Die Insider
Man sieht, dass vor der eigentlichen Entwicklungsarbeit eine Vielzahl an Überlegungen in das große Spielkonzept einfließt. Was daraus praktisch gemacht wird und wie die Arbeit der beteiligten Entwickler in ihren unterschiedlichen Disziplinen aussieht, davon können natürlich am Besten die Eingeweihten selbst erzählen. Deshalb haben wir verschiedene Vertreter deutscher Entwicklerstudios befragt.