SlideShare ist ein Scribd-Unternehmen logo
1 von 42
Downloaden Sie, um offline zu lesen
Was tun, wenn‘s
brennt?
Ralf C. Adam
DISCLAIMER
Dieser Vortrag wurde im Mai 2018 im Rahmen der German Dev Day Conference in
Frankfurt/GERMANY gehalten. Die vorliegende Präsentation enthält möglicherweise
nicht alle Original-Materialien (Bilder, Videos etc.) die seinerzeit gezeigt wurden. Diese
Folien geben stattdessen den erklärenden Text wieder (=Handout). Alle gezeigten
Schutzmarken stellen geistiges Eigentum der jeweiligen Eigentümer dar.
Wer ist der Typ da vorn?
Ralf C. Adam
>25 Jahre in der Spiele-Industrie
Producing, Project Management, Game Design, Writing
Dozent an der Games Academy Berlin
Berater für verschiedene Studios, FFF München, Quo Vadis Game Conference etc.
• Unabhängige Spiele-Entwicklerstudios
• Indies, Mid-Size-Studios, AAA – im Prinzip
jeder Developer, der mit einem Publisher
(oder Investor, Geldgeber etc. zusammen-
arbeitet)
An wen richtet sich der Talk?
• Die häufigsten Brandursachen
Wann kommt es zum Stress mit dem Publisher?
• Vorbeugender Brandschutz
Entwicklungsvertrag, Planung, Zusammenarbeit, Studio-Strategie
• Aktive Brandbekämpfung
Was kann ich tun, wenn es „brennt“?
Themen
Die häufigsten
Brandursachen
TYPISCHE KONFLIKTHERDE
• Ansprechpartner (=Stakeholder) bei Publisher ändert sich -> z.B.
Producer, Entwicklungsleiter wechselt etc.
• Strategie des Publishers ändert sich (Genre, Platformen, Business-
Modell etc.)
• Publisher hat Feature-Änderungswünsche (pocht aber auf Einhaltung
von Zeit & Budget)
• Publisher will zusätzliche Features (gleichzeitig aber nichts von „mehr
Zeit/Budget“ hören)
Die häufigsten Brandursachen
TYPISCHE KONFLIKTHERDE (cont.)
• Publisher will/kann Milestone nicht abnehmen
• Publisher will Planung ändern (z.B. bestimmte Features sollen eher
fertig sein etc.)
• Publisher will zusätzliche Leistungen, die im Vorfeld nicht klar
vereinbart waren (Paradebeispiel: Trailer, Artwork, Screenshots für
Messe -> Todschlagargument: „Ist ja auch in Eurem Interesse“)
• Publisher erbringt seine eigenen (vertraglich zugesicherten) Leistungen
nicht ordnungsgemäß (zu wenig/keine QA, zu wenig/kein Marketing
etc.)
Die häufigsten Brandursachen
TYPISCHE KONFLIKTHERDE (cont.)
• Entwickler kommt in Verzug, weil geplante Features schwieriger
umzusetzen sind, als im Vorfeld geplant
• Publisher gerät mit Zahlungen in Verzug oder hält sie bewusst zurück
(z.B. aus einem der oben genannten Gründe, oder auch grundlos)
Die häufigsten Brandursachen
Vorbeugender
Brandschutz
DER ENTWICKLUNGSVERTRAG
• Euer wichtiges Mittel zur „Brandbekämpfung“ bzw.
„Brandvorbeugung“
• Wichtigste Regel: Vertrag niemals ohne Anwalt!
• Zweitwichtigste Regel: Es ist nie persönlich, es geht
immer nur ums Geschäft!
Vertrag
IN DUBIO PRO REO
• Für den Developer ist es im Zweifel immer von Nachteil,
wenn diese Punkte nicht klar geregelt sind
• Gerichtsverfahren sind langwierig und teuer, und der
Publisher hat deshalb in der Regel immer den längeren Atem
• Außerdem: meist wird Vergleich angestrebt, der dann dem
Entwickler nicht unbedingt alles zuspricht, was ihm
eigentlich zustehen würde
Vertrag
DIE WICHTIGSTEN VERTRAGSKLAUSELN
• Leistungsumfang
• Bezahlung
• Rechte/Source Code
• IP
• Change Request/Change Order
• Milestones & Approvals
• Gewährleistung & Garantien
• Terminierung
➔ DISCLAIMER: Die nachfolgenden Ausführungen sind nur „Best Practices“ und
bedürfen in jedem Fall der individuellen Konsultation und Anpassungen durch
einen entsprechend ausgebildeten Anwalt
Vertrag
VERTRAG: Leistungsumfang
• Worum geht es überhaupt?
• Es muss klar sein, was der Entwickler überhaupt abliefern muss
• Das Game Design Document muss Vertragsbestandteil sein
• Liegt es zum Zeitpunkt der Unterschrift noch nicht vor: klare
Pre-Production definieren, an deren Ende GDD nach Abnahme
Vertragsbestandteil wird
Vertrag
VERTRAG: Bezahlung
• Was verdient der Developer?
• Genaue Definition, wie sich die Netto-Erlöse zusammensetzen
• Außerdem: zu welchen Zeitpunkten wird was ausbezahlt?
• Wie wird es mit dem Dev-Budget verrechnet?
• Advance-against-Royalties? Profit-Share Deal?
Vertrag
VERTRAG: Rechte/Source Code
• Wem gehört was? Wem gehört der Source-Code? Was darf der
Publisher damit machen, falls es zur Vertragsterminierung kommt?
• Was darf der Entwickler damit machen? Hat der Entwickler seine
Technik nur an den Publisher lizensiert? Hat er alle Rechte abgetreten
(also quasi auch die Tech selbst auf den Publisher übertragen?)
• Deutschland: alle Rechte, die übertragen werden sollen, müssen
aufgelistet werden, sonst werden nur die zwingend notwendigen
Rechte übertragen.
Vertrag
VERTRAG: Rechte/Source Code (cont.)
• Üblich: Lizensierung der Technik - Rechte übertragen, dass Publisher
alles mit dem Source Code machen darf, aber nur für dieses Spiel
• Außerdem: Wie gut muss Source Code dokumentiert sein? Üblich: so
gut, dass ein 3rd Party-Entwickler ihn weiterentwickeln kann.
Vertrag
VERTRAG: IP
• Wem gehört die IP?
• Ausschließlich dem Entwickler, ausschließlich dem Publisher?
• Gibt es ein 1st-Option Right für eine der beiden Parteien für Sequel(s)?
Vertrag
VERTRAG: CHANGE ORDER/CHANGE REQUEST
• Einer der Punkte, der am häufigsten zu Konflikten führt
• Change Request hat in der Regel IMMER Auswirkungen auf Zeit und
Ressourcen -> und damit das Budget
• Wer kann CO‘s veranlassen? Was ist der formale Prozess?
• Für den Entwickler beste Lösung: Nach CO-Anfrage macht Entwickler
Angebot für Umsetzung incl. Auflistung der Auswirkungen auf
Zeitplanung + Budget. Nur nach anschließendem Okay durch Publisher
wird CO wirksam.
Vertrag
VERTRAG: MILESTONES
• Wie laufen MS-Approvals ab? Was passiert, wenn Publisher nicht
innerhalb von X Werktagen abnimmt (ideal: Klausel, die besagt: MS ist
dann automatisch abgenommen)
• Sind Zahlungen an Milestones gekoppelt? (besser: entkoppeln und
Zahlungen monatlich - falls Entwickler bei in MS Verzug gerät, kann
Publisher Zahlungen dann anteilig entsprechend zurückhalten)
• Gibt es Penalities bei Nichtablieferung?
• Schwierig: Milestone-Definitionen bei Live-Betrieb für Online-Spiele
Vertrag
VERTRAG: GEWÄHRLEISTUNG & GARANTIEN
• Was ist die Gewährleistung bei kritischen Defekten (Bugs)?
• Schwierig: Garantien, dass man nicht gegen Patente in allen Ländern
verstößt (dafür braucht man eigentliche eine teure Patentprüfung)
Vertrag
VERTRAG: TERMINIERUNG
• Wie kann der Vertrag beendet werden?
• Am Ende der Pre-Production? Nur bei Breach? Auch ohne Grund,
während der Entwicklung?
• Von wem – nur Publisher, oder auch vom Entwickler?
• Welche Fristen?
• Gibt es eine „Kill-Fee“?
Vertrag
PLANUNG
• Nur mit transparenter Planung könnt Ihr Euch wirksam gegen
„Publisher“-Willkür schützen
• Vertrag so gestalten, dass einmal abgenommene Planung automatisch
bindend ist
• Keine „Fuzzy“-Milestones (damit schießt Ihr Euch selbst ins Knie)
• Immer kristallklar kommunizieren, was geliefert wird (und was nicht)
Planung
PLANUNG (cont.)
• Im Zweifel für den Publisher „mitdenken“
• Stehen z.B. Messen an oder eine Presse-Tour?
(Trailer, Artwork, Screenshots)
Planung
ZUSAMMENARBEIT
• Euer wichtigster Ansprechpartner: Publisher-Producer
• Deshalb: Producer möglichst selbst „aussuchen“, bei der Wahl
entsprechend Mitspracherecht fordern
• Warum sollten bestimmte Dinge nur für Publisher gelten? Wie wäre
es z.B. mit einer Publisher-Due Diligence durch den Entwickler? Key-
People-Regel im Vertrag auch auf Publisher-Seite einbauen.
Zusammenarbeit
ZUSAMMENARBEIT (cont.)
• Mag lästig klingen, aber…
o Developer Weekly Report inkl. Risks aber auch Action-Points/To-
Dos für Publisher kann enorm helfen
o Für jedes Meeting MUSS es ein Protokoll geben, mit klarem
„Abnahme-Prozess“ (Nach Erhalt Schweigen = Zustimmung, dass
notierte Punkte so besprochen wurden)
Zusammenarbeit
ZUSAMMENARBEIT (cont.)
• Entscheidungen immer nur schriftlich und per Email
• Niemals Entscheidungen mündlich, in Skype-Calls oder
in Tools wie Slack, Discord etc.
Zusammenarbeit
STUDIO-STRATEGIE
• Wenn Ihr selbst keine Strategie für Euer Studio habt, könnt Ihr nicht
angemessen reagieren, wenn es brennt!
• Nur mit klarer Studio-Strategie und Studio-Vision lässt sich einem
Publisher auf Augenhöhe begegnen
• Wo soll eurer Studio in 2 Jahren stehen? In 3, in 5? Was ist eure
Langzeitstrategie (Exit? Studio-Wachstum?) Eigene IP? Work for hire?
• One-Project- vs. Multi-Project-Studio
Strategie
PITCH-STRATEGIE
• Niemals darauf verlassen, dass man ein Projekt hat
• Besonders riskant, wenn man kleines Studio mit nur einem Projekt ist
• Immer vom Worst-Case ausgehen
• Immer (!) pitchen - und sei es nur Euer Studio und kein konkretes
Projekt: Networking, Messen, Publisher-Kontakt-Pflege etc.
Strategie
PITCH-STRATEGIE (cont.)
• Denkt dran: Euer Netzwerk ist euer nächstes Projekt
• „It‘s a people business“
• Es kann schnell ~6 – 9 Monate von erstem Kontakt bis zur
Vertragsunterschrift dauern
Strategie
Aktive Brand-
bekämpfung
Grundsätzliche Verhaltensregeln
• Bei Konflikten sofort reagieren – nicht schwelen lassen, macht alles nur
viel schlimmer
• Ein Publisher mag so etwas aussitzen können (weil er die finanziellen
Reserven hat), Ihr nicht
• Sofort anwaltliche Hilfe holen – nicht erst auf eigene Faust versuchen
(muss nicht unbedingt gleich nach außen kommuniziert werden, um
nicht gleich die Fronten zu verhärten, aber intern solltet Ihr Euch sofort
abstimmen)
Was tun, wenn‘s brennt?
Grundsätzliche Verhaltensregeln (cont.)
• Ab jetzt alles schriftlich dokumentieren (überlebenswichtig!). Keine
mündlichen Absprachen/faulen Kompromisse mit dem Publisher
• Versuchen, den Grund des Konflikts/des Problems klar herauszu-
arbeiten und zu benennen – gemeinsam mit dem Publisher.
• Vielleicht ist alles nur ein Missverständnis? In jedem Fall auf eine
konkrete schriftliche Benennung des Problems/Mangels „festnageln“.
Was tun, wenn‘s brennt?
Grundsätzliche Verhaltensregeln (cont.)
• Niemals persönlich werden oder emotional reagieren (=wird von der
Gegenseite als Zeichen von Schwäche gedeutet)
• Niemals den Publisher spüren lassen, dass man das Geld braucht und
ggfs. mit dem Rücken zur Wand steht (verschiebt die Machtver-
hältnisse zu Euren Ungunsten)
Was tun, wenn‘s brennt?
Aktive Bekämpfung typischer Brandherde
• Change Request: Publisher will Änderungen, aber nicht dafür bezahlen
-> deshalb formaler CO Prozess (schon im Vertrag) so wichtig:
eigentlich gibt es hier nur: war vereinbart (dann muss es vom
Entwickler auch geliefert werden) oder war nicht vereinbart (dann
muss es vom Publisher gesondert bezahlt werden)
• Nicht auf Spielchen einlassen wie „Ist ja auch in eurem Interesse“ oder
„Das könnt Ihr doch mal eben schnell machen, das kann doch nicht
lange dauern“
Was tun, wenn‘s brennt?
Aktive Bekämpfung typischer Brandherde
• Abnahme-Verweigerung: z.B. von einzelnen Features oder ganzen
Milestones. Meist mit der Begründung: „Das war aber so nicht
vereinbart“ oder „Das habe ich mir aber ganz anders vorgestellt“
• Aus diesem Grund sind konkrete Milestone-Definitionen und genaue
Game Design Specs so wichtig
• Wenn Ihr mit agilen Methoden wie „SCRUM“ arbeitet – definiert
gemeinsam mit dem Publisher im Vorfeld (und Vertrag), wie
entsprechende Milestone-Definitionen/Abnahmen laufen
Was tun, wenn‘s brennt?
Aktive Bekämpfung typischer Brandherde
• Entwicklung eines Features dauert schlicht länger: Auch hier – mit offenen
Karten spielen. Kommunizieren, dass Entwicklung des Features länger dauert.
• Wenn man das Feature im Prinzip hinbekommen würde, aber vielleicht nicht
mit „Schleifchen“ evtl. über aktiven Change Request mehr Zeit/Budget
anfragen.
• Sollte aber frühzeitig erfolgen. Und man muss immer damit rechnen, dass
Publisher auch „Nein“ sagen kann
• Alternativ: Feature-Cut -> bedarf aber klarer Klassifizierung von Must-Haves,
Should-Haves und Nice-To-Haves in Specs
Was tun, wenn‘s brennt?
Weitere Best-Practices
• Einfache Formel: je weiter Ihr im Projekt fortgeschritten seid – und je
wichtiger das Projekt für den Publisher ist –, desto risikoscheuer wird
der Publisher bzgl. Konflikten
• Mahnfristen einhalten: Immer rechtzeitig mahnen/offizielle
Zahlungserinnerungen schicken, wenn der Publisher in Verzug gerät
(gilt ggfs. auch bei Abnahmen etc.)
Was tun, wenn‘s brennt?
Weitere Best-Practices (cont.)
• Publisher-Wechsel wenn es mit dem aktuellen Partner nicht mehr
weitergeht: sehr schwierig – und auch zeitaufwändig. Im Prinzip wie
eine komplett neue Pitch- und Vertragsverhandlungsphase (kann
schnell mehrere Monate dauern)
• Und: Neue Publisher sind besonders zögerlich in solchen Situationen
(warum gab es Stress mit dem vorherigen Partner?)
Was tun, wenn‘s brennt?
Weitere Best-Practices (cont.)
• Ultima-Ratio: Wenn der Publisher nicht zahlt und trotz Mahnungen alle
Nachfristen verstrichen sind – dem Publisher klar und unmissverständlich
kommunizieren, dass man die Arbeit einstellt, bis der Konflikt gelöst ist (diese
Drohung ist natürlich wirkungsvoller bei „Multi-Project-Teams, die
Ressourcen aktiv auf andere Projekte abziehen können)
• Falls „Live-Betrieb“ und Spiel schon auf dem Markt, prüfen, ob man
Urheberrechtsverletzung geltend machen kann (-> Anwalt). Dann lässt sich
ggfs. einstweilige Verfügung erwirken (oder bei Mobile-Spielen kann man
auch Apple/Google informieren – und das Spiel wird im Store gesperrt)
Was tun, wenn‘s brennt?
Special Thanks
Kai Bodensiek
Rechtsanwalt
--------------------------------------------
Anna-Louisa-Karsch-Str. 2
10178 Berlin
Tel.: 030 – 26 93 950
Fax.: 030 – 26 93 95 15
Kai.Bodensiek@bvm-law.de
www.bvm-law.de
Ralf C. Adam
ralf@tigerteam-productions.de
Skype: ralfcadam
www@tigerteam-productions.de www@gameproducersguide.com
Kontakt

