Einen europäischen Co-Development-Partner für Games wählen: Scope, Verantwortung und Belege

Die Frage hinter der Shortlist

Die meisten Producer haben kein Problem, Studios für Game Co-Development zu finden. Schwierig ist der Vergleich. Jeder Partner hat ein Portfolio und ein überzeugendes Vertriebsgespräch. Viel schwerer zu erkennen ist, wer für welchen Teil des Spiels verantwortlich sein wird, wie diese Arbeit in Ihren Build gelangt und was passiert, wenn sich der Plan ändert.

Dieser Leitfaden richtet sich an Producer, Publisher und Studioleitungen, die externe Partner für eine Spieleproduktion vergleichen. Er funktioniert unabhängig davon, ob Sie sich am Ende für Sourcegarden Studio, ein anderes europäisches Studio oder ein Team auf einem anderen Kontinent entscheiden. Das Ziel ist eine Entscheidung, die Sie begründen können: auf Basis von Scope, Verantwortung und Belegen – nicht des glattesten Pitches.

Am Ende finden Sie eine Bewertungsmatrix, die Sie in Ihre eigene Evaluierung übernehmen können.

Beginnen Sie mit dem Ownership-Modell, nicht mit dem Anbieter

Bevor Sie Partner vergleichen, sollten Sie festlegen, welche Art von Verantwortung Sie einkaufen. Externe Spieleentwicklung fällt in der Praxis meist in eines von drei Modellen:

Full-Cycle Development. Der Partner übernimmt die Verantwortung für einen vereinbarten Produktionsumfang – von Discovery und Architektur über Gameplay und Optimierung bis zur Release-Vorbereitung. Sie haben einen verantwortlichen technischen Produktionspartner.
Co-Development. Ihr internes Team behält die Kontrolle über das Gesamtprodukt, während der Partner definierte Features, Systeme oder technische Workstreams verantwortet – mit klaren Schnittstellen und Abnahmekriterien.
Dedicated Engineering-Kapazität. Erfahrene Entwickler arbeiten in Ihrem Repository, Ihrem Backlog und Ihrem Review-Prozess mit. Die technische Verantwortung bleibt bei Ihnen; der Partner ergänzt erfahrene Leute, ohne Ihnen einen eigenen Workflow aufzuzwingen.

Das sind die drei Modelle, in denen Sourcegarden Studio arbeitet, doch die Unterscheidung hilft bei jeder Shortlist, weil die Modelle unterschiedliche Risiken tragen. Bei Full-Cycle liegt das Risiko in der Architektur und dem Produktionsurteil des Partners. Bei Dedicated-Kapazität liegt es in Ihrer eigenen technischen Leitung, denn die externen Entwickler folgen Ihren Vorgaben. Co-Development liegt dazwischen: Der Erfolg hängt davon ab, wie sauber die Grenze zwischen beiden Teams gezogen ist.

Eine nützliche Regel: Wählen Sie das kleinste Ownership-Modell, das noch ein vollständiges, testbares Ergebnis liefern kann. Wenn Sie eine Netzwerkschicht brauchen, brauchen Sie vermutlich keinen Full-Cycle-Partner. Wenn intern aber niemand die Architektur dieser Schicht verantworten kann, löst zusätzliche Kapazität allein das Problem nicht.

Fragen Sie jeden Partner, welches Modell aus seiner Sicht zu Ihrer Situation passt, und warum. Wer für jedes Problem das größtmögliche Engagement vorschlägt, sagt Ihnen damit ebenfalls etwas.

Grenzen Sie den Scope ab, bevor Sie Schätzungen vergleichen

Co-Development scheitert am häufigsten an den Rändern: Gute Arbeit landet in einem Build, der sich weiterentwickelt hat, hängt von einem System ab, dessen Änderung niemand vereinbart hat, oder trifft auf einen Abnahmetest, der nie aufgeschrieben wurde.

Ein abgegrenzter Co-Development-Scope sollte mindestens diese Fragen beantworten:

Was genau verantwortet der Partner? Ein Feature, ein System, einen technischen Workstream oder einen Vertical Slice – so präzise benannt, dass zwei Personen dieselbe Grenze ziehen würden.
Welche Schnittstellen gibt es? Von welchen bestehenden Systemen, Datenformaten, Assets und Diensten hängt die Arbeit ab, und welche davon darf der Partner ändern?
Wer integriert? Merged der Partner in Ihren Main-Branch, liefert er in einen eigenen Branch oder ein Modul, oder übergibt er Pakete, die Ihr Team integriert?
Was bedeutet „fertig“? Abnahmekriterien, die sich in Ihrem Build testen lassen: Funktionsverhalten, Performance-Budgets auf der Zielhardware, Testabdeckung, Dokumentation.
Was bleibt bei Ihnen? Produktvision, IP, finale kreative Freigabe, Release-Entscheidungen und der Zugang zu den Personen, die diese treffen.

