Runde #269: Wie ein Spiel entsteht

Alles, was nicht in ein anderes Forum gehört: Hier rein
Forumsregeln
Datenschutzerklärung: https://www.gamespodcast.de/datenschutzerklaerung/
Impressum: https://www.gamespodcast.de/impressum/

Forenregeln und zukünftige Weltverfassung
ART 1: Behandle andere Nutzer mit Respekt.
ART 2: Do NOT piss off the Podcasters

Lies bitte weitere Hinweise hier: viewtopic.php?f=4&t=2789
Benutzeravatar
Grimlock42G1
Beiträge: 52
Registriert: 31. Aug 2018, 14:32

Runde #269: Wie ein Spiel entsteht

Beitrag von Grimlock42G1 »

Hallo zusammen,

ich bin noch nicht durch die Folge durch, aber Ralf benutzt über mehrere Folgen hinweg häufig ein englisches Wort, was wahrscheinlich übersetzt sowas wie "Aufstellung oder Analyse" bedeutet. Ich verstehe es aber akustisch nie.
Bei 16:30 zum Beispiel.
Was hat er gemacht? Mir ist schon klar, dass es im Entwicklerbereich häufig keine deutschen Fachwörter gibt, aber es würde mich trotzdem interessieren.

Viele Grüße

Gerrit
Me, Grimlock, not nice dino! Me bash brains!
lnhh
Beiträge: 2133
Registriert: 11. Jul 2016, 11:11
Wohnort: Frankfurt am Main

Re: Runde #269: Wie ein Spiel entsteht

Beitrag von lnhh »

Ohne die Folge gehoert zu haben, ich wette du meinst: https://de.m.wikipedia.org/wiki/Due-Dil ... %C3%BCfung
Fuck Tapatalk
Benutzeravatar
Grimlock42G1
Beiträge: 52
Registriert: 31. Aug 2018, 14:32

Re: Runde #269: Wie ein Spiel entsteht

Beitrag von Grimlock42G1 »

lnhh hat geschrieben: 31. Mai 2020, 08:18 Ohne die Folge gehoert zu haben, ich wette du meinst: https://de.m.wikipedia.org/wiki/Due-Dil ... %C3%BCfung
Genau das. Vielen Dank. Ich dachte immer, es wäre ein Wort. Schwer zu verstehen, wenn man es nicht kennt.
Schön, dass du allein aus meiner Beschreibung wusstest, was ich meine. Ohne nachhören zu müssen. :)
Me, Grimlock, not nice dino! Me bash brains!
lnhh
Beiträge: 2133
Registriert: 11. Jul 2016, 11:11
Wohnort: Frankfurt am Main

Re: Runde #269: Wie ein Spiel entsteht

Beitrag von lnhh »

Klasse, gern :)
Fuck Tapatalk
Benutzeravatar
Ralf C. Adam
Beiträge: 51
Registriert: 9. Jan 2020, 12:03
Kontaktdaten:

Re: Runde #269: Wie ein Spiel entsteht

Beitrag von Ralf C. Adam »

Hallo, ja, tut mir leid - ich habe nochmal geschaut, aber keinen wirklich passenden dt. Begriff gefunden. “Team-Evaluierung” trifft es wahrscheinlich noch am ehesten. Die Terminologie Due Diligence ist aber relativ feststehend und wird auch in dt. Entwicklerverträgen so verwendet.

Der Publisher macht in der Regel eine solche Due Diligence bei einem Team, bevor er einen Vertrag unterschreibt. Er nimmt den Entwickler dann genau unter die Lupe und checkt u.a. Punkte wie:

PERSONAL
• Wie hoch ist die technische Expertise des Teams?
• Arbeiten die Teammitglieder gut zusammen?
• Ist jeder im Team vom Spiel überzeugt?
• Aufstellung Track-Record


KOMMUNIKATION
• Wie ist die Kommunikationsstruktur im Team?
• Wie sind die Workflows?
• Gibt es Organigramme und klare Stellenbeschreibung für jedes Teammitglied?
• Wie werden Tasks vergeben und getracked?

DOKUMENTATION
• Gibt es ein klares Design Dokument?
• Glauben alle im Team an die Vision?
• Glauben alle, dass eine Umsetzung realistisch ist?
• Ist das Design-Dokument genau genug?
• Gibt es neben dem GDD ein genaues TDD, alle Asset-Listen, White-Papers etc?

