Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
arrowPress Releases

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Building a solid real-time multiplayer game

by Per Ekstig on 10/24/16 11:42:00 am

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


Consider this dialogue:

Player 1: ”I just made a nice pass to my left forward.”
Player 2: ”But my midfielder made a perfect slide tackle and took the ball.”
Player 1: ”No, your midfielder was way too late!”

When the information about a tackle is delayed due to network latency, such situations are likely to occur. This will ruin the gameplay, unless several basic safety measures are taken.

So, who is right? Did player 2 succeed with his tackle, or was he too late? If you stop and think for a moment, you will probably come to the conclusion that there is no correct answer to this question. The important question is instead: Who has the authority to decide which player won the ball in that situation?

In this article I will suggest a solution to this problem, and a generic approach to make real-time multiplayer games like soccer ”solid”. Even if the two players are located in different parts of the world, with varying mobile connection qualities, being able to play a real-time multiplayer with a good gaming experience might sound like a utopia, but let’s give it a try.

But first, a few words about the choice of network architecture.

Client-server or peer-to-peer?

In a client-server architecture, the server is authoritative. The server decides who will start with the ball, who will intercept, if a shot is saved by the goal keeper, and so on. This approach is pretty straight-forward, and not too complex to implement. But the drawback is that the network actions need to go through a server, which means higher network latency. And players that happen to be located closer to the server will probably have an unfair advantage in the game.

Peer-to-peer is superior. Just look at FaceTime or Skype. Large amounts of information are transferred without notable delay over long distances.

With peer-to-peer, it might be tempting to make one of the players authoritative throughout the game. But this is a very dangerous approach, because the player that is authoritative will have a big advantage to make requests really quick because no network request is needed. And the other player will have to send a request ”I want to shoot the ball now” and wait for a response if the shot was allowed.

Peer-to-peer seems to be best choice for real-time multiplayer games. To succeed in making a solid real-time multiplayer soccer game, I have identified three basic rules:

1. Use deterministic physics.
2. Make predictions in advance.
3. Let the player who has the ball possession be authoritative.

By following these rules, you will have a good foundation for creating a stable game. Network lags will still be disturbing, but the gameplay will be intact and you can do a lot to try to conceal such anomalies.

Rule #1: Use deterministic physics

Some physics engines are non-deterministic. This means that even if both players triggers the shot with the same initial parameters, the ball will probably not follow the exact same path. For player 1 it might hit the bar, for player 2 the shot passes slightly over.

”Even the smallest deviation will accumulate over time, and the result will not be reliable.”

The two players have the exact same conditions but it will result in different outcomes. A common reason for this is that some physics engines make the calculations for a certain amount of time, and high-end devices will therefor be able to calculate more accurately than low-end devices.

Even the smallest deviation will accumulate over time, and the result will not be reliable. In the picture above, the ball hits the bar and bounces back. But when player 2 calculates the same ball path, it hits the bar a few millimeters higher and the ball bounces over the goal. This is why the physics engine needs to be deterministic.

Rule #2: Make predictions in advance

Let’s assume that player 1 sends the action:

”I hit the ball at position p1 with speed v1”.

This would be enough to trigger the shot of the ball, but player 2 that receives this action will be dependent on further instructions and will get in trouble if the next action, that says that the shot was intercepted, came too late.

Instead, try to predetermine the outcome, and send exact information about ball’s journey:

”I hit the ball at position p1 with speed v1 and it will be saved by player 2's goalkeeper at time t1 and after the interception the ball will have the new speed v2 and finally end at position p2, and the new ball possession will be assigned player 7 of team 1.”

With all this information, player 2 will be able to prepare the situation and play it accurately without having to wait for any further instructions.

If the interceptor is the goalkeeper, he will get time to prepare a spectacular save.

Rule #3: Let the player who has the ball possession be authoritative.

The two players are connected peer-to-peer. The first thing that will happen is that the players decide who gets to start with the ball, which is decided by a virtual coin toss. A common implementation of this is that both players pick a random number and sends it over to the other, and the one with the highest number wins the coin toss.

Next, the idea is to let the player who has the ball possession to be authoritative. In the introductory example, player 1 has the ball, he makes a pass, he receives information about a tackle request from player 2, and he decides between the two outcomes:

1. The tackle was unsuccessful. Player 1 will keep the possession. He sends information to player 2 that his tackle attempt was unsuccessful and player 2 is responsible to try to make it look like the tackle failed at his end.

2. The tackle was successful. Player 1 analyses the situation and, in fact, controls the opponent’s player to hit the ball in the tackle situation. The information how the ball was hit in the tackle, together with information how the ball will bounce is sent to player 2 and it is predicted which player will be the closest to the ball after this situation. If player 2 is closer to the ball, player 1 will give away the ball possession and thus the authoritative.

Conclusion: The player who has the ball possession will keep it until he decides to give it away. He will continuously receive requests from the opponent because the opponent is never be allowed to directly touch the ball.

How these rules were applied to Solid Soccer

The game that I've been working on is called Solid Soccer and is available on iOS. It’s a fast real-time multiplayer game using Game Center to connect players peer-to-peer. At the writing moment it is in soft launch in a limited number of countries.

To comply with the three rules, we made the following game design choices:

  • Deterministic physics:  In Solid Soccer, I wrote my own basic physics engine to be sure to have full control. The focus is to make a fun and interactive game, not a realistic football simulator, so I saw no need for advanced physics like rolling-friction, restitution or inertia.
  • The goalkeeper’s actions are time-critical. Once player 1 has made a shot at target, there is no time to let player 2 aim and jump to save the shot, because the sending of such an action over the network may take longer time then the ball to hit the net inside the goal. Therefor, our goalkeepers are controlled by AI. The player who makes the shot predicts the outcome, and triggers the animation of the opponent’s goalkeeper.
  • Tackle interactions. When player 1 has the ball possession, it would be dull for player 2 having to wait for the opponent to lose the ball, so we added tackle actions. When you tackle, a request is sent to the opponent and if approved, the tackle is performed successfully and the ball control will be assigned to the team that will reach the ball next.
  • Every time the ball is hit, the ball’s new target position is calculated and if the opponent has a player closer to the ball, the possession, thus the authoritative, is handed over.

In Solid Soccer, there are only five network actions. These actions are also saved in a history object so it can be used to replay the whole match afterwards.

Although these restrictions will limit the freedom in the gameplay, there is still enough room for interactions, and the game will be very fast and fun, just as in real life. In fact, the illusion is remarkable: The player that intercepts a shot has no idea his interception was predicted at the time the shot was made.

I hope this article encourages you to take the step, you do not have to settle for asynchronous or turn-based solutions, go for real-time multiplayer!

Related Jobs

Question — Remote, California, United States

Senior Gameplay Engineer (Unreal Engine, Work from Home)
Question — Remote, California, United States

Senior Network Engineer (Unreal Engine, Work from Home)
Remedy Entertainment
Remedy Entertainment — Espoo, Finland

Senior Programmer
Remedy Entertainment
Remedy Entertainment — Espoo, Finland

Senior Rigging Artist

Loading Comments

loader image