Making multiplayer feel less fragile

Today was a full networking day: less about adding shiny systems, more about making the current multiplayer path something we can actually use with real people outside a perfect LAN setup.

The first big step was infrastructure. We moved from ad hoc local-host sessions to a persistent dedicated-host workflow backed by AWS scripts and a systemd service. That gives us a stable place to point clients, repeatable startup and restart behaviour, and a clearer line between game code issues and deployment issues. It also made some hard constraints visible quickly, including architecture/runtime mismatches and the practical difference between “it runs once” and “it stays up all day.”

From there, we focused on game-side networking quality. We added clearer host/client diagnostics in the in-game overlay so we can see connection state, connected players, and round-trip timing while testing. We also tackled several immediate UX regressions as they appeared: camera tracking on client, weapon/loadout visibility, and jump edge reliability under latency. None of that is glamorous, but each change removes a blind spot when trying to judge whether movement and combat feel better or worse.

The bigger technical shift was starting a first-pass prediction/reconciliation layer on the client. Local movement now responds earlier, with host correction blended where possible and hard snaps reserved for larger divergence. We also pushed rope and aiming responsiveness by doing more immediate local prediction for those interactions instead of waiting on a full round-trip. The result is still imperfect, but materially better than the earlier “everything waits on snapshots” behaviour.

Design and roadmap decisions

A useful decision today was to keep progress incremental but directional. Rather than pausing for a full netcode rewrite, we are layering improvements in the order that most affects feel and observability: diagnostics first, then immediate input responsiveness, then correction behaviour, then heavier work like snapshot cadence and interpolation buffers. This keeps testing grounded in player experience while preserving momentum.

We also reinforced a practical workflow split: release builds for quick connection tests, and devlog/ImGui-enabled builds when we need instrumentation and recording. That sounds obvious, but tightening this loop matters when every network tweak needs quick verification and clips for public-facing updates.

Open problems and tradeoffs

Movement feels better than it did at the start of the day, but it is not yet where it needs to be. There is still visible drift and choppiness under weapon-heavy moments, and rope behaviour remains sensitive to timing. We are trading immediate responsiveness against authoritative correction, and that balance is still being tuned.

The current snapshot path also does too much hard replacement during combat, which amplifies jitter. That gives us a clear next target: improve snapshot cadence and interpolation strategy, especially for projectile-heavy scenes.

Next session will focus on the deeper feel pass: fixed-rate snapshot timing, buffered interpolation for non-local entities, and tighter reconciliation around action edges (jump, rope, weapon fire). The goal is simple: keep the server authoritative, but make the client feel dependable enough that playtesting stops being a networking stress test and starts being about the game itself.

Screenshots