Evaluating Backdash for a project

[JoNax97]

Hi! First, let me say that this project looks very promising and I'm very excited to try it out.

Project Context

I'm building an open-world multiplayer sandbox with long-lived, persistent worlds similar to Minecraft or Rust that players can join and leave at will. The game focuses heavily on physics simulation and procedural generation, with expected scale of:

• 10-100 concurrent players per world
• Thousands to tens of thousands of entities
• Game state in the hundreds of MB
• 30hz tick rate

I'm in the early stages, currently validating architecture and technology decisions. I have a proof of concept running with a full ECS-authoritative model driving the presentation layer, using Arch ECS (https://github.com/genaray/Arch) with strictly unmanaged, contiguous data in a SOA layout for trivial serialization.

Why Rollback for This Use Case

I chose rollback netcode despite it deviating from the typical deterministic, peer-to-peer, match-based model because it imposes a strict synchronization discipline rather than the "free-for-all" approach of other networking models. This structure is valuable even when perfect determinism isn't achievable.

Proposed Hybrid Architecture

I want to build a hybrid model where the fundamentals are based on rollback architecture, but with an authoritative server that can intervene when needed. The canonical rollback model assumes perfectly deterministic simulation where sharing inputs alone keeps all clients in sync. However, my game cannot guarantee this due to:

1. Numeric precision issues in physics calculations
2. Non-deterministic physics edge cases
3. Partial simulation - clients only simulate entities within their area of interest
4. Late joining - players joining mid-game won't have full history

Therefore, an authority needs to be able to detect discrepancies and say "Player X, this part of your state is wrong/missing. Here's the correct one."

State Synchronization Approach

My approach uses spatial partitioning where entities are sorted into chunks based on their location. Chunks outside a player's relevant area are not simulated by that client at all (interest management).

Players would send, along with their inputs, hashes of the game state chunks they are actively simulating. The system needs to handle N arbitrary parts of the state, serializing and reconstructing them without introducing discrepancies.

When the server detects a discrepancy at tick N, it identifies the last tick without discrepancy (N-M) and builds a delta that the client can apply at N-M to correctly reconstruct up to tick N. For minor discrepancies (numeric precision, physics variance), this delta would be small. For major discrepancies (entire chunks missing/outdated due to late joining or interest management changes), the server may need to send full snapshots over several ticks.

Client Prediction and Reconciliation

Clients would use standard rollback mechanics: extrapolate inputs and then reconcile when receiving authoritative inputs. However, I may need support for custom logic to extrapolate the inputs. Since the game isn't precision-heavy or competitive, I can tolerate a few ticks of input delay for buffering.

When the server detects clients are wrong after reconciliation, clients correct their state. For large state divergence, the authority sends full snapshots incrementally over multiple ticks.

Key Use Cases to Support

1. Desync Recovery: Players out of sync can re-sync just the affected chunks, not the entire world state
2. Interest Management: Clients only simulate/receive state for chunks in their relevant area; chunks can be added/removed from simulation dynamically
3. Late Joining: Mid-game joiners receive authoritative state snapshots to catch up, synchronized with ongoing simulation

Technical Requirements

To support the above architecture, I need to understand the feasibility of:

1. Designating a peer as authoritative server - I want to support player-hosted worlds, though whether this is a true peer-to-peer host or a local dedicated server running alongside a normal client is TBD
2. Splitting game state into arbitrary parts - The system needs to handle independent ECS chunks that can be hashed, serialized, and synchronized separately
3. Sending authoritative state corrections - Beyond inputs, the server needs to send state deltas or snapshots to clients when discrepancies are detected

Would these modifications be feasible within your library's architecture, or would they require significant changes to the core design? I'm happy to discuss implementation approaches or contribute to the project if this aligns with your vision. I'm an experienced C# developer and comfortable implementing features myself, so I'm happy to contribute if needed.