Eigene Engine entwickeln: Wann sich der Aufwand für Spielestudios lohnt

Eine eigene Engine entwickeln heißt, Verantwortung für einen erheblichen Teil der Spieleproduktion zu übernehmen. Der mögliche Gewinn liegt in passgenauer Simulation, kurzen Arbeitswegen und kontrollierbarer Technik. Bezahlt wird er mit Entwicklungszeit, dauerhaftem Wartungsaufwand und Aufgaben, die eine etablierte Engine bereits übernimmt. Entscheidend ist deshalb nicht, ob sich eine ungewöhnliche Idee selbst programmieren lässt, sondern ob daraus ein belastbarer Vorteil für das Spiel und seine Produktion entsteht.

Zwischen Unreal Engine, Unity oder Godot und einer vollständigen Eigenentwicklung liegt allerdings viel Platz. Ein Studio kann eigene Werkzeuge ergänzen, eine Simulation auslagern oder eine verfügbare Codebasis verändern. Die Wahl ist keine Abstimmung zwischen kreativer Freiheit und Fertigbaukasten. Es geht darum, welche Teile der Technik das Team selbst kontrollieren muss und welche es zuverlässig übernehmen kann.

Vier Wege statt einer Entweder-oder-Entscheidung

Der Begriff Engine umfasst mehr als die Ausgabe eines Bildes. Zur produktiven Infrastruktur gehören unter anderem Datenimport, Szenenverwaltung, Animation, Audio, Eingabe, Speicherverwaltung, Diagnose und die Erzeugung auslieferbarer Builds. Hinzu kommen Werkzeuge für Menschen, die keine Engine-Programmierer sind. Eine beeindruckende Rendering-Demo beantwortet deshalb noch nicht die Frage, wie daraus ein dauerhaft nutzbares Produktionssystem wird.

Auch eine Eigenentwicklung muss nicht jede Bibliothek ersetzen. Eine selbst verantwortete Engine kann beispielsweise vorhandene Komponenten für Audio, Physik oder Dateiformate integrieren. Wesentlich ist, wer Architektur, Schnittstellen und Weiterentwicklung kontrolliert. Rez Graham behandelt die Abwägung in seinem GDC-Vortrag über eigene Engines. Der offizielle Sitzungseintrag zur GDC 2024 beschreibt ausdrücklich eine Betrachtung von Kosten und Nutzen, keine allgemeingültige Pflicht zur Eigenentwicklung.

Entscheidungsmatrix: Welcher Engpass rechtfertigt welchen Ansatz?

Die folgende Matrix ist eine redaktionelle Entscheidungshilfe, kein gemessener Leistungsvergleich zwischen Unreal, Unity, Godot und Eigenentwicklungen. Sie ordnet typische Ausgangslagen einem ersten Prüfweg zu. Entscheidend bleibt, ob ein Prototyp den vermuteten Vorteil unter den Bedingungen des konkreten Projekts bestätigt.

Die Matrix bevorzugt zunächst den kleineren Eingriff. Das ist keine Aussage über die Qualität eigener Engines, sondern eine Begrenzung des zu prüfenden Umfangs. Eine technische Vorgabe, fehlender Plattformzugang oder eine ungeklärte Finanzierung kann einen Ansatz ausschließen, auch wenn er in anderen Kriterien gut abschneidet. Solche Ausschlusskriterien sollten nicht durch einen zusammengezählten Punktescore verdeckt werden.

Was die Verbreitungszahlen tatsächlich aussagen

Die GDC-Befragung State of the Game Industry 2026 nennt Unreal bei 42 Prozent und Unity bei 30 Prozent der befragten Entwickler als primär genutzte Engine. Unter den Befragten aus AA-Studios erreicht Unreal 59 Prozent. Das beschreibt Antworten aus einer Branchenbefragung. Daraus lässt sich weder der Anteil aller weltweit entwickelten Spiele noch unmittelbar der wirtschaftliche Erfolg einer Engine ableiten.

Eine andere Perspektive liefert GameDiscoverCos Untersuchung von mehr als 33.000 Steam-Spielen. Dort sinkt der Anteil der Titel ohne erkennbare Engine von 27 Prozent für 2017 auf 13 Prozent für 2025. Wichtig ist die Formulierung: Eine technisch nicht erkannte Engine ist nicht automatisch eine nachgewiesene Eigenentwicklung. Die Stichprobe umfasst zudem Spiele oberhalb einer geschätzten Umsatzschwelle und zahlreiche weitere Titel, keine vollständige Zufallsauswahl aller Spiele. Die beiden Untersuchungen zeigen unterschiedliche Ausschnitte des Marktes und sollten nicht zu einer gemeinsamen Quote für Custom-Engines verrechnet werden.

