The majority of state-of-the-art, in-memory databases follow write-to-read semantics as they are optimised for typical web-based, request-response flows. Some of these systems have auxiliary streaming capabilities; an example of one is the Redis pub-sub system. However such components are never the primary functionality of a system and thus not the first thing to be optimised for.
Our Runtime’s role is to be both the canonical state of the world, and to move state change information from the servers that perform the simulation to clients or other servers. As such, we’ve built the Runtime primarily for write-to-stream semantics. Instead of reading a single state of the database, our queries form subscriptions for a particular subset of data (such as the region of the game world) at a particular fidelity (such as a 1Hz view of something updating at 60Hz).
As a game world undergoes constant changes (like roaming game clients), we had to solve the hard problem of these subscription queries constantly changing. We’ve done it by building proprietary algorithms for real-time stream subscription modification. Coupled with in-house research into stream query optimisation, this has allowed us to build an automatic subscription management system. Thanks to this system, game developers no longer have to hand-write interest management code.
All of this is underpinned by a data format spec called Schemalang. It provides the canonical data interchange format between clients, servers and our persistent storage. This makes it easy to integrate clients and servers that use different data structures. Moreover, the Runtime can act as an in-memory database, with Schemalang providing the, well, “schema” for what forms a data plane for any game built using SpatialOS.
So, whether you’re interested in hardcore algorithms, optimisation problems, tooling for querying and managing state, or providing data abstractions with guarantees, the SpatialOS Core Platform has all these challenges and much, much more.