PLANUNG
• Existiert ein detaillierter, schriftlich fixierter Projektplan?
• Sind alle Tasks darin erfasst – mit Zeiten, die von den jeweiligen Mitarbeitern geschätzt wurden?
• Wie oft wird der Plan upgedatet, wie gepflegt?
• Ist jeder Task verifizier- und verprobbar?
• Existiert ein QA-Plan?
• Berücksichtigt der Projketplan Pufferzeiten für Urlaub, Krankheiten etc.?

PROJEKTKONTROLLE
• Gibt es einen dezidierten Projektleiter?
• Existiert ein genauer Milestoneplan und ist dieser für jeden im Team einsehbar?
• Gibt es einen Change-Request-Workflow sowie ein Change-Board?
• Gibt es regelmäßige Code-Reviews?

RISK MANAGEMENT
• Existiert eine Risk-Liste inkl. Verantwortlichkeiten und Gegenmaßnahmen?
• Wird diese regelmäßig upgedated?
• Erfährt das Projekt pro-aktives Risk-Management?
• Existiert für das Projekt ein Risk-Manager?
Benutzeravatar
Soulaire
Beiträge: 1480
Registriert: 28. Mär 2016, 06:44

Re: Runde #269: Wie ein Spiel entsteht

Beitrag von Soulaire »

langsam wird mir klar, warum sich so viele Kreative in diesem Medium so hart an den Film klammern. die einzige Alternative scheint nämlich nur die zu sein, bei der Spiele zu der IT-Branche zugerechnet werden und es damit noch weniger Freiheiten gibt als wenn man einen interaktiven Film pitcht.
Das erklärt einiges und ist ziemlich ernüchternd.
Aber wird scheinbar als Normalität angesehen und von Herr Adam seit Jahrzehnten praktiziert.
rammmses
Beiträge: 265
Registriert: 28. Okt 2016, 20:05

Re: Runde #269: Wie ein Spiel entsteht

Beitrag von rammmses »

Schöne Folge, interessante Insider-Einblicke; was hält Ralf Adam eigentlich vom Produktionsablauf von Star Citizen? :D
Benutzeravatar
Grimlock42G1
Beiträge: 52
Registriert: 31. Aug 2018, 14:32

Re: Runde #269: Wie ein Spiel entsteht

Beitrag von Grimlock42G1 »

Jetzt bin ich durch. Sehr schöne und interessante Folge. Dickes Lob an euch.
Vielen Dank auch nochmal an Ralf für die ausführliche Erklärung von Due Diligence.
Me, Grimlock, not nice dino! Me bash brains!
Benutzeravatar
Axel
Beiträge: 4170
Registriert: 1. Jul 2018, 20:43
Wohnort: Chemnitz & Erzgebirge

Re: Runde #269: Wie ein Spiel entsteht

Beitrag von Axel »

Ich habe mich die ganze Zeit während der Folge gefragt: „Ist das eigentlich noch zeitgemäß, was da erzählt wird?“

Ich meine, welcher Publisher nimmt denn heute noch einen neuen Developer unter Vertrag? Zumal sämtliche größeren Publisher ja ihre eigenen Studios und eigene Marken haben. Niemand würde doch in eine fremde IP investieren. Bleiben also „nur“ noch die mittelständigen Publisher und diese müssen hart aufs Geld gucken, sind dementsprechend wenig erpicht auf Risiko.

Für neue Devs bleibt dann dementsprechend nur der Weg über den Selbstvertrieb. Also ich kann mir das zumindest nicht vorstellen, dass man mit der Ansage „Hallo, wir haben gerade unser Studium hinter uns und suchen jetzt nen Publisher“ noch irgendjemanden findet. Mimimi kamen ja auch nicht aus dem nichts (weil die häufig erwähnt wurden), die haben sich vor Shadow Tactics jahrelang im Mobile Bereich ihre Sporen verdient. Mit DaWindci ein erstes eigenen kleines Spiel rausgestellt und anschließend für Auftraggeber wie Ravensburger gearbeitet.

Ich denke, das wird sich heute nochmal verschärft haben. Wahrscheinlich bleiben 99 von 100 jungen Studios auf der Strecke - würde ich zumindest schätzen.
Benutzeravatar
Soulaire
Beiträge: 1480
Registriert: 28. Mär 2016, 06:44

Re: Runde #269: Wie ein Spiel entsteht

Beitrag von Soulaire »