Weitere ähnliche Inhalte

Ähnlich wie Was tun wenn's brennt - Hand-out

Ueberlegungen Projektmanagement Web Applications
Ueberlegungen Projektmanagement Web ApplicationsUeberlegungen Projektmanagement Web Applications
Ueberlegungen Projektmanagement Web Applications
Günther Haslbeck
 
Vergleich Agentursoftware - So finden Sie die richtige Software!
Vergleich Agentursoftware - So finden Sie die richtige Software!Vergleich Agentursoftware - So finden Sie die richtige Software!
Vergleich Agentursoftware - So finden Sie die richtige Software!
Because Software
 

Ähnlich wie Was tun wenn's brennt - Hand-out (20)

Wie kann eResult Sie unterstützen?
Wie kann eResult Sie unterstützen?Wie kann eResult Sie unterstützen?
Wie kann eResult Sie unterstützen?
 
Webinar: Webconferencing Do's and Don'ts
Webinar: Webconferencing Do's and Don'tsWebinar: Webconferencing Do's and Don'ts
Webinar: Webconferencing Do's and Don'ts
 
Vorteile von Kundenblogs anhand der Fallstudie Baur-Kundenblog
Vorteile von Kundenblogs anhand der Fallstudie Baur-KundenblogVorteile von Kundenblogs anhand der Fallstudie Baur-Kundenblog
Vorteile von Kundenblogs anhand der Fallstudie Baur-Kundenblog
 
