2. An Introduction to Game Design
Documentation and Project Management
tim.nuechel@stud.unibas.ch
Montag, 26. Oktober 2009 2
3. Faktoren, die einer Entwicklung
zum Verhängnis werden können
• Die Zieldefinition ist • Die Planung beruht auf
unzureichend, nicht unzureichenden
überprüfbar und zu Spezifikationen und
spezifisch. Annahmen.
• Die Ziele wurden nicht • Somit sind auch keine
verbindlich definiert und echten Kontrollen
fixiert. (Soll != Ist) möglich.
• Nicht alle notwendigen • Die Risiken in der Planung
Informationen wurden im sowie die
Vorfeld gesammelt und Rahmenbedingungen
evaluiert. wurden nur unzureichend
berücksichtigt.
• Es wurden keine
spezifischen Anforderungen • Die genauen Anforderungen
festgelegt. an Organisations- und
Prozessabläufe wurden
nicht verbindlich definiert.
Montag, 26. Oktober 2009 3
4. Warum eine
Pre-Production?
Montag, 26. Oktober 2009 4
5. Argumente für eine
Pre-Production
• Sie motiviert in der eigentlichen Produktion das
gesamte Team durch die im Vorfeld geschaffene
Transparenz, Zielorientierung und den messbaren
Fortschritt.
• Veränderungen und Anpassungen in der
Organisation während der laufenden Produktion
eines Spiels sind viel schmerzhafter als in der
Vorproduktion.
• Sie ist effektiv, weil Veränderungen im Kleinen
wahrscheinlicher sind als im Großen.
• Sie ist effektiv, weil wichtige Entscheidungen noch
nicht unter Sachzwängen gefällt werden müssen.
Montag, 26. Oktober 2009 5
6. Argumente für eine
Pre-Production
• Sie ermöglicht (überhaupt erst) die spätere
Steuerung der Produktion durch Kontrolle.
• Sie ist günstiger, weil sie eine iterative Vorbereitung
mit Wenigen bedeutet. Erst anschließend erfolgt die
Umsetzung mit Vielen.
• Sie ist rationaler, weil ein No-Go am Ende der Pre-
Production erheblich leichter fällt (Kosten,
Teammotivation).
• Sie ist rationaler, weil Entscheidungen auf Basis von
Fakten und nicht aus dem Bauch heraus getroffen
Montag, 26. Oktober 2009 6
9. Projekt Kick-Off
Kernziel-Checkliste
Definition der Prozesse Proof-of-Concept-Prototyp
Erstellung der Change Control Core-Spielmechanik
Dokumentation
Approval-Prozesse Definition der Gameplay
Zieldefinition & Vision Qualität
Statement QA-Prozesse
GUI- &
Game Design Dokument Build Prozesse Steuerungsprototyp
Art/Style Guide Version-Control & Definition der
Backup Grafikqualität
Level-/World- &
Story-Guide Konfliktmanagement Sound-Proof
Technical Design Guide Planung Game-Design Risiko-
Evaluierung
Feature Liste & Definition Umfang abgeschlossen
Beurteilung und Qualität
Technologie-Prototyp
Definition der Organisation Task- &
Ressourcenplanung Basic Toolbase
Teamstruktur abgeschlossen
Budgetierung
Projektrollen Middleware Evaluation &
Milestone Definitionen Prototype abgeschlossen
Meetings
Risiko Analyse Basis für 3D-Engine
Reporting intern/mit dem
Recruitmentplan definiert & abgeschlossen
Publisher
Marketing Technical-Backend
Kontrolle der externen abgeschlossen
Ressourcen
Konkurrenzanalyse
Technische Risiko-
Zielgruppenanalyse Evaluierung
abgeschlossen
Montag, 26. Oktober 2009 9
10. • Der kreative Prozess kann in der Pre-Production
zielorientierter erfolgen
• Sie sollte iterativ angelegt werden, so dass die
Produktion nur noch einer geradlinigen
Abarbeitung festgelegter Ziele entspricht
• Macht‘s wie der preußische General Helmut von
Moltke
„Erst wägen, dann wagen!“
Montag, 26. Oktober 2009 10
11. Das Design Dokument
Am Beispiel von Related Design und
Anno 1404
Montag, 26. Oktober 2009 11
12. Wer wird das Design
Dokument lesen?
• Designer: Sie wollen Ideen festhalten und miteinander
austauschen
• Publisher: Er will – meist in Gestalt des Producers – überprüfen,
ob Design und Produkt übereinstimmen und den Anforderungen
gerecht werden.
• Programmierer: Sie sehen das DDD als eine Sammlung von
Arbeitsaufträgen und Inhalten, die am Ende der Produktion ein
fertiges Spiel ergeben sollen.
• QA und Testing: Sie wollen alle Regeln und Inhalte des Spiels
überblicken und überprüfen, ob sie die erforderliche Qualität und
Quantität aufweisen.
• Outsourcing Partner: Sie wollen schnellen Zugriff auf alle für sie
relevanten Informationen zur Erstellung zusätzlicher Spielinhalte
(z.B. Grafiken, Missionen, Musik etc.)
Montag, 26. Oktober 2009 12
13. Was Designer wissen
sollten
Dinge die
Programmierer Hauptsätze Imperativ Bulletpoints Diagramme
mögen
Dinge die
Programmierer Nebensätze Konjunktiv Fließtext Designerprosa
hassen
Montag, 26. Oktober 2009 13
15. Regeln für ein gutes DDD
Ein nützliches DDD muss...:
• ...sich kurz fassen
• ...sein Layout vereinheitlichen
• ...Redundanzen vermeiden
• ...Begründungen von Regeln trennen
• ...Bilder, Diagramme und Flowcharts bevorzugen
• ...Imperativ statt Konjunktiv verwenden
• ...ein verbindliches Glossar enthalten
• ...ständig aktualisiert werden
Montag, 26. Oktober 2009 15
16. „Im Fall des Scheiterns wird das
DDD ein Schattendasein als
ungeliebtes Mauerblümchen fristen
und hilflos dem Chaos beiwohnen,
das unweigerlich beginnt sich
auszubreiten.“
Montag, 26. Oktober 2009 16
18. Ein Wiki hat den
Vorteil, dass...:
• ...übersichtliche Layouts • ...Einträge abonniert
leicht zu erstellen und zu werden können, sodass
verwalten sind. man bei Aktualisierungen
per Mail benachrichtigt
• ...Einträge miteinander wird.
verlinkt werden können.
• ...Einträge wie in Foren
• ...jede Version eines von jedem Nutzer
Eintrags jederzeit wieder kommentiert werden
hergestellt werden kann. können.
• ...alle Versionen eines • ...Bilder, Galerien, Musik
Eintrags miteinander und Filme leicht zu
verglichen werden integrieren sind.
können.
Montag, 26. Oktober 2009 18
19. Anno 1404 Standard-
Designeintrag
• Name • Regeln
• Verantwortliche • Balancing
• Status • FAQ
• Definition • Implementierungs
details
• Kurzbeschreibung
• Schaubilder
Montag, 26. Oktober 2009 19
20. So nicht:
„Schiffe werden in unterschiedliche Schiffstypen
unterteilt. Wir unterscheiden die stolzen Bezwinger der
sieben Weltmeere am besten in Handelsschiffe,
Kriegsschiffe und fliegende Schiffe. Handelsschiffe
besäßen demnach keine Kanonen, könnten aber mehr
Ladung an Bord nehmen als Kriegsschiffe und die
fliegendem Schiffe. Die Kriegsschiffe sollten hingegen viel
mehr Kanonen als fliegende Schiffe besitzen, könnten
aber evtl. deutlich weniger Ladung an Bord nehmen als
z.B. Handelsschiffe. Flugschiffe besäßen optimalerweise
weniger Kanonen als militärische Schiffe, könnten dafür
aber mehr Ladung an Bord nehmen als Letztere.
Ausserdem sollten Flugschiffe, wie schon ihr Name sagt,
als einzige Schiffe hoch oben über den Wolken und
Dächern der Städte ihre Runden drehen können.“
Montag, 26. Oktober 2009 20
22. Bitte so:
Schiffstyp Kanonen Ladevolumen Flugtauglichkeit
Handelsschiff Nein [groß] Nein
Kriegsschiff [viele] [gering] Nein
Flugschiff [wenige] [mittel] ja
Montag, 26. Oktober 2009 22
23. Was gehört denn
nun in ein DD?
Erstmal zwei abschreckende Beispiele:
Montag, 26. Oktober 2009 23
24. Designer Nr. 1, der
„Visionär“
•Er steht dem Team sehr nahe,
manche sagen „auf den Füßen“.
•Er hat jeden Tag neue Ideen, die das Spiel nach vorne
bringen soll und teilt diese meist im persönlichen
Monolog mit.
•Ein Designdokument existiert nicht.
•So wird es zumindest vermutet,
gesehen oder gar gelesen hat es noch keiner.
•Aber tatsächlich gibt es auf seinem Laptop zwei
halbseitiges .txt Dateien,
die er irgendwann einmal fortführen will.
•Das ist sein „Designdokument“.
Montag, 26. Oktober 2009 24
25. Designer Nr. 2, der
„Theoretiker“
•Er hat alles genau geplant.
•Nach monatelanger einsamer Arbeit erblickt sein Werk das
Licht der Welt.
•Als ein Mitarbeiter es ausdrucken wollte musste er fünfmal
Papier nachfüllen und schließlich die Druckerpatrone
wechseln.
•Niemand hat es bisher geschafft, das monumental Werk
des Theoretikers ganz zu lesen, aber alle sprechen in
Ehrfurcht davon.
•Nun leistet es wertvolle Dienste als Sichtschutz,
Fußschemel oder Monitorsockel.
Montag, 26. Oktober 2009 25
26. Der allgemeine Aufbau kann in sieben
große Blöcke eingeteilt werden:
• Grundlagen
• Spielregeln
• Spielinhalte
• Interface
• Grafik
• Sound
• Tools
Montag, 26. Oktober 2009 26
27. Grundlagen
• Alle Rahmendaten sowie strategische
und spieltheoretische Aspekte
• „Mission Statement“
• Spielflussbeschreibung
• Gern vergessen: Theoretische Basis
des Spiels
Montag, 26. Oktober 2009 27
28. Spielregeln
• Alle im Spiel vorkommenden
Features, aber nicht die Inhalte
• Spielphysik
• Spielsteuerung
• Spielmodi
• KI
Montag, 26. Oktober 2009 28
29. Spielinhalte
• Alle Assets, die von Grafikern,
Textern, Level- und Gamedesignern
erstellt werden
Montag, 26. Oktober 2009 29
31. Interface
• Alle Komponenten, über die der
Spieler mit dem Spiel kommunizieren
kann
• Styleguide
• Spielerführung
• Menüs
Montag, 26. Oktober 2009 31
32. Grafik
• Aussagekräftiger Styleguide
• Alle im Spiel vorkommenden,
konkreten Grafikassets (Artbook)
Montag, 26. Oktober 2009 32
35. Sound
• Alle akustischen Signale, denen man
im Spiel begegnen kann
• Styleguide
• Systemfrage (statisch, dynamisch?)
• Quantitative Fragen
Montag, 26. Oktober 2009 35
36. Tools
• Beschreibung des technischen
Instrumentariums
• Stellung in der Toolchain
• Anforderungen an neue Tools
• Verbesserungswünsche zu
existierenden Tools
Montag, 26. Oktober 2009 36
38. Warum
Projektplanung
scheitert
Montag, 26. Oktober 2009 38
39. Standish Group 1994, CHAOS Report:
In der IT Branche sind nur 16,2 % aller
Projekte „on-time“ und „on-budget“.
31,1 % kommen zu spät und/oder laufen
finanziell aus dem Ruder. 52,7 % aller
Projekte werden noch vor Fertigstellung
eingestampft.
Montag, 26. Oktober 2009 39
40. Warum Projektplanung scheitert
Die täglichen Lügen
• Der Publisher verspricht dem Studioleiter vollen Support - lässt ihn aber bei
der ersten Milestone Zahlung im Regen stehen.
• Der Coder verspricht dem Technical Director einen wichtigen Task bis
Freitag fertig gestellt zu haben – zwei Wochen später wartet aber immer
noch das gesamte Team darauf und kann nicht weiterarbeiten
• Das Marketing möchte nur noch einen hochaufgelösten Pappaufsteller des
Orcs für die Games Convention – aber einen Tag vor Messebeginn kommt
eine Liste über 200 Screenshots, einige Highresolution Artworks und einen
Videotrailer...bis gestern bitte.
Montag, 26. Oktober 2009 40
41. Warum Projektplanung scheitert
Die täglichen Lügen
• Irgendwann nimmt der Projektleiter dieses Verhalten als gegeben hin.
Dies führt dazu, dass irgendwann Schuldige oder zumindest Gründe gesucht
werden.
Der Projektmanager ist zu unerfahren, die technischen Probleme haben uns
zurückgeworfen oder die beliebteste Ausrede:
Das Budget war einfach zu knapp bemessen.
„Wenn wir das Budget von Blizzard hätten, ja dann! Dann könnten wir...“
• Aber auch Projekte mit 20, 40 oder 200 Millionen Dollar brauchen doppelt
so lange oder kosten dreimal so viel und scheitern genauso oft wie
kleine...Nur lauter.
Montag, 26. Oktober 2009 41
42. Regel Nummer 1 beim
Projektmanagement
• Was sagt mir mein gesunder
Menschenverstand?
Montag, 26. Oktober 2009 42
43. Regel Nummer 2
stammt direkt von Albert Einstein
• „Mache die Dinge so einfach wie
möglich, aber nicht einfacher!“
Montag, 26. Oktober 2009 43
44. Fragen im
Kick-Off Meeting
• Wie weit soll man die Tasks granulieren?
• Welche Tools sollen für den Workflow
eingesetzt werden?
• Wie sollen Verzögerungen gehandhabt
werden?
• Wie wird miteinander kommuniziert?
• Wie oft finden wann warum welche
Meetings statt?
Montag, 26. Oktober 2009 44
45. Die Sache mit den
Milestones
Montag, 26. Oktober 2009 45
46. Aber wo liegen die
Wurzeln dieses Übels?
Kosten
Projektdreieck
Zeit Qualität
Montag, 26. Oktober 2009 46
47. • Eine Planung sollte niemals auf Basis von
Terminen, sondern immer Ressourcen und
Qualität beruhen
• Am Anfang stehen nicht die Milestones, sondern
die Definition des angestrebten Ergebnisses
• Dann folgt die Zeiteinschätzung der Tasks
• Und danach die Planung des Ablaufs anhand der
Montag, 26. Oktober 2009 47
49. Welche Aufgaben
hat ein Projektleiter
- und welche nicht?
Montag, 26. Oktober 2009 49
50. Die vielen, unterschiedlichen Aufgabenbereiche eines Projektleiters in der Übersicht.
Production Marketing
(Task- und Projektplanung (Schnittstelle zum
& Tracking) Publisher)
R&D Human Ressources
(Sicherstellung der Projektleiter (Konfliktlösung,
Projektdokumentation) Ressourcenplanung)
Finance Managing
(Budgetplanung und (Projektvertretung
Kostentracking) gegenüber Studiohead)
Montag, 26. Oktober 2009 50
51. Wer glaubt, dass ein Projektleiter Projekte leitet, der
glaubt auch, dass ein Zitronenfalter Zitronen faltet!“
Typische Anzeichen für „Anerzogene Hilflosigkeit“:
• ...bei auftretenden Problemen die Arme verschränken und sich
passiv verhalten.
• ...nur am Nörgeln und Jammern sind.
• ...Konflikte nicht lösen, sondern aussitzen.
• ...nicht über den Tellerrand schauen, sondern sich nur um ihren
eigenen kleinen Bereich kümmern („Was geht mich fremdes Elend
an?“)
• ...ihre Versprechen (und damit auch die Zeiteinschätzung) nicht
einhalten.
• ...mit jedem kleinen Problem zum Projektleiter rennen, damit er
das bitteschön für sie lösen soll.
Montag, 26. Oktober 2009 51
52. Die Aufgaben des
Projektleiters sind nicht:
• ...für die Teammitglieder zu denken.
• ...jedem Mitarbeiter seine Arbeit
nachzutragen.
• ...die Methoden und Tools
vorzugeben.
Montag, 26. Oktober 2009 52
53. Bei der Taskplanung
lauten diese Frage:
Wer (Ausführender) macht...
• ...was(Aufgabe, Arbeitspaket)
• ...bis wann(Abgabetermin)
• ...mit welchem wie gemessenem
Ergebnis (Ziel- und Erfolgskriterien)
• ...wozu (wird diese Aufgabe später
gebraucht)
Montag, 26. Oktober 2009 53
54. Die S.M.A.R.T
Zielformulierung
• S pecific (genau, exakt beschrieben?)
• M easurable (messbar?)
• A ttainable (erreichbar?)
• R elevant (Ziel auch wirklich wichtig?)
• T imed (wann fertig?)
Montag, 26. Oktober 2009 54
55. Woran liegt es, dass man
so oft daneben liegt?
• Zu grobe Einteilung der Tasks
• Keine genaue Definition der
Qualitäts- und Zielkriterien
• Der Coder sitzt nicht 8 Stunden am
Tag, 5 Tage die Woche an einem Task
Montag, 26. Oktober 2009 55
56. Die Dreifach-Schätzung
Best Case - Einschätzung: 10 Tage
Most Likely - Einschätzung: 15 Tage
Worst Case - Einschätzung: 25 Tage
Formel zur Bestimmung eines realistischen
Durchschnittswertes (basierend auf den Erfahrungen
aus der Teststatistik, dass eine Aufwandsschätzung in
mehr als 85% der Fälle in Richtung Worst-Case
abweicht):
(2x Best Case) + (3x Worst-Case) + Most Likely = X/6
In diesem Fall:
(2x10) + (3x25) + 15 = 110/6 = 18,33 Tage
Montag, 26. Oktober 2009 56
57. Vielen Dank fürs
Zuhören und viel Erfolg
bei euren zukünftigen
Projekten
http://fg-informatik.unibas.ch/wiki/
index.php/FG-Workshop
http://project-two.org
JOIN the future!
Montag, 26. Oktober 2009 57