Login

Passwort vergessen?

Konto erstellen


N-Zyklopädie

< zurück

Die Videospielbranche - Infos über Jobs und Entwicklungsschritte

03.03.2006

Wir alle sind passionierte Videospieler und konsumieren eine bestimmte Anzahl von Software im Jahr. Doch nur die wenigsten wissen wirklich, wie die Entwicklung eines Spiels vonstatten geht. Was ist die Basis eines Spiels? Was macht eigentlich der Producer? Wie sieht der Job eines Spieletesters aus und was braucht man für Qualifikationen? Was unterscheidet eine Alpha Version von einer Betaversion? Und warum brauchen Konsolenspiele eigentlich keine Patches und kommen im Vergleich zu PC Spielen größtenteils fehlerfrei auf den Markt?

 

Diese und viele andere Fragen möchte ich gerne mit diesem Artikel beantworten. Wieso ich das kann? Nun, ich habe das Glück seit nunmehr fast 6 Jahren als professioneller Tester und Lead Tester für Konsolenspiele zu arbeiten. Mittlerweile habe ich fast 30 Spiele getestet, für sämtliche Plattformen von Gameboy Color bis Xbox, von PSone bis GameCube. Dabei habe ich nicht nur viel über den Job als Tester, sondern auch viel über sämtliche Entwicklungsschritte bei der Herstellung von Videospielen gelernt.

 

Von der Idee zum Spiel. Was sind die ersten Schritte?

Wenn ein Publisher ein neues Spiel entwickeln möchte, gibt es zwei Möglichkeiten. Entweder man entwirft ein eigenes Projekt und beauftragt ein internes oder ein externes Studio mit der Entwicklung. Die zweite Möglichkeit ist, ein dem Publisher angebotenes Projekt zu übernehmen. Denn viele Developer entwickeln frühe Versionen von ihren Ideen bevor sie einen Publisher gefunden haben. Diese werden an mögliche Kooperationspartner verschickt und dann von diesen evaluiert und gegebenenfalls für lukrativ bewertet.

Gehen wir mal davon aus, dass ein Publisher eine eigene Idee in die Tat umsetzen möchte. Da stellt sich zunächst die Frage, ob es sich dabei um eine Lizenzverwertung handelt, wie zum Beispiel ein Spiel zu einem Film oder um eine komplett eigene Entwicklung. Handelt es sich um Lizenzentwicklung, ist die Kreativität der Entwickler in der Regel eingeschränkt, da ein Publisher meistens nur möglichst wenig Inhalte lizenzieren möchte, um Kosten zu sparen. Ferner bestehen die meisten Filmstudios etc. darauf, die Software selbst zu überprüfen. Entspricht diese dann nicht den eigenen Vorstellungen, kann ein Projekt auch schon mal gestoppt werden. Den Lizenzgebern geht es aber weniger um die spielerische Qualität, sondern viel mehr um die exakte und korrekte Darstellung der lizenzierten Inhalte. Deshalb ist die Qualität vieler Lizenzspiele auch nicht so berauschend.

Egal ob Lizenzverwertung oder kompletter Eigenentwurf, zu Anfang steht immer die Frage, um Bud Spencer zu zitieren: „Was ist denn mit den Kohlen?". Ein Gesamtbudget für das Projekt wird festgelegt. Verbunden damit werden der Zeitrahmen für die Entwicklung und die Systeme, auf denen das Spiel erscheinen soll, definiert.

Mit diesen Informationen im Hinterkopf schreibt der Lead Designer oder der Director des Spiels das so genannte „Game Design Document". Im Prinzip ist dieses Dokument das Drehbuch eines Spiels und beinhaltet möglichst genaue Informationen zur Story, Levelstruktur, technischer Umsetzung etc. eines Spiels. Natürlich sind zu der Zeit auch die Designer schon dabei „Artworks" zu entwerfen und diese in das Drehbuch zu integrieren. Anhand des Dokuments wird dann mit der Entwicklung begonnen. Bei aufwendigeren Projekten kann so ein Game Design Document schon mal mehrere hundert Seiten umfassen. Allerdings ist es auch immer so, dass viele Inhalte sich erst während der eigentlichen Entwicklung des Spiels ergeben, weil neue Ideen zugefügt werden oder geplante Inhalte doch nicht umsetzbar sind. Das Game Design Document ist also der Leitfaden der Entwicklung, nicht aber eine zu 100% exakte Vorgabe.