Pagonia: Simulation und Darstellung müssen gemeinsam skalieren

Bei Pioneers of Pagonia gehört die Vielzahl sichtbarer, eigenständig handelnder Figuren zum Spielprinzip. Volker Wertich erklärte bereits im Februar 2023 in einer öffentlichen Entwicklerantwort, dass Envision Entertainment eine eigene Engine für die Darstellung großer Einheitenmengen und eine dynamische Umgebung optimiere. Die offizielle FAQ beschreibt Tausende selbstständig arbeitende Einheiten, sichtbaren Warentransport und prozedural erzeugte Karten.

Daraus ergibt sich eine andere technische Aufgabenstellung als bei wenigen besonders detaillierten Hauptfiguren. Viele kleine Vorgänge müssen zusammen ein verständliches Wirtschaftssystem bilden. Als allgemeine Architekturfragen stellen sich dabei etwa Datenzugriff, Wegsuche, Aktualisierungsintervalle und die Trennung von Simulation und sichtbarer Darstellung. Welche konkreten Verfahren Envision intern verwendet, lässt sich aus diesen öffentlichen Angaben nicht vollständig ableiten.

Große Einheitenzahlen beweisen allerdings nicht, dass eine Standard-Engine grundsätzlich ungeeignet wäre. Epic stellt mit MassEntity ein datenorientiertes Framework in Unreal Engine bereit, das Daten ähnlicher Entitäten gruppiert und gemeinsam verarbeitet. Der faire Vergleich lautet deshalb: Wie viel Anpassung benötigt das konkrete Spiel in einer vorhandenen Architektur, und welchen zusätzlichen Aufwand verursacht die eigene Lösung? Ein Genre-Etikett allein beantwortet das nicht.

GIANTS: Wenn die Datenstruktur zum Spielsystem gehört

Der Landwirtschafts-Simulator 25 liefert ein anschauliches Beispiel für eng verzahnte Simulation und Darstellung. In einem offiziellen Technikinterview zur Bodenverformung beschreibt GIANTS-Programmierer Eddie Edwards ein Raster mit 12,5 Zentimetern Auflösung. Fahrzeuggewicht, Reifen und Bodeneigenschaften beeinflussen die Verformung. Die Informationen werden nicht einfach als vollständig belegte Karte im Speicher gehalten: Das System nutzt komprimierte Bereiche und speichert Veränderungen dort, wo sie tatsächlich auftreten.

Damit betrifft die Funktion mehr als sichtbare Reifenspuren. Datenhaltung, Geländedarstellung und Fahrzeugkontakt müssen zusammenpassen. GIANTS beschreibt dafür Erweiterungen seiner Density Maps, der Geländegeometrie und des virtuellen Texturierens. Der technische Nutzen einer eigenen Engine entsteht hier durch die Abstimmung mehrerer Systeme auf dieselbe Aufgabe. Daraus folgt nicht, dass andere Engines solche Effekte unmöglich machen. Das Beispiel zeigt vielmehr, warum ein über längere Zeit gepflegter Spezialaufbau für eine bestimmte Art von Spiel sinnvoll sein kann.

Holistic und FLEDGE: Produktionswerkzeuge als eigener Wert

Keen Games bezeichnet die Holistic Engine in seiner offiziellen Enshrouded-FAQ als eigene, auf das Spiel ausgerichtete Technik. Die Welt entsteht unter Einsatz prozeduraler Werkzeuge, wird aber von Hand gestaltet. Das ist ein wichtiger Unterschied zu einer Spielwelt, die bei jedem Neustart zufällig neu erzeugt wird. Das Entwicklerteam zeigt einen Ausschnitt dieser Arbeit im Video Creating the world of Enshrouded.

Bei Enshrouded ist deshalb nicht allein die sichtbare Voxelwelt interessant. Entscheidend für die Produktion ist auch, wie schnell neue Orte entstehen und wie gut sich Veränderungen überprüfen lassen. Allgemein kann ein spezialisierter Editor mehr Nutzen stiften als ein einzelner zusätzlicher Grafikeffekt: Wenn Gestaltung, Test und Korrektur weniger Zeit benötigen, profitiert die gesamte Inhaltsproduktion. Ob dieser Gewinn die Engine-Kosten ausgleicht, muss das jeweilige Studio anhand seiner tatsächlichen Abläufe messen.

