Creating a Cross-Platform Multiplayer Game in Unity — Part 4

Synchronizing the State of the Game World

(or, the Big Dark Secret About Multiplayer Tutorials)

You've probably noticed that those crates on the track don't match up on each device — which means you can see your opponents drive straight through a crate:

The car drove right through the crate! It must be a g-g-g-g-ghost car!

You might also notice that an opponent car seems to get stuck on nothing at all — perhaps a particularly dense patch of air? :] And come to think of it, why aren't the cars colliding with each other? The more you think about it, the weirder this game gets...

Congratulations — you've hit upon the big deep dark dirty secret of multiplayer tutorials. Have you noticed that nearly all multiplayer tutorials you see involve racing games? And not just that, but racing games where nothing you do really affects the other player?

That's because trying to write a game where all clients agree on the shared state of the world is, to use a technical term, REALLY HARD. Imagine you're playing a game where both your car and your opponent's car are heading towards the same crate.

Due to network latency, you see your car run into the crate a few milliseconds before your opponent, but your opponent sees that she runs into the crate first. Just a few milliseconds difference means the two player worlds end up in drastically different states:

One minor difference, two drastically different game worlds

Generally, games like this fake it by making all players participate in what ends up being a collection of single player games, and then simply report the end result of those single player games to each other. Puzzle fighter games, in particular, work this way. Of course, any real-time games that rely on slow turns — like the theoretical poker example — don't need to deal with this problem at all.

But you've surely played fast-paced, online multiplayer games where players do interact with each other in a shared world. How do they do it, and why aren't we covering this here?

There are a lot of different strategies to solve this REALLY HARD problem, but here are two of the most common:

Strategy 1: Using Discrete Turns

In real-time strategy games, the game itself is defined as a series of very fast, discrete turns. You assume that when a player makes a move, it won't get carried out until a few turns later. For instance, if you decide to move your tank on turn 1056, it won't start moving until turn 1059, which should be enough time for your "Hey, Todd wants his tank to start moving on turn 1059" message to make it out to all of the other opponents.

On your device, some user interface sleight-of-hand along with some audio feedback ("Rolling out, commander!") would hide the fact that your tank doesn't move right away. This way, each client is able to perfectly recreate the state of the world locally by having everybody perform the exact same actions on the exact same turns, as illustrated below:

Strategy 2: Using a Server to Sync

In first-person shooter games, a separate server determines the state of the world. Sometimes — particularly in mobile games — this "server" is just a player's device. When a player decides to take an action, such as jumping, your client sends a "Start jumping" message to the server. The server then responds back with a message of what actually happened when you started jumping, and your game then updates to reflect the reality as reported by the server.

This solves your multiplayer divergent worlds problem, because the server is the one true source of what's going on in the world. But it would be a terribly laggy experience to wait for a response from the server before you can start jumping. Many games solve this by taking a really good guess as to what they think should happen when you start jumping, but then alter your game state as required when they gets the definitive result from the server.

Here's a quick diagram showing this strategy in action:

Keeping the world in sync in a multiplayer game is a fascinating topic, and there's a lot more detail than can be included here. If you want to delve deeper into this topic, I highly recommend reading 1500 Archers on a 28.8 Network by the developers of Age of Empires, and What Every Programmer Needs to Know About Game Networking by Glenn Fiedler.

These are really interesting problems to solve, but as you can see, they're also quite complicated with lots of thorny issues. And just like the "synchronized start" problem, they are best saved for a future tutorial.

Where to Go From Here?

Congratulations! You now have an awesome multiplayer game that, in spite of its simplicity, is a lot of fun to play against one or more opponents. There are still a few outstanding issues to solve in your game, such as the synchronous world issue described above, but if there's enough interest, we could look into discussing some of these in a future series.

In the meantime, now that you've got the basics down for a multiplayer game, try making your own! Maybe there are some gameplay changes you can add to Circuit Racer to make it more fun. How about giving your player a power-up that messes with their opponent if you can make it through an entire lap without hitting a crate?

You can also take what you've learned here and apply it to your own game. Even a simple game like a single-player puzzle game can have a fun multiplayer component if you turn it into a simple contest of "who can reach the target score first?" If you do make something using what you've learned here, let us know — we'd love to hear about it in the discussion below!