DEV Community

BearPack Salzy
BearPack Salzy

Posted on

Why I built determinism into a physics engine from day one (and what I learned)

Most physics engines treat determinism as an optional feature. I wanted to build one where it was the constraint everything else was designed around.
The core problem
Floating point math isn't deterministic by default across compilers, platforms, or even optimization levels. For lockstep multiplayer or replay verification, that's a dealbreaker.
What bitwise determinism actually requires
Getting identical results across runs on the same binary means controlling three things:

FP evaluation mode — MSVC needs /fp:precise, GCC/Clang need -ffp-contract=off
Memory allocation order — any non-deterministic allocator breaks replay
Execution order — multithreading requires a deterministic parallel mode

UPE enforces all three. State is CRC64-hashed every frame. Proof logs are generated as part of CI. If the hash drifts, the build fails.
What this unlocks
Once you have a deterministic sim, rollback networking becomes dramatically simpler — you're not reconciling floating point divergence, you're just rewinding and replaying authoritative inputs. Time-travel debugging also becomes trivial: snapshot state at frame N, replay from there, get identical results every time.
What's in the engine
Beyond the determinism core, UPE covers rigid body (6DOF), XPBD cloth and rope, SPH fluids, fracture mechanics, N-body orbitals, and more. Zero dependencies, pure C++20, clean C API surface. CI-verified across Windows, Linux, and macOS.
The source is for sale
I'm selling the full source as a per-seat purchase — one payment, unlimited commercial use, no subscriptions or royalties. Aimed at engineers who want a physics foundation they fully own.
Full details and purchase: https://bearpackonline.gumroad.com/l/szlvvo
Happy to go deeper on any of the determinism implementation in the comments.

Top comments (0)