SlideShare ist ein Scribd-Unternehmen logo
1 von 57
Downloaden Sie, um offline zu lesen
Montag, 26. Oktober 2009   1
An Introduction to Game Design
Documentation and Project Management

                           tim.nuechel@stud.unibas.ch




Montag, 26. Oktober 2009                                2
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
Warum eine
                           Pre-Production?



Montag, 26. Oktober 2009                     4
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
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
Montag, 26. Oktober 2009   7
Montag, 26. Oktober 2009   8
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
• 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
Das Design Dokument
                       Am Beispiel von Related Design und
                                   Anno 1404




Montag, 26. Oktober 2009                                    11
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
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
Montag, 26. Oktober 2009   14
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
„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
(Aktuelles DDD=Ordnung)
       > (veraltetes DDD=Chaos)



Montag, 26. Oktober 2009          17
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
Anno 1404 Standard-
                      Designeintrag
                  • Name               • Regeln
                  • Verantwortliche    • Balancing
                  • Status             • FAQ
                  • Definition          • Implementierungs
                                         details
                  • Kurzbeschreibung
                  • Schaubilder


Montag, 26. Oktober 2009                                    19
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
Warum schlecht?
                  • Fließtext
                  • Keine Formatierung
                  • Uneinheitliche Namensgebung
                  • Redundanzen
                  • Unklare Formulierungen
                  • Designerprosa

Montag, 26. Oktober 2009                          21
Bitte so:
       Schiffstyp          Kanonen Ladevolumen Flugtauglichkeit


  Handelsschiff              Nein      [groß]        Nein


     Kriegsschiff           [viele]   [gering]       Nein


        Flugschiff         [wenige]   [mittel]        ja




Montag, 26. Oktober 2009                                          22
Was gehört denn
                            nun in ein DD?
                      Erstmal zwei abschreckende Beispiele:




Montag, 26. Oktober 2009                                      23
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
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
Der allgemeine Aufbau kann in sieben
        große Blöcke eingeteilt werden:
                  • Grundlagen
                  • Spielregeln
                  • Spielinhalte
                  • Interface
                  • Grafik
                  • Sound
                  • Tools
Montag, 26. Oktober 2009                    26
Grundlagen

                  • Alle Rahmendaten sowie strategische
                           und spieltheoretische Aspekte

                  • „Mission Statement“
                  • Spielflussbeschreibung
                  • Gern vergessen: Theoretische Basis
                           des Spiels


Montag, 26. Oktober 2009                                   27
Spielregeln

                  • Alle im Spiel vorkommenden
                           Features, aber nicht die Inhalte

                  • Spielphysik
                  • Spielsteuerung
                  • Spielmodi
                  • KI

Montag, 26. Oktober 2009                                      28
Spielinhalte



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




Montag, 26. Oktober 2009                                       29
Montag, 26. Oktober 2009   30
Interface

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

                  • Styleguide
                  • Spielerführung
                  • Menüs

Montag, 26. Oktober 2009                                         31
Grafik


                  • Aussagekräftiger Styleguide
                  • Alle im Spiel vorkommenden,
                           konkreten Grafikassets (Artbook)




Montag, 26. Oktober 2009                                     32
Montag, 26. Oktober 2009   33
Montag, 26. Oktober 2009   34
Sound

                  • Alle akustischen Signale, denen man
                           im Spiel begegnen kann

                  • Styleguide
                  • Systemfrage (statisch, dynamisch?)
                  • Quantitative Fragen


Montag, 26. Oktober 2009                                  35
Tools

                  • Beschreibung des technischen
                           Instrumentariums

                  • Stellung in der Toolchain
                  • Anforderungen an neue Tools
                  • Verbesserungswünsche zu
                           existierenden Tools


Montag, 26. Oktober 2009                           36
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
Warum
                           Projektplanung
                              scheitert


Montag, 26. Oktober 2009                    38
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
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
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
Regel Nummer 1 beim
                  Projektmanagement


                  • Was sagt mir mein gesunder
                           Menschenverstand?




