Unity Realtime Multiplayer, Part 7: Architectures in Different Genres

Network architecture patterns impact player interactions but they come with their own pros and cons. The choice depends on the genre and interaction scenarios. We'll discuss the lockstep, rollback, snapshot interpolation, and lag compensation patterns and share the best choice for particular genres.

Hello everyone, my name is Dmitrii Ivashchenko and I'm a Lead Software Engineer at MY.GAMES. We're continuing our series of articles examining the landscape of the Unity Realtime Multiplayer in 2023", and this time, we'll be discussing different network architectures in various game genres.

Network architecture patterns

Game developers use various network architecture patterns to ensure reliable and fast interactions between players in multiplayer games. Each pattern has its own advantages and disadvantages, and selecting the appropriate pattern depends on the specific game genre and interaction scenarios you're working with.

In this section, we'll discuss the following patterns: lockstep, rollback, snapshot interpolation, and lag compensation. Additionally, we'll discuss the best-suited patterns for different genres or games.

Lockstep

Lockstep is one of the oldest methods of synchronizing network gameplay, and it's still frequently used today. Although this architecture can take a variety of forms, we'll focus on the most common implementation, and then discuss the necessary conditions, limitations, and possible configurations.

In lockstep architecture, each player sends their input to everyone else, and then advances their simulation as soon as they receive input from all players — that's it! The game is fully synchronized over the internet, uses very little bandwidth, and each player always sees events unfolding exactly the same as everyone else.

To make a game compatible with lockstep architecture, several conditions must be met. Let's discuss those.

Determinism

The main requirement for the lockstep architecture is that the game simulation must support strict, bit-level determinism. Since network code only synchronizes input, the game simulation must compute identical results on each machine in each frame with identical input data. Otherwise, game simulations will desynchronize, diverge, and deviate from each other — ultimately leading to games that look completely different.

This is usually a difficult condition to satisfy, and games must be carefully designed to maintain determinism. Developers often check game state checksums on each frame or at multiple points during a frame and compare these checksums between participants to help track down and fix sources of non-determinism where desynchronization occurs during game testing.

Further, any game that uses floating-point arithmetic (i.e., most modern games) will require additional consideration. If your game runs on multiple platforms, floating-point determinism can be particularly challenging to achieve due to differences between platforms and compilers. Each compiler can use different sets of instructions, reorder instructions, or automatically vectorize. Each system can implement transcendental functions such as cosine, sine, and tangent differently. All of this can lead to desynchronization between platforms, or even between builds. Some developers implement their game simulation exclusively using fixed-point arithmetic or software-emulated floating-point arithmetic to bypass the non-determinism that arises from using floating-point numbers.

Other sources of non-determinism include generating random numbers with different seeds or processing objects in different orders, such as contacts in physics. All of these considerations also greatly limit the third-party libraries that can be used as part of the game simulation, such as collision detection libraries, physics engines, etc. As a result, this may be impractical for many genres of games and engines.

Fixed frame rate

Lockstep also requires all players to synchronize the unit of time represented by each input and tick. In other words, the game will progress at a fixed frame rate. Some games lock the rendering frame rate to match the fixed simulation frame rate. Others allow rendering at an arbitrary frame rate and show interpolation between fixed tick results.

Issues and limitations

Although the lockstep architecture is one of the simplest to implement and comes with no visual artifacts, there are a number of issues and limitations. In some cases, these limitations can be overcome by making certain compromises in the implementation of the game. In other cases, these limitations may simply limit the applicability of this architecture for a given game.

Input delay

Lockstep prevents any delay-induced visual artifacts by waiting to progress until all relevant information has been received. This waiting has a downside: input delay.

“Input delay” usually refers to the time between the user pressing a button and seeing a response on the screen. From a user's perspective, they perceive a response to their input when they see the result of that input on the screen. If the user has to wait until all other players receive and process their input before they see this response, this can lead to a significant input delay.

And in games with high reactivity requirements, such as shooters, input delay can be a critical factor, as it can make the game less responsive and more difficult to play.

Rollback

Moving on, rollback is a popular network code architecture that is widely used in modern competitive games, especially in fighting games.

Rollback can be seen as an extension of the classic lockstep architecture. In the Rollback architecture, players send their commands each frame and continue their game without waiting for commands from other players. The game progresses without waiting for data from remote players — this is called "client prediction" because remote input data is not yet known, and the client must make assumptions about the future actions of other players.

