Elympics Multiplayer Services explained

As opposed to single player, multiplayer gameplays bring a number of tech difficulties. It’s important to know what to expect and how to overcome them before starting the development process. Our networking web3 game engine makes it easier, so let’s dive deep into Elympics Multiplayer Services! 

Multiplayer implementations overview

Game developers take one of the three approaches towards building a multiplayer game:

Peer-to-peer

The most basic and somewhat naive approach. It doesn't require an external server, so it’s easy to implement, but developers rarely take it for its limitations. First of all, it’s suitable only for playing within a single Wi-Fi or Bluetooth connection. Second, as more players join the game, the amount of data transferred increases drastically i. Not very practical.

Client authoritative

It's the most popular solution but has significant limitations too. It gives the players (clients) full control over the game state, so it’s perfectly possible for a malicious player to change it for their advantage. They play the role of the match arbiter, thanks to which there’s no need for an external server to do it. That’s the biggest advantage of this approach as it reduces infrastructure and maintenance costs, but because of the cheating opportunities, it’s absolutely unsuitable for esports and play-to-earn. The one responsible for synchronization and resolving conflicts is the developer.

However, there’s an advantage: it doesn’t require a server to play the role of a 'transmitter' of the information because there’s no code related to the game logic executed on it. The disadvantage is that it’s impossible to create a multiplayer game in the same way as one would build a singleplayer one because the developer is responsible for synchronising the state of the game.

Neither of these solutions ensures fairness. If a developer wants to build a P2E game that rewards users for their in-game achievements, there’s only one option:

Server authoritative

A solution that requires a central server on which the game takes place. Players are only the receivers of the gameplay statuses and creators of minimal inputs according to the game rules and don’t play the arbiter role. Thanks to that, they cannot cheat as in the previous approach, but this solution calls for hosting a separate server with the game logic.

The advantages of this approach are universal architecture and clear conflict resolution. On the other side, the challenges are synchronising the game state correctly without lags and maintaining a production environment according to the number of players. 

Another problem is that the infrastructure needed for this approach is costly and requires a difficult setup. That’s why it’s better to use a ready-made solution with the server authoritative implemented. That’s how Elympics Multiplayer Services work: esports and P2E game developers don’t have to build the infrastructure themselves as the job has been done by our team. Any studio, no matter its size, may create a fair game without writing the network code and paying a fortune.

What's wrong with client authoritative

The client authoritative approach allows players to cheat. The arbiter of the game can modify its statuses freely, and there’s no external party to validate it.

In the example above, the client sends new coordinates without an external arbiter. Even if they don’t comply with the game rules, they can send arbitrary values. They should move only one point, but there's no one to prevent it.

If they delegated the arbiter role to a server, this external party wouldn’t allow them to modify the game state against the game logic.

In the client-server architecture, the logic is played on the server too, and the game state that the clients send are validated and synchronised with the server. It plays the role of the referee and the game state is superior to the players. 

Unity SDK

Elympics system works independently of the game engine. Thanks to that, developers may use whichever production environment they want. To make the development process easier and faster, there’s an SDK for the Unity environment that allows them to easily implement multiplayer gameplay without writing any network code.

Functionalities:

• Built-in game state synchronisation,
• Integration with the Unity editor,
• Multiple game modes (online, local, half-remote),
• Common code on server and client (forced by SDK architecture),
• Prediction,
• Reconciliation,
• Automated server part building.

Prediction mechanism

To avoid lags in the gameplay, developers need prediction: identical game logic running locally that the server also has. 

Let’s explain it in an example. The client sends an input and wants to initiate a 100ms animation. The client has to wait for the response of the server, so the entire procedure takes 200ms. 

To eliminate the lag resulting from increased traffic, Elympics SDK is fitted with a prediction mechanism. Thanks to that, games may run locally while waiting for the validation of inputs from the server side. It minimizes the response time: the operation takes 100ms less than in the first case.

Multiplayer game development: client authoritative vs server authoritative | Elympics Blog

‍

And if the local prediction is not correct?

It may happen that the client predicts the game state incorrectly because of the game indeterminism itself, the opponent’s moves or other reasons. Because of that, it doesn’t match the state of the server. What happens in such a case is reconciliation: the system makes an amendment to the client game state based on the state received from the server. As a result, statuses get synchronised.

Each state and input have their own identifiers. The client predicts their actions and game states with the same identifier as the server and stores them in the game history. Once the server sends a valid game state, the client compares it with the state saved in its history. If they don’t match, the received state is superimposed on the game, and the game logic along with the saved subsequent actions is played back to the point in time where the client was before the conflict.

Prediction and reconciliation are two large mechanisms independent of the logic of a game. We’ve encapsulated them behind a layer of abstraction in the Elympics SDK so that you don’t need to know how they work or that they’re running. It makes the process of building a multiplayer game with Elympics as easy as building a singleplayer one!