Anhand des Dokuments werden dann „Milestones" definiert, d.h. Punkte in der Entwicklung festgelegt, die bis zu einem bestimmten Zeitpunkt erreicht werden müssen. Grundsätzlich unterscheidet man drei Phasen einer Entwicklung, wobei diese meistens nochmals untergliedert werden: Alpha, Beta und Gold.

Bevor ich auf die einzelnen Entwicklungsphasen zu sprechen komme, muss an dieser Stelle ein wichtige Person vorgestellt werden: Der Producer

 

Was macht eigentlich ein Producer?

Wir alle haben sicherlich schon gebannt den Abspann eines Spiels angesehen und viele haben sich gefragt was macht eigentlich Shigeru Miyamoto, wenn er bei einem Mario Spiel als Producer genannt wird? Zunächst einmal ist ein Producer kein Game oder Level Designer, wie es oftmals fälschlicherweise angenommen wird! D.h. Herr Miyamoto wird nicht selbst da sitzen und Levels für Mario oder ein Dungeon für ein Zelda Spiel entwerfen.

Der Producer ist vielmehr der Projektleiter einer Spielentwicklung. Der Producer ist die Schnittstelle zwischen Marketing, Qualitätssicherung, Chefetage und Programmierteam einer Firma. Die Aufgabe besteht darin, die Milestones zu definieren und zu überprüfen. Er überwacht die Qualität eines Projekts und entscheidet, wenn die Zeit und das Budget knapp werden, welche Features noch umgesetzt werden bzw. weggelassen werden. Natürlich wird ein Producer auch Ideen zum Spiel beisteuern, aber das ist in der Regel nicht die wichtigste Aufgabe!

 

Welche Entwicklungsphasen durchläuft ein Spiel bis zur Fertigstellung? Und warum brauchen Konsolenspiele eigentlich keine Patches?

Wie oben bereits erwähnt unterscheidet man drei Entwicklungsphasen: Alpha, Beta und Gold. Bei Konsolenspielen kommt eigentlich noch eine vierte Phase vor der Goldphase hinzu und zwar die Submission.

Während der Alphaphase werden rudimentäre Spielinhalte zusammengefügt. Die „Engine", welche das Herz eines Games darstellt, wird programmiert und modifiziert, um die Inhalte umsetzen zu können. Animationen und Texturen werden erstellt und langsam vom Level Designer zusammengefügt. In der Alphaphase sind nur Bruchstücke eines Levels spielbar und nur wenig ist komplett. Deshalb lasst euch nicht hinters Licht führen, wenn mal wieder ein Publisher oder eine Zeitschrift bei einem Spiel, was kurz vor einem Release steht, behaupten, dass es sich bei der gezeigten Version noch um eine frühe Alphaversion handelt und das noch viel bis zum Launch verbessert wird. Solche Aussagen sind meistens schlichtweg falsch, da die letzten Wochen nur für den Feinschliff verwendet und nur in den seltensten Fällen tatsächlich Alphaversionen der Öffentlichkeit präsentiert werden. Es kann höchstens sein, dass man mal einen Level zu Demozwecken soweit fertig stellt, dass man das Spiel zeigen kann.