Axel hat geschrieben: 31. Mai 2020, 16:26 hart aufs Geld gucken, sind dementsprechend wenig erpicht auf Risiko.
das halte ich tatsächlich für ein Gerücht. mag für andere Branchen zutreffen, aber nicht für Video-Spiele. Wenn ein kleiner Publisher versucht AAA-Konzepte zu kopieren geht das meistens mit Ansage nach hinten los.
siehe all die Battle Royal oder Overwatch-Klone, die komplett gefloppt sind.
warum sollte man schließlich auch Battle Born spielen wenn man auch Overwatch spielen kann?
mein Eindruck ist dass die Publisher am erfolgreichsten sind, die einen eigenen Weg gehen. Wie Paradox, Devolver Digital oder Annapurna.
Benutzeravatar
Axel
Beiträge: 4170
Registriert: 1. Jul 2018, 20:43
Wohnort: Chemnitz & Erzgebirge

Re: Runde #269: Wie ein Spiel entsteht

Beitrag von Axel »

Soulaire hat geschrieben: 31. Mai 2020, 16:36 mein Eindruck ist dass die Publisher am erfolgreichsten sind, die einen eigenen Weg gehen. Wie Paradox, Devolver Digital oder Annapurna.
Die Frage wäre nur: Wieviel Survivorship Bias liegt in dieser Aussage?
Benutzeravatar
Soulaire
Beiträge: 1480
Registriert: 28. Mär 2016, 06:44

Re: Runde #269: Wie ein Spiel entsteht

Beitrag von Soulaire »

Axel hat geschrieben: 31. Mai 2020, 16:59
Soulaire hat geschrieben: 31. Mai 2020, 16:36 mein Eindruck ist dass die Publisher am erfolgreichsten sind, die einen eigenen Weg gehen. Wie Paradox, Devolver Digital oder Annapurna.
Die Frage wäre nur: Wieviel Survivorship Bias liegt in dieser Aussage?
Gegenfrage: wieviel "Survivorship" ist dann bei erfolgreichen Klonen vorhanden?
bei einer Formel wird meistens der als Gewinner hervorgehen, der finanziell am besten aufgestellt ist. der "eigene Weg" wird ja deshalb als "das Riskanteste" angesehen weil es so unberechenbar ist. Ein Pseudo-"Eigener Weg" wird keinen Erfolg haben, weil es nicht diese eine Formel gibt die Buisness-Leute gerne sehen wollen.
Herrmann
Beiträge: 246
Registriert: 14. Apr 2016, 10:30

Re: Runde #269: Wie ein Spiel entsteht

Beitrag von Herrmann »

Schöne Marathon-Folge. Ich als IT-Projektleiter musste sehr oft schmunzeln.
Benutzeravatar
whitespace
Beiträge: 86
Registriert: 22. Sep 2018, 22:15

Re: Runde #269: Wie ein Spiel entsteht

Beitrag von whitespace »

Zum Thema Design Dokument und Pitching:
Ich wollte hier nur mal kurz reingrätschen und richtig stellen, da hier ein Lasten- und ein Pflichtenheft komplett miteinander gemixt werden (Sowohl von André, als auch von Ralph).

Ja, es stimmt, dass ein Pflichtenheft auf Details eingeht und das ist denke ich was Ralph meinte wenn er es mit dem Design Dokument vergleicht. In einem Pflichtenheft steht aufgelistet drin, welche Technologien benutzt werden, wer Infrastruktur bereit stelen wird, Workflows werden beschrieben, Mockups gibt es vom Design, Kosten und Fristen werden auch hier festgelegt und auch die Mindestabnahmeanforderungen.

Nein, ein Pflichtenheft wird für gewöhnlich nicht vom Auftraggeber/dem Unternehmen angefertigt (natürlich, ein Unternehmen wie die Deutsche Bahn mit eigenem IT-Projektmanagment wird schon vorgeben was sie exakt brauchen). Ein Unternehmen entwirft ein Lastenheft oder auch Anforderungsliste, die ein komplett abstraktes Konstrukt ist oder sein sollte (Wieder: Deutsche Bahn wird schon detaillierter wissen was sie brauchen als Mittelständisches Unternehmen XY). Der Entwickler erstellt dann aufgrund diesem ein Pflichtenheft.

