voxelforge

Eine Voxel-Engine mit spielbarer Browser-Demo. Der Renderer zielt auf WebGL2/WASM, während der Simulationskern nativ gebaut und mit Tests abgedeckt ist - Zehntausende Assertions.

TL;DR

Eine Voxel-Engine mit einem spielbaren Browser-Demo. Der Trick ist, dass der Simulationskern nichts vom Rendering weiß - was es erlaubt, die Logik ohne GPU zu testen, über zehntausende Assertionen hinweg.

Überblick

voxelforge ist eine Voxel-Engine mit einem spielbaren Demo, das im Browser läuft. Der Renderer zielt auf WebGL2 und WASM, aber die interessanteste Entscheidung betrifft nicht die Grafik, sondern die Architektur: Der Simulationskern ist vollständig vom Zeichnen getrennt. Er hält die Voxel, die Regeln und die Nachbarschaften und weiß nichts davon, dass irgendetwas auf dem Bildschirm erscheint.

Diese eine Entscheidung veränderte den Charakter des Projekts. Statt einer Engine, die nur läuft, wenn Sie sie mit einer Grafikkarte starten, entstand eine Logikbibliothek, die überall läuft und sich wie gewöhnlicher Code testen lässt. Der Rest dieser Fallstudie erzählt davon, warum sich das gelohnt hat.

Eine Voxel-Engine muss zwei schwere Dinge gleichzeitig tun: die Welt schnell zeichnen und sie korrekt simulieren. Beides lässt sich leicht so kaputtmachen, dass es auf den ersten Blick gut aussieht und doch falsch ist - ein Block verschwindet ein Frame zu spät, eine Nachbarschaft wird einen Voxel daneben gezählt. Diese Fehler schreien nicht, sie zerstören die Welt leise.

Wenn Rendering und Logik in einem Codekörper verflochten sind, lassen sie sich weder beim Testen noch beim Debuggen trennen. Man kann nicht sagen, ob ein Block falsch verschwand, weil die Simulation ihn falsch berechnete, oder weil der Renderer ihn falsch zeichnete. Das Entwirren dieser beiden Welten war das Wichtigste im ganzen Projekt.

Ein Kern, der nichts von der GPU weiß

Die Lösung war zugleich die einfachste: Der Simulationskern ist reine Logik, und der Renderer nimmt seinen Zustand und verwandelt ihn in Dreiecke. Kein Teil des Kerns berührt ein Canvas oder eine GPU. Die Schnittstelle zwischen ihnen ist schmal und explizit, also kann der Renderer beliebig sein, und der Kern weiß nichts davon.

core.ts · typescript

interface SimulationCore {
  tick(dt: number): void;
  voxelAt(x: number, y: number, z: number): Voxel;
}

interface Renderer {
  draw(core: SimulationCore): void;
}

Wer wofür zuständig ist

Schicht	Rolle	GPU-Abhängigkeit
Simulationskern	Voxel, Regeln, Nachbarschaften	keine
Renderer	Zustand in Dreiecke verwandeln	WebGL2 / WASM

Hinweis

Da der Kern nicht von einer GPU abhängt, wird er nativ gebaut und wie eine normale Bibliothek getestet. Der Renderer zielt auf WebGL2 und WASM, aber die Logik besteht ihre Tests sogar auf einer CI-Maschine ohne Grafikkarte.

Tests statt Hoffnung

Diese Trennung ist kein akademischer Luxus. Sie ist der Grund, warum die Simulation eine Testabdeckung in der Größenordnung von zehntausenden Assertionen hat - und das ist der einzige Weg, um zu sagen, dass eine Voxel-Engine korrekt ist, und nicht nur, dass sie "gut aussieht". Fehler von einem Voxel daneben tauchen in einem Test auf, nicht nach einer Stunde Spielen.

tausende

Voxel pro Chunk

zehntausende

Assertionen in den Kern-Tests

Abhängigkeiten des Kerns von der GPU

Das Ergebnis: ein Demo, das ohne Angst wächst

Heraus kommt ein spielbares Browser-Demo, das wachsen kann, ohne Angst, dabei still die Weltlogik zu zerbrechen. Weil der Kern für sich getestet ist, kann eine Änderung im Renderer die Simulation nicht heimlich kaputtmachen, und eine Änderung in der Simulation taucht sofort in den Assertionen auf. Die Engine ist nicht nur effektvoll - sie ist überprüfbar.

Weitere Projekte

Weitere Projekte aus derselben Kategorie - sehen Sie, wie wir ähnliche Herausforderungen angehen.

Haben Sie ein ähnliches Projekt?

Melden Sie sich - ein Angebot ist kostenlos und kommt innerhalb einer Stunde.