10 For the Producers Episode 08

Bitte entschuldigt, dass die Übersetzung von „10 for the Producers“ diesmal etwas auf sich warten ließ. Travis Day und Eric Kieron Davis haben diesmal 10 – wie sie selbst immer wieder betonen – sehr tolle Fragen beantwortet und sind dabei mitunter ziemlich ins Detail gegangen.

Frage 1: Zukünftige Prognosen

Bjoern Schwartz fragt:
Denkt ihr, dass die Entwicklung von Star Citizen stabiler ablaufen wird (Die Zeitplanung genauer zu prognostizieren) sobald das FPS, die Instanziierung, Large World und AC 2.0 fertiggestellt sind? Oder wird das zu einer Menge Reibereien führen, wenn all dies integriert ist? Wie schafft ihr einen Ausgleich dieses Problems, von Integration neuer Features und einer stabilen/vorhersehbaren Entwicklung zwischen dem Hauptentwicklungszweig und unserem live/PTU-Zweig?

TD: Das ist eine Gute Frage … und *High Five* wir haben unsere erste für Produzenten relevante Frage in dieser Show.

EKD: Woohoo!

TD: Ja, um nun deine Frage zu beantworten: Du hast hier einige Dinge hervorgehoben, wie das FPS, Instanziierung, insbesondere Large World, und was wir eigentlich meinen, wenn wir über diese Dinge reden, sind neue Features und die sind definitiv – zumindest für die CryEngine – neue F&E-Features (Forschung&Entwicklung), die also viel Arbeit vom Programmierteam erfordern und es gibt da ein Endziel, das sie erreichen möchten, welches zu Beginn gesetzt wurde, doch der Weg dort hin war nicht sofort von Anfang an klar. Das ist also etwas, das man irgendwie unterwegs entdeckt. Was man also sehen wird ist, dass diese Features sehr viel schwerer vorherzusagen sind. Sie haben einen geringeren Planbarkeits-Quotienten, und diesen Begriff zu prägen. Also ja, das vergrößert unser Unvermögen die Zeitschienen für diese Dinge zu planen und das beeinflusst auch Nachfolgende Sachen. Nun, wenn etwas auf Large World beruht und wir nicht wissen wann das so weit sein wird, dann wissen wir auch nicht wirklich wann das abhängige Ding so weit sein wird und während man dem näher und näher kommt wird all das klarer und es ist quasi unser Job zu betreuen und zu updaten und zu betreuen und zu updaten und das Bild zu jeder Zeit so klar wie möglich zu zeichnen. Um also diese spezifische Frage zu beantworten, ob dies die Vorhersehbarkeit erhöht, sobald diese Dinge erledigt sind. Die Antwort ist: Während wir dem Ende des Projekts näher und näher kommen und es immer weniger und weniger F&E und es weniger und weniger Arbeit an neuen Featuren gibt und einfach nur neue Inhalte angestrebt werden, wird es unendlich besser planbar. Content ist zwar etwas, das umfangreich ist – ausgenommen Designinhalte – doch ich rede über so etwas wie rohe Kunst-Assets oder Levels, die wir machen müssen. Ich meine, das lässt sich viel einfacher abarbeiten und das ist weit weniger Unbekanntes. Also ja, das wird viel vorhersehbarer und schneller werden, während das Projekt zulegt. Und wir erreichen ungefähr den Punkt der Kurve, an dem wir anfangen mehr geradlinigere Inhaltsproduktion zu machen und die Feature-Produktion drosseln. Ich hoffe also, das beantwortet deine Frage und danke für diese Gute.

EKD: Ja, gute Frage. Gute Überleitung: Vorhersehbarkeit.

Frage 2: Planung und das Unerwartete erwarten

Jmack fragt:
Wenn ihr an Zeitplänen arbeitet, wie berücksichtigt ihr dann das Unerwartete? Ich stelle mir vor, dass Spiele-Entwicklungs-Zeitlinien viele vernetzte Abhängigkeiten haben und eine Verzögerung auf einer Arbeitsschiene hält womöglich eine andere auf. Plant ihr für unausweichlich auftretende Probleme einfach Extrazeit mit ein? Sind bestimmte Fertigungslinien vorhersehbarer als andere?

EKD: Fantastische Frage und auch eine gute für Produzenten. Ja, ich würde sagen worauf das hinausläuft: Je besser man sich mit seinem Team und den Entscheidungsträgern seines Teams versteht, werden sie einem irgendwie helfen dies zu führen. Für mich – für die Zeitplanung – ist es ein ein großer Teil zu versuchen, so viel wie möglich einzufangen. Das ist also eine Sache, weißt du, du redest mit einem Künstler oder Entwickler und du sagst: “Wie lange wird X brauchen?” und sie antworten: “Fünf Tage.” Du denkst dir: “Großartig, fünf Tage.” und trägst das ein. Doch es gibt da noch ein paar Dinge drumherum, wie: Beinhalten diese fünf Tage nur die Arbeit, Zeit am Arbeitsplatz, ohne Meetings, sich durch die Arbeit schleppend? Bezieht das Iterationen mit deinem Leiter, deinem Vorgesetzten, mit … du weißt schon … mit alle Projektbeteiligten … ?

TD: … dem Art Director, Chris …

EKD: Genau! Umfasst das irgendwelche anderen Puffer, die wir womöglich in anderen unabhängigen Verbindungen brauchen? Und wenn das der Fall ist, dann ja, dann sind das die fünf Tage, die ich einplane. Dann können wir die ganze Sache so ansetzen, wenn wir die Masse der Arbeitsmenge nachvollziehen. Wie du schon sagtest, wenn wir nicht unbedingt forschen und entwickeln müssen und wir innerhalb der Planbarkeit sind – so sehr dieses Wort keine reale Sache ist, ist das doch etwas, das wir versuchen zu benutzen – man entwickelt ein bisschen mehr Verständnis. Sobald du dein Team verstehst, sobald du den Entscheidungsprozess kapierst, sobald du die Dynamik und Gegensätzlichkeit der Gruppe erkennst, wird das etwas besser. Ich denke ein passender Spruch lautet: “Ein Schlachtplan ist hinfällig, sobald der erste Schuss abgefeuert wurde.”

TD: Ja, nach dem ersten Kontakt mit dem Feind …

EKD: Ja, jeder Plan geht also den Bach runter und als Produzenten ist es unsere Aufgabe mit diesem Plan, diesen Ideen zu iterieren. Und “Planbarkeit” ist ein Wort, das wir in der Spiele-Entwicklung nicht oft genießen können. In jeder Unterhaltungs-Kreation … ich meine, wir schaffen nicht unbedingt etwas Neues, doch wenn man versucht etwas Neuartiges zu machen, dann hat man nicht unbedingt ein Geschäftsmodell, dem man folgen kann.

TD: Ja, auch wenn es neu für das Team, neu für die Leute die das machen, ist. Tatsächlich ist ein Punkt, den du erwähntest wirklich bedeutend, nämlich dass viele Leute den Eindruck haben, dass man sich zu Beginn eines Projektes hinsetzt, das Budget und den Zeitplan für das gesamte Projekt auslegt und dem dann einfach folgt. Du bist im Elfenbeinturm irgendwo und du überblickst quasi das Schlachtfeld …

EKD: Du redest mit niemandem. Du sitzt da und schaust zu.