Der Wohl größte Unterschied aber zwischen einem Design Dokument, welches hier wohl eher in die Richtung des Lastenheft geht ist, dass es nicht rechtlich bindend ist. Ein Pflichtenheft kann wie ein bindender Vertrag angesehen werden. Nicht, dass hier vllt der ein oder andere der das hört glaubt, dass ein Design Document wie ein Pflichtenheft rechtlich das gleiche Gewicht hat.

Hier zu Details für jemand den es interessiert:
https://de.wikipedia.org/wiki/Lastenheft
https://de.wikipedia.org/wiki/Pflichtenheft
Benutzeravatar
Ralf C. Adam
Beiträge: 51
Registriert: 9. Jan 2020, 12:03
Kontaktdaten:

Re: Runde #269: Wie ein Spiel entsteht

Beitrag von Ralf C. Adam »

da hier ein Lasten- und ein Pflichtenheft komplett miteinander gemixt warden
Guter Punkt, danke für die Unterscheidung. Bei den wenigen IT Projekten (und auch bei den Filmprojekten) in die ich involviert war, wurde da nicht so klar getrennt, aber ich kenne es tatsächlich auch so vom Hausbau :D
einem Design Dokument, welches hier wohl eher in die Richtung des Lastenheft geht ist, dass es nicht rechtlich bindend ist
Meinst du jetzt das Lastenheft, oder das Design Dokument? Letzteres ist nämlich auf jeden Fall rechtlich bindend (ansonsten haben beide Seiten beim Vertrag geschlafen :lol: )
mein Eindruck ist dass die Publisher am erfolgreichsten sind, die einen eigenen Weg gehen.
Rein aus Neugier: wie definierst du erfolgreich? Annapurna ist übrigens in erster Linie eine Filmfirma. Und bei Paradox gilt übrigens was für auch fast alle anderen gilt: eigene erfolgreiche Serien/IPs werden in aller Regel fast immer intern gemacht. Egal ob bei Ubi, EA oder eben auch Paradox. Selbst bei THQ Nordic. Mimimi mit D3 ist da eher eine Ausnahme (und wer weiß, vielleicht kauft THQ das Studio demnächst, würde zumindest ins Beuteschema passen).
Ist das eigentlich noch zeitgemäß, was da erzählt wird?“
Ich meine, welcher Publisher nimmt denn heute noch einen neuen Developer unter Vertrag?
Aber unbedingt. Ich arbeite mit verschiedenen Kunden und Teams zusammen, von denen alleine drei seit Beginn von Covid einen Publisherdeal unterzeichnet haben. Alles eigene IPs. Eins davon ein Team, das gerade von der Uni ab ist. Pro größerer Messe wie GDC, Nordic, Gamescom etc. dürften im Schnitt im bis zu dreistelligen Bereich neue Produktionen in dieser Form gestartet werden. Wenn ich aktuell mit Publishern wegen neuer Produktionen rede, habe ich eine Liste von 120 potentiellen Publisherkandidaten.
was hält Ralf Adam eigentlich vom Produktionsablauf von Star Citizen
Haben die denn einen? :D Aber im Ernst, ich würde mir von außen nie ein Urteil erlauben. Und sie haben ja keinen Publisher. Solange ihre Backer happy sind, ist ja alles gut ;)
Benutzeravatar
whitespace
Beiträge: 86
Registriert: 22. Sep 2018, 22:15

Re: Runde #269: Wie ein Spiel entsteht

Beitrag von whitespace »

einem Design Dokument, welches hier wohl eher in die Richtung des Lastenheft geht ist, dass es nicht rechtlich bindend ist
Ich meinte hier das Design Dokument im Stadium des Pitches - war wohl ein wenig zu undeutlich formuliert. :D Das ist eher mit einem Lastenheft, als mit einem Pflichtenheft zu vergleichen. Du unterschreibst ja nicht direkt nach dem Pitch den Endvertrag, das erläuterst du ja auch noch sehr gut. :)
Guter Punkt, danke für die Unterscheidung. Bei den wenigen IT Projekten (und auch bei den Filmprojekten) in die ich involviert war, wurde da nicht so klar getrennt, aber ich kenne es tatsächlich auch so vom Hausbau :D
Richtig! Das meinte ich auch bei dem Beispiel mit der Deutschen Bahn. Je größer die Projekte und beide Firmen sind, desto eher verschwimmt hier ja auch die klare Linie (alleine weil die Projektmanager beider Parteien im engeren Kontakt stehen).