In der Betaphase ist das Spiel so weit zusammengefügt und das Testen der Software kann beginnen. Wie das Testen abläuft, werde ich im Anschluss erläutern, wenn ich auf den Job eines Testers eingehe. In dieser Phase sind Strukturen definiert, d.h. größere Veränderungen sind kaum noch möglich. Die Konzentration liegt auf dem Balancing, Bugs fixen (Fehler im Spiel werden behoben), Lokalisation und Einhaltung der Technical Requirements (TCR). Diese TCR's sind quasi ein mehrere hundert Seiten dickes Regelwerk, was von Nintendo, Microsoft und Sony vorgegeben wird. Das beinhaltet alles von technischen Bestimmungen, wie z.B. welcher Code auf einer DVD wo gebrannt sein muss bis hin zu vorgegebenen Fehlermeldungen, was ein Spiel drauf haben muss, bevor es produziert werden darf!

Ist die Entwicklung des Spiels soweit abgeschlossen wird eine Version erstellt, die dann zu dem jeweiligen Konsolenhersteller in eine „Submission" geschickt wird. D.h. Microsoft, Sony und Nintendo verlangen eine fertige Version des Spiels, die dann von ihnen aufs Genaueste überprüft wird. Nur wenn alle relevanten Technical Requirements eingehalten wurden und auch sonst alles fehlerfrei läuft, darf das Spiel produziert werden. Deshalb kommen Konsolenspiele auch ziemlich fehlerfrei auf den Markt. Bei PC Spielen gibt es eine solche Kontrolle nicht. Deshalb sind diese oft auch fehlerhaft und müssen durch Patches ausgebessert werden.

Hat die Software die Prüfung bei den Konsolenherstellern bestanden, erreicht das Game den so genannten „Gold" Status und darf nun produziert werden.

 

Was macht eigentlich ein Tester? Welche Qualifikationen braucht man dafür?

Sobald ein Spiel die Beta Phase erreicht, wird es im großen Stil getestet. Die Beta Phase dauert je nach Umfang eines Projekts und Größe des Entwicklerteams in der Regel 1 bis 6 Monate. In dieser Zeit müssen möglichst alle Bugs im Spiel gefunden werden und vieles mehr.

Ein Testeralltag sieht dann meistens wie folgt aus: Der Lead Tester informiert sich über neue Versionen eines Spiels und bekommt Instruktionen direkt vom QA Manager, dem Producer und auch von den Entwicklern. Meistens werden mit jeder neuen Version auch Infos zum aktuellen Fertigungsstand des Projekts mitgeteilt. Das erspart nämlich sehr viel Arbeit, wenn man weiß, dass man z.B. einen bestimmten Level gar nicht testen braucht, weil die Entwickler nicht daran gearbeitet haben. Der Lead Tester spricht sich nun mit anderen Testern ab und bestimmt wer welche Aufgabe übernimmt.

Dazu wird zunächst mal der so genannte „Bug Report" angeschaut. In diesem Report, der online abrufbar ist, damit Entwickler und Kooperationspartner auf der ganzen Welt jederzeit einsehen können, werden alle gefundenen Fehler dokumentiert. Eine möglichst genaue Dokumentation mit vielen unterschiedlichen Informationen sind notwendig, damit die Entwickler ohne groß suchen zu müssen, den Bug beheben können. Zu den Infos im Bug Report gehören: Versionsnummer, Levelangabe, Reproduktionsrate des Bugs (Häufigkeit des Auftretens), genaue Bugbeschreibung (wie kann man den Fehler reproduzieren), Art des Bugs (z.B. Kollisionsabfrage, Clipping Fehler, TCR, Lokalisation etc) und vieles mehr. Dann werden Screenshots und gegebenenfalls auch Videos beigefügt, um die Bugsituation genau festzuhalten.

Am wichtigsten sind aber die Angaben zur Bugklassifikation. Man unterscheidet dabei in der Regel vier Bug-Prioritäten:

A Bug: Alles, was ein Weiterspielen verhindert ist ein A Bug. Das können Abstürze und Freezes sein, aber auch wichtige Items, die fehlen oder Ereignisse, die einfach nicht getriggert werden. Alle TCR Bugs sind natürlich auch A Bugs.

