We ran into a difficult-to-reproduce multiplayer bug where party members appeared frozen in walls to other players, though they could move freely on their own screens. Despite receiving movement data from the network, the affected player's position wouldn't update for others. The bug never occurred during initial testing but appeared unpredictably during regular play sessions.
After extensive investigation, we noticed a pattern: the bug only surfaced on subsequent tower playthroughs after completing one, and the victims consistently got stuck in the bottom-left room. This was the key clue that led us to the root cause.
Root Cause
The game uses sequence numbers to prevent displaying outdated movement. If a doggo moves from tile 0 to 4 (sequence 1), then 4 to 8 (sequence 2), then 8 to 12 (sequence 3), and that middle network call was delayed, we can show that the doggo moves from 0 to 4 (sequence 1), then teleports to 8 before the delayed packet arrives. The sequence number lets us discard the stale movement data for tiles 4 to 8, since we already know the doggo is at tile 12.
The problem was that when starting a new tower, sequence numbers reset to 1. However, delayed packets from the previous tower still carried high sequence numbers. When the new tower began and fresh movement data came in with low sequence numbers like 1 or 2, the system compared them against the lingering high sequence numbers from the old tower and concluded the new data was outdated. This caused all new movement data to be ignored, leaving the player frozen in their spawn position in the bottom-left room.
Solution
The fix was straightforward: preserve sequence numbers instead of resetting them when creating new towers. By continuing the sequence count across tower transitions, new movement data always has a higher sequence number than any lingering packets from the previous tower, ensuring it gets processed correctly.