Generell bei dem Beispiel das aber André gebracht hat, war das eher die klassische Beschreibung eines Lastenhefts.
Er gibt in Auftrag welche Buttons er haben will was diese machen können sollen etc. und gibt diese Anforderungsliste dann an den Entwickler weiter der dann im Normalfall eben das Pflichtenheft aufsetzt.

Allgemein tat ich mir da ein wenig schwer die Parallelen nachzuvollziehen, da sie schon seehr sehr runter gebrochen wurden. In der Software Entwicklung ist es ja eher üblich, dass ein Unternehmen mit ihrem Projekt an Entwickler heran tritt und nicht der Entwickler eine Idee dem Unternehmen vorschlägt. Klar, gibt es den umgekehrten Fall auch, wo man seine Idee einem Unternehmen verkauft. Aber verbreiteter ist hier wohl der Entwickler als Dienstleister. :)
Zuletzt geändert von whitespace am 31. Mai 2020, 20:43, insgesamt 1-mal geändert.
Benutzeravatar
WhiteNoise
Beiträge: 57
Registriert: 3. Okt 2019, 14:35

Re: Runde #269: Wie ein Spiel entsteht

Beitrag von WhiteNoise »

Schöne Folge mit tiefen Einblicken in die Entstehung eines Spiels. Ich bin seit 9 Jahren selbst in der Softwareentwicklung tätig (aber nicht im Spielebereich) und die Parallelen sind sehr interessant. Da würde ich gerne mal intensiv mit Ralf drüber reden ;). Interessant finde ich, wie wichtig Ralf ein klares und durchgeplantes Konzept ist. Das hat mich zum einen überrascht, da Agile Software Development inzwischen sehr verbreitet ist und zum anderen, weil man Spaß sehr schwer planen kann. Viele Spiele sind nur durch Ausprobieren wirklich gut geworden, Diablo 1 war z.B. ursprünglich rundenbasiert und wurde dann nur auf Feedback von Blizzard auf Echtzeit geändert (David Breivik war ausdrücklich dagegen). Daher hätte ich erwartet, dass viele Teams sehr iterativ an ihre Spiele herangehen. Nach meine Kenntnisstand haben das auch kleine Studios in den 90igern so gemacht (Condor z.B.).

Auch fand ich erstaunlich, dass kein Wort zum Thema automatisiertes Testen verloren wurde. Starres Abarbeiten von Testfällen ist nach meiner Erfahrung auf dem Rückzug, daher hätte ich gedacht, dass das auch bei Computerspielen so gemacht wird. Dann schleichen sich Fehler auch nicht wieder ein, nachdem sie mal beseitigt wurden. Ralf, hast du damit schon Erfahrungen gesammelt?

Amüsant fand ich Ralfs Kommentar zu Andrés Erfahrung mit Programmierern. Nach meiner Erfahrung gibt es gewaltige Unterschiede was die Quantität und die Qualität der Arbeit angeht. Viele Programmier sind so gründlich und pflichtbewusst, wie André es beschreiben hat, aber es gibt auch genug, die entweder unqualifiziert sind oder denen Qualität völlig egal ist. Wenn man eine richtig vermurkste Code Base hat, dann dauert alles zehnmal länger als sonst. Ich kann mir gut vorstellen, dass das bei langen Projekten wie Star Citizen auch ein riesen Problem ist.
Benutzeravatar
Leonard Zelig
Beiträge: 3450
Registriert: 5. Jan 2016, 19:56

Re: Runde #269: Wie ein Spiel entsteht

Beitrag von Leonard Zelig »

Schöne Folge.

Ich stelle schon länger fest, dass große Publisher wie Ubisoft, Activision und Electronic Arts lieber auf interne Entwicklungen setzen als Spiele von externen Entwicklern zu publishen. Woran liegt das? Lohnt sich das nicht mehr für die Publisher? Hat das zu viele Nachteile für die Entwickler? 2011 hat Electronic Arts noch Nischenprodukte wie Shadows of the Damned von Grasshopper veröffentlicht. Könnte ich mir aktuell nur noch schwer vorstellen. Lohnt es sich überhaupt noch für ein neu gegründetes Studio ihr Spiel bei einem großen Publisher zu pitchen oder sollen sie sich auf kleinere Indie-Publisher konzentrieren? Es gibt zwar Ausnahmen wie Sea of Solitude (deutsches Indiespiel, das letztes Jahr über EA erschien) und Sekiro, aber aktuell sehe ich keine Anzeichen, dass diese bereits eine Trendwende eingeleitet haben. Natürlich haben sich auch die Marktbedingungen verändert. Heutzutage erscheinen jede Woche Dutzende von neuen Spielen in den Konsolen-Stores. Zu Xbox-360-Zeiten hat Microsoft die wöchentliche Anzahl festgelegt und sie haben auch Spiele wie Super Meat Boy gepublisht. Heutzutage kann sich Microsoft diesen Aufwand sparen.
"The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts."