TD: Es ist viel mehr wie bei einem Sergeant im zweiten Weltkrieg, der eine Granate an die Frontlinie wirft, weißt du? So in der Art. Es ist viel mehr von Moment zu Moment, denke ich.

EKD: Mit Sicherheit. So sehr ich auch denke, dass wir als Produzenten planbar sein möchten … Zeitplan und Finanzierung … es ist schwer das zu erreichen. Das ist also eine Menge Arbeit, eine Menge Iterationen, eine Menge Kommunikation, und viel Verständnis dafür, wie sich der Plan entwickeln kann. Sobald man also all die involvierten Mitspieler versteht, kann man – weißt du, sobald ich anfing Projekte zu planen, an denen ich in der Vergangenheit plante, ich habe das ein ein paar Mal gemacht, oder mehrfach mit der selben Gruppe zusammengearbeitet – das hilft enorm. Ich weiß zum Beispiel, dass Tim immer das macht, und Ashley macht jenes, und Fred tut immer dieses. Ich kenne einige ihrer Eigenarten. Großartige Eigenheiten, die sie super in ihren Aufgaben machen, und das hilft mir besser als Produzent zu planen. Also ich hoffe, das beantwortet deine Frage. Das ist eine tolle Frage.

Frage 3: Wie lange ein Feature braucht

Newt fragt:
Ist es möglich ein Beispiel dafür zu geben, wie lange jeder Aspekt eines Features oder Assets braucht? Wie viel Prozent werden beispielsweise in Konzept, Design, Code und in Feinschliff, etc. Investiert? Folgt jedes Asset/Feature einer ähnlichen Gliederung, oder belasten einige in bestimmten Bereichen manche Ressourcen stärker? Wenn ja, gibt es da irgendwelche Anzeichen an jedem Asset, wenn das in einer bestimmten Phase länger braucht?

TD: Ich denke eines der ersten Dinge zu Beginn ist zu wissen, dass sie alle verschieden sein werden. Jeder Feature ist eine einzigartige Schneeflocke. Generell kann man sie Kategorisieren und – sagen wir Schiffe zum Beispiel. Schiffe werde wohl … wenn es dieses, oder jenes Schiff ist wird vermutlich jeder Schritt in der Pipeline einen proportionalen Zeitanteil brauchen. Wenn es dieses Radarsystem im Vergleich zu diesem Raketensystem ist … wird das etwas schwammiger. Also ich denke, ein Schiff wäre ein gutes Beispiel um diese Frage herunterzubrechen und sie zu beantworten. Wie viel Prozent der Zeit wurde für das Konzept aufgewendet? Insgesamt für ein Schiff würde ich sagen: vermutlich 20-25%, klingt das ungefähr richtig?

EKD: Ja, und weißt du … wo wir von Konzepten reden … ich denke das ist ein Ort, wo wir viel Zeit verbringen möchten. Richtig? All unsere Designer-Fragen, Gameplay-Gruppen-Fragen, Kunst-Führungs-Fragen werden beantwortet. Im Grunde ist das der ‘weniger aufwendige’ Anteil des gesamten Entstehungsprozesses.

TD: Das ist ein wirklich triftiger Punkt, es kann genauso angesehen werden, wie die Vorproduktion für das gesamte Spiel. Hier räumt man alles aus dem Weg, sodass jeder andere, ohne Stop-and-Go, einfach machen kann: “Was, wenn das Fahrrad eine Fahrradkette braucht?”

EKD: Ja, genau. Also, 20-25%. Ich denke das trifft es.

TD: Die Design-Seite … nun, das Design ist da quasi mit enthalten, sagen wir also 25-30% für Konzept, Design, Überprüfung der Animationen … all das passiert in dieser Phase. Die Programmierungs-Seite … nun ja, in diesem Fall würde ich Modeling sagen, für ein Schiff währen das wohl ungefähr 70% der Zeit. Das ist der Löwenanteil.

EKD: Und da möchte man viel, viel hinein investieren. Das ist der Look, das ist das Gefühl, so wird es in der Engine funktionieren. Das ist also alles, richtig?

TD: Ja. Und dann natürlich: Audio. VFX. Die letzten 5%.

EKD: Ja. Ein sehr wichtiger Teil, aber … absolut.

TD: Das ist tatsächlich eines der Dinge, was in der Produktion gerne mal auftritt und etwas, das man im Auge behalten und bekämpfen sollte, wenn man ein Produzent sein möchte: VFX und Audio sind der oft vergessene, aber sehr wichtige letzte Schritt in jedem Prozess.

EKD: Ja, um nochmal auf den Planbarkeits-Teil der letzten Frage zurückzukommen: Wenn Dinge, von denen du hoffst, dass sie nicht verschiedene andere Aspekte verschieben, dies möglicherweise doch tun … es muss irgendwo ein Enddatum geben. Und oftmals bewegt sich dieses Enddatum nicht und alles wird zusammengestaucht. Und du kannst darüber mit unserem Audio- oder auch dem Effekt-Team reden … sie planen das irgendwie aus, was du aber nicht möchtest. Du möchtest, dass sie die Fähigkeit haben so kreativ wie möglich zu sein und das coolste überhaupt zu kreieren. Also eine der Arten, wie wir das quasi bekämpfen ist, dass wir sie so früh wie möglich einbeziehen, vielleicht wie zuvor im Konzept: fangt einfach an darüber nachzudenken, wie das Schiff klingen könnte, oder wie dieser Charakter …

TD: Schaut euch die beweglichen Teile an …

EKD: Ja genau, wenn es um Animation geht – absolut.

Frage 4: Outsourcing

[TAC] BuzZz Killer fragt:
Wenn es darum geht ein Projekt zu besetzen, wie kosteneffektiv ist es etwas auszulagern im Vergleich zum anheuern eines neuen Team-Mitglieds? Wie wird diese Entscheidung gefällt?

TD: Für’s Protokoll: Ich mag diese Frage wirklich, da dies auch eine Debatte in der Industrie ist.

EKD: Ja. Für mich kommt es meistens auf folgendes an: Wie viel Zeit hat man für das Projekt? Wie viel Geld hat man für das Projekt? Wann muss das Projekt rausgebracht werden? Danach wird sich offensichtlich die Qualität des Projektes richten. Doch sobald man mindestens einen dieser drei Aspekte versteht – oder so viele von diesen, wie man kann – hilft einem das, eine bessere Entscheidung zu treffen. Du ziehst also in Betracht Leute lokal anzustellen kontra Leute regional oder national zu beschäftigen. Du schaust dir … Für Spiele oder andere Dinge in der Vorproduktion ist das ist das eine große Anlaufphase, man baut viel am Anfang, aber nicht unbedingt am Ende. Es macht also Sinn Leute einzustellen. Aber macht es auch Sinn permanent mehr Leute zu beschäftigen? Nicht unbedingt. Ich denke, die Wunschvorstellung ist es, zu versuchen so viele Leute wie möglich in Jobs in der Spiele-Industrie zu bringen und uns alle eingestellt zu behalten und eine tolle Zeit beim erstellen großartiger Spiele zu haben. Doch in der Realität kommt es darauf an: Wie können wir dies für den bestmöglichen Preis realisieren, doch mit dem Qualitätsanspruch, den wir möchten?