Deck13 beschrieb in einer verifizierten Entwickler-Fragerunde zu Atlas Fallen eine über Jahre auf Action-Rollenspiele ausgerichtete FLEDGE-Engine. Für Atlas Fallen nannte das Team unter anderem GPU-basiertes Culling, datenorientierte Änderungen an der Objektverwaltung, ein neues World-Streaming-System und visuelles Scripting für Gestaltung und Spieldesign. Das sind Eingriffe in Laufzeit und Produktion zugleich. Die öffentliche Antwort dokumentiert die Gründe für dieses Projekt, belegt aber keine pauschale Überlegenheit eigener Engines für alle späteren Spiele.

Quellcodezugriff ist nicht dasselbe wie eine eigene Engine

Ein Studio kann erhebliche eigene Technik entwickeln, ohne bei null anzufangen. Laut technischer FAQ des Publishers verwendet Kingdom Come: Deliverance II eine intern weiterentwickelte Version der CryEngine. Zwischen der Nutzung eines unveränderten Produkts und einer vollständigen Eigenentwicklung liegt damit ein praktisch wichtiger Zwischenweg.

Dabei müssen technische und rechtliche Kontrolle getrennt betrachtet werden. CRYENGINE stellt Quellcode im Rahmen ihres Lizenzmodells bereit. Das ist nicht mit einer beliebig verwendbaren Open-Source-Lizenz gleichzusetzen. Godot steht dagegen unter der MIT-Lizenz, die Nutzung und Änderungen einschließlich kommerzieller Projekte erlaubt, unter Beachtung ihrer Lizenzhinweise. Ein darauf aufgebautes Spiel muss dadurch nicht selbst als Open Source veröffentlicht werden.

Ein eigener Fork spart den Neubau vorhandener Funktionen, schafft aber eine zusätzliche Pflegeaufgabe. Jede größere Abweichung kann spätere Sicherheitskorrekturen, Plattformanpassungen und neue Funktionen des Ursprungsprojekts aufwendiger machen. Wichtig ist daher eine klare Grenze: Welche Änderungen bleiben als getrennte Erweiterung bestehen, welche müssen in die Engine hinein, und welche sollen möglichst an das ursprüngliche Projekt zurückgegeben werden?

Die Kostenrechnung beginnt nicht bei Lizenzgebühren

Für die Entscheidung zählt der Gesamtaufwand über Entwicklung und Betrieb. Bei einer bestehenden Engine gehören dazu Lizenzkosten, Integration, Weiterbildung, Erweiterungen und Versionswechsel. Bei einer Eigenentwicklung kommen Architektur, Werkzeuge, Plattformpflege und die Verantwortung für Fehler hinzu, für die es keinen externen Engine-Anbieter als erste Anlaufstelle gibt. Eine eingesparte Lizenzgebühr ist deshalb noch keine Einsparung im Projektbudget.

Ein ausdrücklich hypothetisches Rechenbeispiel: Vier Vollzeitkräfte, die 18 Monate ausschließlich an Engine-Aufgaben arbeiten, ergeben bei angenommenen vollständig belasteten Personalkosten von 10.000 Euro pro Person und Monat bereits 720.000 Euro. Das ist keine Branchenpreisangabe und keine Schätzung für eines der genannten Studios. Zusätzliche Testkapazitäten, externe Dienstleistungen, Hardware und Verzögerungen sind darin nicht automatisch enthalten. Ebenso muss die Vergleichsrechnung berücksichtigen, welche dieser Tätigkeiten auch mit einer vorhandenen Engine nötig wären.

Besonders relevant sind die verdrängten Aufgaben. Programmierzeit für einen Materialeditor steht nicht gleichzeitig für Spielmechanik zur Verfügung. Umgekehrt können bessere Werkzeuge später vielen Beschäftigten Zeit sparen. Ein belastbarer Business Case verbindet daher direkte Ausgaben mit messbaren Produktionsgewinnen und einem zeitlichen Horizont. Mögliche Nachfolgespiele dürfen die Rechnung verbessern, sollten aber nicht wie bereits finanzierte Projekte behandelt werden.

Dreijahresvergleich: Welche Mehrkosten müsste die Eigenentwicklung ausgleichen?

