Game Design Dokumentation und Projekt Management

1Montag, 26. Oktober 2009

[email protected]

An Introduction to Game Design Documentation and Project Management


mailto:[email protected]

mailto:[email protected]

• Die Zieldefinition ist unzureichend, nicht überprüfbar und zu spezifisch.

• Die Ziele wurden nicht verbindlich definiert und fixiert.

• Nicht alle notwendigen Informationen wurden im Vorfeld gesammelt und evaluiert.

• Es wurden keine spezifischen Anforderungen festgelegt.

• Die Planung beruht auf unzureichenden Spezifikationen und Annahmen.

• Somit sind auch keine echten Kontrollen (Soll != Ist) möglich.

• Die Risiken in der Planung sowie die Rahmenbedingungen wurden nur unzureichend berücksichtigt.

• Die genauen Anforderungen an Organisations- und Prozessabläufe wurden nicht verbindlich definiert.

Faktoren, die einer Entwicklung zum Verhängnis werden können


Warum 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.

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

Argumente für eine Pre-Production


Kernziel-ChecklisteProjekt Kick-Off

Erstellung der Dokumentation

Zieldefinition & Vision Statement

Game Design Dokument

Art/Style Guide

Level-/World- & Story-Guide

Technical Design Guide

Feature Liste & Beurteilung

Definition der Organisation

Teamstruktur

Projektrollen

Meetings

Reporting intern/mit demPublisher

Kontrolle der externen Ressourcen

Definition der Prozesse

Change Control

Approval-Prozesse

QA-Prozesse

Build Prozesse

Version-Control & Backup

Konfliktmanagement

Planung

Definition Umfang und Qualität

Task- & Ressourcenplanung

Budgetierung

Milestone Definitionen

Risiko Analyse

Recruitmentplan

Marketing

Konkurrenzanalyse

Zielgruppenanalyse

Proof-of-Concept-Prototyp

Core-Spielmechanik

Definition der Gameplay Qualität

GUI- & Steuerungsprototyp

Definition der Grafikqualität

Sound-Proof

Game-Design Risiko-Evaluierung abgeschlossen

Technologie-Prototyp

Basic Toolbase abgeschlossen

Middleware Evaluation & Prototype abgeschlossen

Basis für 3D-Engine definiert & abgeschlossen

Technical-Backend abgeschlossen

Technische Risiko-Evaluierung abgeschlossen


• 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!“


Das Design Dokument

Am Beispiel von Related Design und Anno 1404


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.)


Was Designer wissen sollten

Dinge die Programmierer

mögenHauptsätze Imperativ Bulletpoints Diagramme

Dinge die Programmierer

hassenNebensätze Konjunktiv Fließtext Designerprosa


Regeln für ein gutes DDD

• ...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

Ein nützliches DDD muss...:


„Im Fall des Scheiterns wird das DDD ein Schattendasein als ungeliebtes Mauerblümchen fristen und hilflos dem Chaos beiwohnen, das unweigerlich beginnt sich auszubreiten.“


(Aktuelles DDD=Ordnung) > (veraltetes DDD=Chaos)


Ein Wiki hat den Vorteil, dass...:

• ...übersichtliche Layouts leicht zu erstellen und zu verwalten sind.

• ...Einträge miteinander verlinkt werden können.

• ...jede Version eines Eintrags jederzeit wieder hergestellt werden kann.

• ...alle Versionen eines Eintrags miteinander verglichen werden können.

• ...Einträge abonniert werden können, sodass man bei Aktualisierungen per Mail benachrichtigt wird.

• ...Einträge wie in Foren von jedem Nutzer kommentiert werden können.

• ...Bilder, Galerien, Musik und Filme leicht zu integrieren sind.


Anno 1404 Standard-Designeintrag

• Name

• Verantwortliche

• Status

• Definition

• Kurzbeschreibung

• Schaubilder

• Regeln

• Balancing

• FAQ

• Implementierungsdetails


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.“


Warum schlecht?

• Fließtext

• Keine Formatierung

• Uneinheitliche Namensgebung

• Redundanzen

• Unklare Formulierungen

• Designerprosa


Bitte so:Schiffstyp Kanonen Ladevolumen Flugtauglichkeit

Handelsschiff Nein [groß] Nein

Kriegsschiff [viele] [gering] Nein

Flugschiff [wenige] [mittel] ja


Was gehört denn nun in ein DD?

Erstmal zwei abschreckende Beispiele:


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“.


•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.

