Spiele-Entwicklung: Ablauf/Projektmanagment

[Plutos]

Heyho,

ich suche Informationen zu dem Thema Projektmanagement bei der Spiele-Entwicklung. Was ich bräuchte, wäre entweder mal ein Beispiel-Projekt (egal welches Format, MS Project taugt z.B.); oder alternativ grundlegend ein paar Richtwerte bezüglich "was fällt alles an Aufgaben an, wie lange dauern diese, wie aufwändig sind sie (Engine vs. Content bspw.), was kostet der Spaß etc."...speziell geht's eher um Konsolen- denn PC-Spiele.

Ich weiß nicht, ob es da was gibt, da das ja wahrscheinlich für die meisten professionellen Entwicklungsstudios/Publisher doch zu den besser gehüteten Betriebsgeheimnissen gehört X-D. Aber vielleicht hat doch wer Zahlen und Daten für mich?

[RMC]

Mit den Zahlen und Daten wirst du gar nichts anfangen können, weil das hauptsächlich vom Projekt und von innerbetrieblichen Abläufen abhängt.

Wenn du 2 Mappen mit Daten von 2 Firmen mit ähnlich großen Projekten in der Hand halten solltest, wirst du das nicht gegenrechnen können.

Btw, Projektmanagement bei Spiele-Entwicklungen unterscheidet sich fast gar nicht von anderen IT-Projekten.

[Monger]

Das würde mich auch mal interessieren! :D

Wenn du allgemeine Tipps suchst, kann ich dir die Management-Romane von Tom DeMarco empfehlen, wie z.B. "Der Termin".

Edit:
Wenn ich bedenke, was das Projektmanagement bei uns für ein riesiger Klotz ist... das lässt sich nicht ein einziges Dateiformat quetschen, schon eher in eine eigene Festplatte.

[Demirug]

Btw, Projektmanagement bei Spiele-Entwicklungen unterscheidet sich fast gar nicht von anderen IT-Projekten.

Und entsprechend viele unterschiedliche Ansätze gibt es. Funktionierend tun sie natürlich alle nicht. ;)

[mapel110]

Funktionierend tun sie natürlich alle nicht. ;)
Stimmt. Wenn ich da nur an das Pflichtenheft denke. Eigentlich sollte das im Voraus entstehen, bevor man mit der Realisierung anfängt. Aber dann wird hier noch gebastelt, da noch gebastelt und dann will der Kunde doch was ganz anderes. ;(

[Monger]

Funktionieren tun sie natürlich alle nicht. ;)
;D

Stimmt. Wenn ich da nur an das Pflichtenheft denke. Eigentlich sollte das im Voraus entstehen, bevor man mit der Realisierung anfängt. Aber dann wird hier noch gebastelt, da noch gebastelt und dann will der Kunde doch was ganz anderes. ;(
Oh ja, das kommt mir sehr bekannt vor. Hab da schon viele Szenen im Systemtest erlebt à la: "Was heißt hier 'zeig mir das mal in der Feature Verification'? Ich HABE keine Feature Verification!!!"

"Steht das jetzt auf der Cut-Liste, oder steht es nicht drauf? Was soll das heißen, es gibt noch ne andere Cut-Liste ?!?"

[Trap]

Es gibt für Sourcecode Aufwandschätzungssysteme basierend auf LOC und bei den LOC der Engines ist man ja etwas offener. Irgendwas in der Gegend um 500k LOC hat man ja bei aktuellen FPS-Engines (mit allem drum und dran), das sind grob geschätzt 100 Mannjahre Entwicklungsaufwand für eine komplette Neuentwicklung, bei 3 Jahren Entwicklungsdauer braucht man also ~30 Entwickler.

Ein anderer Ansatz um an etwas Informationen zu kommen ist Mod-Entwickler zu fragen oder Leute in den Credits zählen und Entwicklungsdauer recherchieren.

[RMC]

Ein anderer Ansatz um an etwas Informationen zu kommen ist Mod-Entwickler zu fragen

Mag sein, dass man da mehr Infos kriegt, aber auf die kann man so gut wie gar nicht bauen ;)

[Demirug]

Wenn du allgemeine Tipps suchst, kann ich dir die Management-Romane von Tom DeMarco empfehlen, wie z.B. "Der Termin".

So sehr ich seinen Schlussfolgerungen im Bereich des Personalmanagements auch zustimme so liegt er IMHO was den eigentlichen Entwicklungsprozess angeht falsch.

[Monger]

So sehr ich seinen Schlussfolgerungen im Bereich des Personalmanagements auch zustimme so liegt er IMHO was den eigentlichen Entwicklungsprozess angeht falsch.
Hast du zufällig ein konkretes Beispiel im Kopf?

[Demirug]

Hast du zufällig ein konkretes Beispiel im Kopf?

In „Der Termin“ wird im Prinzip nichts anderes als das klassische V Model (nicht die neue XT Variante) eingesetzt. IMHO funktioniert das V Model in der Praxis einfach nicht weil es von zu vielen theoretischen Voraussetzungen ausgeht die einfach nicht der Realität entsprechen.

Zudem ist das V Model aus der Sicht des Personalmanagements sowieso eine Katastrophe. Die eigentlich notwenige starke Veränderung der Teamgröße während des Projektverlaufs (die DeMarco ja erkannt hat) ist dabei ja nur der Anfang.

[Monger]

Okay, da hast du sicherlich Recht. Ich fand aber die Problematik beim Personalmanagement sowieso viel spannender, weil er so ziemlich das Gegenteil von dem lehrt was in der Praxis vorkommt :D - kurze Arbeitszeiten, "Kummerkasten", Termine lieber ein Stückchen zu spät ansetzen um früher fertig zu werden, lieber gar nichts machen als was falsches machen...

Da waren schon einige recht lustige Thesen dabei! :D

[Demirug]

Okay, da hast du sicherlich Recht. Ich fand aber die Problematik beim Personalmanagement sowieso viel spannender, weil er so ziemlich das Gegenteil von dem lehrt was in der Praxis vorkommt :D - kurze Arbeitszeiten, "Kummerkasten", Termine lieber ein Stückchen zu spät ansetzen um früher fertig zu werden, lieber gar nichts machen als was falsches machen...

Da waren schon einige recht lustige Thesen dabei! :D

Die meisten dieser Dinge erwähnte Steve Maquire bereits in Strategien der Software-Entwicklung. Das Buch entstand aus seiner Praxis Erfahrung bei Microsoft. Wobei man hierbei natürlich nicht unerwähnt lassen darf das Maquire zu dieser Zeit wohl auch eine Ausnahme unter den Projektmanagern bei Microsoft war.