Eurogamer Create: Solar System

Die erste Zeit- und Budgetplanung betritt die Pre-Production-Phase, also die also nach der Erstellung eines Treatments/Grobkonzepts und bis das Game Design Dokument fertig ist. In dieser Phase entstehen neben dem Game-Konzept (Game-Design-Dokument) die verschiedenen Voraussetzungen (Requirements) für die Produktion und eben der eigentliche Game Plan (Zeit, Personal und Budget). Die Voraussetzungen werden dabei von den unterschiedlichen Leads mitgestaltet und sorgen dafür, das man zielgerichtet entwickeln und spätere Probleme zielgerichtet lösen kann.

Auf das Game-Design-Dokument sind wir ja schon im letzten Special näher eingegangen. Heute soll es um die Planung gehen. Je nach Vorgehensweise werden für jede Aufgabe Mann-Tage angegeben, die auf die verschiedenen Abteilungen verteilt werden. Zwischen den einzelnen Bestandteilen der Entwicklung, also eingeplanten Features, vorhandenen Ressourcen, angesetzter Zeit und der finalen Qualität, besteht ein enger Zusammenhang. Zu Beginn legt man diese basierend auf Erfahrungen, dem Game-Design-Dokument und dem Input aus dem Team erst einmal fest. Wenn sich dann im Laufe der Entwicklung einzelne Bereiche ändern, muss der Zeitplan natürlich entsprechend angepasst werden.

Soll zum Beispiel nachträglich ein Koop-Modus eingebaut werden, erweitert sich das Feature-Set und man benötigt entweder mehr Ressourcen oder mehr Zeit, um die angestrebte Qualität zu erreichen. Dabei kann es auch vorkommen, dass die Entwicklungszeit verlängert werden muss, um die Qualität zu erreichen. Diese Abhängigkeiten machen es schwer, ohne weitreichende Erfahrungswerte frühzeitig einen Releasetermin zu verkünden. Deshalb wird dieser oft erst recht spät in der Entwicklung publik gemacht. Große Publisher wie Electronic Arts, Ubisoft und Activision besitzen oft so eingespielte Teams, dass sie einen Titel recht pünktlich veröffentlichen können, während Ubisoft in letzter Zeit mit der Verschiebung des jüngsten Splinter Cells und den großen Fragezeichen hinter Beyond Good & Evil 2, I am Alive und Ghost Recon: Future Soldier einige Rückschläge verkraften musste.

Einer der wichtigsten Faktoren bei der Entwicklung ist aber noch immer das Budget. Dieses ist von den zu erwartenden Verkaufszahlen abhängig. Bei der Berechnung werden oft auch noch das Marketing und das eigentliche Packaging mit eingerechnet. Wenn ein Titel also zehn Millionen in der Produktion kostet, muss er mit weiteren drei bis vier Millionen Marketing und einer Million Packaging und Versand mindestens eine Million Stück verkaufen, um wirklich rentabel zu sein. Durch die steigenden Produktionskosten ist es nicht verwunderlich, dass sich viele Publisher auf bekannte Marken konzentrieren, weil diese viel leichter zu planen sind. In der Bildergalerie findet ihr ein paar Beispiele von Grobplanungen und auch zu detaillierteren Planungen. Zum Beispiel das Design eines Levels. Wie viele Elemente werden diese Pläne anhand der Abhängigkeiten ständig angepasst. Als Producer muss man also die ganze Zeit mit Features, Zeit, Ressourcen und dem Budget jonglieren. Kein einfacher Job.

of

Caption

Attribution

Wie oben erwähnt, handelt es sich bei Scrum um eine iterative, agile Entwicklungsmethode, die recht gut zu der Spieleentwicklung passt. Der Grund: Da es bei Spielen weiche Qualitätskriterien wie den Spielspaß gibt, muss dieser ständig anhand von Prototypen überprüft werden. In der Scrum-Technik gibt es kurze, sogenannte Sprints, die einzelne Teams, bestehend aus Artists, Designern und Programmierern, auf unterschiedliche Einzelfeatures ansetzen. Zum Beispiel ein funktionierendes Hauptmenü, das Schießen mit einer Waffe oder die Sprung-Funktion. Am Ende der Sprint-Phase (zwei bis vier Wochen) gibt es ein testbares Ergebnis, das im Idealfall direkt im Spiel dargestellt wird. Dadurch werden nicht nur Probleme relativ früh erkannt, sondern können in der nächsten Sprint-Phase auch relativ schnell gelöst werden.

Zum ersten Mal wurde die Grundidee zu diesem System von den zwei Japanern Hirotaka Takeuchi und Ikujiro Nonaka 1986 formuliert. Sie verglichen ihren Ansatz mit der Arbeit eines Rugby-Teams. Um dort auf dem Spielfeld voranzukommen, muss der Ball immer wieder nach hinten gepasst werden. Die Bezeichnung Scrum wurde aber erst von 1991 von den Autoren DeGrace and Stahl in „Wicked Problems, Righteous Solutions" definiert. Sie nahmen den Begriff aus der Rugby-Analogie, die Takeuchi und Nonaka verwendeten. 2001 wurde die Technik dann von Schwaber und Beedle im Buch „Agile Software Development with Scrum" auch einem größeren Publikum bekannt. Seitdem wird sie in immer mehr Entwicklungsteams angewandt.

Im Grunde liefert Scrum ein Grundgerüst für die Softwareentwicklung mit festgelegten Rollen. Über allem schwebt der Scrum-Master. Er ist praktisch ein reiner Projektmanager und kümmert sich allein um die Abläufe. Außerdem gibt es sogenannte Product-Owner, meistens externe Producer, Lizenzinhaber oder in seltenen Fällen auch mal ein Game Designer. Sie legen zusammen mit dem Scrum-Master Ziele fest und sorgen dafür, dass die wichtigsten Rahmenbedingungen eingehalten werden. Und es gibt natürlich das Team, das auf einzelne Scrum-Teams verteilt wird.