Two-client dedicated progress, with plenty still to fix

Tonight’s work was about pushing beyond the earlier single-remote-client assumptions and making the dedicated host path behave more like a real multiplayer server.

The most important step was infrastructure hardening. We rotated to a fresh EC2 key pair, launched a clean host, and reconnected the local automation scripts to the new instance. We also fixed an expensive trap in the idle path: the dedicated process could exit cleanly, but systemd was configured to restart it immediately. That meant “idle timeout” never translated into cost savings. The service now exits cleanly on idle and can stop the instance, which gives us a much more sensible baseline for ongoing testing.

On the gameplay side, we continued reducing net jitter and input delay with fixed snapshot cadence, client prediction/reconciliation improvements, and smoother remote interpolation. Movement is now notably better than it was at the start of the networking push, but this session made one thing clear: weapon-heavy moments still stress the current model hard. Rope and projectile interactions expose any mismatch between local prediction and authoritative correction almost immediately.

The biggest structural change tonight was beginning true dedicated two-client slot handling rather than relying on a single remote slot model. Host-side input/snapshot ownership was split by slot, and snapshot self/other mapping was made explicit. That is necessary groundwork for two players to see and interact with each other consistently, but we are still in transition. Some edge cases are improved; others still show that the simulation model needs deeper refactoring to support robust multi-client gameplay under real latency.

Decisions and direction

We are now treating this as staged multiplayer architecture work rather than incremental bug fixing. The order matters: first stabilise hosting and deployment, then lock down deterministic slot ownership and snapshot identity, then expand action parity and reconciliation quality. Doing this in order keeps test results interpretable instead of chasing symptoms from multiple layers at once.

We also confirmed that rapid “patch and retry” loops across two machines are essential. The dedicated server can appear correct in local logs while still presenting stale or contradictory behaviour on clients if build/version drift creeps in. Tightening pull/rebuild/restart discipline is now part of the process, not an afterthought.

Remaining problems

Two key issues remain open:

Multi-client gameplay parity is incomplete in dedicated mode. Baseline locomotion and identity mapping are moving in the right direction, but full weapon/rope behaviour still needs systematic slot-safe handling.
Combat-time smoothness remains behind target. Movement alone is much better, but action-heavy scenes still feel choppy due to current snapshot application patterns and partial prediction coverage.

Next session will focus on finishing the two-player dedicated gameplay path end-to-end: full per-slot action handling, cleaner authoritative state ownership, and improved reconciliation around rope and projectile events. The objective is simple: both clients connect, see each other reliably, and can use the full kit without the simulation falling apart.