Skip to content

Deterministic Simulation

Determinism in SeinARTS is an architectural boundary. The authoritative simulation is designed to produce the same state from the same initial state and ordered command stream on every peer.

Simulation math uses 32.32 fixed-point types:

  • FFixedPoint for scalar values.
  • FFixedVector for positions and directions.
  • FFixedTransform and FFixedQuaternion for transforms and rotation.
  • FFixedRandom for deterministic pseudo-random values.

Simulation code uses FSeinEntityHandle instead of raw Unreal object or actor pointers. Floating-point math, FVector, Unreal random helpers, and renderer-owned objects stay outside authoritative state.

Data crosses the boundary in one direction:

Input → command buffer → deterministic simulation → render state → presentation

The input and presentation layers submit commands through the command buffer. They do not mutate simulation storage directly. Render telemetry can improve visuals or diagnostics, but it cannot become a simulation input.

Lockstep systems need more than deterministic arithmetic. State ownership, iteration order, serialization, restore behavior, and derived caches must also remain canonical.

Changes to authoritative state therefore need lifecycle coverage across:

  • Initial construction and reset.
  • Snapshot and restore.
  • Replay and reconnection.
  • Schema and cache consistency.
  • Fresh-process and peer comparison.

Project settings that can alter simulation results participate in a configuration fingerprint. Each owning plugin registers its contribution under a stable identifier with canonical property ordering.

A missing extension or mismatched sim-affecting setting must fail compatibility at join instead of becoming a delayed desynchronization.

A successful compile cannot prove deterministic behavior. Simulation changes are qualified with serial-versus-parallel state-hash comparisons and, where relevant, peer, replay, reconnection, and snapshot evidence.