#

Making an Asynchronous Turn-based Game in Unity, Part I-A

The nice thing about working with a bunch of friendly and clever folk at Braintree is that they are always willing to brainstorm on better ways of building software. “Clans” is no exception, and within 20 minutes of posting Part I we¹ had come up with a simpler way to build it.

In our last thrilling installment…

I left off in Part I talking about running Unity on the server. It consisted of two parts:

1. Clients (our players) submit orders to the server that represent what they wanted to do on their turn.
2. When the server has all orders for all players, it processes those orders on the server and sends back to clients the new game state that results from it.

Turns out that Step #2 is overkill². Instead, once we have all players’ orders, we just have to send back to each client that collection of all players’ orders and let each client simulate what happened. As long as the simulation is deterministic, clients should end up with the same game state that the server would have generated. This avoids any kind of Unity/Mono running on the server at all.

This introduces the possibility of clients accidentally generating different ideas of the “current state” of the game and getting out-of-sync from one another. This is hardly a novel problem or indeed solution. The original Warcraft used a similar scheme in multiplayer albeit to solve very different problems than what I’m solving. There is a fascinating analysis of the Warcraft out-of-sync problem and its solution by one of Warcraft’s creators, Patrick Wyatt.

My solution will be a slight variation on the first step above. When clients send the server their orders, they’ll also send their understanding of the current game state. Specifically, each client will serialize the current state of the game as they understand it and produce an MD5 sum of the result. If any client sends an MD5 sum that differs from the others, the game is out-of-sync and is dealt with³.

The New Plan ⁴

1. Clients (our players) submit orders to the server that represent what they want to do on their turn. In addition they submit an MD5 checksum of the current game state.
2. When the server has all orders for all players, it verifies all clients had the same game state. It then sends back to clients all other clients’ orders.
3. Each client verifies and simulates orders on their own to determine the next game state.

Next Time, on “Clans!”

Scott outlines how the server will work, something he promised to do in Part I! Enriquela discovers a terrible secret about sharks! Captain Boontz makes a decision that will change OMEGA GOGO SQUADRON forever.

TUNE IN NEXT TIME!

SP