Montag, 26. Oktober 2009                         42
Regel Nummer 2
              stammt direkt von Albert Einstein




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




Montag, 26. Oktober 2009                                     43
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
Die Sache mit den
                          Milestones



Montag, 26. Oktober 2009                   45
Aber wo liegen die
                 Wurzeln dieses Übels?
                               Kosten




                            Projektdreieck




                     Zeit                    Qualität

Montag, 26. Oktober 2009                                46
• 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
Montag, 26. Oktober 2009   48
Welche Aufgaben
                hat ein Projektleiter
                           - und welche nicht?




Montag, 26. Oktober 2009                         49
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
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
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
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
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
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
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
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

Weitere ähnliche Inhalte

Was ist angesagt?

UX STRAT USA: Leah Buley, "The Role of UX / CX in Business"
UX STRAT USA: Leah Buley, "The Role of UX / CX in Business"UX STRAT USA: Leah Buley, "The Role of UX / CX in Business"
UX STRAT USA: Leah Buley, "The Role of UX / CX in Business"UX STRAT
 
LAFS Game Design 8 - Playtesting
LAFS Game Design 8 - PlaytestingLAFS Game Design 8 - Playtesting
LAFS Game Design 8 - PlaytestingDavid Mullich
 
I love mincraft_powerpoint
I love mincraft_powerpointI love mincraft_powerpoint
I love mincraft_powerpointantonyfnaf
 
06. Game Architecture
06. Game Architecture06. Game Architecture
06. Game ArchitectureAmin Babadi
 
Game development life cycle
Game development life cycleGame development life cycle
Game development life cycleSarah Alazab
 
Airbnb Case Study - Design Thinking
Airbnb Case Study - Design ThinkingAirbnb Case Study - Design Thinking
Airbnb Case Study - Design ThinkingSaishAdlak
 

Was ist angesagt? (7)

UX STRAT USA: Leah Buley, "The Role of UX / CX in Business"
UX STRAT USA: Leah Buley, "The Role of UX / CX in Business"UX STRAT USA: Leah Buley, "The Role of UX / CX in Business"
UX STRAT USA: Leah Buley, "The Role of UX / CX in Business"
 
LAFS Game Design 8 - Playtesting
LAFS Game Design 8 - PlaytestingLAFS Game Design 8 - Playtesting
LAFS Game Design 8 - Playtesting
 
I love mincraft_powerpoint
I love mincraft_powerpointI love mincraft_powerpoint
I love mincraft_powerpoint
 
06. Game Architecture
06. Game Architecture06. Game Architecture
06. Game Architecture
 
Game development life cycle
Game development life cycleGame development life cycle
Game development life cycle
 
Various Topics on Game Design
Various Topics on Game DesignVarious Topics on Game Design
Various Topics on Game Design
 
Airbnb Case Study - Design Thinking
Airbnb Case Study - Design ThinkingAirbnb Case Study - Design Thinking
Airbnb Case Study - Design Thinking
 

Andere mochten auch

Artificially Intelligent Design(er). The End of User Experience as we know it?
Artificially Intelligent Design(er). The End of User Experience as we know it?Artificially Intelligent Design(er). The End of User Experience as we know it?
Artificially Intelligent Design(er). The End of User Experience as we know it?Agnieszka Maria Walorska
 
Approaches to game AI overview
Approaches to game AI overviewApproaches to game AI overview
Approaches to game AI overviewIvan Dolgushin
 
Artificial Intelligence in games
Artificial Intelligence in gamesArtificial Intelligence in games
Artificial Intelligence in gamesDevGAMM Conference
 
Asynchronous Multiplayer on Mobile Network
Asynchronous Multiplayer on Mobile NetworkAsynchronous Multiplayer on Mobile Network
Asynchronous Multiplayer on Mobile NetworkIvan Dolgushin
 
Game playing in artificial intelligent technique
Game playing in artificial intelligent technique Game playing in artificial intelligent technique
Game playing in artificial intelligent technique syeda zoya mehdi
 