B Bug: Sind gröbere Fehler, die das Weiterspielen behindern, aber nicht unmöglich machen. Dazu gehören gröbere Grafikfehler, schlechte Kollisionsabfragen, Logikfehlern bei Rätseln, eine zu schlechte Framerate etc.

C Bug: Sind kleinere Bugs, die je nach vorhandener Zeit korrigiert werden wie kleinere Clipping Fehler, matschige Texturen, Rechtschreibfehler etc.

D Bug: Unter D Bugs fasst man oft alles zusammen, was nicht unbedingt Fehler sind wie z.B. Verbesserungsvorschläge.

 

Bevor ein Tester mit seiner Arbeit beginnt, checkt er zuerst den Bug Report. Wenn ein Entwickler einen Bug bearbeitet hat, so wird dies an beigefügten Kommentaren erkenntlich. Außerdem wird der Status auf „fixed - to be checked" gesetzt, was so viel heißt, dass der Programmierer den Bug bearbeitet hat und nun der Tester aufgefordert ist zu checken, ob das Problem tatsächlich behoben ist. Solche „tbc bugs" müssen möglichst schnell nachgesehen werden. Außerdem ist es wichtig sich immer wieder einen Überblick über die bereits eingetragenen Bugs zu machen, damit keine doppelt eingetragen werden. In einer Datenbank von teilweise über 1000 Einträgen ist das unablässig.

Nachdem der Bug Report bearbeitet ist, beginnt das eigentliche Testen, wobei die meisten Aufgaben zugeteilt werden, d.h. z.B. einer prüft bearbeitete Bugs nach, der nächste achtet auf die Framerate in bestimmten Levels, ein anderer widmet sich den Fehlermeldungen im Spiel, während ein weiterer Tester die Physik eines Fahrzeuges ausprobiert. Die Aufgaben sind mannigfaltig und nur durch eine gute Organisation zu bewältigen.

Grundsätzlich unterscheidet man vier Arten von „Testing":

 

1) Gameplay Testing: Das ist wohl die angenehmste Aufgabe. Dabei wird das Spiel von mehreren Testern gezockt. Es wird auf Fehler geachtet, die mit dem Gameplay zu tun haben. Das können Logikfehler bei Rätseln sein oder eine schlechte Kollisionsabfrage bei bestimmten Gegenständen etc.

 

2) Balancing: Beim Balancing wird herausgefunden, ob das Spiel einen angemessenen Schwierigkeitsgrad hat. Das ist vor allem bei Rollenspielen etc. sehr aufwendig, weil man quasi jedes Item, jede Waffe und Rüstung auf Stärke und Funktionalität prüfen muss. Kann der Spieler das Spiel schaffen, obwohl er z.B. Item X nicht bekommen hat? Wird das Spiel nicht zu leicht, wenn der Spieler alles gefunden hat? Wie führt man den Spieler zu den wichtigen Items ohne die Verstecke zu offensichtlich zu machen?

 

3) Lokalisation: Dabei wird geprüft, ob auch wirklich alle Texte von Nachrichten im Spiel über Fehlermeldungen der Hardware bis hin zu Menü-Angaben korrekt in alle Sprachen übersetzt wurden.

 

4) Technical Requirements: Das ist sicherlich die undankbarste und schwierigste Aufgabe eines Testers. Wie gesagt, wenn nur eine relevante Vorgabe nicht eingehalten wurde, darf das Spiel nicht produziert werden! Viele der Technical Requirements sind aber sehr technisch und nur von den Programmierern selbst nachprüfbar.

 

