Mein Spiel ist kaputt (Prototyp)

[Faciendum]

Hallo Zusammen,

Die Folge war ein sehr interesssanter Einblick, fällt aber auch in mein Fachgebiet weshalb sowieso Interesse vorhanden ist. Großes Lob für die Folge und dass ihr das gemacht habt. Sollte ich einen Thread übersehen haben - Sorry.

Ich könnte mir aber vorstellen, dass es schwierig ist für jemand, der/die nicht mit Softwareentwicklung vertraut ist, dem zu folgen. Es könnte Sinn ergeben noch einmal Grundlagen zu legen und klassisches Projektmanagement, Wasserfall und V-Model im Detail zu erklären, um dann eXtremeProgramming, das agile Manifesto und seine Prinzipien einzuführen. Danach kann es dann zu Scrum, Kanban und Hybriden gehen.
Es wurde zwar ein wenig in der Folge zwischen Ralph und Wolfgang angerissen, aber ich denke, dass man da nochmal ausführlicher einsteigen müsste, um mehr Leute abzuholen.
Es könnte auch Leuten wie mir helfen, denn ich habe den Eindruck, dass wir hier nicht unbedingt alles gleich definieren. In meinem Umfeld merke ich auch immer wieder, dass ich Begriffe und Rollen definieren muss, da das Verständnis häufig abweicht (z.B. ist ein Scrum Master Moderator für das Team und/oder räumt Barrieren aus dem Weg und/oder ist Agile Coach für das Team und/oder schützt das Team vor externen Einfluss?).

Meine Erfahrungen liegen im Enterprise Umfeld (Burnrates im hohen AAA-Games Bereich) mit Agile in der Softwareentwicklung aber auch zunehmend Business Agility (insbesondere Kanban, LeSS, Nexus, SAFe, Scrum), Agilen Transformationen, klassisches PM (ist aber schon eine Weile her) und General Management.

Es gibt da ein paar Dinge, die mir aufgefallen sind:

- Die Games-Entwicklung selbst scheint recht agil, aber das drum herum erscheint eher konventionell durch die Beziehung und Abhängigkeiten zwischen Publisher und Entwickler.
- Sobald es zu terminierten Stagegates, zeitlicher Einteilung von Phasen und Meilensteinen kommt, würden wir in meinem Umfeld es eher Wagile, Scrumfall oder eine hybride Methode nennen (böse Zungen nennen es auch Fake-Agile). Die Entwicklung erfolgt in Sprints, muss sich aber einem Projektplan unterordnen.
- Es scheint die Rolle eines klassischen PMs zu geben anstelle der Verantwortung des agilen Teams und eines dienenden Führungsstils.
- Die Pre-Prod funktioniert als Risikominimierung und wird dafür in Kauf genommen. In meinem Umfeld wird die vergleichbare Phase 0 inzwischen eher als Verschwendung betrachtet.

Die Ausgangsbedingungen sind jedoch ganz anders. Aufgrund der Komplexität und Dynamik im Umfeld wird eine Planung, die über ein paar Wochen hinaus geht, falsch sein und damit auch jegliche Kostenschätzung - und zwar signifikant. So signifikant, dass eine Phase 0 lediglich Kosten verursacht.
Der Scope lässt sich nicht festlegen, da das gesamte Umfeld und die abhängigen Systeme auch dynamisch sind. Die Abhängigkeiten lassen sich aber auch nicht einfach einfrieren. So bleibt nur: Just enough planning - just in time... Insofern konnte ich auch in der Folge mit Wolfgang nicht ganz mitgehen, dass Spieleentwicklung komplizierter ist - ich denke, da gibt es auf beiden Seiten ganz eigene Herausforderungen und ich würde mich da nicht festlegen wollen.
Auch die Finanzierungsmechanismen unterscheiden sich stark. Projekte sind aufgrund der Dynamiken langsam am Aussterben und es werden tendenziell eher Wertschöpfungsketten (Value Streams) oder Teams finanziert und dann Arbeit priorisiert (Project to Product). Lean Flow hat hier starken Einfluss, DevOps und Agile machen es möglich.
Die Entscheidungen werden in den Rhythmus der Iterationen oder Product Increments eingebettet. Das Ziel ist eine gesamte "Business Agility". Es wird also nicht mit artifiziellen Stagegates, Phasen oder Plänen gearbeitet, sondern mit einem Investmentportfolio sowie Produktvisionen, Roadmaps, Kanban und Flow. All das ist dynamisch, wird aber an strategischen Themen und Produkvisionen ausgerichtet und es werden regelmäßig Entscheidungen getroffen, ob weiter gemacht wird oder ein Pivot notwendig ist - Transparenz ist dabei wichtiger als Governance...

