netcode-feel ยท diff
git:20260912.07837c1 to git:20260913.9374bb1
25 added, 16 removed. Audit A to A.
---
name: netcode-feel
- description: Online is a feel column. Ask delay-based vs rollback vs lockstep vs server-auth. Fighting prefers rollback. Kart items may be server-auth. Do not add a second clock to hide latency.
+ description: Use when online play needs an explicit authority, input-delay, prediction, rollback, correction, or confirmation contract without coupling network latency to the render clock.
---
# Netcode feel
- Ask the column:
+ Choose the networking model before tuning feel:
- | Column | Who is right |
+ | Mode | Authority / wait model |
|---|---|
- | delay-based | both wait N frames |
- | rollback | predict, rewind, resimulate |
- | lockstep | both sims, pause on stall |
- | server-auth | server pose wins |
+ | delay-based | inputs wait a published number of logical ticks |
+ | rollback | predict remote input, snapshot, rewind and resimulate |
+ | lockstep | peers advance only when required inputs for a tick are available |
+ | server-auth | server state is authoritative; clients predict/interpolate where allowed |
- ## Rules
+ ## Deterministic state boundary
- 1. Fighting-design prefers rollback. Racing cars can rollback; items may be server-auth.
- 2. Publish input delay. Do not stack delay on top of rollback error.
- 3. Resimulate from the logic step. Camera must survive a rewind without a pop.
- 4. Hitstop stays on ActorClocks. Do not freeze the network clock.
- 5. Prefer a short freeze or a correction over a teleport unless the column is server-auth shooting.
+ Networking owns transport/authority; gameplay systems still own their state. A rollback snapshot must include every gameplay value needed to reproduce future simulation: transforms/velocities, action state and timers, health/resources, spawned logical entities, RNG stream state/counters (`rng-seed`), and any other deterministic state read by later ticks.
- ## Accept
+ Presentation-only camera shake, particles and audio need stable event IDs or predicted/confirmed lifecycle rules so resimulation does not duplicate them.
- - Training mode and a 2-frame delay lobby feel like the same game
- - A rollback correction does not cancel a move the player already saw connect
+ ## Predicted versus confirmed
+
+ A client may present a **predicted** hit or state before authority/remote input is confirmed. Rollback is allowed to invalidate a prediction the player already saw. The correction policy therefore distinguishes predicted from confirmed events instead of pretending visible predictions can never be revoked.
+
+ Publish which effects may play speculatively, which wait for confirmation, and how canceled predictions are reconciled. Confirmed durable outcomes must not be applied twice during resimulation.
+
+ ## Timing
+
+ Input delay, simulation tick, render interpolation and network transport are separate quantities. Do not slow the simulation clock to hide network latency. Hitstop affects only the gameplay clocks named by its owner; transport/network time keeps progressing.
+
+ For rollback, snapshot before the earliest rewound tick, restore that state, inject corrected inputs and resimulate through the current tick. Reversing entity iteration or replaying the same packet/input trace must not change deterministic gameplay results.
+
+ ## Acceptance
+
+ Replay a captured input/packet trace with artificial latency, jitter, reordering and packet loss appropriate to the selected model. For rollback, compare deterministic state hashes after rewind/resimulation, RNG state, predicted/confirmed event transitions and duplicate-effect suppression. Record maximum rollback/correction distance and user-visible correction separately from transport delay. Unrun network/device tests stay `not-run`.