Agile Verträge - Vertragsgestaltung für agile Softwareentwicklung
Agile Verträge - Vertragsgestaltung für agile SoftwareentwicklungAgile Verträge - Vertragsgestaltung für agile Softwareentwicklung
Agile Verträge - Vertragsgestaltung für agile Softwareentwicklung
 
Briefingvorlage pdf
Briefingvorlage pdfBriefingvorlage pdf
Briefingvorlage pdf
 
Vertrauen als Vertragsbasis (Agile Contracts 2015, München)
Vertrauen als Vertragsbasis (Agile Contracts 2015, München)Vertrauen als Vertragsbasis (Agile Contracts 2015, München)
Vertrauen als Vertragsbasis (Agile Contracts 2015, München)
 
Stay calm & keep shipping - iOS DevCon 2013
Stay calm & keep shipping - iOS DevCon 2013Stay calm & keep shipping - iOS DevCon 2013
Stay calm & keep shipping - iOS DevCon 2013
 
Lean Startup: Wie sieht der Einsatz von MVPs in der deutschen Praxis aus?
Lean Startup: Wie sieht der Einsatz von MVPs in der deutschen Praxis aus?Lean Startup: Wie sieht der Einsatz von MVPs in der deutschen Praxis aus?
Lean Startup: Wie sieht der Einsatz von MVPs in der deutschen Praxis aus?
 
