How W4 Cloud's multiplayer works

To start with, let's explore how W4 Cloud works.

There are two main ways of building up networking for games:

• Peer-to-Peer (P2P), where each player is directly connected to other players in a mesh.

• Authoritative server, where each player communicates with a central node.

W4 supports both. You can even mix the two approaches: W4 makes no assumption about your network architecture.

Most commercial games out today use an authoritative server, which is far simpler and more resilient to cheating by default than Peer-to-Peer. This is why we will learn to set up authoritative multiplayer in this series.

The most common reason people use Peer-to-Peer is generally the initial accessibility and lower costs: authoritative multiplayer requires connecting all players to the central server and having some infrastructure to run your game.

Peer-to-Peer is also used in specific games that require tight reflexes, generally alongside authoritative servers. For example, games like StarCraft 2 and versus-fighting games use peer-to-peer.

This networking architecture can be useful for certain games and when prototyping online multiplayer games. But this setup is much harder to secure and scale.

Thankfully, W4 Cloud gives you access to the infrastructure, making authoritative multiplayer easy to set up.

How to play a game round with W4 Cloud

In short, for multiple people to play against each other online, with W4 Cloud, we need to:

1. Identify the different players (authenticate them).

2. Gather players together in groups that can play simultaneously (using lobbies and matchmaking).

3. Run a copy of the Godot game on the server and connect all the players to it. That's a game round.

Here's a more detailed figure of the technology's flow:

Let's break down how the system works:

1. Authentication.

   • During the authentication flow, we log users in by sending their username and password to the authentication server. To make this experience seamless, we can generate a user ID and a user password directly on the player's machine and save them invisibly. This way, players don't have to do anything. We call this "credentialless login".

   • The server sends back an auth token to identify the user and keep them logged in while the Godot game is running.

2. Lobby. Once the player is authenticated, they can create a new lobby or request a list of lobbies to join.

   • If the player creates a lobby, they automatically join it and become the "host".

   • Otherwise, players have to join an existing lobby to play. You can set up rules to decide which lobbies players can see and join using W4 Cloud's Matchmaking system.

3. Game round. After everyone joined a lobby, the player who created the lobby can start a game round. When this player requests the game start, W4 runs an instance of Godot with a Linux export of your project.

What happens next depends on each game project.

Note

W4 uses Supabase behind the scene for authentication. Because Supabase does not support logins without emails, we also added SAML support for credentialless logins.

This means that if you need more resilient user accounts, your players can use all authentication methods that Supabase supports: Magic email link, email and password, and all social media OAuth providers like Google, Facebook, GitHub, Azure (Microsoft), GitLab, Twitter, Discord, and many more.

How to synchronize players with an authoritative server

Once W4 has joined all our players in a lobby, we can finally start the game round.

How should we synchronize the game's state on each player's computer? Players might be on either side of the globe, and data could take several frames to travel from one player to another.

The easiest way would be to have each player send their position to the server.

In this scenario:

1. The player presses a button on their keyboard or gamepad.

2. Godot moves the player's avatar locally on their computer.

3. The player sends their updated position to the server.

4. The server relays the position to other players.

This would work and make our game easy to write. On the gameplay side, we could just write a single-player game and add a little code to synchronize positions!

Unfortunately, that would lead to a game that is excessively easy to hack.

A hacker could:

1. Run some code that changes their position in the computer's memory.

2. The game would move the player's avatar accordingly.

3. The server would relay that hacked position to other players.

Of course, the server could check for impossible positions, but that quickly gets unmanageable.

Instead, to limit the risk of hacks, in real-time online games, we usually do the following:

1. We send player inputs to the server, not their positions.

2. The server updates the game simulation and calculates all positions based on the received input.

3. The state of the game calculated by the server gets synchronized back to all players.

This means that the game only partially runs on the player's machine!

Everything that doesn't affect the gameplay and other players can still run locally: Visual effects, user interface, audio, and more. We only want to synchronize and send data when necessary.

The more of the game simulation we run on the server, the more resources it uses and the costlier it gets.

That's a quick run through how W4's multiplayer works. In the next part, we'll download and explore the start project for this series.