www.gamersglobal.de
Benutzeravatar
Ralf C. Adam
Beiträge: 51
Registriert: 9. Jan 2020, 12:03
Kontaktdaten:

Re: Runde #269: Wie ein Spiel entsteht

Beitrag von Ralf C. Adam »

Eine sehr schöne Diskussion :) - und wie Ihr seht, kann selbst ein längerer Podcast darüber nur an der Oberfläche kratzen. Man kann eigentlich über jede einzelne der Fragen eine eigene Sendung machen und wahrscheinlich mehrere Stunden lang reden. Und bei allem bitte immer auch bedenken: es gibt nicht den einen Weg bei der Spiele-Entwicklung. Und jede "Regel" oder "Norm" wird gerade in diesem Augenblick wahrscheinlich irgendwo gebrochen - manchmal sehr bewusst, und das ist oft gut so. Häufiger aber leider auch mangels besseres Wissen, und das kann dann schnell nach hinten losgehen :D
Ubisoft, Activision und Electronic Arts lieber auf interne Entwicklungen setzen als Spiele von externen Entwicklern zu publishen. Woran liegt das? Lohnt sich das nicht mehr für die Publisher? Hat das zu viele Nachteile für die Entwickler?
Das hat sicherlich mehrere Gründe - zum einen sind die großen IPs der Publisher natürlich die "heiligen Kühe", über die man möglichst die volle Kontolle haben möchte. Das ist Risikominimierung. Zum andern sind aber gerade bei den großen Titeln wie einem GTA, einem Assassin's Creed oder einem Battlefield viele hundert Entwickler mehrere Jahre damit beschäftigt die für ein solches AAA-Spiel benötigten "Production-Values" zu erstellen. Es gibt nur noch ganz wenige externe, unabhängige Studios, rein von ihrer Größe her, die das bewältigen könnten. In Deutschland vielleicht noch Crytek, in Europe würden mir zumindest spontan sonst nur noch vielleicht Remedy und Quantic Dreams einfallen (wird noch den ein oder anderen geben, den ich gerade vergesse - aber du verstehst, was ich meine). Deshalb behaupte ich auch - weil es bislang bei jedem Konsolenzyklus am Ende und Übergang zur nächsten Generation so war - das weitere dieser noch unabhängigen Studios von den Majors wie Microsoft, Sony, EA, Epic etc. aufgekauft werden - da diese Nachschub (und noch mehr Production-Values) für die neuen Konsolen benötigen.
Lohnt es sich überhaupt noch für ein neu gegründetes Studio ihr Spiel bei einem großen Publisher zu pitchen oder sollen sie sich auf kleinere Indie-Publisher konzentrieren? Es gibt zwar Ausnahmen wie Sea of Solitude (deutsches Indiespiel, das letztes Jahr über EA erschien) und Sekiro, aber aktuell sehe ich keine Anzeichen, dass diese bereits eine Trendwende eingeleitet haben.
"Bei einem großen Publisher" zu pitchen ist tatsächlich schwierig. Lohnen tut es sich aber immer, und sei es nur für das manchmal durchaus hilfreiche Feedback, das du als Entwickler bekommst. Und gerade auch Microsoft und Sony unterstützen durchaus auch kleinere Indie-Studios immer wieder, weit mehr, als man vielleicht von außen denken könnte (oder auch Epic). "Sea of Solitude" ist vielleicht eine Ausnahme, die man hier aus dt. Sicht besonders wahrnimmt, aber da gibt es insgesamt schon noch wesentlich mehr. Aber Du hast im Kern natürlich recht - von den von mir schon erwähnten 120 Publishern, ist die Chance bei den ~20 wirklich großen eher geringer. Aber es gibt noch verdammt viele darunter. Ein anderer Aspekt: wenn man ein vergleichsweise kleineres Indie-Projekt für sagen wir mal 1-2 Mio Euro entwickelt, ist das für große Publisher oft auch einfach "zu klein". Das ist für die - im übertragenen Sinne - zu viel Papierkram und Bindung von kostbaren Resourcen, selbst wenn es hintenraus vielleicht 10 Mio einspielt. Das ist bitter - aber Entwickler hören tatsächlich oft von kleinen Publishern "Das ist uns zu teuer" und von großen "Das ist uns zu billig". :roll:
Daher hätte ich erwartet, dass viele Teams sehr iterativ an ihre Spiele herangehen. Nach meine Kenntnisstand haben das auch kleine Studios in den 90igern so gemacht (Condor z.B.).
Nicht falsch verstehen - das tuen Spiele-Entwickler immer noch. Und auch das von Dir angesprochene Blizzard-Beispiel ist ein gutes (es gab mal im Zuge dieses Post Mortems, auf das Du Dich beziehst, sogar das Original Design Doc von Diablo 1 im Netz, weiß aber nicht, ob das noch verfügbar ist). Tatsächlich war Spiel-Entwicklung schon immer "agil", lange vor irgendwelchen Manifestos Anfang der 2000er ;)

