1 aoi snapshot replication
forgejo-actions edited this page 2026-07-06 16:45:10 +00:00

AOI Snapshot Replication

Area-of-interest replication sends each player the authoritative player snapshots they should currently know about. The simulation builds AOI visibility on zone ticks, emits fresh snapshots over datagrams, and uses client receipts to repair missed snapshots through reliable stream fallback.

AOI Computation

AOI is zone-local. A player can only see other players in the same zone and inside the configured AOI radius. The current radius is PLAYER_AOI_RADIUS_TILES.

Zone simulation builds a replication view, indexes players into a SpatialHashGrid, and asks the grid for nearby players per observer. The grid buckets players by tile cell, scans the observer cell plus adjacent cells, then applies the final same-zone and distance filter.

The distance check uses Chebyshev tile distance:

  • compute abs(dx) and abs(dy);
  • take the larger value;
  • compare it to the AOI radius.

That keeps diagonal visibility consistent with square tile AOI previews and avoids a second set of circular-distance rules for replication.

Interest Buckets

Visible players are grouped into interest buckets for stable partial updates. Bucket IDs are derived from the player tile cell. The current interest_buckets_v1 capability is required by the default replication path.

Interest buckets let the server describe changes at a coarser level than individual entity scans:

  • full syncs reset the observer's visible bucket set;
  • deltas compare the previous and current bucket sets;
  • moved or changed players are emitted in the relevant bucket update;
  • removed entity IDs are emitted for players that left the observer's AOI or changed buckets.

Bucket IDs are stable protocol data, so changes to the bucket formula must be coordinated through the realtime compatibility registry.

Full Sync And Delta Sync

The server sends a full sync when:

  • the observer has no visibility baseline yet;
  • the session requests or forces a full sync;
  • reliable repair marked the session for full-sync fallback.

Full sync bucket updates carry reset: true for the current visible buckets. Delta syncs compare previous and current visibility, then emit entered, changed, and removed players.

Non-full snapshots are rate-shaped by the runtime replication policy. Snapshot interval and quantization can change with the runtime profile, such as moving from nominal to constrained or recovery profiles under transport pressure.

Snapshot Delivery

SessionAoiUpdate contains the encoded datagram snapshot and optional reliable stream repair events.

The fresh snapshot path is intentionally datagram-first:

  • ServerStateSnapshot is delivered on the server datagram path;
  • the durability policy is freshness-first;
  • missed datagrams are repaired by receipt-driven reliable stream packets rather than by retransmitting every stale datagram.

When a reliable repair or fallback full sync is needed, the same AOI update also queues RealtimeServerStreamPacket::StateSnapshot events on the reliable stream.

Snapshot Receipts

Clients report snapshot progress with ClientSnapshotReceipt:

  • acknowledged_snapshot_id: the newest contiguous snapshot the client accepted;
  • missing_snapshot_ids: newer snapshot IDs the client believes it missed.

Receipt validation enforces the repair-id cap and requires missing IDs to be newer than the acknowledged snapshot and strictly increasing. The stream descriptor coalesces receipts and replays the latest receipt across reconnect because only the most recent snapshot frontier matters.

Receipts with missing IDs are throttled as snapshot repair requests. The server records repair metrics, asks the session repair buffer for retained stream envelopes, and sends any returned repair packets on the reliable stream.

Repair Buffer

Each session keeps a retained repair buffer of recent encoded stream snapshots. Snapshot IDs start at 1. Acknowledged history is pruned, and retained missing IDs can be replayed directly as reliable stream envelopes.

If any requested snapshot is no longer retained, the session marks pending_reliable_full_sync_repair. The next AOI pass emits a full sync on the reliable stream and also sends the fresh datagram snapshot. That fallback restores the client baseline without relying on old datagram history.

Retention adapts upward under observed loss, subject to the protocol cap and repair byte budget. This makes lossy periods more repair-friendly without turning normal replication into a reliable full-state stream.

Metrics And Diagnostics

AOI and repair diagnostics include:

  • total AOI enters and leaves;
  • full-sync and delta snapshot counts;
  • snapshot repair receipts;
  • requested repair IDs;
  • retained repair hits and misses;
  • full-sync repair fallbacks;
  • AOI status telemetry for active sessions.

When debugging replication gaps, compare the client's latest acknowledged snapshot ID with server repair hits and misses. A steady stream of retained misses means the client is requesting snapshots outside the server repair horizon, and fallback full sync should follow on the next AOI update.

Tuning

AOI replication tuning lives in protocol constants, generated registry limits, and runtime replication policy rather than game-server-specific environment variables.

Important knobs include:

  • AOI radius and spatial bucket size;
  • snapshot interval;
  • quantization precision;
  • retained repair snapshot count;
  • repair byte budget;
  • datagram and stream packet size limits;
  • runtime policy transitions for loss, RTT, and congestion.

Keep registry-backed limits and delivery metadata synchronized with server behavior when changing these values. Client receipts, repair buffers, and reliable fallback all assume the same snapshot IDs and capability gates.

Operational Checks

When investigating missing or stale remote players:

  1. Confirm both players are in the same zone and inside the AOI radius.
  2. Check whether interest bucket capability negotiation selected interest_buckets_v1.
  3. Compare full-sync and delta counters for the session.
  4. Inspect snapshot receipt validation and repair throttling.
  5. Check retained repair misses and full-sync fallback counts.
  6. Verify reliable stream fallback packets were queued when repair history was unavailable.