TD: Ja und ich denke, dass Outsourcing irgendwie einen schlechten Ruf in unserer Industrie erhält. Da heißt es: “Die haben unsere Jobs geklaut!” oder “Das bedeutet schlechtere Qualität.” Und tatsächlich gibt es eine Menge super-talentierter Leute da draußen, die Outsourcing-Arbeit erledigen und das ist also nicht unbedingt gleichzusetzen mit schlechterer Qualität. Das mit dem Jobs wegnehmen ist die andere Sache, worauf ich folgendes antworten möchte: … Wenn man jemanden wie Chris Smith hat – Chris Smith, Leitender Fahrzeug-Künstler, macht einige wunderschöne Schiffe, machte viele der großartigen Schiffe, die wir im Spiel haben – ihn zu bitte 34 Variationen von Kisten, Fässern und Topfpflanzen zu machen ist … vielleicht macht er es, ich weiß es nicht, ich möchte da nicht für Chris sprechen, doch das wäre ein Missbrauch seines Talents. Denn man kann nicht einfach jeden dazu bringen eines der Schiffe zu machen, die er erschafft, doch man kann viele unterschiedliche Leute finden, die diese Topfpflanzen oder die Kisten erstellen.

EKD: Und ich finde, jemandem, der eher ein Anfänger ist – gerade erst in die Industrie einsteigt – die Möglichkeit zu bieten an einem Spiel zu arbeiten … das ist perfekt für die.

TD: Genau.

EKD: Das vermittelt ihnen ein Gespür für: Wie passt das ins Spiel? Wie fügt sich das in das Gesamtsystem ein?

TD: … Was ist die Pipeline? … Ja.

EKD: Ja. Direkt nach der Schule, oder jemand, der nach einem Job sucht, oder eine Arbeit für zwischendurch … absolut. Wir versuchen, so viele Jobs wie wir können zu vergeben, doch das auch mit den realistischen Zielen dieses Projekts auszugleichen, ohne das aufzublasen … alles, auch Budget oder Zeitplan, richtig?

TD: Ja. Das ist eine weiter Sache, womit viele Studios kämpfen. Ich meine, in dieser Industrie ging es für die längste Zeit nur um alles oder nichts, richtig? Man hat also immer weiter aufgestockt, bis man schließlich genügend Leute hatte um das Produkt zu verschiffen … und dann nach einem Quartal wird jeder entlassen, da man sich das nicht leisten kann. Und dann gab es da eine beliebte Idee: “Oh, wir werden zwei Teams gleichzeitig im Studio haben, sodass wenn ein Projekt in der Vorproduktion steckt, ist das andere in voll aufgeblühter Produktion und wir haben den Großteil von Team 2 zu Team 1 verlegt und sobald dann Team 1 ausliefert, geht jeder zu Team 2 und wir machen mit Team 1 Vorproduktion.” Und dies funktionierte tatsächlich für eine ganze Weile und hat sich verbessert, denke ich. Doch eines der Dinge, die uns Outsourcing erlaubt – und das war wirklich wichtig für Chris – ist, dass du willst, dass jedem dem du angeheuert hast klar ist, dass du eine Verpflichtung mit denen eingegangen bist. Das unternehmen hat ihnen zugesichert sich um sie zu kümmern, sie zu schulen, sie in ihrer professionellen Kariere zu fördern und im Austausch dafür bekommen wir diese wunderschöne Kunst, wir erhalten wunderbaren Code … worum es auch immer bei dieser Transaktion geht. Und man möchte diesen Leuten Sicherheit und Vertrauen und Glauben in den Job bieten. Outsourcing ist also ein Mittel, welches man nutzen kann um zu wachsen, ohne das Risiko einzugehen nichts bei diesem Kontrakt zu gewinnen.

EDK: Ja um noch für eine Sekunde beim Outsourcing zu bleiben: Wenn wir Outsourcing sagen, dann meinen wir damit nicht einfach lokal Jobs von Leuten zu wegzunehmen – oder welches Wort auch immer man benutzen möchte, da ich denke, dass es negativ behaftet sein wird. Die Outsourcer, die wir nutzen – einige von denen sind vor Ort. Sie werden nur Outsourcer genannt, da sie sich nicht unbedingt im Haus befinden.

TD: Ja, ich weiß … Leute wie Ether.

EKD: Du hast es erfasst. Es gibt da draußen ganze Teams, die mit mehreren Studios zusammenarbeiten. Sie heuern Künstler, oder Programmierer, oder was auch immer an und dann arbeiten sie mit Unternehmen wie uns zusammen, um deren Spiele zu erstellen. Und das ist tatsächlich eine sehr große Industrie. Viele Leute erhalten Arbeit, dank dieser Outsourcing-Möglichkeit.

TD: Die andere Sache, auf die man hinweisen sollte ist, dass dies deren gesamtes Geschäftsmodel darauf basiert, dass sie einen Gesellschaftsvertrag mit einem Typen schließen, der andernfalls ein Freischaffender wäre, was wirklich “friss oder stirb” bedeutet und unsicher ist. Und er bekommt einen normalen Vollzeitjob und sie gehen da raus und jagen im Grunde nach Arbeit … hohlen sich 20 Projekte auf einmal und erhalten so ihre Unternehmensstabilität. Das ist ein interessantes Ökosystem. Weißt du, ich habe nie realisiert, was für ein Geschäfts-/Produktions-Nerd ich war, bis ich diese Art von Fragen erhielt, die mich extrem begeisterten.

EKD: Ja, das begeistert uns. Um auf deine ursprüngliche Frage zurückzukommen: Wir betrachten all diese Faktoren und dann noch alles, was zu dieser Zeit für das Projekt Sinn macht. Denn kein Projekt gleicht dem anderen, selbst wenn man … ich werf’ mal Madden 25 ein … da mag es eine Art von Formel geben, doch das ist trotzdem ein neues Projekt, neue Technik, neue Künstler, neue Spieler auf dem Feld. Es hat trotzdem Neuheiten an sich, es kommt also alles auf das Projekt an.

TD: Das muss schrecklich sein. Sie müssen diese Trikots jedes Mal neu machen.

EKD: Jedes Mal … neue Pipeline, ja. Grauenhaft … oder vielleicht auch spaßig, wenn man Trikots mag.

TD: Ja. Ich liebe die Vorstellung, dass es irgendwo da draußen einen Typen gibt, der nichts anderes als Radkappen für GTA macht.

EKD: *lacht* Sicher. Und er liebt es. Sein Vollzeitjob ist es echte Radkappen zu machen, und sein Teilzeitjob sind die Virtuellen.

TD: Und an Wochenenden bringt er Radkappen an seinem Auto an. *lacht*

EKD: Ich liebe es.

Frage 5: Auswirkungen von Verzögerungen

Amontillado fragt:
Wenn Verzögerungen im Produktionsstrom auftreten – so wie das mit Star Marine der Fall ist – was unternehmen dann die Produzenten bei CIG um die Auswirkungen auf den Gesamtzeitplan der Spielentwicklung zu minimieren? Mir ist klar, dass diverse Module parallel entwickelt werden um zu helfen dies auszugleichen, doch gibt es da noch andere bestimmte Sachen, die gemacht werden, derer wir uns vielleicht nicht bewusst sind?

TD: Also das ist eigentlich eine sehr gute Frage für Sean Tracy … Sean Tracy, Jeremy Masker … mit diesen Leuten führe ich ständig Diskussionen – manchmal auch Streitgespräche – darüber, was der beste Weg ist um das Risiko, dass dies andere Ströme verzögert, auszugleichen und abzuschwächen.

EKD: Positive Streitgespräche.