Dave Theurer, der Designer von Tempest und Missile command aus den 80ern hat das mal wie folgt beschrieben: "Pick an idea. Write up a game proposal. Get it OK'd by management. Take a couple of weeks to bring up a playable simple version. Management reviews that and OKs it or axes
it. If OK'd, continue with the whole game. Regular reviews by management to make sure still fun. Kill the game if not."

Das geschieht aber alles zu Beginn der Entwicklung. Sprich, alleine bis Du Dein Game Vision Statement hast, also das erste, was du überhaupt für den Pitch brauchst, iterierst du buchstäblich "die Hölle" aus Deiner Idee - mit Papierprototypen, echten Prototypen, Rip-o-matics etc. Und das geht dann in der von mir ausgeführten Pre-Production-Phase weiter - aber wie ein Trichter wird es immer "enger" während du alles, von dem du weißt, wie du es umsetzen willst, nach und nach in ein Design gießt, bis Du am Ende der Pre-Prod genau weißt, was Du machen willst. Und selbst während der Produktion schreibst Du weiter Detail-Specs für die einzelnen Features, Balancing Sheets etc. (also: auch das Game Design ist eigentlich bis zur Beta nie fertig und "final").

Du kannst es Dir aber halt selbst als kleines Studio mit vielleicht 30 Mitarbeitern nicht leisten, noch in der Produktion - wenn alle 30 Leute wirklich auf dem Projekt sind - wesentliche Kernspielmechaniken auszuprobieren und rumzutesten. Dann sind schnell 2 Monate weg - und das entspricht dann locker 300.000 €. Es ändert sich auch dann schon noch genügend, dir kommen neue Ideen beim Entwickeln etc. - aber Du musst versuchen, diesen Prozess mit klaren "Change Requests" zu kontrollieren. Denn es gibt kein schlechteres Spiel, als ein Spiel, das nicht fertig wird (weil z.B. dem Entwickler das Geld ausgeht).

