Terraria und Celeste im Browser: Die Faszination von WebAssembly-Portierungen

Krypto-Startups und Risikokapital

Die Welt der Videospiele bewegt sich immer stärker in Richtung plattformübergreifender Erlebnisse. Während Desktop- und Konsolenversionen von Spielen mittlerweile weit verbreitet sind, gewinnt das Browser-Gaming zunehmend an Bedeutung. Einen besonders spannenden Weg dabei zeigt die Portierung von komplexen Spielen wie Terraria und Celeste in WebAssembly, um sie ohne Installation direkt im Browser lauffähig zu machen. Diese Technologie ermöglicht es, Programme mit nahezu nativer Geschwindigkeit im Web auszuführen – und das sogar für Titel, die ursprünglich auf anderen Plattformen und Sprachen entwickelt wurden. Terraria und Celeste gehören zu den beliebtesten Indie-Spielen der letzten Jahre und sind bekannt für ihre reiche Spielmechanik und ästhetische Tiefe.

Beide Spiele basieren auf der Programmiersprache C# und verwenden die FNA Engine, die eine Open-Source-Implementierung von Microsofts XNA Framework darstellt. Diese Gemeinsamkeit half zumindest theoretisch dabei, die Portierung der Titel vom Desktop in den Browser mittels WebAssembly anzugehen. Dennoch erwies sich der Weg als wesentlich komplexer und anspruchsvoller als zunächst angenommen. Die Herausforderung beginnt bereits bei der Dekompilierung des Spiels. Obwohl der MSIL (Microsoft Intermediate Language) Bytecode, den C# verwendet, nah an der Originalquelle liegt, sind einige externe Abhängigkeiten eingebettet, was die Analyse erschwert.

Ein Beispiel ist die in Terraria eingebettete DLL ReLogic.dll, die nicht als separate Datei vorlag, sondern als Ressourcenbestandteil innerhalb der EXE extrahiert werden musste. Erst mit der vollständigen Entschlüsselung dieser eingebundenen Bibliotheken ließ sich der Code erfolgreich dekompilieren und in eine kompilierbare WebAssembly-Datei überführen. Die WebAssembly-Zielplattform stellt dabei eigene Anforderungen. Obwohl die meiste C#-Logik problemlos übersetzt wurde, war das Zusammenspiel mit den nativen Komponenten der FNA Engine, die in C++ geschrieben sind, eine weitere Hürde.

Besonders die Grafikkomponenten, die auf SDL3 basieren und OpenGL nutzen, mussten überarbeitet werden, da OffscreenCanvas und DOM-Thread-Zugriffe in WebAssembly eine spezielle Behandlung benötigen. Um dieses Problem zu lösen, wurde eine Proxy-Schicht eingebaut, welche die OpenGL-Aufrufe zwischen Worker-Thread und Haupt-Thread synchronisiert. Dieser Schritt war essenziell, um die im Browser strengen Einschränkungen für Canvas-Zugriffe einzuhalten. Neben technischen Details gab es auch Herausforderungen im Bereich der Dateisystemintegration. Da die Spieldaten von Terraria nicht lokal vorhanden sind, kam die Origin Private File System API zum Einsatz, welche es erlaubt, lokale Verzeichnisse im Browser zu mounten.

So können Benutzer ihre eigenen Spieldateien hochladen und einbinden. Dies erforderte wiederum Workarounds für Browser-Inkompatibilitäten, etwa die fehlende Unterstützung von showDirectoryPicker in Firefox, die teilweise mit Drag-and-Drop-Funktionen umgangen werden konnte. Nachdem das Grundgerüst stand, zeigte sich die nächste Komplikation durch die fehlende Unterstützung von Threads in älteren .NET-Versionen für WebAssembly. Erst die Veröffentlichung von .

NET 9 brachte eine Lösung, indem es Mehrthreading in WebAssembly ermöglichte. Dennoch bewahrte die Thread-Problematik Spielstarts vor einer reibungslosen Ausführung und erforderte das Umschalten auf moderne WebAssembly-Optionen. Während Terraria ein Vorreiter in Sachen Browserportierung war, stellte die Umsetzung von Celeste weitere spezialisierte Anforderungen. Das Spiel nutzt anstelle von FAudio die proprietäre FMOD-Audioengine, die eigene IMC- und Audio-Schnittstellen besitzt und speziell für die Webplattform angepasst werden musste. Die Kompatibilität mit SDL3 und OffscreenCanvas ermöglichte hierbei die native Canvas-Bindung, ohne den Umweg über Proxy-Calls.

Gleichzeitig mussten weitere externe Abhängigkeiten von FMOD per Objektdateien eingebunden werden, da eine Neukompilierung der proprietären Bibliotheken nicht ohne Weiteres möglich war. Ein bedeutender Bestandteil im Ökosystem von Celeste ist die Modding-Community sowie der Everest-Modloader. Um auch Mods im Browser lauffähig zu machen, war die Übersetzung der komplexen Laufzeitmanipulationen durch MonoMod eine der größten Herausforderungen. RuntimeDetour, das Herzstück für Function Hooks und Modifikationen, operiert traditionell durch Manipulation von nativen Maschinencode-Bereichen. Im WebAssembly-Umfeld mit AOT-Kompilierung und read-only Modulen ist dies jedoch nicht möglich.

