Box3D — deterministische 3D-Physik vom Box2D-Autor, schon als Godot-Extension

Wer je ein 2D-Spiel mit Physik gebaut hat, hat mit hoher Wahrscheinlichkeit Box2D benutzt — Erin Cattos Engine treibt seit zwei Jahrzehnten alles von Angry Birds bis zu unzähligen Godot- und Unity-Titeln an. Am 30. Juni 2026 hat Catto den Schritt in die dritte Dimension veröffentlicht: Box3D, eine 3D-Physik-Engine für Spiele, MIT-lizenziert, in reinem C17 mit sauberer C-API. Entstanden ist sie aus der Praxis — bei der Arbeit an einem großen Open-World-Projekt stieß sein Team an die Grenzen der Unreal-eigenen Physik. Der Code begann als Ableger von Valves „Rubikon-Lite“ (der Engine hinter Half-Life: Alyx) und wurde nach und nach durch Box2D-Algorithmen und neue Verfahren ersetzt. Facepunchs s&box setzt sie bereits ein, ebenso ein Multiplayer-Experiment von Glenn Fiedler mit tausend Spielern im selben Raum.

Technisch bringt Box3D mit, was eine moderne Spiele-Physik braucht: Triangle-Mesh- und Heightfield-Kollision, vorgebackene Compound-Shapes, einen Sub-Stepping-Solver, kontinuierliche Kollisionserkennung gegen Durchtunnel-Fehler, SIMD-Kontakt-Solver und Multithreading, dazu Double-Precision-Positionen für sehr große Welten. Bemerkenswert ist weniger die Feature-Liste als die Haltung dahinter: kein Framework, keine Abhängigkeiten, keine Cloud — eine Bibliothek, die man versteht, baut und besitzt.

Zwei Eigenschaften stechen für uns heraus. Erstens der plattformübergreifende Determinismus: dieselben Eingaben erzeugen auf jedem Rechner exakt dieselbe Simulation, egal ob Mac, Android oder Linux. Das klingt unscheinbar, ist aber die technische Voraussetzung für Lockstep-Multiplayer ohne Server — Geräte tauschen nur ihre Eingaben aus, und jede Seite errechnet die identische Welt selbst. Kein Spielserver, keine Zustands-Synchronisation, minimale Bandbreite. Das ist exakt das Muster, nach dem unsere kullerkiste und unser ganzes „Sync ohne fremden Server“ gebaut sind — nur dass es bislang an der Physik scheiterte, denn Godots eingebaute Engines garantieren diese Gleichheit nicht. Zweitens das eingebaute Record/Replay: Physik-Läufe lassen sich aufzeichnen und exakt wiedergeben, was Fehler reproduzierbar macht.

Und Godot? Die Antwort ist ein überraschend klares ja, schon — aber experimentell. Mit godot-box3d existiert eine GDExtension, die Box3D als Drop-in-Ersatz für Godots PhysicsServer3D einhängt — nach demselben Muster, mit dem godot-jolt einst bewies, dass sich Godots Physik austauschen lässt (und das so erfolgreich, dass Jolt seit Godot 4.4 eingebaut ist). Starre Körper, die gängigen Shapes, Raycasts, Areas und CharacterBody3D funktionieren; Zylinder, einige Joint-Typen und SoftBody fehlen noch. Man kopiert die Extension ins Projekt, wählt Box3D in den Projekteinstellungen — fertig.

Wir haben den Spike am 14. Juli 2026 selbst gemacht — eine Mini-Kegelbahn („kegelkiste“-Labor) auf godot-box3d in Godot 4.7. Die Ergebnisse: Nativ überzeugt Box3D — die Extension läuft als Drop-in, und der Determinismus-Hash über 40 Physik-Ticks ist nicht nur über Läufe, sondern sogar über SIMD- und Skalar-Builds hinweg bitidentisch. Der Web-Export funktioniert und läuft in voller Echtzeit — 16 ms pro Physik-Tick im Browser, Extension als selbst kompiliertes wasm-Side-Module, und anders als die Doku behauptet, liefert Godot 4.7 die nötigen dlink-Templates offiziell mit. (Eine erste Messung sah nach „300-fach zu langsam“ aus — das entpuppte sich als Chrome-Drosselung bei verdecktem Fenster, ein Messartefakt, das wir hier bewusst dokumentieren statt verschweigen.)

Und das Lockstep-Versprechen? Zuerst sah es gebrochen aus — die Plattform- Hashes wichen ab, und im Spiel fiel stets nur ein einziger Kegel. Die Spur führte zu einem Bug der Godot-Extension: Setzt man einem Körper eine eigene Masse, wird die Trägheit nicht mitskaliert, und beim Anhängen der Kollisionsformen gehen die Massedaten ganz verloren. Umgeht man diesen Pfad (Massen aus den Formen ableiten, Anstoß als Geschwindigkeit), passiert das Bemerkenswerte: macOS-arm64 und WebAssembly liefern bitidentische Zustands-Hashes — selbst über 240 Physik-Ticks Voll-Kollisions-Chaos, bei dem alle sechs Kegel fallen. Box3Ds Determinismus kommt tatsächlich durch die ganze Kette aus Engine, Bindings und Browser — ein kompletter Geschwindigkeits-Sweep über neun Messpunkte, alle bitgleich. Ein zunächst vermuteter Randfall entpuppte sich als Fehler unseres eigenen Test-Aufbaus (ein Reset mitten im Physik-Tick lässt sterbende Körper einen Tick weiterleben) — und wurde damit selbst zur Lockstep-Lektion: Weltaufbau gehört deterministisch getaktet, nie eingabe-getrieben. Godots eingebaute Physik weicht cross-platform dagegen durchweg ab.

Ehrlich eingeordnet: Box3D ist Alpha, die Godot-Extension jünger noch, und zwei ihrer Baustellen haben wir selbst dokumentiert. Unsere Kisten sind überwiegend 2D; der Hebel betrifft gezielt die Physik-Kisten. Aber das Kern-Ergebnis steht: Deterministische 3D-Physik über Plattformgrenzen hinweg ist mit Box3D in Godot real erreichbar — der Lockstep-Weg für die kullerkiste ist offen, und der lauffähige Labor-Aufbau liegt bereit.