Die Sprache, die nie wurde: Ein Blick auf gescheiterte und verlorene Programmiersprachen im Game Development

Interviews mit Branchenführern

In der Welt der Spieleentwicklung dreht sich alles um Performance, Flexibilität und kreative Freiheit. Videospiele sind keine gewöhnlichen Programme. Sie sind komplexe Systeme, verschmelzen Kunst mit Technik und benötigen eine Softwarearchitektur, die sowohl leistungsfähig als auch intuitiv ist. Es ist nicht verwunderlich, dass viele Entwickler den Wunsch verspüren, eine eigene Programmiersprache zu kreieren, die speziell auf die Bedürfnisse von Gamedev zugeschnitten ist. Eine Sprache, die schneller, ergonomischer und adaptiver ist als die bestehenden Optionen.

Doch die Realität zeigt, dass eine solche Sprache selten den Weg aus der Nische findet und oft als „die Sprache, die nie wurde“ in die Geschichten der Entwickler eingeht. Das Streben nach der perfekten Sprache für Spieleentwicklung weist gleich mehrere komplexe Anforderungen auf. Im Zentrum steht die Performance. Objekte und Werte müssen als sogenannte Value Types definiert werden, die Speicherfehler vermeiden und ohne teure Heap-Allokationen auskommen. Dabei ist Kontinuität wichtig: Datenstrukturen sollen im Speicher sequenziell und dicht beieinander liegen, um die Cache-Lokalisierung zu optimieren.

Hinter diesem simplen Prinzip verbirgt sich eine Herausforderung, denn die meisten modernen Sprachen abstrahieren genau diese Details, was sich negativ auf die Performance auswirkt – ein entscheidendes Kriterium bei Spielen, die mit tausenden Partikeln oder Gegnern in Echtzeit hantieren. In vielen Diskussionen rund um neue Programmiersprachen für Gamedev fehlt oftmals ein tieferes Verständnis für Metaprogrammierung. Dabei zählt gerade die Fähigkeit, Boilerplate-Code zu automatisieren oder zur Compilezeit Datenstrukturen zu reflektieren, zu den wichtigsten Werkzeugen, um einen produktiven Entwicklungsprozess zu gewährleisten. Spiele sind unglaublich facettenreich: Sie kombinieren Weltsimulation, Nutzerinteraktion und visuelles Design. Die besten Sprachen erlauben deshalb die dynamische Inspektion von Code, das effiziente Generieren von Funktionen und die Verwendung von Annotationen, die das Verhalten von Systemen steuern.

Dieser Grad an Reflexion, sowohl zur Compilezeit als auch zur Laufzeit, ist essenziell, um mit den oft schnellen und iterativen Anforderungen der Spielentwicklung Schritt zu halten. Eines der größten Hindernisse, dem sich Entwickler bei der Spracherstellung gegenübersehen, ist der Kompromiss zwischen statischem Typsystem und Flexibilität während der Entwicklung. Ein starres Typsystem kann die Produktivität einschränken, während ein zu dynamisches System unerwartete Laufzeitfehler begünstigt. Spieleentwickler wünschen sich daher eine Art von starken Typen, die vor Fehlern schützt, ohne jede kreative Freiheit einzuschränken. Modern interpretiert, bedeutet das oft, das System so zu gestalten, dass es zwar aussagekräftige Fehlermeldungen liefert, aber auch eine reibungslose Integration ins Entwickler-Tooling besitzt.

Die Verbindung zu Language Server Protocols (LSP) ist hier eines der wichtigsten Kriterien, da sie schnelles Feedback ohne konstantes Kompilieren ermöglicht. Ein weiterer elitärer Traum vieler Entwickler war und ist eine sogenannte Hot-Reload-Funktion, die es ermöglicht, Codeänderungen im laufenden Spiel sofort zu reflektieren, ohne das Programm neu starten zu müssen. Gerade in der Spieleentwicklung, bei der Iteration und Anpassung essenziell sind, kann das herkömmliche „kompilieren-loop testen“-Modell schnell zu Bremsklötzen werden. Die Herausforderung hierbei liegt jedoch darin, dass viele Low-Level-Sprachen, trotz aller Performancevorteile, in Kombination mit optimierten Binaries und dem notwendigen ABI (Application Binary Interface) untereinander nicht flexibel genug sind, um Hot Reloading ohne Neustart sicher und effizient umzusetzen. Während höhere Sprachen meist problemlos Hot Reloading bieten, stehen sie bei der Speicher- und Performanceoptimierung im Nachteil.

Das Problem dabei ist nicht allein technischer Natur – es ist eins mit kultureller Dimension. Viele etablierte Low-Level-Sprachen wie Rust oder C++ bieten keine stabile ABI, was bedeutet, dass sich binäre Schnittstellenlagerungen bei Compiler-Updates verändern können. Das macht das sichere Austauschen von Codeteilen während der Laufzeit quasi unmöglich, ohne potenziellen undefinierten Verhalten zu provozieren. Hier würden Entwickler eine Sprache benötigen, die einerseits performant und „low-level“ genug ist für Spieleprogrammierung und andererseits eine stabile ABI garantiert – eine Kombination die kaum zu finden ist. Im Kontext all dieser Überlegungen haben einzelne Entwickler sogar versucht, eigene Sprachen zu erschaffen, ausgestattet mit modernen Features und einer auf Spiele zugeschnittenen Architektur.