Compared to the lockstep architecture (which provides perfect sequence from frame to frame but with input delay) the rollback architecture provides instant command response, but at the expense of sequence.

In the rollback process, the game progresses and this is immediately displayed as soon as commands from a local player have been sent. However, since commands from the remote player have not yet been received, the displayed information is a prediction. Once data from the remote player is received, this new information must be reconciled with the prediction. If the information does not match the prediction, the game is rolled back to "correct" the error.

What is a "rollback"?

Let's assume that new data from a remote player has arrived for frame 5 while the client was preparing to render frame 7. In this case, the client needs to take the following steps:

1. Load/restore the state of the entire game as it was on frame 4, i.e. the last unpredictable frame where all commands were known.

2. Move the game to frame 5 using the original local commands for frame 5 along with the newly received commands from the remote player.

3. Continue advancing forward by applying local commands for each frame until we reach the current frame (in our example, this is frame 7).

   
   

After completing these steps, we may notice that the actions of the remote player in frame 5 could have led to different outcomes than predicted; it is these corrected outcomes that will now be displayed in the game.

Thus, "rollback" in this context means that the game "rolls back" to the last frame when everything was known, and then "replays" forward with new information. This provides the ability to correct prediction errors.

It should be noted that for this to work, the game must be able to quickly save and restore its full state, as well as move forward any number of frames with arbitrary commands. Depending on the complexity of the game, this may require significant computational resources.

Snapshot interpolation

Snapshot interpolation is a technique that was popularized by the game Quake, and it has since been widely used in games and game engines derived from Quake. Indeed, this model is particularly well-suited for shooters.

The snapshot interpolation approach is based on the concept of two separate temporal streams for game objects: one reflects the state of objects in the past, the other the expected state of objects in the future.

The client (player) sends their commands to the server, which processes these commands, changes the state of the game, and then sends back a "snapshot" of the current state of the game to the clients. This snapshot contains information about all objects in the game at the time of its creation.

To keep the game responsive, clients apply part of the commands immediately to some objects, predicting their behavior. This results in objects being simultaneously present on the player's screen in different states:

• Interpolated objects are represented as they were at a certain point in the past.
• Predicted objects are represented as they are expected to be at a certain point in the future.

This creates an interesting dynamic, for example, when your predicted character tries to dodge an incoming projectile that is interpolated. This can be more difficult than it seems, because your character is moving in the future, while the projectile is in the past.

Nevertheless, this model has a number of advantages:

• The game instantly responds to player commands; unlike the lockstep model, no input delay is required.
• The client side requires significantly less processing time compared to full rollback architecture.
• Objects are interpolated between known states obtained from the server, so objects only pass through states they have already been in.

It's important to note that for effective use of this model, the game must be able to quickly process and transmit snapshots of the game state, as well to instantly respond to player commands.

Best architectures for different gaming genres

Each gaming genre imposes its own limitations on network latency, stability, and throughput. For example, MMO games require high throughput, low latency, and high stability. Meanwhile, first-person shooter (FPS) games require low latency and high throughput. In both genres, it's recommended to use a server-client topology with an authoritative game server and data exchange based on state and input.

The following table below provides a comparative overview of network requirements, data exchange formats, recommended network topologies, and network patterns for different video game genres.

We can draw some conclusions by analyzing this table:

1. Network requirements depend heavily on genre: for example RTS and FPS games require low latency to ensure smooth and realistic gameplay.

   
   

2. The data exchange format also varies depending on the genre: most games use state and input exchange, but some, such as RTS and action games, use only input.

   
   

3. Network patterns and topology are chosen based on the specific requirements of each genre: action and sports games usually use prediction and rollback, while MMO and RPG games usually use snapshot prediction and interpolation.

Rolling on

Each game has its own set of requirements and genre intersections, which imposes its own limitations on network interaction. In many cases, choosing a proven solution will be a better alternative to independent development.

In this post, we reviewed the main patterns of network architecture in realtime multiplayer games. We also compiled a general table of recommended solutions for different genres. Of course, these recommendations are not final and universal, but they can serve as a starting point when choosing your architectural solutions.

In the next article, we will review ready-made solutions for realtime multiplayer games.