TD: Wir haben produktive Streits – weißt du, eine weitere Sache, die ich in der Produktion für wichtig halte, ist total offen zu sein: ‘Meine Idee ist nicht immer die Beste.’ generell sollte jeder in der Spiele-Entwicklung so denken und das ist wie … um ein Zitat von unseren alten Freunden bei Activision zu gebrauchen: “Das ist der Kampf um den besten Einfall.” Und das ist wirklich wahr. Ich liebe diese Gespräche, da du vielleicht denkst, dass du recht hast. Doch dann kommst du da rein und denkst dir: “Ah okay, das ist eine bessere Lösung.”
Wie auch immer. Zurück zu deiner Frage. Der eigentliche Punkt davon ist … ja. Wir haben eine interessante Strom- und Zweigstruktur. Wenn wir also über ‘Main’ reden, dann meinen wir den Haupt-Code-Strom … und das ist eigentlich nicht mehr der Fall bei uns … das Meiste unserer Spielentwicklung machen wir in … das lässt sich am besten mit zwei Pyramiden beschreiben: zum einen eine umgekehrte Pyramide und darunter eine normale Pyramide. In der Mitte sitzt ‘Main’ und darunter haben wir ‘Game Dev’, also ‘Game Dev FPS’, ‘Game Dev AC’, ‘Game Dev Social’, ‘Game Dev …’ und da arbeitet jedes Team in seinem eigenen kleinen separaten Bereich. Nun gibt es da einen Haufen Zwischenströme, die sich ständig gegenseitig synchronisieren. Was das bedeutet ist: Wenn zwei Leute in zwei unterschiedlichen Strömen an der selben Datei arbeiten, dann bringt es sich da ein, sie integrieren sich gegenseitig, schickt eine E-Mail an die beiden, die besagt: “Löst das. Stellt sicher, dass das sauber zusammenkommt” Und alles was dann sauber, stabil und schön ist – theoretisch – gelangt dann zu ‘Main’. Dann verzweigen wir das von ‘Main’ aus um eine Veröffentlichung zu machen. Der Punkt, ab dem wir also zur oberen Pyramide kommen ist wenn wir sagen: “Hey, wir möchten Star Marine veröffentlichen.” Was … wir sagten, dass wir Star Marine veröffentlichen möchten, da wir das machen werden. Wir schaffen dann also einen Zweig darüber – das ist der Star-Marine-Veröffentlichungs-Zweig – und dieser wird letztendlich an die Öffentlichkeit gelangen. Dies wird also abseits von ‘Main’ kreiert, was theoretisch – mit dem System, das im Ökosystem der unteren Pyramide abläuft – schön stabil bleibt, und wir machen den letzten Feinschliff, Bugfixing und – sehr zu Seans Ärger – vielleicht auch etwas Feature-Entwicklung in diesem Release-Strom, der dann später, sobald wir veröffentlichen, wieder durch die ganze Baumstruktur zurück-integriert wird. Das ist also die technische Struktur, wie wir unser Perforce angeordnet haben, um zu versuchen den Einfluss, den die Veröffentlichungen aufeinander haben, zu mildern.
Doch dann gibt es da auch … ich nenne sie soziale, psychologische oder Marketing-Einflüsse. Wenn du versuchst deine Veröffentlichungen ein bisschen auszubreiten um einem Release Zeit zum atmen zu geben, um das Team zu sammeln und ihm Zeit zu geben, sich auf dieses Release zu konzentrieren und sicherzugehen, dass sie es nach seiner Veröffentlichung unterstützen und alles andere. Auf diese Weise möchte man also seine Releases ein bisschen ausbreiten, denn sonnst brennt man jedem im Team aus und zerstreut die Konzentration. Möchtest du da noch irgendwas hinzufügen?

EKD: Nein, du hast diese Frage gemeistert. Das war großartig. Ich habe nichts hinzuzufügen. Ich denke, was wir versuchen zu entschärfen ist, dass jedes einzelne Modul die anderen Module negativ beeinflusst. Ich denke, das ist es eigentlich, worüber wir hier sprechen. Und als
Produzenten versuchen wir Wege zu finden – so wie das Travis über die Jahre exzellent gemacht hat – Wege zu finden … “Wie können wir dieses Modul voranbringen ohne die anderen zu beeinflussen?”

TD: Das ist ein wirklich guter Punkt, den du da ansprichst, denn … so etwas kommt vor. Wir versuchen es nur zu minimieren. In der Produktion trifft auf viele Dinge zu: “Ich kann nicht versprechen, dass das nicht passieren wird, doch ich kann versuchen es zu begrenzen und dessen Auswirkungen zu minimieren.”

EKD: Ja, und so viele Pläne wie möglich in unserm Gepäck zu haben. Wie: “Hier ist der Plan, auf den wir alle abzielen. Doch hier sind unsere anderen 10 Pläne, die wir noch auf Lager haben für den Fall, dass … ” Wir haben die im Hinterkopf, oder als Teil unserer Zeitpläne

TD: Danke dir. Gute Frage.

EKD: Ja, toll!

Frage 6: Senior Producer

Nostromo1977 fragt:
Als Senior Producer, was ist da der schwierigste Aspekt dieses Jobs? Leute/Zeit zu managen, geplante Meilensteine zu erreichen, die Kommunikation zu erleichtern oder im Budgetrahmen zu bleiben?

EKD: Ja, all diese auszubalancieren …

TD: Ja, die hängen alle zusammen.

EKD: Ich denke das anstrengendste für mich ist es, das alles abzustimmen. Ich denke nicht, das irgendeines davon deutlich schwieriger ist als die anderen. Jedes davon erfordert andere Arten von Fähigkeiten, nicht wahr? Also mit Leuten zusammenzuarbeiten, sie zu führen, zu helfen sie zu großartigen Leistungen zu inspirieren … dies erfordert viel mehr Soft Skills (soziale Kompetenz). Es kommt also auf deine Fähigkeiten als Produzent an. Wie ich schon vor ein paar Wochen in Around the ‘Verse sagte: Es gibt unterschiedliche Arten von Senior Producers. Jeder hat – hoffentlich – schmeichelhafte Fähigkeiten, die einander helfen zusammenzuarbeiten um ein großartiges Team zu bilden. Einige Leute sind also sehr auf Soft Skills fokussiert um einfach nur das Team zu vereinen und diesen Kommunikations-Mittelpunkt zu bilden, der einfach alles synchronisiert. Andere sind technischer, manche lieben es Zeitpläne zu schmieden … wir alle haben Synchronisierungs-Fähigkeiten, denke ich.

TD: Ich denke, du und ich – wir veranschaulichen dieses Verhältnis …

EKD: Auf Jeden!

TD: Ich bin so “eh” beim Planen. Soweit es mich betrifft, ist das nicht meine größte Stärke und ich denke, dass du wirklich stark bist in der Planung und du bist hervorragend in dieser Sache. Wir beide haben ziemlich gute Soft Skills, würde ich sagen, darin sind wir ebenbürtig. Dein Fokus liegt dann viel mehr auf der Kunst und der Terminplanung und der Pipeline-Seite und ich denke, das weist du selbst auch sehr gut. Mein Fokus liegt wohl eher auf der technischen und der Design-Seite …

EKD: Absolut.

TD: Ich denke darum sind wir ein gutes Team.