Selbst bei dem von Dir angesprochenen Diablo 1 hat ja Blizzard die Entscheidung nicht hintenraus getroffen, sondern realtiv bald nachdem man mit dem damals erst noch externen (und später gekauften und in Blizzard North umgewandelten) Studio verhandelt hat.
Auch fand ich erstaunlich, dass kein Wort zum Thema automatisiertes Testen verloren wurde. Starres Abarbeiten von Testfällen ist nach meiner Erfahrung auf dem Rückzug
Automatisiertes Testen, Unit Testing etc. sind inzwischen so ein Standard in der Spiel-Entwicklung, dass ich sie tatsächlich nicht erwähnt habe, aber guter Punkt und absolut richtig :D Ein Team, das so nicht arbeitet, wird mit Sicherheit durch keine vernünftige Publisher Due Diligence kommen. Vielleicht am Rande noch ein interessanter Aspekt: die meisten Engineers/Coder im Game Developemt sind wirklich richtig, richtig gut (und deshalb auch außerhalb so begehrt). Test-Cases sind aber nach wie vor ultrawichtig, und werden auch nie ihre Bedeutung verlieren - denn Automated Testing sorgt für stabilen Code - aber Du willst ja, dass die QA auch Deine Features auf Spiel-Spaß und Funktionalität durchtestet, und insbesondere versucht, Was-Wäre-Wenn-Szenarien durchzuspielen (aber was passiert, wenn der Spieler diesen Button eben nicht drückt, wie vom Design vorgesehen, sondern stattdessen XY macht). Das im Zusammenspiel, dass Du bei größeren Produktionen oft mit großen externen QA-Dienstleistern zusammenarbeitest - da sind Test-Cases in der QA eigentlich dein wichtigstes Tool überhaupt. Das geht nicht ohne.
Ich meinte hier das Design Dokument im Stadium des Pitches - war wohl ein wenig zu undeutlich formuliert. :D Das ist eher mit einem Lastenheft, als mit einem Pflichtenheft zu vergleichen. Du unterschreibst ja nicht direkt nach dem Pitch den Endvertrag, das erläuterst du ja auch noch sehr gut.
Ach so, verstehe. Hm - ein klares Jein! :D Du hast natürlich absolut recht, der Entwickler hat in 90% der Fälle am Ende des Pitchings/zur Vertragsunterschrift eben noch kein Design Dokument. Deshalb ist es aber so wichtig (und wird leider auch manchmal vergessen - deshalb mein Kommentar mit dem "haben beide Seiten geschlafen" -> passiert leider durchaus in der Realität), dass der Vertrag von vorneherein eine Klausel hat, die besagt "Am Ende der Pre-Prod wird das Design Dok nach Abnahme automatisch Vertragsbestandteil" (sinngemäß). Dazu habe ich in diesem Kontext auch ein paar Vorträge auf Konferenzen gemacht, falls Dich das interessiert:

https://www.slideshare.net/RalfCAdam/wa ... nt-handout
(Seite 14 ff)

https://www.slideshare.net/RalfCAdam/wh ... eed-a-plan
(mehr oder weniger eine englische Version des Vortrags)
Benutzeravatar
Andre Peschke
Beiträge: 9736
Registriert: 9. Jan 2016, 16:16
Kontaktdaten:

Re: Runde #269: Wie ein Spiel entsteht

Beitrag von Andre Peschke »

Ralf C. Adam hat geschrieben: 1. Jun 2020, 10:27
Ubisoft, Activision und Electronic Arts lieber auf interne Entwicklungen setzen als Spiele von externen Entwicklern zu publishen. Woran liegt das? Lohnt sich das nicht mehr für die Publisher? Hat das zu viele Nachteile für die Entwickler?
Das hat sicherlich mehrere Gründe - zum einen sind die großen IPs der Publisher natürlich die "heiligen Kühe", über die man möglichst die volle Kontolle haben möchte. Das ist Risikominimierung. Zum andern sind aber gerade bei den großen Titeln wie einem GTA, einem Assassin's Creed oder einem Battlefield viele hundert Entwickler mehrere Jahre damit beschäftigt die für ein solches AAA-Spiel benötigten "Production-Values" zu erstellen. Es gibt nur noch ganz wenige externe, unabhängige Studios, rein von ihrer Größe her, die das bewältigen könnten.
Ich würde glauben, das außerdem Unternehmen einer bestimmten Größe immer versuchen werden, die gesamte Produktionskette zu besitzen um möglichst wenig Reibungsverluste zu haben. Ein externes Studio will noch XY% Gewinn für sich selbst rausschlagen. Warum das nicht selbst einstreichen. Zudem hält man Know-How und Tech inhouse. Die schicke Physik-Engine-Anpassung, der neue Renderer der entwickelt wurde, vielleicht gar die Engine - bleibt alles bei dir, anstatt das es ein externes Studio mitnimmt und beim nächsten Projekt vielleicht zugunsten des Wettbewerbs einsetzt.

Eine Aluhut-Frage am Rande, nur zur Unterhaltung: Ist es möglich, dass es zumindest ein erwünschter Nebeneffekt der ganzen Inhouse-Engines ist, dass dein Personal auf eine Technik spezialisiert wird, die nur in deinem eigenen Firmenverbund zum Einsatz kommt und sie daher nicht so leicht zur Konkurrenz wechseln können (gilt natürlich nur für Leute, die auf diese Technologie spezialisert sind - nicht für den Concept-Artist)? Kann ein Leveldesigner, der auf CryEngine super ist mal einfach so die gleiche Leistung auf Dunia/Glacier/Frostbite etc abrufen? Oder müssen die jeweils über Monate erstmal neu eingelernt werden?

Andre
Antworten