Traditional game networking designs include client-server, peer-to-peer or MMO-like clustering. Whichever it is, there’s always a piece of custom, imperative code that, on every “tick” of the game server frame, decides what part of the world a given game client should be updated with (usually referred to as “area interest management”). The same code decides how to package that information into a capped-by-bandwidth, finite number of network protocol packets (typically UDP) that the server can send to this client in a given frame (usually referred to as “netcode”).
However, in SpatialOS game worlds, the distributed Runtime acts as a middleman between hundreds of game servers and thousands of game client connections. The “game state” in a SpatialOS simulation is spread across different machines, whether parts of the distributed Runtime or particular servers (instances of game engines or processes).
Because of the distributed nature of this state, SpatialOS needs a generic, declarative, entity-component-based area of interest management system. Since users no longer write explicit netcode, SpatialOS contains a generic networking stack that must work for a variety of games, whether an MMORPG, a massive FPS or a huge Minecraft-like world.
This single networking stack needs to solve a plethora of problems in a generic way. To do this, we’ve built a highly flexible solution that utilises multiple techniques: delta compression for efficient exchange of large pieces of data, automated interest management, dealing with partial updates to collections, and dynamic prioritisation of data. These are extremely important on the server side of the game world simulation in order to make the resource and latency overhead of server-to-server communication negligible.
The biggest challenge, though, are latency and any packet loss of client connections. For this, game networking has both the challenges typical with unreliable, lossy real-time video streaming (like RTP with H.264 payload), as well as reliable web service request-response semantics. This is why we’re utilising forward-error correction techniques, as well as developing a proprietary state synchronisation protocol that is tolerant of packet loss… at the same time.
Moreover, as SpatialOS is available across multiple platforms and devices (mobiles, consoles and PCs), the algorithm problems inherent in the network protocol design are multiplied by engineering problems. One of these is providing portability across those platforms and low-level customisation such as custom memory allocators. Another is catering for the networking properties of a given platform, like dealing with connection roaming on mobile networks.
So whether you’re interested in building generic solutions to problems that have had only bespoke solutions so far, building security fundamentals of network protocols, researching efficient compression and lossy data synchronisation, or enjoy the challenges of writing extremely portable code, the SpatialOS Core Platform has all these challenges and much, much more.