Designer Nr. 2, der „Theoretiker“


Der allgemeine Aufbau kann in sieben große Blöcke eingeteilt werden:

• Grundlagen

• Spielregeln

• Spielinhalte

• Interface

• Grafik

• Sound

• Tools26Montag, 26. Oktober 2009

Grundlagen

• Alle Rahmendaten sowie strategische und spieltheoretische Aspekte

• „Mission Statement“

• Spielflussbeschreibung

• Gern vergessen: Theoretische Basis des Spiels


Spielregeln

• Alle im Spiel vorkommenden Features, aber nicht die Inhalte

• Spielphysik

• Spielsteuerung

• Spielmodi

• KI


Spielinhalte

• Alle Assets, die von Grafikern, Textern, Level- und Gamedesignern erstellt werden


Interface

• Alle Komponenten, über die der Spieler mit dem Spiel kommunizieren kann

• Styleguide

• Spielerführung

• Menüs


Grafik

• Aussagekräftiger Styleguide

• Alle im Spiel vorkommenden, konkreten Grafikassets (Artbook)


Sound

• Alle akustischen Signale, denen man im Spiel begegnen kann

• Styleguide

• Systemfrage (statisch, dynamisch?)

• Quantitative Fragen


Tools

• Beschreibung des technischen Instrumentariums

• Stellung in der Toolchain

• Anforderungen an neue Tools

• Verbesserungswünsche zu existierenden Tools


Muster eines DDD1. Grundlagen

• Rahmendaten• Mission Statement• Brand-DNA• Gameflow• Lernkurve• Spielphase• USPs• Spielflussbeispiele• Spielertypen

2. Spielregeln• Feature-Spezifikation• Steuerung• Kamera• Spielphysik• KI• Spielmodi

3. Spielinhalte• Charaktere• Einheiten• Gebäude• Objekte• Vegetation• Ausrüstung• Story• Szenarien• Missionen

4. Interface• Styleguide• Hauptmenü• In-Game-Interface• Feedbacks• Optionen• Tastaturbelegung

5. Grafik• Styleguide• Charaktere• Einheiten

• Gebäude• Objekte• Vegetation• Gegenstände• Effekte• Sequenzen und

Videos6. Sound

• Styleguide• Musiken• Soundeffekte• Interface-Sounds• Soundsystem

7. Tools• Toolchain• Welt-Editor• Level-Editor• Effekt-Editor• Text-Editor• Lokalisations-Kit


Warum Projektplanung

scheitert


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.


• 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.

Warum Projektplanung scheitertDie 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.

Warum Projektplanung scheitertDie täglichen Lügen


Regel Nummer 1 beim Projektmanagement

• Was sagt mir mein gesunder Menschenverstand?


Regel Nummer 2stammt direkt von Albert Einstein

• „Mache die Dinge so einfach wie möglich, aber nicht einfacher!“


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?


Die Sache mit den Milestones


Aber wo liegen die Wurzeln dieses Übels?

Kosten

QualitätZeit

Projektdreieck


• 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


Welche Aufgaben hat ein Projektleiter

- und welche nicht?


Die vielen, unterschiedlichen Aufgabenbereiche eines Projektleiters in der Übersicht.

Finance(Budgetplanung und

Kostentracking)

Managing(Projektvertretung

gegenüber Studiohead)

Marketing(Schnittstelle zum

Publisher)

Human Ressources(Konfliktlösung,

Ressourcenplanung)

R&D(Sicherstellung der

Projektdokumentation)

Production(Task- und Projektplanung

& Tracking)

Projektleiter


Wer glaubt, dass ein Projektleiter Projekte leitet, der glaubt auch, dass ein Zitronenfalter Zitronen faltet!“

• ...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.

Typische Anzeichen für „Anerzogene Hilflosigkeit“:


Die Aufgaben des Projektleiters sind nicht:

• ...für die Teammitglieder zu denken.

• ...jedem Mitarbeiter seine Arbeit nachzutragen.

• ...die Methoden und Tools vorzugeben.


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)


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?)


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


Die Dreifach-SchätzungBest Case - Einschätzung: 10 TageMost Likely - Einschätzung: 15 TageWorst 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


Vielen Dank fürs Zuhören und viel Erfolg bei euren zukünftigen

Projektenhttp://fg-informatik.unibas.ch/wiki/index.php/FG-Workshop

http://project-two.org

JOIN the future!


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






Game Design Dokumentation und Projekt Management

Documents

Transcript of Game Design Dokumentation und Projekt Management