Die wichtigste Erkenntnis ist aber, dass Testen nichts mit Spielen zu tun hat! Nur in den seltensten Fällen kommt es mal vor, dass ein Tester ein Spiel am Stück durchspielen soll. Meistens hat man sehr genaue Aufgaben, die mitunter sehr langweilig sind. Wer mal ein riesiges Areal mit Blick auf den Boden auf der Suche nach Stellen ohne Kollisionsabfrage, wo man aus dem Level fallen kann, abgegangen ist, der weiß wovon ich spreche! Man muss auch schnell lernen, Bugs zu provozieren. Viele der Fehler treten nur unter den kuriosesten Umständen auf. So hatte ich in der Dreamcast Version von Rainbow Six Rogue Spear mal einen Crash, der nur dann auftrat, wenn ich einen bestimmten Gegner getötet habe, mich dann an einer bestimmten Stelle verschanzt habe, bis ein weiterer Gegner den Bereich betrat. Wenn dieser ein paar Meter weiterging crashte das Spiel. Sobald meine Position aber nur wenig anders war oder ich die Gegner anders ausschaltete, trat dieser Bug nicht auf.

Man braucht also sehr viel Geduld und die Fähigkeit, sich in die Situation rein denken zu können. Nur wenn man den Umstand, der zu dem Bug geführt hat, genau beschreiben kann, sind die Entwickler in der Lage, diesen Fehler zu beheben. In einem Egoshooter kann es z.B. zu einem Crash kommen, wenn man an einer bestimmten Stelle eine bestimmte Waffe einsetzt und gleichzeitig dabei springt. Solche Sachen findet man natürlich oft nur zufällig heraus. Aber ein guter Tester muss sich dessen bewusst sein und die Zufälle provozieren.

Außerdem muss man immer daran denken, dass Spieler vielleicht verrückte Dinge ausprobieren abseits des normalen Weges, die dann eventuell zu Folgefehler führen können.

Folgende Qualifikationen braucht man als Tester:

 

1) Geduld

 

2) Teamfähigkeit, da man nur selten für sich alleine arbeitet

 

3) Gute Englischkenntnisse in Wort und Schrift. Fast sämtliche Kommunikationen und der Bug Report erfolgen in Englisch!

 

4) Technisches Grundverständnis: Man sollte wissen, was die einzelnen Plattformen in etwa leisten können, und welche Effekte was bewirken wie z.B. Bump Mapping. Außerdem sollten Fachbegriffe wie Kollisionsabfrage, Clipping etc bekannt sein.

 

5) Gute Officekenntnisse, vor allem Word, Excel

 

6) Flexible Arbeitszeiten, weil man kurz vor Release auch mal abends sehr lange oder auch am Wochenende arbeiten darf.

 

7) Umfassendes Wissen der Videospielbranche. Vor allem wichtig ist, über alle Genres bescheid zu wissen, um das zu testende Projekt einordnen zu können. Ein wirklich guter Tester und natürlich ein Lead Tester muss in der Lage sein, wenn z.B. ein Rätsel ein wenig unlogisch erscheint gleich einen Lösungsvorschlag mitzuliefern. Wichtig ist auch, die Qualität des Produktes beurteilen zu können.

 

8) Abgeschlossenes Abitur wird oftmals vorausgesetzt

 

Viele weitere Fähigkeiten erlernt man mit der Zeit und dann kann es auch sein, dass sich das Tätigkeitsfeld erweitert. So habe ich auch schon an Handbüchern für Spiele mitgeschrieben, Games für Presse und Partner präsentiert etc.

Wenn ihr euch nun überlegt einen Job als Tester, Producer oder was auch immer in der Gamesbranche anzustreben, dann könnt ihr Jobs auf der Webseite der jeweiligen Publisher finden oder ihr geht auf die Seite www.usf3.de

 

 

Ich hoffe, ich konnte euch hiermit einen tieferen Einblick in die Entwicklung von Videospielen gewähren und mit Infos versorgen, die euch bisher unbekannt waren. Natürlich gibt es auch noch viele andere Dinge, über die man berichten könnte. Wenn ihr also Fragen habt, dann schickt diese doch einfach an unseren neuen N-Vestigativ Bereich. Dann werden wir sie sicherlich bald beantworten.


Aktuell auf 10doTV

10do Show

Oktober-Ausgabe: Die Metroid-Reihe

RSS-FeedDie 10do Show in iTunes