Vielen Dank nochmal und ein Entschuldigung für das Denglisch - 10 Jahre europäische Ebene und 6 Jahre USA hinterlassen Spuren...

[Numfuddle]

Das Problem an Agile ist ja eigentlich dass es erstens nur funktioniert wenn man es konsequent durchführt (duh!) und nicht einfach die unangenehmen Schritte ignoriert. Deshalb haben wir ja so viel Fake-Agile Projekte.

Zweitens wurde agile im Kern für Projekte erfunden wo das Team Kontrolle über Termine und/oder Budget und/oder Features hat.

Wenn aber alles von vorne herein fest vorgegeben ist kann agile seine Vorteile kaum ausspielen.

Mit Agile will man ja am Ende jedes Sprints im Prinzip eine verkaufbare Version haben die man auch als minimum viable Product verkaufen kann damit man was shippen kann wenn einem die Zeit und/oder das Budget erstmal ausgegraben ist.

Da wundert es mich nicht das das bei Spielen nur mäßig funktioniert die ja von was Features, Budget und Zeitplan angeht sehr unflexibel sind und wo das Minimum Viable Product erst sehr spät in der Entwicklung überhaupt erst entsteht

[Gonas]

Ich möchte nur anmerken, dass ich es total unverständlich finde, das ehemalige Drehbuch vom letzten Star Wars Film als deutlich besser zu sehen.

Das war auch total absurd und wäre mindestens eine genau so große Katastrophe geworden. Nur halt anders.

[Faciendum]

Wenn aber alles von vorne herein fest vorgegeben ist kann agile seine Vorteile kaum ausspielen

Das scheint das Faszinierende an der Spieleentwicklung zu sein. Das Rahmenwerk ist relativ starr und durch die Pre-Prod definiert, aber dennoch sieht es so aus als ob der klassische Wasserfall nicht die Lösung ist, da in der Entwicklung zu viele Überraschungen auftreten.

Die adaptierten Stacymatrix scheint hier nicht so gut zu greifen, da weitere Dimensionen wie z.B. "Spielmechanik" und "Story" die Komplexität pushen.

Mit Agile will man ja am Ende jedes Sprints im Prinzip eine verkaufbare Version haben die man auch als minimum viable Product verkaufen kann damit man was shippen kann wenn einem die Zeit und/oder das Budget erstmal ausgegraben ist.

Da wundert es mich nicht das das bei Spielen nur mäßig funktioniert die ja von was Features, Budget und Zeitplan angeht sehr unflexibel sind und wo das Minimum Viable Product erst sehr spät in der Entwicklung überhaupt erst entsteht

Ja, sehr guter Punkt, daher die hybriden Lösung in der Spieleentwicklung...
Wobei wir die erste Aussage evtl. auf Scrum begrenzen sollten.
Kanban z.B. nutzt keine Sprints, LeSS erlaubt mehr Flexibilität durch das Potentially Shippable Product Increment und MVP ist in SAFe anders definiert (wobei es natürlich die Diskussion gibt, ob SAFe nun agil ist oder nicht).

Der Kontrast zu Mobile- und Browsergames wäre interessant - hier schiene sich mehr echte Agilität bzw. Scrum mit MVP anzubieten. Insbesondere wenn Entwickler = Publisher.

[Numfuddle]

Im Prinzip ist mir egal wie man die Komplexität runterbricht und handhabbar macht. Wirtschaftliche Risiken zu minimieren die durch klassische Entwicklungsmethodiken entstehen war ja eines der Kernziele im Agile manifesto, ebenso wie Komplexitätsreduktion und der Fokus auf Prototypen bzw. MVP. Damit man halt nach am Ende von Budget und Zeit was hat was man als 1.0 verkaufen kann. Erzähl ich dir ja nichts neues.

Wie das letztendlich umgesetzt wird lassen die Unterzeichner ja offen solange es die Ziele erfüllt.

Spiele waren da aber nie im Fokus ebensowenig wie die klassischen Gewerke wo du zum Festpreis ein festgelegtes Produkt zum Stichtag X fertig habe musst und du nicht Herr über dein Featureset bist. Automobilbranche hätte z.B. gerne agile geht aber nie so richtig gut weil man ja drei Jahre vor dem SOP des Autos schon für ein komplettes Produkt zum Teilepreis X bei Featureset Y gepitcht hat

Wäre interessant zu wissen in wie weit sich das durch Hybridansätze z.B. für die Games-Entwicklung doch adaptieren lässt

[Numfuddle]

Der Kontrast zu Mobile- und Browsergames wäre interessant - hier schiene sich mehr echte Agilität bzw. Scrum mit MVP anzubieten. Insbesondere wenn Entwickler = Publisher.