Die Geschichte des sogenannten „Rebel“ oder 🥕lang Projektes erzählt von genau solch einem Versuch. Diese Sprache folgte stringent den Performance-Kriterien, integriert automatische Referenzzählung als Speicherverwaltung, bietet pragmatische Syntax, simple generische Typen und deren extrem wichtige Hot-Reload-Fähigkeiten. Die Sprache sollte „Rusts perfekte Begleitung“ sein: nicht so restriktiv wie Rust, aber dennoch performant und sicher. In „Rebel“ finden sich spannende Ansätze zu globalen Variablen, Makrosystemen mit Token-Substitution und orthogonalen Typdefinitionen, die oftmals in etablierten Projekten fehlen oder kompliziert umgesetzt werden. Das Konzept, Standard-Datentypen als echte Value Types mit festem Layout anzulegen, hatte das Potenzial, die typischen Engpässe in der Spieleentwicklung zu adressieren.

Ebenso löste der pragmatische Umgang mit Operatorüberladungen und das einfache Hot Reloading mit LLVM JIT eine Welle von Begeisterung aus. Doch trotz all der theoretischen und technischen Finessen haben der Entwickler auch mit dunklen Seiten dieser Reise zu kämpfen gehabt. Neben der enormen geistigen Belastung, die der Compilerbau mit sich bringt, spielten auch psychische Faktoren eine nicht geringe Rolle beim Scheitern des Projektes. Burnout, Frustrationen mit der rustigen Compiler- und Open-Source-Community, und die Schwierigkeiten, das Projekt über einen langen Zeitraum zu tragen, führten dazu, dass „Rebel“ letztlich nur ein Versuch blieb und nie über eine „Sprache im Kleinformat“ hinauswuchs. Interessanterweise durchlief der Entwickler im Anschluss eine überraschende Wendung hin zu etablierten Lösungen.

C# und das .NET Ökosystem boten ihm genau jene Features, die er sich wünschte: Hot Reloading von Haus aus, Value Types mit sicherem Speicherlayout, ein ausgewogenes Typsystem mit starker, aber pragmatischer Typisierung und vor allem ein funktionierendes Tooling mit großem Ökosystem. Die moderne Ausgestaltung von C# hat viele der damaligen Einschränkungen anderer Sprachen überwunden und ist zu einer depressiv guten Alternative für Spieleentwickler geworden, die nicht auf „wilde Experimente“ mit völlig neuen Sprachen setzen wollen. Der Fall zeigt exemplarisch, wie anspruchsvoll es ist, eine eigene, konkurrenzfähige Programmiersprache zu schaffen, besonders wenn sie den hohen Anforderungen der Spieleentwicklung gerecht werden muss. Themen wie schnelle Iteration, verlässliche Speicherverwaltung, umfassende Metaprogrammierung und eine stabile ABI sind nicht leicht unter einen Hut zu bringen.

Die Community zeigt sich zudem spurbar ermüdet, wenn invasive Paradigmen oder zu komplexe Typensysteme den Spaß an der Entwicklung behindern. Obwohl „die Sprache, die nie wurde“ nicht als fertiges Produkt den Markt erreichte, bleibt ihr Erbe bemerkenswert. Viele der Gedanken und Prinzipien, die sie vertrat, fließen in die Debatten um zukünftige Programmiersprachen ein. Sie unterstreicht die Bedeutung einer klaren Zielsetzung und die Herausforderung, eine Sprache von Entwicklern für Entwickler zu schaffen, insbesondere in einem so speziellen und fordernden Bereich wie der Spieleentwicklung. In der Summe bietet die Geschichte solcher Projekte wertvolle Einsichten für jeden, der sich mit Spracheentwicklung beschäftigt oder nach besseren Werkzeugen für sein Gamedev-Studio sucht.

Der Wunsch nach einer perfekten Balance zwischen Performance und Benutzerfreundlichkeit ist universell, aber gerade bei Spielen gilt: Produktivität, schnelle Iterationen und Spaß sind oft wichtiger als reine Rohleistung. Die perfekte Gamedev-Sprache muss nicht unbedingt neu erfunden werden. Ohne Zweifel sind in den letzten Jahren etablierte Sprachen wie C#, Rust oder selbst C++ mit ihrer spezialisierten Toolchain und Ökosystemen stark gereift. Dennoch bleibt die Suche nach idealen Konzepten, wie saubere Value Types, unkomplizierte Metaprogrammierung oder Hot Reloading weiter eine spannende Herausforderung und Inspiration für zukünftige Innovationen. Die „Sprache, die nie wurde“ erinnert uns daran, dass Vision und Realität oft weit auseinanderliegen und dass technische Raffinesse ohne nachhaltige Motivation und Community-Unterstützung kaum dauerhaft eine Nische besetzen kann.

Sie steht als Mahnung und Inspiration gleichermaßen für die unzähligen stillen Versuche, das Puzzle der perfekten Programmiersprache zusammenzusetzen, die Entwicklern mehr als nur Syntax bieten will: Sie soll ally, Werkzeug und treuer Begleiter auf der Reise zum perfekten Spiel sein.