EKD: Ich stimme dir völlig zu. Ich denke nicht, dass das eine oder andere für einen von uns schwieriger wäre – wenn man uns als Beispiele nimmt. Ich denke es kommt wirklich nur darauf an, was deine Kernstärken sind und dann die Leute in deinem Team zu finden, die drumherum mit ihren Fähigkeiten aushelfen können, sodass wir alle das erledigen können. Ich denke, Nostromo hat einige wichtige Punkte hervorgehoben, dass dies die wichtigsten Dinge sind, die wir als Produzenten beachten. Das sind die Hauptanliegen. Zu versuchen im Budget zu bleiben, mit einem fantastischen, großartig funktionierenden Team, welches toll kommuniziert. Wir erreichen so viele Meilensteine, wie wir können, um die bestmögliche Erfahrung herauszubringen. Das ist unser Ziel, darum müssen wir zurück gehen, zu all den verschiedenen … Pfeilern der Produktion, wie du sagtest. Ich denke das Ausbalancieren ist auf jeden Fall der härtere Teil.

Frage 7: Wissenschaft und Bauchgefühl

Logical Chimp fragt:
Wie viel ist bei der Planung kalkulierbare ‘Wissenschaft, und wie viel ist ‘Bauchgefühl’? Und wie erarbeitet ihr die Zuverlässigkeit/Genauigkeit einer Entwickler-Einschätzung für die Implementierung eines Features?

TD: Ich werden den letzten Teil der Frage zuerst beantworten: Jeder Entwickler ist ganz unterschiedlich. Als Produzent ist es schwierig genaue Schätzungen aus Leuten herauszukitzeln, bis man sie wirklich kennt. Je mehr Zeit man also mit ihnen verbringt, desto eher kann man sagen: “Ok, 4 Stunden für diesen bedeuten in Wirklichkeit 2, oder 4 Stunden für jenen sind in Wahrheit 8.” Es ist nicht so, als ob einer langsamer oder schneller ist, es ist wirklich nur die Art und Weise, wie sie die Dauer einschätzen.

EKD: Ja, ich denke, wir haben bei Jmacks Frage darüber gesprochen: Je besser du dein Team verstehst, desto einfacher wird es. Die Teams, die schon seit zig Jahren zusammenarbeiten, wissen ganz genau, was sie meinen. Oder die müssen das nicht einmal machen. Oftmals bekomme ich ein Gespür dafür, nachdem ich mit einem bestimmten Team eine gewisse Zeit zusammengearbeitet habe, ich könnte ihre Angaben schon im Vorfeld eintragen. Natürlich würde man noch nachfragen, um sicherzugehen, dass sie stimmen. Ich weiß, dass Jennifer üblicherweise drei Wochen dafür braucht, du weißt … da steckt eine Wissenschaft dahinter und dieses Wissen versteht dein Team und dadurch auch das Projekt, an dem du arbeitest.

TD: Ja und die technischen Details zu kennen, oder zu wissen, was sie machen … . Während der 1.0-Krise zum Beispiel, sind wir an einen Punkt gelangt, wo ich 90% der Aufgaben, die durch kamen, zuordnen konnte, was – wie ich finde – ein ziemlich guter Wert ist. Und das habe ich mir dann mit den Leuten angesehen und sie sagten: “Yup,yup,yup,cool.” Ein weiteres lustiges Spiel für jeden angehenden Produzenten da draußen ist, das “Was wäre wenn … ?”-Spiel mit jedem zu spielen, der dir eine Schätzung gibt, besonders wenn diese länger ist. Wenn es eine Sache für 2-3 Wochen ist und sie sagen: “Ja wir könnten es wohl in 3 oder 4 Wochen schaffen” Und du sagst: “Oh, du würdest wohl gerne einen Tag frei nehmen? Doch was, wenn du krank wirst? Was wenn dein Hund krank wird?” Das ist zwar irgendwie böse – all diese schlimmen Sachen, die dir im Leben passieren können, die dich zu Fall bringen könnten. Doch es gibt immer viele Dinge, welche die Leute nicht berücksichtigen, das ist völlig natürlich. Sie haben sogar Studien dazu angestellt und ich habe auch in Büchern darüber gelesen – Büchern wie “Drive” von Daniel Pink – was großartig ist.

EKD: Ja, das ist toll.

TD: Wie auch immer, als menschliches Wesen hat man eine natürliche Vorliebe dafür eine große Aufgabe zu unterschätzen und eine kleine zu überschätzen. Da kann man also einige grundsätzliche mathematische Modifikatoren anwenden, so kommen wir zurück zu deinem “ist das berechenbar?”Guter Durchschnitt ist, dass jeder etwa 70% eines Achtstundentages arbeitet, zwischen Toilettengängen, Mittagessen und bla, bla, bla. Daran kann man sich also auch orientieren. Wenn man also eine Vierzigstundenaufgabe hat, wird das eineinhalb Wochen Arbeit entsprechen. Solche kleinen Sachen kann man also mathematisch machen, der Rest ist Bauchgefühl. Besonders wenn man die Finalisierung eines Projektes betrachtet kann man sehen, was das Burn-Down-Diagramm sagt – wie viele Bugs hinzugekommen sind im Vergleich zu denen, die gelöst wurden. Du fragst dich: “Okay, was ist die Steigerungsrate?” und trägst das ein. Und dann kannst du deine eigenen kleinen Berechnungen anstellen, die besagen: “Okay, wahrscheinlich um dieses Datum herum.” … Ich erinnere mich an Arena Commander 0.8. Ich wusste, um all die kritischen und wichtigen Probleme zu lösen habe ich diese Formel angewendet, und ich glaube das Datum war der 30. Mai und letztendlich kamen wir beim 4. Juni raus.

TD: es geht also um beides – Mathe und Bauchgefühl.

EKD: Zu diesem Punkt: Ich denke, Erfahrung … . Der Grund, warum sie sagen, je mehr zeit man mit etwas verbringt – das gilt für jeden Job – desto vertrauter wird man mit diesen Informationen. Je mehr Erfahrung man also hat – ob nun mit einem Team, oder indem man einfach in der Industrie oder mit einem bestimmten Produkttyp arbeitet – vielleicht hast du schon immer FPS gemacht – desto besser ist das für deine Angaben und dein Bauchgefühl reagiert auf diese Erfahrung. Doch eine Sache, zu der ich die Leute mit dieser Erfahrung auffordern möchte ist … mit dieser Erfahrung, diesem Wissen anzufangen, doch dann mehr hinzuzufügen, es zu brechen und nicht einfach … viele Produzenten bleiben da einfach stehen.

TD: Man sitzt in seiner Zone.

EKD: Ja, die Technologie verändert sich ständig. Neue fantastische Talente kommen aus dem College, nicht wahr? Es gibt neue Sachen, die Leute da draußen machen mit einem kleineren Team, als was du jemals vor 20, 30 Jahren gemacht hast …

TD: Völlig neue Wege seine Zeit zu managen.

EKD: Du hast es erfasst. Also bleib agil genug um dich mit diesem Zeug mitzubewegen. Doch auch eine solide Basis aus Erfahrungen ist gut. Tolle Frage.

Frage 8: Wie man ein Pruducer wird