Die sind aber auch näher an einer Art der Produktentwicklung dran, für die Agile Methoden ursprünglich mal entwickelt wurden. Für Service-Games oder Hochrisiko-Entwicklungen wie z.B. MMOs oder Multiplayer Titel mit Long tail dürfte das auch gut klappen. WoW hat lange mehr oder weniger so funktioniert allerdings erst nachdem sie das Grundspiel draußen hatten und in die monatliche Patch/Update Zyklen gegangen sind

[Faciendum]

Absolut.

Wäre interessant zu wissen in wie weit sich das durch Hybridansätze z.B. für die Games-Entwicklung doch adaptieren lässt

Für größere Entwicklungsaufwände könnte SAFe ganz gut passen, würde auch die Story- und Spielmechanikherausforderungen ganz gut adressieren. Die größte Frage wäre wahrscheinlich, ob Publisher sich auf agiles Vertragsmanagement einlassen könnten (https://www.scaledagileframework.com/agile-contracts/).

Für Service-Games oder Hochrisiko-Entwicklungen wie z.B. MMOs oder Multiplayer Titel mit Long tail dürfte das auch gut klappen.

Ja, den Gedanken hatte ich auch.

WoW hat lange mehr oder weniger so funktioniert allerdings erst nachdem sie das Grundspiel draußen hatten und in die monatliche Patch/Update Zyklen gegangen sind

Danke, wieder etwas gelernt.

[Reinhard]

Ich möchte hier noch anmerken, dass mir dieser Prototyp wirklich sehr gut gefallen hat. Ralf ist sowieso eine riesige Bereicherung und Dominik hör ich auch gerne zu. Ich hoffe diese Pilotfolge war für euch erfolgreich und das Format wird fortgesetzt, diese Einblicke in die aktuelle Spiele- und Softwareentwicklung finde ich als "vor langer Zeit mal Softwareentwickler" sehr interessant.

[Kesselflicken]

Dann muss ich mal reingrätschen, denn ich fand diesen Prototypen echt nicht gut. Soweit ich verstanden habe ist der Sinn des Formats, dass Zuhörer die unterschiedlichen Phasen der Spieleproduktion en Detail kennenlernen. Das hat bei mir leider überhaupt nicht funktioniert, denn ich konnte dem Ganzen kaum folgen. Ich habe mir den Prototypen heute auch noch ein zweites Mal angehört, um auszuschließen, dass ich am Mittwoch nur zu unaufmerksam war.

Das fing schon damit an, dass ich die Zielrichtung des Formats wohl nicht mal verstanden hätte, wenn André diese nicht schon in der Weltherrschaft erklärt hätte. Der Einstieg war etwas holprig und ich hätte mir eine strukturiertere Einleitung gewünscht.

Das viel größere Problem für mich ist aber Ralfs Redeart... Eigentlich sage ich immer, dass jeder auf seine Art sprechen soll, solange man ihn versteht. Aber hier ist mir eben das Verständnis verloren gegangen. Dieses Denglisch und die ständigen Anglizismen waren overkill. Klar, die Hauptsprache im digitalen Bereich ist Englisch, aber hier ging das imo über das übliche Maß weit hinaus. Da wurden teils einfachste Grundvokabeln durch englisch Pendants ersetzt. Ich zumindest kam überhaupt nicht mehr mit.

Dazu möchte ich aber auch zugeben, dass ich nicht vom Fach bin und der Entwicklungsprozess selber auch nicht so weit oben auf meiner Interesseskala angesiedelt ist. Aber bei der eigentlich kommunizierten Richtung des Formats, sollte das doch kein Problem sein. Wenn es eine Runde für Eingeweihte und Coder sein soll, dann sollte das imo deutlicher gesagt werden.

[Mohnbrötchen]

Mir ging es ähnlich wie Varus. Ich fand es teilweise schwierig, dem Podcast zu folgen, vor allem weil viele Begriffe (z.B. Wasserfall, Sprints, agile Softwareentwicklung, minimum viable,...) nicht eingeführt bzw. erklärt wurden. Hatte ein bisschen das Gefühl, einen Podcast für Spieleentwickler zu hören und dass mir sehr viel Vorwissen über Projektmanagement etc. fehlt.

Bitte nicht falsch verstehen, ich finde es an sich gut, dass ihr diese Themen in dieser Tiefe behandelt. Mir fehlt aber die Zugänglichkeit für einen Außenstehenden.

[jeanpaulrichter]

Ich empfand es im Gegensatz zu manch anderem als sehr angenehm dem Gespräch zweier Leute mit Ahnung zuzuhören, die sich nicht bei jedem zweiten Satz fragen: Wird ein dritter das auch ja richtig verstehen können? Im Übrigen hätte ich eine Frage an den "Producer" Adam, der aber womöglich dem Forum hier nicht so genau folgt. Ich stelle sie mal dennoch: In der letzten Episode des Podcasts "Three Moves Ahead" über die Autobiografie von Sid Meier waren sich alle drei beteiligten, re­nom­mierten Designer (Sid Meier, Johan Andersson und Soren Johnson) einig, dass "Design Documents" zumindest für Strategiespiele ein Ding des Teufels seien. ( https://www.idlethumbs.net/3ma/episodes ... ers-memoir ab 39:30 ) Wäre die Sicht des Producers: "Ja, die Dynamik der Spieleentwicklung ist tatsächlich so hoch, dass etwas so starres, wie ein Design Document sie nicht abbilden kann" oder "Diese Designer haben leicht reden..." ?

[Ingmar1981]

Ich stecke in vielen der besprochenen Abläufe nicht drin, an Interesse mangelt es allerdings nicht. Ganz im Gegenteil. Mir persönlich bietet das Format einen echten Mehrwert und ich würde sehr gerne mehr von der Kombo Ralf/Dominik hören. Ein sehr schönes Format!

[Dr. Zoidberg [np]]

Erstmal danke euch allen für das Feedback

Ich könnte mir aber vorstellen, dass es schwierig ist für jemand, der/die nicht mit Softwareentwicklung vertraut ist, dem zu folgen. Es könnte Sinn ergeben noch einmal Grundlagen zu legen und klassisches Projektmanagement, Wasserfall und V-Model im Detail zu erklären, um dann eXtremeProgramming, das agile Manifesto und seine Prinzipien einzuführen. Danach kann es dann zu Scrum, Kanban und Hybriden gehen.

Daran habe ich tatsächlich wenig Interesse. Ähnlich wie bei "Mein Scrum ist kaputt" ist hier die Idee, dass man sich den Podcast anhört, wenn man bereits mit den Grundlagen vertraut ist und weiterführende Ideen haben möchte. Davon ab, gibt es dafür bereits massig sehr gute Quellen, exemplarisch sei hier der Podcast Scrum meistern erwähnt, der sich vornehmlich mit grundlegenden Definitonen auseinandersetzt (der Vollständigkeit halber: Ich war in einer Folge dort bereits zu Gast)

Aus dem gerade gesagten ergibt sich auch:

Wenn es eine Runde für Eingeweihte und Coder sein soll, dann sollte das imo deutlicher gesagt werden.

Das ist in der Tat der Fall und das haben wir dann offenbar nicht vernünftig kommuniziert. Ich bin wahrscheinlich auch zu sehr von meiner "Standard-Podcast-Einstellung" ausgegangen, dass ich den Punkt zu wenig, wenn nicht vielleicht sogar gar nicht bedacht habe.

Um es zu konkretisieren: Der Podcast richtet sich an Leute, die in der Spiele- und Softwareentwicklung tätig sind (völlig egal, ob Coder, Artist oder Projektmanagement). Wir wollen vor allem Ideen liefern, wie mit Situationen umgegangen werden kann, die dabei oftmals zwangsläufig entstehen. Unser Setup ist dabei, dass Ralf der Mann vom Fach ist, während ich mich zwar in der Softwareentwicklung und in Prozessgedöns auskenne, aber von Spieleentwicklung selber wenig kenne. Die Idee: Wir nähern uns den Themen und Problemen, indem ich Ralf mit fachlichen Fragen löchere.

Dann muss ich mal reingrätschen, denn ich fand diesen Prototypen echt nicht gut. Soweit ich verstanden habe ist der Sinn des Formats, dass Zuhörer die unterschiedlichen Phasen der Spieleproduktion en Detail kennenlernen.

Ich denke mal, dass dafür Walkthrough weiterhin besser geeignet sein wird, das es die Themen aus einer "metaigeren" Perspektive betrachtet

Kanban z.B. nutzt keine Sprints

Um das aufzugreifen und weil es mir wichtig ist (auch weil ich immer wieder über den "Kanban-Modus" stolpere): Kanban ist kein Prozess, sondern etwas, das sich auf jeden Prozess anwenden lässt. Kanban (vor allem das Software-Kanban) geht idR davon aus, dass du bereits einen bestehenden Prozess, eine bestehende Arbeitsweise hast und möchte dich - mit Hilfe seiner Regeln und Prinzipien - dazu ermutigen, diesen Prozess konstant und konsequent zu verbessern. Ob du dabei nun Wasserfall, SAFe oder meinetwegen auch FDD nutzt, ist Kanban völlig egal.

Und zu guter Letzt:

Es wurde zwar ein wenig in der Folge zwischen Ralph und Wolfgang angerissen, aber ich denke, dass man da nochmal ausführlicher einsteigen müsste, um mehr Leute abzuholen.

Ich freue mich zwar über die Adelung, muss dann aber doch darauf hinweisen, dass ich nicht Wolfgang bin

[Voigt]

Mhm als ich konnte der Folge schon ok folgen, ohne in der Spieleentwicklung tätig zu sein. Einfach durch die bereits gehörten Folgen von Ralf und Wolfgang zu Spieleentwicklung, letztens erst wieder zu Crunch.
Und auch so weiß ich schon grob was Agile und Wasserfallentwicklung ist. Auch durch diesen Comic:


Was mir aber etwas fehlte war der Fokus. Eigentlich sollte Folge ja über Pre-Production gehen, aber gefühlt war das nur die Hälfte der Folge, die andere Hälfte war allgemeines palavern über Spieleeentwicklung und ob die nun Agil ist oder nicht. Aber vielleicht sehe ich da bloß nicht den Zusammenhang, vielleicht hat das dramatischen Einfluss auf die Pre-Production ob das kommende Projekt Agil entwickelt wird oder nicht, hätte man vielleicht noch mehr drauf eingehen können (außer das ist für die eigentliche Zielgruppe, die Entwickler eh bereits klar).

Ein Nebenkommentar noch, ich finde es immer verwirrend wenn Leute mit denen man viel zu tun hat, sich mit einem ungewohnten Namen vorstellen. Dr. Zoidberg ist nunmal Dr. Zoidberg, und so kenne ich ihn primär und halt glaube auch das Forum hier so. Nur weil seine Offline Name Dominik ist...

[Kesselflicken]

Aus dem gerade gesagten ergibt sich auch:
Varus hat geschrieben: ↑Samstag 7. November 2020, 13:03
Wenn es eine Runde für Eingeweihte und Coder sein soll, dann sollte das imo deutlicher gesagt werden.
Das ist in der Tat der Fall und das haben wir dann offenbar nicht vernünftig kommuniziert. Ich bin wahrscheinlich auch zu sehr von meiner "Standard-Podcast-Einstellung" ausgegangen, dass ich den Punkt zu wenig, wenn nicht vielleicht sogar gar nicht bedacht habe.

Um es zu konkretisieren: Der Podcast richtet sich an Leute, die in der Spiele- und Softwareentwicklung tätig sind (völlig egal, ob Coder, Artist oder Projektmanagement). Wir wollen vor allem Ideen liefern, wie mit Situationen umgegangen werden kann, die dabei oftmals zwangsläufig entstehen. Unser Setup ist dabei, dass Ralf der Mann vom Fach ist, während ich mich zwar in der Softwareentwicklung und in Prozessgedöns auskenne, aber von Spieleentwicklung selber wenig kenne. Die Idee: Wir nähern uns den Themen und Problemen, indem ich Ralf mit fachlichen Fragen löchere.
Varus hat geschrieben: ↑Samstag 7. November 2020, 13:03
Dann muss ich mal reingrätschen, denn ich fand diesen Prototypen echt nicht gut. Soweit ich verstanden habe ist der Sinn des Formats, dass Zuhörer die unterschiedlichen Phasen der Spieleproduktion en Detail kennenlernen.
Ich denke mal, dass dafür Walkthrough weiterhin besser geeignet sein wird, das es die Themen aus einer "metaigeren" Perspektive betrachtet

Vielen lieben Dank für die Konkretisierung!

[schneeland]

Ich glaube, ich muss mir das trotz mittelschwerer SCRUM-Allergie doch mal anhören

Bin mir aber gerade nicht so sicher, ob die Zielgruppe nicht ein bisschen schmal ist, wenn Vorwissen aus dem IT-Projektmanagement vorausgesetzt wird.

[skade]

Hi,

ich hab die Folge "Mein Spiel ist kaputt" mit Interesse gehört und hatte meinen Spass daran, aber fand sie noch verbesserungwürdig. Aber ist ja gut, dafür sind ja Prototypen da.

Ich fang mal mit dem Guten an. Man merkt eindeutig, dass da Leute vom Fach am Reden sind und der Umstand, dass Dominik nicht aus der direkten Branche stammt, tut dem Ganzen gut. Als Vergleich nehme ich da gerne DevPlay, das ich normalerweise wenig spannungsgeladen finde, aber in der Folge zu Cyberpunk durch Jochen sehr gut wurde - weil er eine leicht externe, aber nicht naive Perspektive eingenommen hat und halt mal kein Geschäftsführer einer Spielefirma ist. Die Chemie ist hier auch drin und passt. Auch gut fand ich, dass Ralf zwar viele der Dinge mal in einer anderen Folge mit Andre erzählt hat, aber es halt nochmal tut, damit das Format komplett ist. Super fand ich auch, dass mit konkreten Beispielen gearbeitet wurde - mit der Star Trek-Sache kriegt man einfach ein besseres Feel für die Probleme. Gerade auch auf der "großen" Ebene hat es einen wirklich guten Überblick über die Ideen und Hintergedanken gegeben.

Was aus meiner Sicht verbessert werden sollte, ist die Natur eines Cross-Over-Podcasts ist: Ralf schneidet zwar an, dass Spieleentwicklung aus seiner Sicht immer agil war, aber es wird nicht stark drauf eingegangen. Genauso werden Begriffe, die Laien eventuell nicht so bekannt sind, vorrausgesetzt - zum Beispiel Scrum und Sprint. Nun kann ich das schlecht einschätzen, weil ich generell auch in agilen Umgebungen arbeite. Aber auch mich hätte mich sehr gefreut, wenn man da vielleicht etwas mehr ins Detail gegangen wären. Wie sieht das Tag zu Tag aus? Wieviel Zeit verbringt man in der Spieleentwicklung mit Planung? Was sind so die Skillsets, die man in der Vorproduktion brauch und später nicht? _Warum_ macht man jetzt Prototypen eher mit Seniors und warum haben da Juniors keinen Platz (müssen die das Prototypisieren nicht auch lernen?). An der Ecke würde ich mich über mehr Gedankengänge und weniger reine Statements freuen.

Ich hoffe, das Feedback ist hilfreich?

[HerrReineke]

Zunächst: bitte nicht wundern skade, ich habe deinen Beitrag hierhin verschoben

Genauso werden Begriffe, die Laien eventuell nicht so bekannt sind, vorrausgesetzt - zum Beispiel Scrum und Sprint. Nun kann ich das schlecht einschätzen, weil ich generell auch in agilen Umgebungen arbeite. Aber auch mich hätte mich sehr gefreut, wenn man da vielleicht etwas mehr ins Detail gegangen wären.

Dazu hatte Dominik hier im Thread schon ein wenig ausgeführt:

Um es zu konkretisieren: Der Podcast richtet sich an Leute, die in der Spiele- und Softwareentwicklung tätig sind (völlig egal, ob Coder, Artist oder Projektmanagement). Wir wollen vor allem Ideen liefern, wie mit Situationen umgegangen werden kann, die dabei oftmals zwangsläufig entstehen. Unser Setup ist dabei, dass Ralf der Mann vom Fach ist, während ich mich zwar in der Softwareentwicklung und in Prozessgedöns auskenne, aber von Spieleentwicklung selber wenig kenne. Die Idee: Wir nähern uns den Themen und Problemen, indem ich Ralf mit fachlichen Fragen löchere.

Die Grundlagen werden in diesem Format also tatsächlich vorausgesetzt

[skade]

Die Grundlagen werden in diesem Format also tatsächlich vorausgesetzt

Naja, dafür finde ich den Umgang mit dem Thema aber immernoch zu flach. Es wird momentant halt als "flavour" in den Raum geschmissen. Und dann macht halt das Crossover wenig Sinn.

Darüber hinaus sehe ich halt gerade, wenn man über "agil" redet halt schon eine Notwendigkeit, ins Detail zu gehen: das ist ein sehr weites Feld. Was passt, was passt nicht?

[Ralf C. Adam]

Hallo zusammen,

leider war es mir aufgrund eines Trauerfalls in der Familie nicht möglich, eher zu antworten - aber jetzt: here we go (und gleich ein Anglizismus, das fängt ja gut an ). Zunächst mal vielen Dank für all Euer Feedback, das ist auf jeden Fall sehr hilfreich.

- Die Games-Entwicklung selbst scheint recht agil, aber das drum herum erscheint eher konventionell durch die Beziehung und Abhängigkeiten zwischen Publisher und Entwickler.

Ja, das ist sehr gut beobachtet - und genau eins dieser Spannungsfelder, in denen sich die Spiele-Entwicklung meist bewegt. Erschwerend kommt hinzu: In der klassischen IT ist es oftmals so, dass der Auftraggeber zumindest ein erstes Pflichtenheft bzw. zumindest eine Grund-Spezifikation der Software erstellt, die er in Auftrag gibt. Deshalb übernimmt er bei z.B. SCRUM ja auch sinnvollerweise meist die Rolle des Product Owners. In unserem Falle ist der Auftraggeber aber i.d.R. der Publisher - und der hat mit der Erstellung des "Pflichtenhefts" (Game Design, Tech Design etc.) sehr viel weniger zu tun. Und den Publisher zum Product Owner zu machen - also demjenigen der z.B. das Backlog priorisiert und dem Team vorgibt, was in den nächsten Sprint kommt - das funktioniert in dieser Form auch nicht.

Du beschreibst es ja in Deinem weiteren Post auch sehr schön, wie ich es auch von der klassischen (wobei - ich sollte eher sagen: modernen) IT her selbst kenne: Pläne sind weniger wichtiger; es werden Teams finanziert und Arbeiten priorisiert. Das ist eine ziemlich perfekte Umschreibung. In der Spiele-Entwicklung kenne ich das auch, allerdings nur bei reinen Auftragsarbeiten, oder wenn kleinere (meist Tech-)Teams für größere Studios zuarbeiten.

- Sobald es zu terminierten Stagegates, zeitlicher Einteilung von Phasen und Meilensteinen kommt, würden wir in meinem Umfeld es eher Wagile, Scrumfall oder eine hybride Methode nennen (böse Zungen nennen es auch Fake-Agile). Die Entwicklung erfolgt in Sprints, muss sich aber einem Projektplan unterordnen.

Ja, auch das ist eine ziemlich gute Umschreibung dessen, wie es in der Regel läuft - gegeben durch Faktoren wie Konsolenzyklen, sich ständige ändernde Marktanforderungen &-wünsche, Deadlines (Thanksgiving in den USA), Budgets etc. Die Spiele-Entwicklung verwendet keinen Deiner Begriffe (in der Regel verwendet sie gar keinen ), und im Detail gibt es teilweise auch signifikante Unterschiede. Aber grob zusammengefasst trifft es das recht gut.

Da wundert es mich nicht das das bei Spielen nur mäßig funktioniert die ja von was Features, Budget und Zeitplan angeht sehr unflexibel sind und wo das Minimum Viable Product erst sehr spät in der Entwicklung überhaupt erst entsteht

Yap, ganz genau. Es funktioniert sehr gut früh in der Entwicklung für Prototypen. Aber die erste Version, die per Definition überhaupt in der Theorie so etwas wie ein "shippable product" wäre, wäre der Vertical Slice. Erfahrungsgemäß hat man den so nach der Hälfte der Gesamtproduktionsdauer (oder auch 2/3 wenn man die Pre-Production noch mit einberechnet).

Ich möchte nur anmerken, dass ich es total unverständlich finde, das ehemalige Drehbuch vom letzten Star Wars Film als deutlich besser zu sehen. Das war auch total absurd und wäre mindestens eine genau so große Katastrophe geworden. Nur halt anders.

Nun, je nachdem, wer Regie geführt hätte Aber J.J. hätte es mit Sicherheit geschafft auch dieses Drehbuch zu versenken, das mag sein...

Der Kontrast zu Mobile- und Browsergames wäre interessant - hier schiene sich mehr echte Agilität bzw. Scrum mit MVP anzubieten. Insbesondere wenn Entwickler = Publisher.

Ein wichtiger Faktor, den Du nennst ist tatsächlich, dass Publisher und Entwickler in der Regel identisch sind. Und gerade Studios wie Inno oder Wooga oder Good Games haben den Vorteil (im Vergleich zu einem kleinen bis mittelgroßen unabhängigen Entwickler), dass sie dank vieler bereits etablierter und gutlaufender "Geld-Druck-Maschinen" weder großartig monetäre noch zeitliche Zwänge haben. Umgekehrt habe ich genau dann oft erlebt, dass in der Spiele-Branche bei dieser Art von "Freiheit" nur Berliner Flughäfen entstehen: sie werden nie fertig, und wenn doch, sind sie große hässliche, seelenlose Monster.

Obwohl (und vielleicht gerade weil) ich selbst auch Game Designer bin, bin ich ein großer Freund der These: "Creativty benefits from Constraints". (guter Artikel hierzu: https://www.inc.com/thomas-oppong/for-a ... aints.html)

Aber prinzipiell ist Deine Aussage absolut korrekt, und gerade im sogenannten "Live-Betrieb", wenn also das Browser/Online/Mobile Game im Markt ist und anhand von Kundenfeedback und den "mystischen" KPI's (=Key Performance Indicators = Kennzahlen, was sich im Spiel wie gut verkauft bzw. wie oft angeklickt wird) weiterentwickelt und gepflegt wird, sind iterativere Ansätze natürlich viel besser, effizienter und wirkungsvoller.

Für größere Entwicklungsaufwände könnte SAFe ganz gut passen, würde auch die Story- und Spielmechanikherausforderungen ganz gut adressieren. Die größte Frage wäre wahrscheinlich, ob Publisher sich auf agiles Vertragsmanagement einlassen könnten

Tatsächlich lässt sich diese Frage relativ eindeutig mit einem "Nein" beantworten. Oder besser: der Publisher wird sagen: "Ist mir wurscht, wie ihr es macht aber ich möchte genau dann, dann und dann feste Milestones, immer genau einen Einblick darüber, wo das Spiel gerade steht und nächstes Jahr zur E3 muss die Demo mit folgenden Features [...] fertig sein. Aber Du kannst es gerne agil machen." Und: siehe oben - der Publisher hat eben in der Regel auch nicht die... Kompetenz für z.B. eine Product Owner Rolle, während ich z.B. auch Spiele-Studios kenne, die als lukratives Zweitgeschäft für BMW arbeiten, und da sieht das dann völlig anders aus.

Dieses Denglisch und die ständigen Anglizismen waren overkill.

Es tut mir leid. Ich werde hier versuchen, weiterhin an mir zu arbeiten, versprochen. Aber mir geht es ein bisschen so wie Faciendum - wenn man den ganzen Tag nur Englisch spricht und schreibt geht das irgendwann in Fleisch und Blut über. Plus - wie mehrfacht aufgeführt: ganz viele der Begriffe (Product Owner, SCRUM Master etc.) gibt es nicht übersetzt. Zumindest nicht, dass ich wüsste...

...stelle sie mal dennoch: In der letzten Episode des Podcasts "Three Moves Ahead" über die Autobiografie von Sid Meier waren sich alle drei beteiligten, re­nom­mierten Designer (Sid Meier, Johan Andersson und Soren Johnson) einig, dass "Design Documents" zumindest für Strategiespiele ein Ding des Teufels seien.

Hahaha - ein sehr gute Frage Ich lese ja tatsächlich gerade die Bio von Sid (sehr zu empfehlen: A life in Games), da führt er das auch noch einmal auf, aber man muss eben immer auch den Zusammenhang sehen. Als Sid "Pirates!" oder auch "Civilization" gemacht hat, hat er diese komplett allein programmiert. "Civ 2" hat er schon gar nicht mehr gemacht (das war der gute Brian Reynolds). Ich entwickle selbst auch noch privat für mich Spiele, und natürlich ist dann meine Dokumentation auf ein Minimum reduziert, das auf einen Bierdeckel passt.

Aber Bruce Shelley, mit dem ich seit Ewigkeiten gut befreundet bin, und der mit Sid in den Anfangszeiten bei Mircroprose als Co-Designer mit dabei war, hat ja dann später u.a. an Age of Empires 1 + 2 mitgearbeitet, und wir haben damals als ich bei Infogrames war mit Ensemble über "Age of Mythology" verhandelt (und auch mit Stainless Steel über Empire Earth). Die hatten alle Game Design Dokumente, und das nicht zu knapp. Und wir hatten genauso auch Dokumentationen bei "Desperados" oder "Gilde" oder "Spellforce" oder "Anno" oder "Siedler" (alles Strategiespiele).

Grundsätzlich gilt bei Game Design immer der alte Albert Einstein Spruch (wenn er denn wirklich von ihm stammt): Everything should be made as simple as possible - but not simpler!

Du brauchst schlicht Dokumentation, wenn Du mit einem Team arbeitest, da du als Game Designer ja nicht den ganzen Tag neben den einzelnen Teammitgliedern stehen kannst, um ihnen zu erklären, was Du in Deinem Kopf hast. Und je größer das Team - und das Projekt - desto mehr Doku ist erforderlich (von Publisher-Anforderungen und Vertragsanhängen will ich hier gar nicht anfangen). Und: ja, gerade in der Anfangszeit/Pre-Prod wirst du erstmal ganz viel prototypen und dich sukzessive deinem Design annähern. Und Du wirst auch in einem Game Design nicht anfangen, alle Balancing-Formeln festzulegen etc. (das passiert dann später in der Produktion - denn Dokumentation ist ein fortlaufender Prozess und nicht an einem bestimmen Punkt abgeschlossen).

Ich habe mal einen Vortrag zu dem Thema gemacht - der enthält am Ende auch noch ein paar gute Quellen und Verweise zu weiteren Dokumentationen zu diesem Thema: https://www.slideshare.net/RalfCAdam/an ... sch-4ckyiv

Nun kann ich das schlecht einschätzen, weil ich generell auch in agilen Umgebungen arbeite. Aber auch mich hätte mich sehr gefreut, wenn man da vielleicht etwas mehr ins Detail gegangen wären. Wie sieht das Tag zu Tag aus? Wieviel Zeit verbringt man in der Spieleentwicklung mit Planung? Was sind so die Skillsets, die man in der Vorproduktion brauch und später nicht? _Warum_ macht man jetzt Prototypen eher mit Seniors und warum haben da Juniors keinen Platz (müssen die das Prototypisieren nicht auch lernen?). An der Ecke würde ich mich über mehr Gedankengänge und weniger reine Statements freuen.

Cool, vielen Dank - das sind alles Super-Punkte, die man, wenn wir das Format fortführen, auf jeden Fall mal konkretisieren können

Nochmal vielen Dank Euch allen