![Bitte so:
Schiffstyp Kanonen Ladevolumen Flugtauglichkeit
Handelsschiff Nein [groß] Nein
Kriegsschiff [viele] [gering] Nein
Flugschiff [wenige] [mittel] ja
Montag, 26. Oktober 2009 22](https://image.slidesharecdn.com/gamedesign-111223065151-phpapp01/85/Game-Design-Dokumentation-und-Projekt-Management-22-320.jpg)
Game Design Dokumentation und Projekt Management
- 1. Montag, 26. Oktober 2009 1
- 2. An Introduction to Game Design Documentation and Project Management [email protected] 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