Gantt-Diagramm Spieleentwicklung: vom Vertical Slice zu Gold
Bearbeitbares Gantt-Diagramm für die Spieleentwicklung: Prototyp, Vertical-Slice-Gate, Code, Grafik und Audio parallel, Alpha, Beta, Wartezeit der Plattform-Zertifizierung und Gold mit Abhängigkeiten und Meilensteinen.
Was ist Gantt-Diagramm spieleentwicklung: vom vertical slice zu gold?
Ein Spiel wird anders geplant als andere Software, weil sein größtes Risiko nicht ist, ob es sich bauen lässt, sondern ob es Spaß macht. Das kann kein Zeitplan wegplanen, also setzt der Plan eine Entscheidung früh an: ein kleines, fertiges Stück des Spiels, der Vertical Slice, der Look, Gefühl und Kernschleife in annähernd finaler Qualität zeigen muss. Bis der Slice freigegeben ist, sollten nur wenige Leute etwas Teures bauen. Danach können Grafik, Audio und Code in voller Größe laufen, und die Änderung der Kernidee wird teuer. Ein Zeitplan zeigt, wie viel Arbeit hinter diesem Gate wartet und wo eine späte Änderung wehtäte.
Die Vorlage hat fünf Gruppen: Konzept und Prototyp, Code und Design, Grafik und Audio, Test und Zertifizierung sowie Veröffentlichung. „Spielkonzept und Säulen schreiben“ (3 Arbeitstage) ist die einzige Startaufgabe. „Greybox-Prototyp bauen“ (8) folgt darauf, und „Art-Stil und Concept Art entwickeln“ (7) beginnt gleichzeitig, sodass der Look erkundet wird, während das Spielgefühl getestet wird. „Prototyp playtesten“ (3) liegt vor „Vertical Slice bauen“ (12), das 3 Tage nach dem Start von „Assets für den Vertical Slice erstellen“ (8) beginnt, mit einer Start-zu-Start-Verknüpfung, denn die ersten Assets werden früh gebraucht, aber nicht alle. „Vertical Slice freigegeben“ ist das erste Gate und wartet auf beides.
Nach dem Gate fächert sich die Arbeit auf. „Kern-Gameplay-Systeme bauen“ (20) beginnt, und „Level bauen und abstimmen“ (18) startet 6 Arbeitstage später, sodass das Leveldesign die Systeme nutzt, sobald sie brauchbar werden. „Produktionsgrafik und Animationen erstellen“ (36) und „Musik komponieren und Soundeffekte aufnehmen“ (15) beginnen ebenfalls am Gate; das ist die gefahrlose Überlappung im Spiel, denn Inhalte entstehen neben dem Code, der sie tragen wird. „Alpha erreicht“ wartet auf die Systeme und die Level, nicht auf die Grafik. Inhalte entstehen auch zur Alpha noch, und „Alpha-Bugs beheben und Balancing“ (10) läuft daneben. „Beta erreicht“ wartet auf diese Korrekturen sowie auf Grafik und Audio. In den Beispielzahlen ist die Grafik die längere Kette: Sie endet 2 Arbeitstage nach den Alpha-Korrekturen, sodass die Grafik, nicht der Code, das Beta-Datum bestimmt.
Das Ende des Plans ist eine Wartezeit, die Sie nicht kontrollieren. „Beta-Testrunde durchführen“ (8) und „Beta-Bugs beheben und Feinschliff“ (10) führen zu „Release Candidate einreichen“ (1), und „Plattform-Zertifizierung“ (10) ist die eigene Prüfung des Builds durch die Plattform. Ersetzen Sie die Dauer durch das, was die Plattform nennt, und behalten Sie „Zertifizierungsbefunde beheben und erneut einreichen“ (3) als Puffer, auch wenn Sie erwarten, beim ersten Mal zu bestehen. Darauf folgt „Gold Master freigegeben“, und „Launch-Tag“ schließt den Plan nach 94 Arbeitstagen ab. „Store-Seiten und Launch-Trailer vorbereiten“ (8) beginnt zur Beta, da Trailer-Material einen Build braucht, der fertig aussieht, und hat Luft. Alle Dauern sind Beispielwerte; ersetzen Sie sie durch die Schätzungen Ihres eigenen Teams.
Ein Zeitplan plant die Arbeit. Er besteht keine Zertifizierung, klärt keine Musik-, Schrift- oder sonstigen Lizenzen und macht das Spiel nicht spaßig. Ein Spiel unterscheidet sich auch darin von einem gewöhnlichen Software-Release, was spät teuer zu ändern ist: eine neue Mechanik nach dem Slice oder ein Levellayout, nachdem die Grafik darauf aufbaut, kostet weit mehr als ein Bugfix zur Beta. Für einen Plan, der nur aus Code besteht, gibt es die Vorlage für das Softwareprojekt, für die Release-Schritte einer Anwendung die Vorlage für den Software-Release und für denselben Gedanken in der Filmproduktion die Vorlage für die Animationsproduktion. Die Methode hinter einem Plan mit Gates, gemeinsamen Vorlaufzeiten und festem Termin beschreibt der Leitfaden zu Vorlaufzeiten bis zum Veröffentlichungstermin.
Was dieses Flussdiagramm abdeckt
In dieser Vorlage
- Fünf Gruppen, Konzept und Prototyp, Code und Design, Grafik und Audio, Test und Zertifizierung sowie Veröffentlichung, mit 22 Aufgaben und fünf Meilensteinen: „Vertical Slice freigegeben“, „Alpha erreicht“, „Beta erreicht“, „Gold Master freigegeben“ und „Launch-Tag“.
- Ein kreatives Gate: „Vertical Slice freigegeben“ wartet auf „Vertical Slice bauen“ und „Assets für den Vertical Slice erstellen“, bevor die großen Produktionsaufgaben beginnen.
- Grafik, Audio und Code parallel: „Produktionsgrafik und Animationen erstellen“, „Musik komponieren und Soundeffekte aufnehmen“ und „Kern-Gameplay-Systeme bauen“ beginnen alle am Gate, wobei „Level bauen und abstimmen“ 6 Arbeitstage nach dem Start der Systeme startet.
- Eine Trennung zwischen Alpha und Beta: „Alpha erreicht“ wartet auf Code und Level, während „Beta erreicht“ auch auf Grafik und Audio wartet.
- Eine Zertifizierungswartezeit: „Release Candidate einreichen“, „Plattform-Zertifizierung“ und „Zertifizierungsbefunde beheben und erneut einreichen“ liegen zwischen Beta und „Gold Master freigegeben“.
Wann Sie diese Vorlage verwenden sollten
- Sie planen ein Spiel vom Prototyp bis zum Launch und brauchen einen Zeitplan, der Code, Grafik und Audio zusammenhält.
- Sie wollen sehen, ob Code, Grafik oder die Zertifizierungswartezeit das Launch-Datum bestimmt und wie viel Spielraum der Rest hat.
- Ein Publisher oder eine Plattform erwartet Meilensteine namens Alpha, Beta und Gold, und Sie wollen sie als terminierte Gates.
- Sie entwickeln regelmäßig Spiele und wollen einen Standardplan, den Sie für jedes Projekt anpassen.
Der Plan, Aufgabe für Aufgabe
Alle Aufgaben des Diagramms mit ihrer Dauer in Arbeitstagen und dem, worauf sie warten. Eine Abhängigkeit ist eine Schrittnummer; SS bedeutet Start-zu-Start, FF Ende-zu-Ende, +n eine Verzögerung in Arbeitstagen.
| # | Aufgabe | Gruppe | Arbeitstage | Abhängig von |
|---|---|---|---|---|
| 1 | Spielkonzept und Säulen schreiben | Konzept und Prototyp | 3 | |
| 2 | Greybox-Prototyp bauen | Konzept und Prototyp | 8 | 1 |
| 3 | Prototyp playtesten | Konzept und Prototyp | 3 | 2 |
| 4 | Vertical Slice freigegeben | Konzept und Prototyp | Meilenstein | 5, 9 |
| 5 | Vertical Slice bauen | Code und Design | 12 | 3, 9SS+3 |
| 6 | Kern-Gameplay-Systeme bauen | Code und Design | 20 | 4 |
| 7 | Level bauen und abstimmen | Code und Design | 18 | 6SS+6 |
| 8 | Art-Stil und Concept Art entwickeln | Grafik und Audio | 7 | 1 |
| 9 | Assets für den Vertical Slice erstellen | Grafik und Audio | 8 | 8 |
| 10 | Produktionsgrafik und Animationen erstellen | Grafik und Audio | 36 | 4 |
| 11 | Musik komponieren und Soundeffekte aufnehmen | Grafik und Audio | 15 | 4 |
| 12 | Alpha erreicht | Test und Zertifizierung | Meilenstein | 6, 7 |
| 13 | Alpha-Bugs beheben und Balancing | Test und Zertifizierung | 10 | 12 |
| 14 | Beta erreicht | Test und Zertifizierung | Meilenstein | 10, 11, 13 |
| 15 | Beta-Testrunde durchführen | Test und Zertifizierung | 8 | 14 |
| 16 | Beta-Bugs beheben und Feinschliff | Test und Zertifizierung | 10 | 15 |
| 17 | Release Candidate einreichen | Test und Zertifizierung | 1 | 16 |
| 18 | Plattform-Zertifizierung | Test und Zertifizierung | 10 | 17 |
| 19 | Zertifizierungsbefunde beheben und erneut einreichen | Test und Zertifizierung | 3 | 18 |
| 20 | Gold Master freigegeben | Veröffentlichung | Meilenstein | 19 |
| 21 | Store-Seiten und Launch-Trailer vorbereiten | Veröffentlichung | 8 | 14 |
| 22 | Launch-Tag | Veröffentlichung | Meilenstein | 20, 21 |
So funktioniert es
Festlegen, was der Slice beweisen muss
Behalten Sie „Vertical Slice freigegeben“ als Gate für die großen Ausgaben. Halten Sie in den Notizen der Aufgabe fest, was er zeigen muss, und kürzen oder verlängern Sie „Vertical Slice bauen“ auf die Größe des Slice, den Sie tatsächlich beurteilen werden.
Die parallelen Stränge bemessen
Legen Sie „Kern-Gameplay-Systeme bauen“, „Level bauen und abstimmen“ und „Produktionsgrafik und Animationen erstellen“ nach Ihren eigenen Schätzungen fest und lesen Sie ab, welche zuletzt endet. Sagen Sie mit der Start-zu-Start-Verknüpfung bei den Leveln, wie weit die Systeme voraus sein müssen.
Festlegen, was Alpha und Beta bedeuten
Entscheiden Sie, was bei „Alpha erreicht“ und „Beta erreicht“ für Ihr Projekt vorliegen muss, und passen Sie die Abhängigkeiten an. Braucht Ihre Alpha die Grafik, fügen Sie diese Verknüpfung hinzu.
Die Zertifizierungswartezeit ersetzen
Legen Sie „Plattform-Zertifizierung“ nach den Angaben der Plattform fest. Behalten Sie „Zertifizierungsbefunde beheben und erneut einreichen“ im Plan, auch wenn Sie mit einem Bestehen rechnen.
Das Release-Datum prüfen
Steht der Launch fest, geben Sie „Spielkonzept und Säulen schreiben“ ein festes Startdatum und „Launch-Tag“ ein festes Startdatum. Der Plan beginnt am frühesten festen Start und wird vorwärts geplant: Passt die Arbeit nicht hinein, markiert das Diagramm „Launch-Tag“ mit einem Konflikt und nennt das früheste Datum, das die Abhängigkeiten erlauben.
Verantwortliche eintragen, teilen und exportieren
Tragen Sie die verantwortliche Person jeder Aufgabe unter „Personen“ ein, teilen Sie das Diagramm als Link mit Publisher oder Team und exportieren Sie ein PDF oder PNG für Reviews.
Häufig gestellte Fragen
Wie unterscheidet sich ein Spieleplan von einem Softwareprojektplan?
Ein Softwareplan kann meist davon ausgehen, dass das Design feststeht, sobald die Anforderungen stehen. Ein Spieleplan muss herausfinden, ob das Design funktioniert, und setzt daher „Vertical Slice freigegeben“ vor die teure Arbeit und lässt Grafik und Audio als große parallele Stränge laufen, die die Beta begrenzen. Er endet außerdem mit einer Plattformprüfung, die außerhalb Ihrer Kontrolle liegt. Besteht Ihr Projekt überwiegend aus Code, beginnen Sie mit der Vorlage für das Softwareprojekt.
Was ist der kritische Pfad in der Vorlage?
In den Beispielzahlen läuft er über den Vertical Slice, dann die Grafik, die Beta, die Beta-Runde, die Zertifizierung und den Launch. Schalten Sie unter „Ansicht“ den kritischen Pfad ein, um ihn hervorzuheben. Die Code-Kette ist einige Tage kürzer als die Grafik, sodass die Grafik „Beta erreicht“ bestimmt, bis Sie die Dauern ändern.
Mein Launch-Termin steht fest. Kann das Diagramm ihn prüfen?
Ja. Geben Sie der ersten Aufgabe ein festes Startdatum und „Launch-Tag“ ein festes Startdatum. Der Plan beginnt am frühesten festen Start und wird vorwärts geplant; ist die Kette vom Konzept bis zur Zertifizierung zu lang, markiert das Diagramm „Launch-Tag“ mit einem Konflikt. Vergleichen Sie das Enddatum mit dem Termin, den Sie brauchen.
Kann ich weitere Plattformen oder Content-Updates ergänzen?
Ja. Duplizieren Sie „Plattform-Zertifizierung“ und die Aufgabe zum erneuten Einreichen für jede Plattform, die getrennt prüft, und verknüpfen Sie jede mit „Gold Master freigegeben“. Updates nach dem Launch können ein zweiter Plan sein, der bei „Launch-Tag“ beginnt.
Ersetzt das Diagramm einen Produktions-Tracker?
Nein. Es plant die Arbeit und zeigt, wie Aufgaben voneinander abhängen. Es verwaltet keine Bugs, Asset-Listen oder Build-Nummern und klärt keine lizenzierte Musik oder Middleware. Den Fortschritt können Sie je Aufgabe markieren, aber der Fortschritt verschiebt nie Termine.