Das folgende Modell erweitert die Beispielrechnung um eine Alternative mit bestehender Engine. Sämtliche Personalansätze sind frei gewählte Rechenannahmen, keine erhobenen Branchenwerte und keine Angebote von Engine-Anbietern. Beide Varianten werden über 36 Monate betrachtet. Unterstellt werden 10.000 Euro vollständig belastete Kosten pro Vollzeitkraft und Monat sowie derselbe Funktionsumfang. Ob beide Personalansätze diesen Umfang tatsächlich liefern könnten, müsste ein Studio separat nachweisen.

Nicht enthalten sind Lizenzgebühren, externe Dienstleistungen, zusätzliche Hardware, gesonderte Testteams und Unterschiede beim Veröffentlichungstermin. Gemeinsame Gameplay- und Inhaltsproduktion wird ebenfalls nicht angesetzt. Die ausgewiesenen Summen sind deshalb nur Engine-bezogene Personalkosten. Für eine Gesamtentscheidung müssten die jeweils unterschiedlichen übrigen Ausgaben und Risiken hinzugerechnet werden. Auch eine bestehende eigene Codebasis würde die Startannahmen verändern.

Eine einfache Sensitivitätsrechnung zeigt den Einfluss des Kostensatzes: Bei 8.000 statt 10.000 Euro pro Person und Monat sinkt die Differenz auf 432.000 Euro; bei 12.000 Euro steigt sie auf 648.000 Euro. Diese Spanne bildet ausschließlich den veränderten Personalkostensatz ab, keine statistische Unsicherheit und kein vollständiges Risikoszenario. Zusätzliche Personenmonate durch unterschätzte Aufgaben würden beide Varianten gesondert verteuern.

Soll ausschließlich bessere Werkzeugproduktivität die Differenz von 540.000 Euro ausgleichen, wären bei einem weiteren angenommenen Verrechnungswert von 75 Euro je produktiver Arbeitsstunde insgesamt 7.200 eingesparte Stunden nötig. Verteilt auf 20 Beschäftigte, 220 Arbeitstage pro Jahr und drei Jahre sind das rund 33 Minuten pro Person und Arbeitstag. Das ist eine rechnerische Gewinnschwelle unter günstiger Annahme: Der Nutzen müsste über den gesamten Zeitraum anfallen. Beginnt er erst nach den ersten 18 Monaten, wären im verbleibenden Zeitraum rund 65 Minuten täglich nötig.

Solche Zeitgewinne sind nicht automatisch eingespartes Geld. Kürzere Wartezeiten können zusätzliche Iterationen ermöglichen, ohne den Personaletat zu senken. Ein finanzieller Vorteil entsteht erst, wenn die frei werdende Kapazität sinnvoll genutzt wird oder tatsächlich Ausgaben entfallen. Außerdem darf derselbe Effekt nicht doppelt verbucht werden, etwa zugleich als geringerer Personalbedarf und als unverändert große zusätzliche Produktionskapazität.

Konsolen-Portierung bleibt ein eigenes Arbeitsgebiet

Ein lauffähiger PC-Prototyp ist noch kein Nachweis für eine tragfähige Konsolenstrategie. Speicherbedarf, CPU-Last, Ladeverhalten und die Integration von Plattformdiensten müssen auf den vorgesehenen Zielgeräten funktionieren. Eine kleinere interne Codebasis kann die Analyse erleichtern. Fehlende Plattformabstraktionen und Diagnosewerkzeuge können denselben Vorteil wieder aufheben.

Die offiziellen Hinweise von Godot zu Konsolen machen die organisatorische Seite sichtbar: Erforderlich sind die Zulassung durch den Plattformbetreiber und Zugriff auf dessen Entwicklungsumgebung. Die Godot Foundation pflegt keine offiziellen Konsolenports; möglich sind spezialisierte Anbieter oder eigene Integrationen. Selbst offen verfügbarer Engine-Code ersetzt also weder Plattformzugang noch die technische Umsetzung. Auch das Godot-Beispiel für Xbox-Entwicklung auf PC ist von einer fertigen Unterstützung für Xbox-Konsolen zu unterscheiden.

Die Planung muss solche Grenzen vor Beginn der Vollproduktion klären. Welche Plattformen werden verbindlich unterstützt? Wer pflegt die jeweiligen Schnittstellen? Wie werden Fehler auf Geräten untersucht, die nicht an jedem Arbeitsplatz stehen? Bei einer Eigenentwicklung müssen diese Zuständigkeiten genauso konkret sein wie die Verantwortung für Rendering oder Gameplay.

Der Prototyp muss die schwierigen Fälle nachweisen