Introduction to AI - Seventh Lecture
Introduction to AI - Seventh LectureIntroduction to AI - Seventh Lecture
Introduction to AI - Seventh LectureWouter Beek
 
Game design document template for serious games
Game design document template for serious gamesGame design document template for serious games
Game design document template for serious gamesAntoine Taly
 
Game Playing in Artificial Intelligence
Game Playing in Artificial IntelligenceGame Playing in Artificial Intelligence
Game Playing in Artificial Intelligencelordmwesh
 

Andere mochten auch (9)

Artificially Intelligent Design(er). The End of User Experience as we know it?
Artificially Intelligent Design(er). The End of User Experience as we know it?Artificially Intelligent Design(er). The End of User Experience as we know it?
Artificially Intelligent Design(er). The End of User Experience as we know it?
 
Approaches to game AI overview
Approaches to game AI overviewApproaches to game AI overview
Approaches to game AI overview
 
Artificial Intelligence in games
Artificial Intelligence in gamesArtificial Intelligence in games
Artificial Intelligence in games
 
Asynchronous Multiplayer on Mobile Network
Asynchronous Multiplayer on Mobile NetworkAsynchronous Multiplayer on Mobile Network
Asynchronous Multiplayer on Mobile Network
 
Game playing in artificial intelligent technique
Game playing in artificial intelligent technique Game playing in artificial intelligent technique
Game playing in artificial intelligent technique
 
Practical AI in Games
Practical AI in GamesPractical AI in Games
Practical AI in Games
 
Introduction to AI - Seventh Lecture
Introduction to AI - Seventh LectureIntroduction to AI - Seventh Lecture
Introduction to AI - Seventh Lecture
 
Game design document template for serious games
Game design document template for serious gamesGame design document template for serious games
Game design document template for serious games
 
Game Playing in Artificial Intelligence
Game Playing in Artificial IntelligenceGame Playing in Artificial Intelligence
Game Playing in Artificial Intelligence
 

Ähnlich wie Game Design Dokumentation und Projekt Management

mimacom f the_process
mimacom f the_processmimacom f the_process
mimacom f the_processFelix Kubasch
 
Mimacom f the_process
Mimacom f the_processMimacom f the_process
Mimacom f the_processFelix Kubasch
 
QS von IT-Consulting bis Software Development
QS von IT-Consulting bis Software DevelopmentQS von IT-Consulting bis Software Development
QS von IT-Consulting bis Software Developmentadesso AG
 
NICE Quality Monitoring und Performance Management
NICE Quality Monitoring und Performance ManagementNICE Quality Monitoring und Performance Management
NICE Quality Monitoring und Performance ManagementNICE_Systems_Deutschland
 
Präventives Lieferantenrisikomanagement / Risikomanagement in der Supply Chain
Präventives Lieferantenrisikomanagement / Risikomanagement in der Supply ChainPräventives Lieferantenrisikomanagement / Risikomanagement in der Supply Chain
Präventives Lieferantenrisikomanagement / Risikomanagement in der Supply ChainStefan Paul
 
KEGON agile entwicklung in großen Organisationen
KEGON agile entwicklung in großen OrganisationenKEGON agile entwicklung in großen Organisationen
KEGON agile entwicklung in großen OrganisationenKEGON AG
 
DevOps - Programmierst Du noch oder betreibst Du schon?
DevOps - Programmierst Du noch oder betreibst Du schon?DevOps - Programmierst Du noch oder betreibst Du schon?
DevOps - Programmierst Du noch oder betreibst Du schon?Jean-Pierre König
 
Ökonomische Planung von Prozessverbesserungsmaßnahmen - Ein modelltheoretisch...
Ökonomische Planung von Prozessverbesserungsmaßnahmen - Ein modelltheoretisch...Ökonomische Planung von Prozessverbesserungsmaßnahmen - Ein modelltheoretisch...
Ökonomische Planung von Prozessverbesserungsmaßnahmen - Ein modelltheoretisch...Maximilian Roeglinger
 