Wenn ein Partner Ihnen nicht helfen kann, das vor Arbeitsbeginn festzuhalten, ist seine Schätzung eine Vermutung über einen undefinierten Scope. Wer solche Schätzungen vergleicht, vergleicht den Optimismus der Partner, nicht ihre Fähigkeiten.

Ein praktischer Test: Bitten Sie jeden Partner zu beschreiben, wie die ersten zwei Integrationswochen in Ihrem Projekt aussehen würden. Gute Antworten sind konkret: Repository-Zugang, ein Build, den sie reproduzieren müssen, eine erste kleine Änderung, die gemergt und reviewt wird, und die Person auf Ihrer Seite, mit der sie sprechen müssen.

Kommunikation und Review: Wie Entscheidungen tatsächlich fallen

Integrationsprobleme sind meist Kommunikationsprobleme, die zu spät sichtbar wurden. Schauen Sie über das Versprechen „regelmäßiger Updates“ hinaus und fragen Sie, wie Entscheidungen im Alltag getroffen werden.

Hilfreiche Fragen:

Wann überschneiden sich die Arbeitszeiten? Überschneidung zählt mehr als Entfernung. Mit einem Partner in einer nahen Zeitzone können Sie am selben Tag einen Build prüfen, einen Blocker besprechen und einen Fix vereinbaren. Mit wenig oder keiner Überschneidung kann dieselbe Schleife einen Tag oder länger dauern – und diese Kosten summieren sich über eine ganze Produktion.
Wer nimmt an Reviews teil? Den Fortschritt sollte die Person präsentieren, die für die technischen Entscheidungen verantwortlich ist, nicht nur ein Account Manager.
Wie läuft Code Review? Im Co-Development sollten Review-Regeln in beide Richtungen vereinbart sein: Wer prüft die Merges des Partners, und prüft der Partner Änderungen, die seine Systeme betreffen?
Wo landen Risiken? Ein Partner sollte Risiken und die Auswirkungen von Änderungen an jedem Meilenstein sichtbar machen, nicht erst am Ende einer Phase.

Ein Bezugspunkt: Sourcegarden Studio sitzt in Budapest, arbeitet in mitteleuropäischer Zeit und innerhalb der Europäischen Union. Für europäische Partner bedeutet das tägliche Überschneidung über den Kontinent hinweg, praktikable Reisen und einen vertrauten EU-Rahmen für Verträge und Rechnungsstellung. Deutschland, Österreich und die Schweiz liegen in derselben Zeitzone wie Budapest; die Frage der Arbeitszeiten stellt sich dort kaum – Review- und Entscheidungsregeln sollten Sie trotzdem festhalten. Für Teams in anderen Regionen ist die Überschneidung kleiner und sollte ausdrücklich geplant statt vorausgesetzt werden. Der Standort allein ist keine Qualitätsgarantie – bewerten Sie, ob der Arbeitsrhythmus des Partners zu Ihrem passt. Mehr zur Zusammenarbeit mit einem Team in Budapest finden Sie unter Warum Budapest.

Technische Belege: So prüfen Sie die Aussagen eines Partners

Bei Portfolios wird der Vergleich schwierig, weil es in der Branche keine einheitliche Konvention für die Zuordnung von Arbeit gibt. Ein Studio kann ein Spiel zeigen, das es vollständig gebaut hat, eines, für das es ein einzelnes System geliefert hat, oder eines, das von Personen geliefert wurde, die damals woanders gearbeitet haben.

Nichts davon ist an sich ein Problem. Problematisch wird es erst, wenn die Zuordnung unklar ist. Fragen Sie bei jedem relevanten Projekt:

Wer hat es geliefert? Das heutige Unternehmen oder heutige Teammitglieder in früheren Rollen bei einem anderen Studio?
Welchen Teil haben sie verantwortet? Die komplette Produktion, ein benanntes System, die technische Leitung oder vertraglichen Support?
Arbeitet diese Person an Ihrem Projekt? Erfahrung überträgt sich nur, wenn die Menschen, die sie haben, an Ihrem Scope arbeiten.
Was lässt sich überprüfen? Eine öffentliche Store-Seite, Credits, eine Publisher-Referenz, ein Fachvortrag oder ein Code-Walkthrough unter NDA.
Welche Zahlen sind gemessen, welche sind Ziele? „90 FPS“ kann ein Designziel, ein typischer Messwert oder ein Worst Case auf bestimmter Hardware sein. Fragen Sie nach – und nach dem Build.