Ueberlegungen Projektmanagement Web Applications
Ueberlegungen Projektmanagement Web ApplicationsUeberlegungen Projektmanagement Web Applications
Ueberlegungen Projektmanagement Web Applications
 
FMK2015: Software Engineering Basics by Jan Rüdiger
FMK2015: Software Engineering Basics by Jan RüdigerFMK2015: Software Engineering Basics by Jan Rüdiger
FMK2015: Software Engineering Basics by Jan Rüdiger
 
Vertraege in Agilen Projekten
Vertraege in Agilen ProjektenVertraege in Agilen Projekten
Vertraege in Agilen Projekten
 
Teil 1 - BIM Planung die Spass macht
Teil 1 - BIM Planung die Spass machtTeil 1 - BIM Planung die Spass macht
Teil 1 - BIM Planung die Spass macht
 
Die 10 fatalsten Pitch-Fehler.
Die 10 fatalsten Pitch-Fehler.Die 10 fatalsten Pitch-Fehler.
Die 10 fatalsten Pitch-Fehler.
 
Open Source im Unternehmenseinsatz
Open Source im UnternehmenseinsatzOpen Source im Unternehmenseinsatz
Open Source im Unternehmenseinsatz
 
User Experience Design - von der Idee zum erfolgreichen Produkt
User Experience Design - von der Idee zum erfolgreichen ProduktUser Experience Design - von der Idee zum erfolgreichen Produkt
User Experience Design - von der Idee zum erfolgreichen Produkt
 