Zero Lambda fragt:
Was unternehmen Produzenten um ihre Fähigkeiten zu stärken? Müde zu sein ist offensichtlich ein Faktor und kann die Leistung beeinflussen und wie schnell Dinge gemanagt werden. Es steht also fest, dass ein guter Nachtschlaf die Kapazität Dinge zu handhaben erhöhen kann. Jedoch in Bezug auf andere Dinge, außerhalb der Arbeit – welche Arten von Aktivitäten kann man unternehmen um seine Fähigkeiten für die “Produktion” zu steigern? Gibt es da Übungen in einem Software-Programm, die man als Ressource benutzen kann, oder eine außenstehende Gruppe aus anderen Produzenten, von der ihr ein Teil seid? Bücher, die ihr lest um Inspiration zu sammeln?

EKD: Ja. Tolle Frage.

TD: Okay, jetzt fühle ich mich mies, denn das ist tatsächlich eine fantastische Frage. Ich habe sie diesen Morgen in den Foren gelesen, als wir unsere Fragen aussuchten. Und ich dachte mir: “Wow, das ist eine großartige Frage, ich sollte sie direkt beantworten.” Und ich schrieb ihm eine Antwort im Forum.

EKD: Also besucht das Forum. Nächste Frage.

TD: Nein, nein, nein. Im Ernst, wir sollten die beantworten, denn das war eine echt gute.

EKD: Du hast schon dazu gepostet, du hattest etwas Vorbereitungszeit. Es gibt Vieles, was man da tun kann. Ein Produzent zu sein hat viele verschiedene Aspekte. Und darum gibt es auch viele verschiedene Fähigkeiten, die man an unterschiedlichen Stellen lernen kann, um sich für diese Rolle vorzubereiten.Bücher sind großartig, wie du eben schon über “Drive” gesprochen hast. Mein Lieblingsbuch zu Führerschaft ist “First, Break All The Rules.” Es ist fantastisch. Und dann gibt es da “The Game Developer’s Handbook” und es gibt ein Produktionsbuch da draußen, es gibt eines zur Teamführung für Spiele-Entwicklung, geschrieben von Seth Spaulding, das ich liebte. Es waren quasi nur Übersichtsbilder von kleinen Studios. Allerdings es gibt eine Masse von richtig coolen Büchern da draußen, von sehr talentierten …

TD: Dale Carnegie’s “How to Win Friends and Influence People.”

EKD: Ja, das ist fantastisch. Denn ich denke, was so cool – oder ungewöhnlich – an diesem Job ist, ist dass wir so viele Elemente, so viele verschiedene Dinge haben, von denen wir lernen können, nicht wahr? Also auch der Manager im örtlichen Mini-Markt zu sein ist hilfreich um ein Produzent zu werden, richtig? Leute führen, einen Prozess managen, verantwortlich zu sein, für Dinge haftbar sein. Das ist sehr wichtig. Es gibt da draußen haufenweise Leute, die die überall Spiele machen mit der Masse an SDKs (Software Entwicklungs-Bausatz) da draußen und der Menge der heutigen Möglichkeiten. Ganz zu schweigen von den Schulen die überall aus dem Boden sprießen. Doch es gibt massenweise coole Spiele- … mir fallen gerade keine der Webseiten ein … doch es gibt einige Webseiten, googelt sie einfach, auf denen steht: “Suchen nach Autor. Suchen nach Produzenten. Suchen nach Entwickler.” Springt da einfach bei einem auf und sagt: “Hey, ich werde euer Produzent dafür sein. Ich weiß zwar nicht, was das bedeutet, doch wie kann ich helfen?” Und dann fang an ein Team zu formen, und dann hilf diesem Team ein Ziel zu erreichen, selbst wenn es nur euer erster Sprint ist. Benutze verschiedene Arten des Projektmanagements: Scrum, Agile, Wasserfall, das PNP Programm, welches vom gesamten großen Projektmanagement-Prozess erzählt. Das ist wirklich cool. Es gibt also massenhaft wirklich großartige Schulungen und es und Unmengen verschiedener Dinge, auf die du dich konzentrieren kannst, um in diesem Job gut zu sein. Spiele zu spielen ist fantastisch, aber ist nicht der einzige Teil dieses Jobs. Tatsächlich musst du das Schaffen von Spielen oder Unterhaltung genauso sehr, oder sogar noch mehr lieben, wie das Spielen, um – wie ich finde – diesen Job zu machen.

TD: Ja … da gibt es viele … wie Eric schon sagte, gibt es viele großartige Projektmanagement-Trainingsressourcen/-Lesestoff. Es gibt etliche fantastische Bücher zu Psychologie und Personalmanagement und wie man mit Leuten umgeht. Ein Großteil unseres Jobs ist es, uns mit Kommunikation und Individuen zu befassen. Man kann auch … eine andere tolle Taktik, die ich selbst schon angewendet habe, ist jedes Softwarestück des Teams, mit dem du zu tun hast, kennenzulernen. Somit kannst du tatsächlich mitreden, dich mit ihnen unterhalten und verstehen, wenn sie dir ein Problem beschreiben, was dieses Problem bedeutet, wie lange das brauchen wird. Ich meine, es gibt auch andere Dinge, die du nicht machen kannst, bis du nicht selbst einmal in dieser Industrie warst. Doch es ist eine gute Charaktereigenschaft, sich immer seiner selbst bewusst zu sein. Das ist irgendwie schrecklich, doch ich verbringe viel meiner Zeit in der Nacht, oder – du weißt schon – “Badezimmer-Zeit”, oder was auch immer, damit über frühere Entscheidungen nachzudenken, die ich getroffen habe, oder Dinge die ich sagte, wie ich diese Interaktion gehandhabt habe. Und das spiele ich in Gedanken immer und immer wieder durch. “Was wenn ich es so gemacht hätte?” “Was wenn ich es anders gemacht hätte?” Und ich versuchte irgendwelche neuen Lösungen aufzunehmen. Und das ist, als würde man einen ständigen Rückblick auf sein Leben nehmen, schätze ich. “Was habe ich verbockt? Was haben wir okay gemacht, hätten es aber besser machen können? Und was haben wir gut gemacht?” Oder Sachen wie die E3 … es ist toll, dass wir etwas später heute noch zur E3 gehen. E3, GDC, alte Kollegen zu sehen ist wie ein Netzwerk aus Mentoren zu entwickeln, respektierte Kollegen, selbst wenn du noch nie zuvor mit ihnen zusammengearbeitet hast, kannst du Leute haben, die du respektierst und mit denen du in Beziehung stehst. Oft, wenn ich ein größeres Problem habe, oder eine entscheidende Frage, auf die ich eine Antwort brauche, dann wende ich mich an das, was ich meinen kleinen Rat nenne, weißt du, was ich meine? Ich ersuche das an so viele Leute wie möglich weiterzugeben und zu einer Konsens-Meinung zu gelangen.

EKD: Ja. Wo wir gerade von der Software-Sache reden. Also um ein paar Beispiele zu nennen. Wie 3ds Max und Maya, die werden oft benutzt. Für die Produktions-Nachverfolgung: JIRA. JIRA, Shotgun Software, oder jede Art von Produktions-Verfolgung-Software in den Griff zu bekommen. Ich habe gesehen, dass auch Mircrosoft Projekt von vielen Unternehmen verwendet wird.

TD: Projekt Hansoft. Und man kann sich kostenlose Probeversionen von all denen holen.

EKD: Das kann man absolut. Mit welchen anderen Programmen können sich Leute die Hände schmutzig machen?