Sourcegarden Studio wendet diese Unterscheidung im eigenen Portfolio an. Bad Goons wird als aktuelles, aktiv entwickeltes eigenes IP des Studios präsentiert, die 64 Spieler sind als Designziel gekennzeichnet. Bean stalker und VOXSYS werden als Arbeit heutiger Teammitglieder in ihren früheren Rollen bei VR Storm Studio dargestellt, nicht als Produktionen von Sourcegarden Studio. Dieselbe Klarheit dürfen Sie von jedem Partner erwarten, und Sie können direkt danach fragen.

Über das Portfolio hinaus ist der stärkste Beleg meist ein technisches Gespräch über Ihr Projekt. Bitten Sie einen Senior Engineer des Partners, Ihnen zu erläutern, wie er Ihr riskantestes System angehen würde. Allgemeine Antworten, die auf jedes Spiel passen, sind ein schwaches Signal. Fragen zu Ihren Rahmenbedingungen, Ihrer Zielhardware und Ihrer bestehenden Architektur sind ein starkes.

Schätzannahmen: Vergleichen Sie Annahmen, nicht Summen

Zwei Schätzungen zum selben Briefing können aus legitimen Gründen weit auseinanderliegen. Ein Partner nimmt an, dass Engine-Version und Build-Pipeline stabil sind; ein anderer plant Zeit ein, um sie zu reproduzieren und zu stabilisieren. Einer geht davon aus, dass Ihr Team integriert; ein anderer nimmt die Integration in den eigenen Scope auf.

Wenn die Schätzungen vorliegen, bitten Sie jeden Partner um eine Liste:

des enthaltenen und ausdrücklich ausgeschlossenen Scopes;
der Annahmen zu Ihrer Codebasis, Ihren Tools, Assets und der Verfügbarkeit Ihres Teams;
der Abhängigkeiten von Entscheidungen oder Zulieferungen Ihrerseits;
der Faktoren, die die Schätzung ändern würden, und in welcher Größenordnung;
der Ergebnisse jedes Meilensteins und wie sich jedes davon testen lässt.

Sind zentrale Annahmen noch offen – etwa eine unbekannte Codebasis oder ein unerprobter technischer Ansatz –, wird ein seriöser Partner eine kurze Discovery-Phase oder einen Risiko-Prototyp vorschlagen, bevor er den ganzen Workstream kalkuliert. Das ist kein Verkaufstrick, sondern der Weg, nicht für eine Schätzung ohne Fundament zu bezahlen. Sourcegarden Studio arbeitet bei erheblichen Unbekannten so: zuerst eine fokussierte Discovery oder ein Prototyp, danach ein Meilensteinplan auf Basis der Ergebnisse.

Illustratives Beispiel: Ein Studio lässt sich von drei Partnern eine Matchmaking- und Lobby-Integration anbieten. Das niedrigste Angebot setzt voraus, dass der Backend-Dienst bereits konfiguriert ist; das höchste umfasst die Konfiguration und eine Deployment-Dokumentation. Auf dem Papier wirkt ein Partner dreimal so teuer. Tatsächlich sind die Scopes verschieden. Das zeigt erst eine Gegenüberstellung der Annahmen.

Übergabe und Change Management

Jedes Co-Development-Engagement endet oder verändert seine Form. Fragen Sie daher von Anfang an, wie die Arbeit übergeben wird:

Dokumentation. Architekturnotizen, Setup-Anleitungen und bekannte Einschränkungen – geschrieben für die Menschen, die das System warten werden, nicht für das Vertriebsdeck.
Build und Pipeline. Kann Ihr Team die gelieferte Arbeit ohne den Partner bauen, testen und deployen?
Wissenstransfer. Pairing-Sessions, aufgezeichnete Walkthroughs oder eine Übergangsphase, in der Ihre Engineers Änderungen vornehmen, während der Partner noch erreichbar ist.
Verantwortung nach dem Release. Wer behebt Bugs, wer reagiert auf Live-Incidents, und wie lange?

Change Management ist ebenso wichtig. Der Scope wird sich im Lauf einer Produktion verschieben. Entscheidend ist, ob Änderungen vor der Umsetzung sichtbar, bepreist und freigegeben werden – oder später als Überschreitung auffallen. Lassen Sie sich von jedem Partner zeigen, wie eine Scope-Änderung vorgeschlagen wird, wie ihre Auswirkung auf Zeitplan und Budget dargestellt wird und wer sie auf beiden Seiten freigibt.

Die Bewertungsmatrix für Partner