360 Grad Projekt Review Christian Bauer PMI SUMMIT
360 Grad Projekt Review Christian Bauer PMI SUMMIT360 Grad Projekt Review Christian Bauer PMI SUMMIT
360 Grad Projekt Review Christian Bauer PMI SUMMITChristian Bauer
 
Roadshow 2019: Praxistipps für die erfolgreiche Einführung von Camunda in Ihr...
Roadshow 2019: Praxistipps für die erfolgreiche Einführung von Camunda in Ihr...Roadshow 2019: Praxistipps für die erfolgreiche Einführung von Camunda in Ihr...
Roadshow 2019: Praxistipps für die erfolgreiche Einführung von Camunda in Ihr...camunda services GmbH
 
Roadshow 2018 - Camunda in der Praxis: So geht's
Roadshow 2018 - Camunda in der Praxis: So geht'sRoadshow 2018 - Camunda in der Praxis: So geht's
Roadshow 2018 - Camunda in der Praxis: So geht'scamunda services GmbH
 
360° Projekt-Review für Softwareprojekte
360° Projekt-Review für Softwareprojekte360° Projekt-Review für Softwareprojekte
360° Projekt-Review für Softwareprojektedox42
 

Ähnlich wie Game Design Dokumentation und Projekt Management (20)

YOUR SL GmbH
YOUR SL GmbHYOUR SL GmbH
YOUR SL GmbH
 
mimacom f the_process
mimacom f the_processmimacom f the_process
mimacom f the_process
 
Mimacom f the_process
Mimacom f the_processMimacom f the_process
Mimacom f the_process
 
101 Projektmanagement
101 Projektmanagement101 Projektmanagement
101 Projektmanagement
 
Präsentation RUP
Präsentation RUPPräsentation RUP
Präsentation RUP
 
QS von IT-Consulting bis Software Development
QS von IT-Consulting bis Software DevelopmentQS von IT-Consulting bis Software Development
QS von IT-Consulting bis Software Development
 
NICE Quality Monitoring und Performance Management
NICE Quality Monitoring und Performance ManagementNICE Quality Monitoring und Performance Management
NICE Quality Monitoring und Performance Management
 
Präventives Lieferantenrisikomanagement / Risikomanagement in der Supply Chain
Präventives Lieferantenrisikomanagement / Risikomanagement in der Supply ChainPräventives Lieferantenrisikomanagement / Risikomanagement in der Supply Chain
Präventives Lieferantenrisikomanagement / Risikomanagement in der Supply Chain
 
KEGON agile entwicklung in großen Organisationen
KEGON agile entwicklung in großen OrganisationenKEGON agile entwicklung in großen Organisationen
KEGON agile entwicklung in großen Organisationen
 
KAIZEN
KAIZENKAIZEN
KAIZEN
 
DevOps - Programmierst Du noch oder betreibst Du schon?
DevOps - Programmierst Du noch oder betreibst Du schon?DevOps - Programmierst Du noch oder betreibst Du schon?
DevOps - Programmierst Du noch oder betreibst Du schon?
 
FMEA
FMEAFMEA
FMEA
 
Ökonomische Planung von Prozessverbesserungsmaßnahmen - Ein modelltheoretisch...
Ökonomische Planung von Prozessverbesserungsmaßnahmen - Ein modelltheoretisch...Ökonomische Planung von Prozessverbesserungsmaßnahmen - Ein modelltheoretisch...
Ökonomische Planung von Prozessverbesserungsmaßnahmen - Ein modelltheoretisch...
 
360 Grad Projekt Review Christian Bauer PMI SUMMIT
360 Grad Projekt Review Christian Bauer PMI SUMMIT360 Grad Projekt Review Christian Bauer PMI SUMMIT
360 Grad Projekt Review Christian Bauer PMI SUMMIT
 
Roadshow 2019: Praxistipps für die erfolgreiche Einführung von Camunda in Ihr...
Roadshow 2019: Praxistipps für die erfolgreiche Einführung von Camunda in Ihr...Roadshow 2019: Praxistipps für die erfolgreiche Einführung von Camunda in Ihr...
Roadshow 2019: Praxistipps für die erfolgreiche Einführung von Camunda in Ihr...
 