Vergleich Agentursoftware - So finden Sie die richtige Software!
Vergleich Agentursoftware - So finden Sie die richtige Software!Vergleich Agentursoftware - So finden Sie die richtige Software!
Vergleich Agentursoftware - So finden Sie die richtige Software!
 
PR Kampagnen
PR KampagnenPR Kampagnen
PR Kampagnen
 
Change By Design
Change By DesignChange By Design
Change By Design
 
Digitale Produktentwicklung für Verlage
Digitale Produktentwicklung für VerlageDigitale Produktentwicklung für Verlage
Digitale Produktentwicklung für Verlage
 
FMK2022 Dokumentation - Thomas Hirt
FMK2022 Dokumentation - Thomas HirtFMK2022 Dokumentation - Thomas Hirt
FMK2022 Dokumentation - Thomas Hirt
 

Mehr von Ralf C. Adam

Mehr von Ralf C. Adam (15)

2019 - Getting the right partner for your game
2019 - Getting the right partner for your game2019 - Getting the right partner for your game
2019 - Getting the right partner for your game
 
10 surefire ways to screw up your studio
10 surefire ways to screw up your studio10 surefire ways to screw up your studio
10 surefire ways to screw up your studio
 
When shit hits the fan you need a plan
When shit hits the fan you need a planWhen shit hits the fan you need a plan
When shit hits the fan you need a plan
 
Anatomy of a Modern Game design Document - Ralf Adam, Vera Frisch - 4C:Kyiv
Anatomy of a Modern Game design Document - Ralf Adam, Vera Frisch - 4C:KyivAnatomy of a Modern Game design Document - Ralf Adam, Vera Frisch - 4C:Kyiv
Anatomy of a Modern Game design Document - Ralf Adam, Vera Frisch - 4C:Kyiv
 
MS-Project - Unleash the Force | Ralf C. Adam
MS-Project - Unleash the Force | Ralf C. AdamMS-Project - Unleash the Force | Ralf C. Adam
MS-Project - Unleash the Force | Ralf C. Adam
 
Building the right team | Ralf C. Adam
Building the right team | Ralf C. AdamBuilding the right team | Ralf C. Adam
Building the right team | Ralf C. Adam
 
The ten Commandments of Project Management | Ralf C. Adam
The ten Commandments of Project Management | Ralf C. AdamThe ten Commandments of Project Management | Ralf C. Adam
The ten Commandments of Project Management | Ralf C. Adam
 
Seven Lies my Project Manager told me | Ralf C. Adam
Seven Lies my Project Manager told me | Ralf C. AdamSeven Lies my Project Manager told me | Ralf C. Adam
Seven Lies my Project Manager told me | Ralf C. Adam
 
Pitching Workshop for Game Developers | Ralf C. Adam
Pitching Workshop for Game Developers | Ralf C. AdamPitching Workshop for Game Developers | Ralf C. Adam
Pitching Workshop for Game Developers | Ralf C. Adam
 
German Game Development Post Mortems | Ralf C. Adam
German Game Development Post Mortems | Ralf C. AdamGerman Game Development Post Mortems | Ralf C. Adam
German Game Development Post Mortems | Ralf C. Adam
 
Outlook on the (potential) Future of the German Games Industry | Ralf C. Adam
Outlook on the (potential) Future of the German Games Industry | Ralf C. AdamOutlook on the (potential) Future of the German Games Industry | Ralf C. Adam
Outlook on the (potential) Future of the German Games Industry | Ralf C. Adam
 
Moving from boxed title Game Development to F2P | Ralf C. Adam
Moving from boxed title Game Development to F2P | Ralf C. AdamMoving from boxed title Game Development to F2P | Ralf C. Adam
Moving from boxed title Game Development to F2P | Ralf C. Adam
 
100 of the most influential German Videogames | Ralf C. Adam
100 of the most influential German Videogames | Ralf C. Adam100 of the most influential German Videogames | Ralf C. Adam
100 of the most influential German Videogames | Ralf C. Adam
 
Outsourcing a Game Trailer/TV-Spot | Ralf C. Adam
Outsourcing a Game Trailer/TV-Spot | Ralf C. AdamOutsourcing a Game Trailer/TV-Spot | Ralf C. Adam
Outsourcing a Game Trailer/TV-Spot | Ralf C. Adam
 
Beyond agile - Pitfalls & misconceptions when working with SCRUM & Co | Ralf ...
Beyond agile - Pitfalls & misconceptions when working with SCRUM & Co | Ralf ...Beyond agile - Pitfalls & misconceptions when working with SCRUM & Co | Ralf ...
Beyond agile - Pitfalls & misconceptions when working with SCRUM & Co | Ralf ...
 