Vor einer langfristigen Festlegung braucht es einen Vergleich unter realistischen Bedingungen. Ein kleiner Demonstrator mit wenigen Figuren und leeren Landschaften testet selten die späteren Engpässe. Aussagekräftiger ist ein repräsentativer Ausschnitt mit der erwarteten Menge an Objekten, ungünstigen Sichtweiten, typischen Änderungen an der Welt und den vorgesehenen Ladewegen. Beide technischen Ansätze sollten dabei dieselbe Aufgabe lösen.

Zu den Messwerten gehören CPU- und GPU-Zeiten, Spitzen beim Speicherverbrauch, Ladezeiten und auffällige Verzögerungen. Durchschnittliche Bilder pro Sekunde reichen nicht aus, wenn einzelne Frames das Spiel regelmäßig unterbrechen. Ebenso wichtig ist die Produktionsseite: Wie lange dauert der Weg von einer geänderten Quelldatei bis zum getesteten Ergebnis? Können Designer Fehler selbst nachvollziehen? Bleiben gespeicherte Zustände nach einer Änderung des Datenformats verwendbar?

Auch Ausfälle gehören zum Test. Beschädigte Assets, fehlende Ressourcen, abgebrochene Ladevorgänge oder ein erschöpftes Speicherbudget dürfen nicht erst kurz vor Veröffentlichung sichtbar werden. Für Multiplayer-Projekte kommen je nach Architektur zusätzliche Anforderungen hinzu, etwa reproduzierbare Zustandsänderungen oder der kontrollierte Umgang mit unterschiedlichen Spielständen. Nicht jedes Netzwerkspiel benötigt dabei dieselbe Form deterministischer Simulation.

Für die Laufzeitmessung trennt auch Epics Profiling-Dokumentation Bildrate, Frame-Zeit und konkrete Ressourcenengpässe. Die nachstehende Prüftabelle überträgt diesen Grundgedanken auf einen Engine-Vergleich und ergänzt eigene Kriterien für die Produktion. Sie enthält keine gemessenen Resultate und behauptet keine schnellere Engine.

Für ein 60-FPS-Ziel stehen rechnerisch etwa 16,67 Millisekunden pro Bild zur Verfügung, für 30 FPS etwa 33,33 Millisekunden. Diese Werte sind Zeitbudgets, keine pauschalen Qualitätsurteile. Das 99. Perzentil beschreibt die Grenze, unter der 99 Prozent der gemessenen Frame-Zeiten liegen; seltenere Ausreißer müssen zusätzlich betrachtet werden. CPU- und GPU-Zeiten werden nicht einfach addiert, weil ihre Arbeit je nach Pipeline überlappen kann. Mehrere wiederholte Durchläufe und dokumentierte Einstellungen verhindern, dass ein günstiger Einzelversuch die Entscheidung bestimmt.

Wann sich eine eigene Engine entwickeln lässt und lohnt

Technische Machbarkeit und wirtschaftliche Tragfähigkeit sind verschiedene Prüfungen. Für eine eigene Engine sprechen ein klar begrenzter Anwendungsbereich, ein nachgewiesener Vorteil im entscheidenden Spielsystem und ein Team, das auch die weniger sichtbaren Aufgaben tragen kann. Dokumentation, automatisierte Tests und Wissenstransfer gehören dazu. Wenn nur eine Person zentrale Systeme versteht, besteht unabhängig von der Qualität des Codes ein erhebliches Produktionsrisiko.

Eine bestehende Engine ist häufig die passendere Wahl, wenn die besonderen Anforderungen als überschaubare Erweiterung umsetzbar sind und ihre Werkzeuge bereits zum Team passen. Ein eigener Kern mit fremden Komponenten kann sinnvoll sein, wenn nur einzelne Systeme stark abweichen. Der vollständige Eigenbau braucht den stärksten Nachweis: Er muss nicht nur etwas Besonderes ermöglichen, sondern dessen Herstellung, Veröffentlichung und langfristige Pflege tatsächlich tragen.

Die sinnvollste Entscheidung fällt daher nicht anhand eines einzelnen Effekts oder einer grundsätzlichen Vorliebe für eigene Technik. Sie folgt aus gemessenen Engpässen, realistischen Personalressourcen und der Frage, welche Arbeit über mehrere Jahre verlässlich erledigt werden kann. Eine Engine ist dann eine gute Investition, wenn sie dem Spiel und seiner Produktion dient, statt selbst zum unüberschaubaren Hauptprojekt zu werden.