Der innovative Lösungsansatz bestand darin, die IL-Bytecodes der Methoden direkt dynamisch zu modifizieren und die Mono-Runtime intern zu patchen, um einen kompatiblen Hook-Mechanismus bereitzustellen. Dieser Prozess erforderte tiefe Eingriffe in die Mono Mono-Interpreter-Transformationen und Laufzeitstrukturen. Durch die Möglichkeit, eigene C-Codes in das Gesamt-Wasm-Modul einzufügen und interne Mono-Funktionen aufzurufen, konnte die genaue Position der bytecode-repräsentierten Funktionen ermittelt und im Speicher modifiziert werden. Damit wurde das RuntimeDetour-System so angepasst, dass es mit den Beschränkungen von WebAssembly und der jiterpreter-basierten Ausführung funktionierte. Darüber hinaus gab es zahlreiche weitere Kompatibilitätsprobleme zwischen Mono und der CoreCLR-Laufzeitumgebung, die auf Desktop-Systemen üblich sind.

Viele Celeste-Mods setzten auf Reflection, mehrere Patches in Mono waren notwendig, um Sicherheitsbeschränkungen und Laufzeitfehler zu beheben. Diese Modifikationen reichen von der Anpassung der Methodensignatur-Verifikation bis hin zu einer Neukonzeption des Modul-Loaded Prozesses, um statische Initialisierungen in korrekter Reihenfolge durchzuführen. Ein weiterer interessanter Aspekt ist die Möglichkeit, die Celeste-App zur Laufzeit zu patchen, anstatt sie vorab zu kompilieren. Das WebAssembly-Modul funktioniert als eine dynamische Loader-Anwendung, die das Originalspiel und die Everest-Modifikationen in den emulierten Dateisystemspeicher lädt. Diese Flexibilität erlaubt es, die aktuellsten Spiel- und Mod-Versionen einzubinden, ohne die gesamte Codebasis neu zu veröffentlichen.

Zusätzlich zur technischen Umsetzung gab es viele praktische Hürden, etwa die Einschränkungen der Browser-APIs, CORS-Beschränkungen beim Laden externer Modfiles oder die Performance-Drosselung auf schwächeren Geräten. Trotz allem konnte durch die Aktivierung von Ahead-Of-Time (AOT) Kompilierung eine akzeptable Framerate erreicht werden, die auch auf älteren oder leistungsschwächeren Systemen ein flüssiges Spielerlebnis ermöglicht. Die Motivation hinter diesem ambitionierten Projekt war nicht nur technischer Natur. Insbesondere für Nutzer von Chromebooks, die auf Linux-Emulationen angewiesen sind, die oft träge reagieren, stellt eine native WebAssembly-Version von Terraria oder Celeste eine attraktive Alternative dar. Auch wenn kaum jemand plant, das gesamte Spielerlebnis direkt im Browser zu absolvieren, bietet dieses Experiment wertvolle Erkenntnisse über die Grenzen und Möglichkeiten moderner Webtechnologien.

Zusammenfassend zeigt die Portierung von Terraria und Celeste in WebAssembly, dass der Browser schon heute weit mehr leisten kann, als häufig angenommen wird. Die Kombination aus C#-Decompilierung, nativer C++-Integration, niedrigschwelliger Laufzeitmodifikation und Browser-spezifischen APIs ermöglicht ein Spielerlebnis, das traditionell nur nativen Plattformen vorbehalten war. Diese Projekte eröffnen eine neue Perspektive für crossmediales Gaming, bei dem komplexe Spiele unmittelbar und plattformunabhängig verfügbar sind. Darüber hinaus spiegelt das Projekt die Lust am Experimentieren und die Faszination für „Super Nischen“ Technologien wider. Es zeigt, wie Innovation Enabler nicht immer unmittelbar wirtschaftlich sein müssen, sondern auch durch reinen Forscherdrang und Spaß an technischer Kreativität entstehen können.

Und nicht zuletzt beweist es, dass WebAssembly als Technologie eine Transportbrücke bilden kann, um bisher schwer zugängliche Anwendungen in neue Umgebungen zu bringen – direkt in den Browser, wo heute fast jeder Nutzer sitzt. Wenn Sie selbst Interesse haben, diese Browserportierungen zu erleben, stehen gut dokumentierte Git-Repositories zur Verfügung, die den Einstieg erleichtern. Von der Einrichtung der Entwicklungsumgebung bis hin zum direkten Spielen im Browser – die Reise durch WebAssembly und C# ist offen für mutige Entwickler und neugierige Gamer gleichermaßen. Es bleibt spannend, welche weiteren Spiele und Anwendungen künftig auf diesem Weg den Sprung in den Browser schaffen werden.