Nutzen Sie diese Tabelle während und nach den Partnergesprächen. Bewerten Sie jede Zeile mit 0 bis 2 Punkten: 0 – kein Beleg, 1 – behauptet, aber noch nicht geprüft, 2 – mit Belegen geprüft, die Sie auch Dritten zeigen könnten. Die Zeilen fragen bewusst nach Belegen: Ein Partner mit starkem Pitch und schwachen Belegen erreicht weniger Punkte, als das Vertriebsgespräch vermuten lässt.

Kriterium	Was Sie fragen	Wie ein guter Beleg aussieht	Warnsignale
Nachgewiesene relevante Erfahrung	Welche früheren Projekte ähneln unserem Scope, und was genau haben Sie verantwortet?	Benannte Projekte mit klarer Zuordnung (heutiges Unternehmen vs. frühere Rollen), präzise beschriebener eigener Anteil, überprüfbare Quellen	Logos ohne Rollen; „wir haben daran mitgearbeitet“ ohne Details; vermischte Firmen- und Personenreferenzen
Verantwortliche Senior-Person	Wer ist technisch für unseren Workstream verantwortlich, und mit welchem Zeitanteil?	Eine benannte Senior- oder Lead-Person, die an technischen Calls teilnimmt und im Projekt bleibt	Senior-Leute nur in der Vertriebsphase; Verantwortung verteilt auf „das Team“
Passendes Ownership-Modell	Welches Modell empfehlen Sie uns, und warum?	Eine begründete Empfehlung – auch wenn ein kleineres Modell genügen würde	Für jedes Problem das größte Engagement
Abgegrenzter Scope und Schnittstellen	Was verantworten Sie, wovon hängen Sie ab, was dürfen Sie ändern?	Eine schriftliche Grenze: verantwortete Systeme, Schnittstellen, Abhängigkeiten, Ausschlüsse	Scope nur als Feature-Liste
Integrationsplan	Wie gelangt Ihre Arbeit in den ersten zwei Wochen in unseren Build?	Konkrete Schritte: Zugang, Build-Reproduktion, erster reviewter Merge, benannte Ansprechpartner	„Wir passen uns Ihrem Prozess an“ ohne Details
Kommunikation und Review	Wann überschneiden sich unsere Zeiten, wer prüft was, wo landen Risiken?	Vereinbarte Überschneidungszeiten, beidseitige Review-Regeln, ein Risikolog oder Vergleichbares	Nur schriftliche Reports; keine Review-Vereinbarung
Meilenstein-Ergebnisse	Was erhalten wir an jedem Meilenstein, und wie testen wir es?	Spielbare oder messbare Ergebnisse, verknüpft mit Abnahmekriterien	Meilensteine nach verstrichener Zeit oder geleisteten Stunden
Schätzannahmen	Was setzt Ihre Schätzung voraus, was enthält und was schließt sie aus?	Eine explizite Annahmenliste und die Auslöser, die sie ändern würden	Eine einzige Summe ohne Annahmen
Technisches Verständnis unseres Projekts	Wie würden Sie unser riskantestes System angehen?	Fragen zu unseren Rahmenbedingungen und der Zielhardware; Optionen mit Trade-offs	Allgemeine Antworten, die auf jedes Spiel passen
Übergabe und Change Management	Wie übergeben Sie, und wie wird eine Scope-Änderung freigegeben?	Dokumentations- und Wissenstransferplan; ein sichtbarer Änderungsprozess	Übergabe als finale Zip-Datei

Bewerten Sie jeden Partner anhand derselben Zeilen und mit denselben Personen im Raum. Eine hohe Gesamtpunktzahl zählt weniger als die Zeilen, die Ihr Hauptrisiko abbilden. Ist Ihre größte Sorge die Integration in eine fragile Codebasis, sollte die Zeile Integrationsplan stärker gewichtet werden als das Portfolio.

Die Entscheidung

Ein guter Co-Development-Partner macht Verantwortung sichtbar: was ihm gehört, was Ihnen gehört und wo beides in Ihrem Build zusammenkommt. Am besten erkennen Sie das nicht im Portfolio, sondern in einem kurzen, konkreten Gespräch über Ihren Scope – gefolgt von einem schriftlichen Angebot, das Sie mit der Matrix oben prüfen können.

Wenn Sie dieses Gespräch vorbereiten, beschreibt die Seite zu unseren Game-Development-Leistungen, wie Sourcegarden Studio Full-Cycle-, Co-Development- und Dedicated-Engagements aufsetzt. Wenn Sie bereits einen Workstream im Blick haben, können Sie Ihr Briefing senden – ein Senior-Teammitglied antwortet direkt.