Building games around
multiplayer synchronization.

Synchronization architecture

The synchronization model is intentionally lightweight on the server. Clients perform most of the simulation work while the networking layer provides the information required to keep the different simulations aligned.

• Movement and actions are confirmed by the server. The client can react immediately instead of waiting for a round trip before presenting the result.
• Client prediction is reconciled with authoritative information. When a confirmation differs from the local prediction, the affected state can be corrected.
• Rollback is part of the synchronization strategy. Instead of requiring the server to reproduce every expensive operation, the client can rewind and replay the relevant sequence of actions.
• The server remains deliberately lightweight. The architecture avoids making the server responsible for reproducing the entire simulation when the gameplay rules do not require it.

This led to a close relationship between game mechanics, deterministic behavior, movement design and network protocol: mechanics that are expensive or difficult to synchronize are deliberately designed around representations that can be reproduced consistently by the clients.

Why the simulation was designed this way

The central problem was not simply sending player positions over the network. The objective was to make the simulation predictable enough that clients could reproduce the same result from the same sequence of events.

• Movement was represented through discrete targets instead of arbitrary continuous trajectories.
• The simulation was deterministic and strongly dependent on the ordering of network messages.
• Because clients could reproduce the relevant simulation, significantly less computation had to be performed centrally.
• The approach reduced the amount of state that needed to be continuously transmitted as authoritative physical state.

Recording and replay architecture

Games are particularly challenging to test because their behavior depends not only on which events occur, but also on when they occur. Input, network messages, physics and internal game systems can all generate events concurrently during the simulation.

The testing system addressed this by recording events together with their position in the simulation timeline, allowing a previously captured gameplay situation to be reproduced under controlled conditions.

• Events could be recorded at different abstraction levels. Device inputs and network messages could be captured directly, but the resulting game-level events could also be recorded independently.
• Events retained their original simulation timing. Replaying a session did not simply execute the events as fast as possible. They were injected at the same points in the simulation timeline in which they had originally occurred.
• Higher-level gameplay events could be tested directly. For example, instead of reproducing every input that caused a character to move, a test could replay the resulting command to move the character from one tile to another.
• The same infrastructure supported different testing scenarios. Depending on what needed to be investigated, a test could reproduce the original inputs or work at a higher level of the gameplay system.

Testing interface

The tools included a dedicated interface for managing the recorded simulations. Testers could browse the available scenarios, inspect their stored descriptions and launch a selected simulation.

When a test was started, the appropriate game scene was loaded and the recorded session was automatically reproduced, allowing the tester to observe the same gameplay sequence under controlled conditions.

This approach was particularly useful for gameplay scenarios where manually reproducing the exact sequence of inputs, network events and timing would otherwise be difficult or inconsistent.

Shared synchronization architecture

Buccaneer's Booty uses the same gameplay and synchronization architecture developed for Fizzle Fighters. This allowed the puzzle game to reuse the same simulation model instead of introducing a separate codebase specifically for single-player gameplay.

• The gameplay simulation is independent from the synchronization backend. Game actions are processed through the same architecture regardless of whether the game is running locally or connected to a multiplayer server.
• LocalSynchronizer replaces the server for single-player gameplay. It implements the same synchronization interface while executing the required operations locally, allowing the game to run without a network connection.
• The architecture keeps multiplayer as a natural extension of the game. Because the gameplay code does not depend directly on a server implementation, the same puzzle simulation can be connected to the network synchronization layer.
• The approach makes multiplayer puzzle development possible without rebuilding the game architecture. The same codebase can therefore support local puzzle gameplay while providing a foundation for future cooperative or competitive online puzzle modes.

This architecture also creates a reusable foundation for multiplayer puzzle games: the local implementation can be used during development and single-player gameplay, while the same synchronization layer can later be connected to a server when online gameplay is required.