Qualitaetszirkel
QualitaetszirkelQualitaetszirkel
Qualitaetszirkel
 
Virtuelle projekte
Virtuelle projekteVirtuelle projekte
Virtuelle projekte
 
2011 10 05 10-15 knut mertens
2011 10 05 10-15 knut mertens2011 10 05 10-15 knut mertens
2011 10 05 10-15 knut mertens
 
Roadshow 2018 - Camunda in der Praxis: So geht's
Roadshow 2018 - Camunda in der Praxis: So geht'sRoadshow 2018 - Camunda in der Praxis: So geht's
Roadshow 2018 - Camunda in der Praxis: So geht's
 
360° Projekt-Review für Softwareprojekte
360° Projekt-Review für Softwareprojekte360° Projekt-Review für Softwareprojekte
360° Projekt-Review für Softwareprojekte
 

Mehr von fg.informatik Universität Basel

JavaScript packt aus: "Alle haben mich falsch verstanden!"
JavaScript packt aus: "Alle haben mich falsch verstanden!"JavaScript packt aus: "Alle haben mich falsch verstanden!"
JavaScript packt aus: "Alle haben mich falsch verstanden!"fg.informatik Universität Basel
 

Mehr von fg.informatik Universität Basel (17)

fg.workshop: Software vulnerability
fg.workshop: Software vulnerabilityfg.workshop: Software vulnerability
fg.workshop: Software vulnerability
 
fg.workshop: Opensource licenses
fg.workshop: Opensource licensesfg.workshop: Opensource licenses
fg.workshop: Opensource licenses
 
Version management mit Git und Github
Version management mit Git und Github Version management mit Git und Github
Version management mit Git und Github
 
Drahtlose Kommunikation und SDR
Drahtlose Kommunikation und SDR Drahtlose Kommunikation und SDR
Drahtlose Kommunikation und SDR
 
OpenCL Grundlagen
OpenCL GrundlagenOpenCL Grundlagen
OpenCL Grundlagen
 
Website-Security
Website-SecurityWebsite-Security
Website-Security
 
Hardware-Basteleien für Informatiker
Hardware-Basteleien für InformatikerHardware-Basteleien für Informatiker
Hardware-Basteleien für Informatiker
 
Emergent gameplay
Emergent gameplayEmergent gameplay
Emergent gameplay
 
JavaScript packt aus: "Alle haben mich falsch verstanden!"
JavaScript packt aus: "Alle haben mich falsch verstanden!"JavaScript packt aus: "Alle haben mich falsch verstanden!"
JavaScript packt aus: "Alle haben mich falsch verstanden!"
 
Hydraulische Erosion und Terraingeneration (GPGPU)
Hydraulische Erosion und Terraingeneration (GPGPU)Hydraulische Erosion und Terraingeneration (GPGPU)
Hydraulische Erosion und Terraingeneration (GPGPU)
 
Ruby, Ruby, Ruby!
Ruby, Ruby, Ruby!Ruby, Ruby, Ruby!
Ruby, Ruby, Ruby!
 
CS108 Bootcamp Eyeballs
CS108 Bootcamp EyeballsCS108 Bootcamp Eyeballs
CS108 Bootcamp Eyeballs
 
CS108 Bootcamp Einführung YASY
CS108 Bootcamp Einführung YASYCS108 Bootcamp Einführung YASY
CS108 Bootcamp Einführung YASY
 
CS108 Bootcamp 2011 Intro - Jarwars
CS108 Bootcamp 2011 Intro - JarwarsCS108 Bootcamp 2011 Intro - Jarwars
CS108 Bootcamp 2011 Intro - Jarwars
 
NumericOS - How to build your own Operatingsystem
NumericOS - How to build your own OperatingsystemNumericOS - How to build your own Operatingsystem
NumericOS - How to build your own Operatingsystem
 
DLL-Injection
DLL-InjectionDLL-Injection
DLL-Injection
 
Open source hardware
Open source hardwareOpen source hardware
Open source hardware
 

Game Design Dokumentation und Projekt Management

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