TD: Visual Studio. Tatsächlich glaube ich – falls ich mich nicht irre – dass sie Visual Studio kostenfrei machen wollen. Ich glaube, das war vor Kurzem eine Ankündigung. Ich kann mich nicht genau erinnern. Aber ja: Visual Studio. Ich meine, wirklich einfach nur die Grundlagen der Programmierung lernen. Es gibt da draußen so viele Tutorials, die einem beibringen, was eine virtuelle Funktion, ein Pointer ist, wie diese Dinge funktionieren, wie sie interagieren, wie man ein Programm erstellt. Ja und vielleicht macht ihr irgendwas blödes, so wie ich, und erstellt einen kleinen MS DOS Taschenrechner. Doch, weißt du, das verschafft einem ein kleines bisschen einer Grundlage, auf der man aufbauen kann.

EKD: Ja, und ein kleines bisschen zu verstehen, was für ein Team … du weißt schon: Einfach nur ein typischer Produzent zu sein, der jedem hilft ist fantastisch. Doch du wirst feststellen – als wir zuvor über verschiedene Sets von Fähigkeiten gesprochen haben – es mag in deinem Hinterkopf vielleicht eine bestimmte Sache geben, für die du eine Leidenschaft hast. Wenn ich also ein großer Kunstfan bin, viel Kunst schuf, während ich aufwuchs, ich habe einen BFA (Bachelor of Fine Arts). Und darum mag ich es mit Künstlern zu arbeiten und sie zu ermutigen einen guten Job zu machen. Das bedeutet nicht, dass ich nicht mit jedem zusammenarbeiten möchte, mit den Designern und Programmierern. Doch das ist sozusagen mein Ding, worüber ich am meisten weiß, darum würde ich ihnen gerne helfen. Je mehr man weiß, desto besser ist es – um zu einer anderen Frage zurückzukommen, über die wir schon gesprochen haben, wo es um das Verstehen von Schätzungen ging und wie viel Zeit Leute brauchen. Je mehr man von dem Job versteht, den sie machen – nicht tiefgreifend, sondern nur Grundwissen – desto besser ist es, wenn sie sagen: “Das wird mich vier Tage kosten.” kannst du quasi antworten: “Nun das scheint … normalerweise brauchten wir nur zwei, denn ich kenne die Software, die du nutzt. Ich weiß, was es üblicherweise braucht um so ein Stück Kunst zu schaffen, da ich gesehen habe, wie jemand anderes das machte.” Das hilft den Produzenten in dir anzufeuern.

TD: Ja.

EKD: Also eine großartige Frage. Ich hoffe das beantwortet sie.

Frage 9: Ein Feature implementieren

Weyoun “six” of Imperium fragt:
Geehrte Produzenten, Wir haben den Prozess des Bugfixings in Bugsmashers gesehen. “Ein toller Programmiere setzt sich hin, denkt nach, und magische Codefixes fliegen aus seinen Fingern.”
Ist der Prozess der Implementierung neuer Features ähnlich? Viele Leute scheinen das zu glauben. Könnt ihr uns von Anfang bis Ende des Prozesses führen, ein Feature von einer Idee aus Chris Roberts Kopf (oder dem, eines andern) zu nehmen, bis hin zur Spielbarkeit auf unseren Computern, einschließlich einiger Hindernisse, denen ihr begegnet, und wie ihr diese überwindet?
Von besonderem Interesse sind für mich die lokalisierten Schiffs-Physik-Instanzen, GOST, oder Grabby Hands!

TD: Last uns … ich denke, das Beste von denen wäre … GOST. GOST ist ein wirklich gutes Beispiel und wir gehen das jetzt durch. Um diesen Prozess also zu durchlaufen … “ist dieser Prozess ein Feature zu implementieren ähnlich wie das beheben eines Bugs?” Nein, einen Bug zu richten ist Teil der Implementierung eines Features. Am Ende davon gibt es eine ganze Phase dafür. Die Realität ist: Jedes Feature ist ein Paket von Bugs, die man noch nicht geschaffen hat. Mit jedem Feature muss man also am Ende auch eine Menge QA (Qualitätssicherung) und Bugfixing-Zeit einbauen, da es so kommen wird. Selbst die besten Techniker des Planeten – es ist nicht so, als ob sie Fehler machen würden. Das sind einfach Dinge, die sich über die Zeit entwickeln, oder diese Sache hier drüben hat sie in einer Art beeinflusst, die nicht vorhersehbar war.
Also mit dem Beispiel von GOST: Wir haben ein Bedürfnis im Spiel, oder ein Bedürfnis wird identifiziert. Und darum geht es eigentlich, wenn man von einem neuen Feature spricht: Es ist entweder eine Notwendigkeit oder eine neue Idee. Und im Fall von GOST, war es ein Erfordernis. Wir das Verlangen zu begreifen, wo sich der Spieler in Relation zum Schiff befindet und was deren jeweilige Zustände sind, sodass wir sie in geeigneten Weisen interagieren lassen können. Wie zum Beispiel, dass man nicht ein einen Geschützturm steigen kann, wenn schon jemand darin sitzt. Oder sich bewusst zu sein, dass die Leiter schon ausgefahren ist, und dass man dementsprechend die Leiter raufklettern sollte, anstatt die Ausfahranimation der Leiter abzuspielen. Oder zu erkennen, wenn der Spieler das Licht anschaltet. Wie auch immer, ich könnte euch haufenweise Beispiele nennen. Doch dies ist eine Liste von Notwendigkeiten, die von Chris und den Designern identifiziert wurden. Was also grundsätzlich passiert ist, dass sie da eintauchen, eine Liste von “Hey, hier sind all die Erfordernisse, hier sind all die Probleme, die wir haben, die wir lösen müssen um diese Dinge zu erreichen” schreiben. Und das würde man allgemein als unser GDD, unser Game Design Document, oder Level Design Document, oder – in diesem Fall – Feature Design Document bezeichnen. Das sind die Dinge, die wir haben, das ist eine Liste von Problemen und die nimmt man dann also und gibt sie an das Technikteam weiter. Und die sagen einem dann: “Okay, der beste Weg, um das zu lösen wäre … ” Und dann dokumentieren sie ihr Technical Design Document. Und sie überprüfen es gleichrangig und setzen sich wieder mit den Designern zusammen. Sie halten die beiden zusammen und sagen in etwa: “Okay, das ist wirklich die beste Lösung um all diese Probleme ganzheitlich zu lösen.” Dann kommt es zum: “Okay! Grünes Licht, alle sind glücklich. Das ist genau, was wir machen möchten, so möchten wir das umsetzen, jeder ist dabei. Wir haben die Einsatztruppe zusammengestellt.” Dann setzen wir uns wortwörtlich hin und brechen es runter, vom Anfang bis zum Ende. Und einige dieser Dinge brauchen sechs Monate, oder sogar länger. Dann sagt man sich: “Okay, hier werden wir anfangen. Hier ist das Einfachste, das Simpelste und dann bauen, bauen und bauen wir.” Und üblicherweise fängt man mit dem Programmiergerüst, dem Fundament an, und baut weitere Features darauf auf. Und dann am Ende … oder auch während des Prozesses, aber dann am Ende hat man quasi eine lange Puffer-Zeit, für QA, Tests, Bugfixing, Integration in welchen relevanten Strom auch immer, wo das drinnen sein sollte. Diese Feature könnte in der Doppel-Pyramide beispielsweise unten bei ‘Game Dev’ > ‘Arena Commander’ > Untergruppe Feature-Zweig von GOST. Und dann erfährt das fortwährende Integrationen mit dem Arena Commander, es muss darin eingepasst werden, eingefügt in ‘Main.’ Man muss also vielleicht eine Woche da rein stecken, um jedes Problem zu lösen. Das ist also wirklich die absolute Grundlage, und ich könnte wohl ewig darüber reden, doch ich habe vielleicht schon zu lange gemacht. Der absolut grundlegende Prozess um ein Feature von einer Idee den ganzen Weg, bis ins Spiel zu bringen.

