http://fg-informatik.unibas.ch/wiki/index.php/An_Introduction_to_Game_Design_Documentation_and_Projectmanagement

1. Montag, 26. Oktober 2009 1

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

7. Montag, 26. Oktober 2009 7

8. Montag, 26. Oktober 2009 8

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

14. Montag, 26. Oktober 2009 14

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

17. (Aktuelles DDD=Ordnung)
> (veraltetes DDD=Chaos)
Montag, 26. Oktober 2009 17

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

21. Warum schlecht?
• Fließtext
• Keine Formatierung
• Uneinheitliche Namensgebung
• Redundanzen
• Unklare Formulierungen
• Designerprosa
Montag, 26. Oktober 2009 21

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

30. Montag, 26. Oktober 2009 30

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

33. Montag, 26. Oktober 2009 33

34. Montag, 26. Oktober 2009 34

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

37. Muster eines DDD
1. Grundlagen 3. Spielinhalte • Gebäude
• Rahmendaten • Charaktere • Objekte
• Mission Statement • Einheiten • Vegetation
• Brand-DNA • Gebäude • Gegenstände
• Gameflow • Objekte • Effekte
• Lernkurve • Vegetation • Sequenzen und
Videos
• Spielphase • Ausrüstung
6. Sound
• USPs • Story
• Spielflussbeispiele • Szenarien • Styleguide
• Spielertypen • Missionen • Musiken
2. Spielregeln 4. Interface • Soundeffekte
• Feature-Spezifikation • Styleguide • Interface-Sounds
• Steuerung • Hauptmenü • Soundsystem
7. Tools
• Kamera • In-Game-Interface
• Spielphysik • Feedbacks • Toolchain
• KI • Optionen • Welt-Editor
• Spielmodi • Tastaturbelegung • Level-Editor
5. Grafik • Effekt-Editor
• Styleguide • Text-Editor
• Charaktere • Lokalisations-Kit
• Einheiten
Montag, 26. Oktober 2009 37

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

48. Montag, 26. Oktober 2009 48

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