Was tun wenn's brennt - Hand-out

  • 2. DISCLAIMER Dieser Vortrag wurde im Mai 2018 im Rahmen der German Dev Day Conference in Frankfurt/GERMANY gehalten. Die vorliegende Präsentation enthält möglicherweise nicht alle Original-Materialien (Bilder, Videos etc.) die seinerzeit gezeigt wurden. Diese Folien geben stattdessen den erklärenden Text wieder (=Handout). Alle gezeigten Schutzmarken stellen geistiges Eigentum der jeweiligen Eigentümer dar.
  • 3. Wer ist der Typ da vorn? Ralf C. Adam >25 Jahre in der Spiele-Industrie Producing, Project Management, Game Design, Writing Dozent an der Games Academy Berlin Berater für verschiedene Studios, FFF München, Quo Vadis Game Conference etc.
  • 4. • Unabhängige Spiele-Entwicklerstudios • Indies, Mid-Size-Studios, AAA – im Prinzip jeder Developer, der mit einem Publisher (oder Investor, Geldgeber etc. zusammen- arbeitet) An wen richtet sich der Talk?
  • 5. • Die häufigsten Brandursachen Wann kommt es zum Stress mit dem Publisher? • Vorbeugender Brandschutz Entwicklungsvertrag, Planung, Zusammenarbeit, Studio-Strategie • Aktive Brandbekämpfung Was kann ich tun, wenn es „brennt“? Themen
  • 7. TYPISCHE KONFLIKTHERDE • Ansprechpartner (=Stakeholder) bei Publisher ändert sich -> z.B. Producer, Entwicklungsleiter wechselt etc. • Strategie des Publishers ändert sich (Genre, Platformen, Business- Modell etc.) • Publisher hat Feature-Änderungswünsche (pocht aber auf Einhaltung von Zeit & Budget) • Publisher will zusätzliche Features (gleichzeitig aber nichts von „mehr Zeit/Budget“ hören) Die häufigsten Brandursachen
  • 8. TYPISCHE KONFLIKTHERDE (cont.) • Publisher will/kann Milestone nicht abnehmen • Publisher will Planung ändern (z.B. bestimmte Features sollen eher fertig sein etc.) • Publisher will zusätzliche Leistungen, die im Vorfeld nicht klar vereinbart waren (Paradebeispiel: Trailer, Artwork, Screenshots für Messe -> Todschlagargument: „Ist ja auch in Eurem Interesse“) • Publisher erbringt seine eigenen (vertraglich zugesicherten) Leistungen nicht ordnungsgemäß (zu wenig/keine QA, zu wenig/kein Marketing etc.) Die häufigsten Brandursachen
  • 9. TYPISCHE KONFLIKTHERDE (cont.) • Entwickler kommt in Verzug, weil geplante Features schwieriger umzusetzen sind, als im Vorfeld geplant • Publisher gerät mit Zahlungen in Verzug oder hält sie bewusst zurück (z.B. aus einem der oben genannten Gründe, oder auch grundlos) Die häufigsten Brandursachen
  • 11. DER ENTWICKLUNGSVERTRAG • Euer wichtiges Mittel zur „Brandbekämpfung“ bzw. „Brandvorbeugung“ • Wichtigste Regel: Vertrag niemals ohne Anwalt! • Zweitwichtigste Regel: Es ist nie persönlich, es geht immer nur ums Geschäft! Vertrag
  • 12. IN DUBIO PRO REO • Für den Developer ist es im Zweifel immer von Nachteil, wenn diese Punkte nicht klar geregelt sind • Gerichtsverfahren sind langwierig und teuer, und der Publisher hat deshalb in der Regel immer den längeren Atem • Außerdem: meist wird Vergleich angestrebt, der dann dem Entwickler nicht unbedingt alles zuspricht, was ihm eigentlich zustehen würde Vertrag
  • 13. DIE WICHTIGSTEN VERTRAGSKLAUSELN • Leistungsumfang • Bezahlung • Rechte/Source Code • IP • Change Request/Change Order • Milestones & Approvals • Gewährleistung & Garantien • Terminierung ➔ DISCLAIMER: Die nachfolgenden Ausführungen sind nur „Best Practices“ und bedürfen in jedem Fall der individuellen Konsultation und Anpassungen durch einen entsprechend ausgebildeten Anwalt Vertrag
  • 14. VERTRAG: Leistungsumfang • Worum geht es überhaupt? • Es muss klar sein, was der Entwickler überhaupt abliefern muss • Das Game Design Document muss Vertragsbestandteil sein • Liegt es zum Zeitpunkt der Unterschrift noch nicht vor: klare Pre-Production definieren, an deren Ende GDD nach Abnahme Vertragsbestandteil wird Vertrag
  • 15. VERTRAG: Bezahlung • Was verdient der Developer? • Genaue Definition, wie sich die Netto-Erlöse zusammensetzen • Außerdem: zu welchen Zeitpunkten wird was ausbezahlt? • Wie wird es mit dem Dev-Budget verrechnet? • Advance-against-Royalties? Profit-Share Deal? Vertrag
  • 16. VERTRAG: Rechte/Source Code • Wem gehört was? Wem gehört der Source-Code? Was darf der Publisher damit machen, falls es zur Vertragsterminierung kommt? • Was darf der Entwickler damit machen? Hat der Entwickler seine Technik nur an den Publisher lizensiert? Hat er alle Rechte abgetreten (also quasi auch die Tech selbst auf den Publisher übertragen?) • Deutschland: alle Rechte, die übertragen werden sollen, müssen aufgelistet werden, sonst werden nur die zwingend notwendigen Rechte übertragen. Vertrag
  • 17. VERTRAG: Rechte/Source Code (cont.) • Üblich: Lizensierung der Technik - Rechte übertragen, dass Publisher alles mit dem Source Code machen darf, aber nur für dieses Spiel • Außerdem: Wie gut muss Source Code dokumentiert sein? Üblich: so gut, dass ein 3rd Party-Entwickler ihn weiterentwickeln kann. Vertrag
  • 18. VERTRAG: IP • Wem gehört die IP? • Ausschließlich dem Entwickler, ausschließlich dem Publisher? • Gibt es ein 1st-Option Right für eine der beiden Parteien für Sequel(s)? Vertrag
  • 19. VERTRAG: CHANGE ORDER/CHANGE REQUEST • Einer der Punkte, der am häufigsten zu Konflikten führt • Change Request hat in der Regel IMMER Auswirkungen auf Zeit und Ressourcen -> und damit das Budget • Wer kann CO‘s veranlassen? Was ist der formale Prozess? • Für den Entwickler beste Lösung: Nach CO-Anfrage macht Entwickler Angebot für Umsetzung incl. Auflistung der Auswirkungen auf Zeitplanung + Budget. Nur nach anschließendem Okay durch Publisher wird CO wirksam. Vertrag
  • 20. VERTRAG: MILESTONES • Wie laufen MS-Approvals ab? Was passiert, wenn Publisher nicht innerhalb von X Werktagen abnimmt (ideal: Klausel, die besagt: MS ist dann automatisch abgenommen) • Sind Zahlungen an Milestones gekoppelt? (besser: entkoppeln und Zahlungen monatlich - falls Entwickler bei in MS Verzug gerät, kann Publisher Zahlungen dann anteilig entsprechend zurückhalten) • Gibt es Penalities bei Nichtablieferung? • Schwierig: Milestone-Definitionen bei Live-Betrieb für Online-Spiele Vertrag
  • 21. VERTRAG: GEWÄHRLEISTUNG & GARANTIEN • Was ist die Gewährleistung bei kritischen Defekten (Bugs)? • Schwierig: Garantien, dass man nicht gegen Patente in allen Ländern verstößt (dafür braucht man eigentliche eine teure Patentprüfung) Vertrag
  • 22. VERTRAG: TERMINIERUNG • Wie kann der Vertrag beendet werden? • Am Ende der Pre-Production? Nur bei Breach? Auch ohne Grund, während der Entwicklung? • Von wem – nur Publisher, oder auch vom Entwickler? • Welche Fristen? • Gibt es eine „Kill-Fee“? Vertrag
  • 23. PLANUNG • Nur mit transparenter Planung könnt Ihr Euch wirksam gegen „Publisher“-Willkür schützen • Vertrag so gestalten, dass einmal abgenommene Planung automatisch bindend ist • Keine „Fuzzy“-Milestones (damit schießt Ihr Euch selbst ins Knie) • Immer kristallklar kommunizieren, was geliefert wird (und was nicht) Planung
  • 24. PLANUNG (cont.) • Im Zweifel für den Publisher „mitdenken“ • Stehen z.B. Messen an oder eine Presse-Tour? (Trailer, Artwork, Screenshots) Planung
  • 25. ZUSAMMENARBEIT • Euer wichtigster Ansprechpartner: Publisher-Producer • Deshalb: Producer möglichst selbst „aussuchen“, bei der Wahl entsprechend Mitspracherecht fordern • Warum sollten bestimmte Dinge nur für Publisher gelten? Wie wäre es z.B. mit einer Publisher-Due Diligence durch den Entwickler? Key- People-Regel im Vertrag auch auf Publisher-Seite einbauen. Zusammenarbeit
  • 26. ZUSAMMENARBEIT (cont.) • Mag lästig klingen, aber… o Developer Weekly Report inkl. Risks aber auch Action-Points/To- Dos für Publisher kann enorm helfen o Für jedes Meeting MUSS es ein Protokoll geben, mit klarem „Abnahme-Prozess“ (Nach Erhalt Schweigen = Zustimmung, dass notierte Punkte so besprochen wurden) Zusammenarbeit
  • 27. ZUSAMMENARBEIT (cont.) • Entscheidungen immer nur schriftlich und per Email • Niemals Entscheidungen mündlich, in Skype-Calls oder in Tools wie Slack, Discord etc. Zusammenarbeit
  • 28. STUDIO-STRATEGIE • Wenn Ihr selbst keine Strategie für Euer Studio habt, könnt Ihr nicht angemessen reagieren, wenn es brennt! • Nur mit klarer Studio-Strategie und Studio-Vision lässt sich einem Publisher auf Augenhöhe begegnen • Wo soll eurer Studio in 2 Jahren stehen? In 3, in 5? Was ist eure Langzeitstrategie (Exit? Studio-Wachstum?) Eigene IP? Work for hire? • One-Project- vs. Multi-Project-Studio Strategie
  • 29. PITCH-STRATEGIE • Niemals darauf verlassen, dass man ein Projekt hat • Besonders riskant, wenn man kleines Studio mit nur einem Projekt ist • Immer vom Worst-Case ausgehen • Immer (!) pitchen - und sei es nur Euer Studio und kein konkretes Projekt: Networking, Messen, Publisher-Kontakt-Pflege etc. Strategie
  • 30. PITCH-STRATEGIE (cont.) • Denkt dran: Euer Netzwerk ist euer nächstes Projekt • „It‘s a people business“ • Es kann schnell ~6 – 9 Monate von erstem Kontakt bis zur Vertragsunterschrift dauern Strategie
  • 32. Grundsätzliche Verhaltensregeln • Bei Konflikten sofort reagieren – nicht schwelen lassen, macht alles nur viel schlimmer • Ein Publisher mag so etwas aussitzen können (weil er die finanziellen Reserven hat), Ihr nicht • Sofort anwaltliche Hilfe holen – nicht erst auf eigene Faust versuchen (muss nicht unbedingt gleich nach außen kommuniziert werden, um nicht gleich die Fronten zu verhärten, aber intern solltet Ihr Euch sofort abstimmen) Was tun, wenn‘s brennt?
  • 33. Grundsätzliche Verhaltensregeln (cont.) • Ab jetzt alles schriftlich dokumentieren (überlebenswichtig!). Keine mündlichen Absprachen/faulen Kompromisse mit dem Publisher • Versuchen, den Grund des Konflikts/des Problems klar herauszu- arbeiten und zu benennen – gemeinsam mit dem Publisher. • Vielleicht ist alles nur ein Missverständnis? In jedem Fall auf eine konkrete schriftliche Benennung des Problems/Mangels „festnageln“. Was tun, wenn‘s brennt?
  • 34. Grundsätzliche Verhaltensregeln (cont.) • Niemals persönlich werden oder emotional reagieren (=wird von der Gegenseite als Zeichen von Schwäche gedeutet) • Niemals den Publisher spüren lassen, dass man das Geld braucht und ggfs. mit dem Rücken zur Wand steht (verschiebt die Machtver- hältnisse zu Euren Ungunsten) Was tun, wenn‘s brennt?
  • 35. Aktive Bekämpfung typischer Brandherde • Change Request: Publisher will Änderungen, aber nicht dafür bezahlen -> deshalb formaler CO Prozess (schon im Vertrag) so wichtig: eigentlich gibt es hier nur: war vereinbart (dann muss es vom Entwickler auch geliefert werden) oder war nicht vereinbart (dann muss es vom Publisher gesondert bezahlt werden) • Nicht auf Spielchen einlassen wie „Ist ja auch in eurem Interesse“ oder „Das könnt Ihr doch mal eben schnell machen, das kann doch nicht lange dauern“ Was tun, wenn‘s brennt?
  • 36. Aktive Bekämpfung typischer Brandherde • Abnahme-Verweigerung: z.B. von einzelnen Features oder ganzen Milestones. Meist mit der Begründung: „Das war aber so nicht vereinbart“ oder „Das habe ich mir aber ganz anders vorgestellt“ • Aus diesem Grund sind konkrete Milestone-Definitionen und genaue Game Design Specs so wichtig • Wenn Ihr mit agilen Methoden wie „SCRUM“ arbeitet – definiert gemeinsam mit dem Publisher im Vorfeld (und Vertrag), wie entsprechende Milestone-Definitionen/Abnahmen laufen Was tun, wenn‘s brennt?
  • 37. Aktive Bekämpfung typischer Brandherde • Entwicklung eines Features dauert schlicht länger: Auch hier – mit offenen Karten spielen. Kommunizieren, dass Entwicklung des Features länger dauert. • Wenn man das Feature im Prinzip hinbekommen würde, aber vielleicht nicht mit „Schleifchen“ evtl. über aktiven Change Request mehr Zeit/Budget anfragen. • Sollte aber frühzeitig erfolgen. Und man muss immer damit rechnen, dass Publisher auch „Nein“ sagen kann • Alternativ: Feature-Cut -> bedarf aber klarer Klassifizierung von Must-Haves, Should-Haves und Nice-To-Haves in Specs Was tun, wenn‘s brennt?
  • 38. Weitere Best-Practices • Einfache Formel: je weiter Ihr im Projekt fortgeschritten seid – und je wichtiger das Projekt für den Publisher ist –, desto risikoscheuer wird der Publisher bzgl. Konflikten • Mahnfristen einhalten: Immer rechtzeitig mahnen/offizielle Zahlungserinnerungen schicken, wenn der Publisher in Verzug gerät (gilt ggfs. auch bei Abnahmen etc.) Was tun, wenn‘s brennt?
  • 39. Weitere Best-Practices (cont.) • Publisher-Wechsel wenn es mit dem aktuellen Partner nicht mehr weitergeht: sehr schwierig – und auch zeitaufwändig. Im Prinzip wie eine komplett neue Pitch- und Vertragsverhandlungsphase (kann schnell mehrere Monate dauern) • Und: Neue Publisher sind besonders zögerlich in solchen Situationen (warum gab es Stress mit dem vorherigen Partner?) Was tun, wenn‘s brennt?
  • 40. Weitere Best-Practices (cont.) • Ultima-Ratio: Wenn der Publisher nicht zahlt und trotz Mahnungen alle Nachfristen verstrichen sind – dem Publisher klar und unmissverständlich kommunizieren, dass man die Arbeit einstellt, bis der Konflikt gelöst ist (diese Drohung ist natürlich wirkungsvoller bei „Multi-Project-Teams, die Ressourcen aktiv auf andere Projekte abziehen können) • Falls „Live-Betrieb“ und Spiel schon auf dem Markt, prüfen, ob man Urheberrechtsverletzung geltend machen kann (-> Anwalt). Dann lässt sich ggfs. einstweilige Verfügung erwirken (oder bei Mobile-Spielen kann man auch Apple/Google informieren – und das Spiel wird im Store gesperrt) Was tun, wenn‘s brennt?
  • 41. Special Thanks Kai Bodensiek Rechtsanwalt -------------------------------------------- Anna-Louisa-Karsch-Str. 2 10178 Berlin Tel.: 030 – 26 93 950 Fax.: 030 – 26 93 95 15 Kai.Bodensiek@bvm-law.de www.bvm-law.de
  • 42. Ralf C. Adam ralf@tigerteam-productions.de Skype: ralfcadam www@tigerteam-productions.de www@gameproducersguide.com Kontakt