For this assignment I originally wanted to write about the networking in the new Planetary Annihilation. This was mostly because early on in development they talked about how they could just record events and replay the events to make saved replays. I had expected it to be easier to find information about the internal implementation of this because PA needed to support synchronizing hundreds of units across clients. Unfortunately, I could not find many resources on this subject. I expect that they will write something about the networking back end of the game later on in development or after the official release date since they have been so open about the internals of the engine so far.
Upon failure to find resources on PA’s networking I turned towards the MMO FPS Planetside 2. This was tied with PA on how much I wanted to research its networking. This game really interested me because it is a MMO and a FPS which, aside from being an interesting genre, it is impressive from a networking perspective. There are few games like Planetside 2 that support open world battles of hundreds of players. This is because FPS games have a very low tolerance for lag from a game play standpoint. Despite this, Planetside 2 does a very good job at keeping latency down even with all the players, tanks, jets, and transport vehicles moving around and firing shells. I was unable to find any specific resources about how their network architecture works, but I found a person who referred to http://www.gdcvault.com/play/1014345/I-Shot-You-First-Networking. This video is a GDC talk about how some of the networking in Halo Reach was implemented.
This talk was very through in its coverage of how different things such as grenades and player assassinations get networked within the game. The networking model that Halo Reach uses is based on the TRIBES Engine networking model. This model is based on the idea of semi-reliable data delivery so packets do not need to get re-sent if they are dropped. In this system, there are three main types of data that are all sent best-effort. The first data type is state data. State data transmits the current state of all objects in the game and guarantees eventual delivery of the most current game state. Some things transmitted by state data could be an object’s position or health.
The second type of data sent is event data. Events are sent when something happens such as a bomb explosion or a gun fires. Events are used only as transitions, and do not cause anything other than a visual effect on the client side if the client receives a grenade explosion event then it will make an explosion effect and start playing a sound. Nothing that directly affects the client’s game play is transmitted through events; only state data is used in this way. Events are also best-effort, but only get sent once so they are not guaranteed to get received by the client in the same way as state data. Since the player only needs to know the end state of an area, much of the event data they would not be able to view the results of may then get culled from the server’s network updates.
The final type of data is control data. This is the data from when the player presses a button on their controller. This data contains the current state of the controller and gets resent to the host frequently.
The state data is organized and prioritized by the distance from the player, if the player is looking at an object, and through custom priorities set by designers. Each object has three stats that determine their priority for network updates. The first number is their overall priority which will allow objects to get their update sent out before other objects queued for an update. The second is the relevance. The relevance is generally meant to represent how visible the object is. The last is the desired update period. Some objects that don’t move much would have a desired update period of around 400ms.
Using this setup Bungi was able to meet the low bandwidth constraints that many console players had.