Voxel-Spiele erfreuen sich seit Jahren wachsender Beliebtheit, nicht zuletzt aufgrund ihrer charakteristischen Blocklandschaften und spielerischen Freiheit. Die Entwicklung solcher Games verlangt einerseits nach performantem und sicherem Code, andererseits nach einem flexiblen Design, das schnelle Iterationen und Erweiterungen erlaubt. Ein besonders spannendes Thema hierbei ist, wie sich die Wahl der Programmiersprache auf das Endprodukt auswirkt. Ein faszinierendes Beispiel dafür ist die Portierung des voxelbasierten First-Person-Shooters „Robocave“ von F# nach Rust, die nicht nur technische, sondern auch konzeptionelle Einblicke in beide Welten bietet. Der ursprüngliche „Robocave“ wurde für events wie den 7dfps und PROCJAM entwickelt und nutzt eine maßgeschneiderte F#-Engine auf Basis von Garnet und Veldrid. Die Spielwelt besteht aus blockartig aufgebauten, zerstörbaren Terrainstrukturen, durch die sich Spieler mit Waffen gegen Roboter behaupten.
Diese Prototypenform des Spiels liefert vor allem die Grundlage für technische Experimente und sprachliche Portierungen. Der Hauptgrund für die Portierung nach Rust lag im Wunsch, diese moderne Systemsprache zu erlernen und auszuprobieren, wie gut ein DIY-Engine-Ansatz in Rust funktionieren kann. Rust gilt als performant und sicher im Umgang mit Speicher, verfügt aber über eine komplexere Syntax im Bereich der „Ownership“ und „Borrowing“-Mechanismen. Im Gegensatz dazu punktet F# mit einer funktionalen Programmierweise und einer hohen Entwicklerproduktivität, wobei es manche Low-Level-Themen durch die . NET-Laufzeit abstrahiert. Bei der Realisierung des Rust-Ports war von Anfang an wichtig, dass der Code weitestgehend einfach gehalten werden sollte. Komplexe Sprachfeatures wie unsicherer Code (unsafe), Share-Ownership mit Referenzzählung (Rc, Arc) oder generische Abstraktionen wurden möglichst vermieden, um den Fokus auf klare, nachvollziehbare Strukturen zu legen.
Auch der Einsatz von externen Abhängigkeiten wurde minimiert, um die Kontrolle zu behalten und Eigenentwicklungen beispielsweise bei der Entity-Component-System (ECS)-Implementierung zu ermöglichen. Die ursprüngliche F#-Codebasis hatte bereits viele Konzepte berücksichtigt, die sich gut auf Rust übertragen lassen, beispielsweise eine bewusste Beachtung von Ownership-Prinzipien sowie Verzicht auf zu komplexe Abstraktionen. Diese Gemeinsamkeiten erleichterten die Portierung trotz grundlegender Unterschiede in Syntax und Sprachphilosophie. Im Bereich der Spielearchitektur setzte die F#-Version auf Garnet, eine eigens entwickelte ECS-Bibliothek, die speziell auf 2D-Zellebene mit Chunk-Iteration ausgerichtet ist. Dieser Ansatz unterscheidet sich von vielen gängigen ECS-Frameworks und bringt eigene Herausforderungen mit sich. Im Rust-Neuentwurf wurde bewusst auf komplexe Bibliotheken verzichtet.
Stattdessen entschied sich der Entwickler für eine einfache Lösung basierend auf gepagtem Speicher, Bitvektoren und effizienten Iterationsmechanismen. Obwohl der neue Code auf den ersten Blick mehr Boilerplate beinhaltet, erwies sich diese Struktur als bemerkenswert übersichtlich und performant genug für die Prototypphase. Die Parallele zwischen Garnets actor-ähnlichem Messaging und der selbstentwickelten Rust-Multithreading-Implementierung zeigt, wie der Entwickler bewusst bekannte Konzepte aus F# in Rust adaptierte. Bei diesem Messaging-System wurde nur an einer Stelle das dynamische Trait-Objekt (dyn) verwendet, um eine abstrakte Handler-Schicht einzubauen. Dies verweist darauf, dass Rust in manchen Fällen pragmatische Kompromisse jenseits vollständiger statischer Typisierung erlaubt. Wichtig für die Nutzererfahrung ist natürlich die Grafik.
Während F# mit Veldrid einen Vulkan-artigen, abstrahierenden Grafik-Stack nutzt, ist Winit im Rust-Ökosystem die Standardbibliothek für plattformübergreifendes Window-Management. Die Portierung der Rendering-Pipeline von Veldrid nach WGPU (Rusts zeitgemäße GPU-Abstraktionsschicht) verlief mit einigen Herausforderungen, speziell beim Übersetzen von Shader-Code von GLSL zu WGSL. Diese Aufgabe ist typisch für den Technologie-Wandel in der Game-Engine-Entwicklung und verdeutlicht die Wichtigkeit, sich mit den modernen Grafik-Standards vertraut zu machen. Die Audio-Komponente wechselte vom Rodio-Framework zu Fyrox Audio, einem Teil des Fyrox-Game-Engines, welcher sich als leicht integrierbar und gut handhabbar herausstellte. Im Bereich der Benutzeroberfläche sah der Entwickler die Notwendigkeit einer besseren Lösung als die einfache Overlay-UI des F#-Originals.
Anstelle externer GUI-Bibliotheken wählte er die Entwicklung eines eigenen terminalbasierten Interfaces (TUI), das über ein Messaging-System auf das Zeichnen reagiert. Dieses Design lehnt sich stilistisch an das Elm-Architecture-Modell an, bietet Features wie Drag-and-Drop und Tooltips und ermöglicht ein flexibles Interface für Inventar- und Interaktionssysteme. Das Herzstück eines Voxelspiels sind natürlich die für die Weltgenerierung, Chunk-Verwaltung, Sichtbarkeitsberechnung und Streaming verantwortlichen Codes. Hier zeigte sich, dass viele der im F# vorhandenen Low-Level-Funktionen und Strukturen problemlos nach Rust übertragen werden konnten. Die unmittelbare Nähe zu hardwarenaher Programmierung ohne große Abhängigkeiten ermöglichte einen reibungslosen Übergang.
Interessanterweise verlangten manche Stellen, insbesondere solche mit object pooling in F#, tiefere Umstrukturierungen, da Rust eher auf präzises Speichermanagement und Ownership setzt statt auf wiederverwendete Speicherpools. Auch wenn die Netzwerkfunktionalität im aktuellen Stand des Spiels noch nicht ausgebaut ist, bietet der F#-Entwurf bereits einen logischen Server mit Client-Side Prediction, angelehnt an das Quake 3 Modell. Die zukünftige Umsetzung der echten Netzwerkkommunikation in Rust berücksichtigt Möglichkeiten von zuverlässiger UDP-Nachrichtenübertragung mit KCP als oberer Protokollschicht sowie Überlegungen zu WebRTC und QUIC für Web-Plattformen. Ein oft unterschätztes Thema bei der Spieleentwicklung ist die Feedback-Schleife bei der Programmierung. F# bietet mit seiner interaktiven Entwicklungsumgebung und F# Interactive eine schnelle Experimentiermöglichkeit.
Trotz anfänglicher Sorge bezüglich der Kompilierungszeiten bei Rust zeigte sich auf einem temporären M1-System, dass Rust mit angepassten Optimierungen nach einigen Sekunden fast genauso schnelle Iterationen ermöglicht. Eine Feinjustierung der Compiler-Optionen wirkt sich hier deutlich auf die Geschwindigkeit und die Entwicklerproduktivität aus. Auch der Aufbau der Codebasis wurde nicht reine Kopie übernommen, sondern hinsichtlich Modularität an die Eigenheiten von Rust angepasst. So existieren mehrere Crates, die sowohl generische Engine-Komponenten (z. B. für Numerik, Grafik, Audio) als auch spielespezifische Logik (Server, Client, Frontend) abdecken. Diese Struktur verbessert parallele Kompilation und erlaubt übersichtlichere Trennung von Verantwortlichkeiten. Der Leistungsvergleich beider Versionen auf einer älteren Hardware zeigte interessante Ergebnisse. Die F#-Version erreichte mit deaktiviertem V-Sync hohe 120 FPS bei minimaler CPU-Auslastung und vernachlässigbaren GC-Pausen.
Dafür brauchte sie zusätzlicher Pooling-Code, um Speicherallokationen zu begrenzen. Die Rust-Implementierung lief mit V-Sync bei 60 FPS und höherer CPU-Auslastung, allerdings mit mehr Zeichenaufrufen und einem aggressiveren Scheduling. Diese Unterschiede sind angesichts des noch frühen Entwicklungsstatus der Rust-Version nachvollziehbar. Letztlich sind beide Plattformen in der Lage, vergleichbare Performance-Niveaus zu liefern, wobei weitere Mikrofineinstellungen im Bereich Sichtbarkeitsberechnung oder Beleuchtung noch Potenzial bergen. Die Entwickler-Einschätzung fiel insgesamt sehr positiv aus. Rust konnte mit Sicherheit, Performance und noch wahrnehmbarer Produktivität überzeugen, auch wenn das Management von Levity und Borrowing zeitweise seinen Tribut forderte. F# zeichnet sich durch eine angenehm schlanke Syntax und weniger explizite Typannotation aus, was Schreibfluss begünstigt.
Rust fordert dagegen konsequentes Ownership-Denken, was für Neulinge erst nach einem tiefen Lernaufwand natürlich wird. Dabei stehen beide Sprachen für unterschiedliche Entwicklungsphilosophien mit jeweils eigenen Stärken in Low-Level- und Hochsprachen-Domänen. Das Resultat ist eine funktional weitgehend gleichwertige Umsetzung der Spiel-Engine, bei der der Rust-Quellcode sogar um rund ein Viertel kürzer ausfiel. Das liegt einerseits an der Vereinfachung der ECS-Logik und dem Verzicht auf GLTF-Import sowie Objektpooling, andererseits auch an einer stärker statisch typisierten und weniger abstrakten Architektur. Zudem ist die Distribution des Spiels in Rust kompakter und leichter zu handhaben, mit einem einzelnen ausführbaren Programm inklusive eingebetteter Assets und WebAssembly-Unterstützung. Zusammenfassend betrachtet lässt sich feststellen, dass sowohl F# als auch Rust geeignete Plattformen für die Entwicklung von voxelbasierten Spielen bilden.
Die Wahl sollte deshalb vor allem von den persönlichen Präferenzen, dem geplanten Umfang und Zielplattformen sowie dem gewünschten Entwicklungsmodell (DIY-Engine vs Third-Party) abhängig gemacht werden. Für Entwickler, die Wert auf maximale Sicherheit und Kontrolle legen, bietet Rust eine zukunftsorientierte und leistungsstarke Alternative. Wer dagegen schnelle Prototypen und höhere Abstraktion bevorzugt, wird mit F# glücklich. Für den Spielmacher bleibt das wichtigste Fazit: Technologie ist nur ein Werkzeug – gute Spielideen, abwechslungsreicher Content und durchdachtes Gameplay sind der Schlüssel zum Erfolg. Die vorgestellte Portierung von „Robocave“ zeigt, dass man mit beiden Welten erfolgreich experimentieren kann und dadurch nicht nur technische, sondern auch kreative Horizonte erweitert. Die kombinierte Erfahrung und der Erkenntnisgewinn bilden letztlich eine wertvolle Ressource für zukünftige Indie-Projekte.