Frage 10: Konflikte schlichten/vermeiden

AragornBH fragt:
Stellt euch vor, dass ihr zwei Künstler, Designer, oder andere CIG-Mitarbeiter hat, die an einem Projekt innerhalb von SC arbeiten, dass ihr produziert. Auf ihrem Weg haben sie eine professionelle Auseinandersetzung darüber, was sie tun sollten und es ist klar, dass es unmöglich wäre beide Versionen unterzubringen. Wie entscheidet ihr, welche Version behalten und welche verworfen wird? Ist es schwierig den Mitarbeitern – selbst wenn sie hart arbeiten – zu sagen, dass sie ihre Arbeitsweise ändern müssen, weil es nicht in eure Pläne passt? Welche Hilfsmittel nutzt ihr, um die Chance, auf die oben beschriebene Situation, zu minimieren?

EKD: Das ist eine tolle Frage. Und das führt zu anderen Fragen zu den Soft Skills in dem Job zurück. Und die Kommunikations-Anteile des Jobs. Und ich denke, dass es sehr wichtig ist jedem zu verstehen zu geben, dass ihre Ideen bedeutend sind, dass ihre Meinungen eine Rolle spielen. Was sie zu sagen haben ist absolut wichtig. Und ich denke Travis hat schon zuvor davon gesprochen … als es um diese professionelle Debatte ging, wo man schließlich zu einem Kompromiss gelangt. Also für mich – zumindest wie ich versuchen würde das zu lösen, ist zu verstehen was die beiden möchten, nicht wahr? Ehrlich gesagt, ist eines der besten Mittel dieses Berufs ist es alle im selben Raum zu sammeln und das und uns allen zu helfen, dies auseinanderzuklamüsern. Denn in dieser Industrie sind wir alle Profis, richtig? Wir produzieren vielleicht Unterhaltung und sind womöglich wirklich leidenschaftlich bei dem, was wir tun …

TD: Und allgemein, an alle Betreffenden … Ich habe noch keine Person getroffen, die super egoistisch ist. Jeder ist also wirklich mitten drin. Sie haben nur legitime Diskussionen darüber, was das beste für das Produkt ist. Was die besten Kontroversen sind.

EKD: Die beste Diskussion, die man haben kann. Man fängt also gleich stark, auf die richtige Weise an. Ihnen also zu helfen, zu einem Kompromiss zu kommen ist nun dein Ziel. Sie dabei zu unterstützen zu verstehen, was richtig ist, ist auch dein Ziel. Also bring sie in einen Raum, hilf ihnen ihr Gespräch zu leiten, biete beiden eine Plattform um auszusprechen, worum auch immer es geht. Stelle sicher, dass all die Schlüssel-Projektbeteiligten hier sind um alle Seiten anzuhören. Und dann ist die Hoffnung, da raus zu gehen – und das ist eines der Dinge, die wir Produzenten versuchen zu tun, wenn wir ein Meeting leiten – ist da raus zu gehen, mit einem Satz von Lösungen, mit denen wir uns alle gut fühlen. Wir finden das vielleicht nicht großartig – besonders, wie du schon erwähntest, AragornBH – dass es schwierig ist, jemandem zu sagen: “Großartige Idee, aber wir werden diese Idee nicht nutzen.” Doch wenn ihr alle zusammen seid, und ihr seid zu einem Kompromiss gekommen … ehrlich, das ist nicht so schwer. Nochmal: Das sind Profis, wir alle sind Profis, wir sind alle Erwachsene. Und wir alle verstehen … “Okay, ich habe kapiert, was du meinst. Ich würde immer noch lieber Meines machen, doch das klingt am besten für das Projekt. Lass uns damit weitermachen.” Das neigt dazu sich selbst zu lösen, durch einfache Anleitung, Kommunikation und das Team zu versammeln um einen guten Plan zu entwickeln.

TD: Ich denke, was Eric sagte ist genau die Herangehensweise an ein aufgetretenes Problem, ein Konflikt, der aufkam. Die besten Probleme sind die, die man nicht lösen muss. Ich denke, dass hier gegebene Beispiel ist vermutlich … wenn ich dem zuhöre, höre ich heraus, dass die Situation ungefähr etwas ist, dass womöglich schon komplett eliminiert sein könnte, indem man einfach klarer definierte Rollen und Verantwortungen hätte. Denn diese beiden Typen haben offenbar an der selben Sache gearbeitet und nutzten konkurrierende Methoden. Das ginge nur für eine gewisse Zeit, bevor wir sie zusammensetzen und mit ihnen reden müssten. Was auf jeden Fall ein Fehler von uns wäre. Denn es wäre die Schuld des Produzenten, dass er zwei Leute parallel arbeiten lässt.

EKD: Das ist ein guter Punkt. Ich denke, was wir hier haben ist ein Symptom eines viel grundsätzlicheren Problems. Diese Problemquelle ist es klar definierte Rollen für jede Person im Team zu etablieren. Ich lasse aus, was du eben schon sagtest. Sobald jeder das verstanden hat, ist es absolut okay Meinungen zu dem zu haben, woran die andern arbeiten, doch auch jeden anderen genug zu respektieren, um zu wissen: “In Ordnung, das ist dein Fachgebiet. So habe ich es seit vielen Jahren in der Industrie gemacht. Hier ist meine Perspektive … ” Doch es ist sehr klar definiert, dass dies die Rolle dieser Person ist.

TD: Ja. Ich hatte viel Erfolg damit die Zuständigkeit für verschiedene Teile des Spiels klar zu etablieren. Sogar Teile von Featuren. Das sollte jeder verstehen: Jeder hat Meinungen. Und tatsächlich haben viele Leute im Team … Zane ist ein tolles Beispiel. Zane ist sehr engagiert, Zane verbringt unglaublich viel Zeit damit, a seiner Kunst zu arbeiten. Und er ist der erste, der auf dich zu geht und fragt: “Was denkst du? Was könnte ich besser machen? Wie könnte ich es besser machen? Wie wäre es damit zu spielen? Mochtet ihr Jungs was ich machte, oder nicht?” Jeder ist also sehr offen für Feedback. Ich denke jeder muss seine Zuständigkeit haben und dann können sie eine schöne kleine Operation durchführen.

EKD: Ich liebe auch diesen letzten Punkt, über Zane. Und das trifft so ziemlich auf jeden zu. Ich denke, selbst auf Produzenten, nicht wahr? Wenn ich Etwas an Travis weitergebe, so wie: “Macht das Sinn? Das habe ich vor zu tun. Dies, das und jenes.” Das gibt einem einfach eine weitere Perspektive, um sich weiterzuentwickeln. Wir möchten ein wirklich cooles Produkt für unsere Backer und Abonnenten schaffen und für Leute, die eine tolle Erfahrung machen möchten. Darum kämpfen wir alle gegeneinander, richtig? Das tun wir letztendlich. Und wie du am Anfang dieses Interviews sagtest: Das ist das beste Problem, dass man haben kann.


// End Transmission

3 Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Time limit is exhausted. Please reload the CAPTCHA.