Our approach to networking
Published 5 years ago
Solving problems from a player’s perspective


There is a big difference between creating a game with local/couch multiplayer and developing a game for online multiplayer. In this post I will go over the process we went through in networking one of our core mechanics from the 2D local multiplayer prototype to the full 3D online multiplayer game.
A small rush of customers
Throughout games of Cone Wars, we have ‘rushes’ of customers that appear and act as the main way players can earn points (in our case, money). They appear around the map in different locations (depending on a few factors) and either drive players to interact with each other, or separate them to provide a breather (depending on how the game is playing).


To fully recreate rushes in an online multiplayer game it would require us to synchronize a lot of information. Regardless of the overhead of instantiation, destruction and general sync bulk each customer instance would need the following:
  • Position
  • Rotation
  • Serve state (who served them, which ice cream are they holding etc.)
There are a number of variables and states we can derive locally such as animation state and visual effects, but when considering the number of customers and the amount of bandwidth used to sync all of this information, it’s not insignificant.
To resolve these issues (and try to hit our bandwidth goals), we could look at bandwidth optimization, state synchronization or snapshot compression, but if take we take a step back and actually consider what a ‘rush’ is, we can do a whole lot better. (Glenn Fiedler covers various networking techniques in great depth on his blog if you're interested)


One of the major differences between local multiplayer and online multiplayer is that when playing online you can’t see what other players can see. Creating a networked game requires a sleight of hand to give players the impression that everything is as they see it and all other players see the world exactly as they do. In reality this isn’t the case with extrapolation, client side prediction and lag correction – players are sharing the experience of playing together.
This freed us up to think about what a ‘rush’ is and consider it from the three perspectives that are needed when developing for online:
  • What do we see ourselves doing (local client)
  • What do we see others doing (remote clients)
  • What does the server ‘see’


The server doesn’t care about pretty visuals - it’s just the authority over the game world. All it needs to know is, who is in the rush area and whether they have any stock. If a player is in a rush and has the stock to give a customer then the server will routinely take an ice cream from them and then add a coin to their count. It’s just basic arithmetic and the server can handle that without breaking a sweat.
How the server sees rushes


When we drive our truck to a rush of customers we expect ice creams to move from our truck to a customer, with the customer giving us a coin in return. We expect to see our stock go down and our money to go up. Pretty simple.
In this case, this is basically the same as what we expect to see if other players are at a rush as well.
How the client sees rushes
Essentially, customers don’t even exist on the server, they only exist in each player's game as a representation of a rush. You could see another player drive into a rush and start serving customers. If they serve a customer in their game with a red shirt and in your game you see them serve a customer wearing a blue shirt, does it affect your experience of the game? You still see an ice cream go to the customer and the player collect the money along with all the sounds and visual effects you’d expect.


By considering what we’re trying to achieve for each player, we have done the most optimal bandwidth optimization - we don’t send anything. All we need to sync is where the rush is and the number of customers in the rush. Networking isn't just about different techniques for minimizing bandwidth but also about considering your problems from a player's perspective. This doesn’t mean there isn’t a place for bandwidth optimization... there will most probably be a post on that in the near future.
Don’t forget to join our infrequent mailing list for Cone Wars updates directly to your inbox.
Game Design Director - Executive