Today, we’re incredibly excited to introduce the new SpatialOS Runtime. The Runtime is the heart of SpatialOS. It is the foundational system that leverages distributed computation so that you can exceed the limitations of a single game engine or server. Given the importance of this core system, this upgrade marks a significant milestone for the SpatialOS platform as a whole.
We will be rolling out the new Runtime in steps, initially as opt-in releases. This enables you to verify the performance of your existing projects in the new environment. In this post, we explain what’s changed, the benefits of the new Runtime, and how you can opt into the upgrade today – starting with the new bridge architecture.
We will make additional announcements when each of these upgrade steps is available. In the meantime, we want your feedback! Please let us know your experience in the forums.
As we said earlier, the Runtime is the foundation of a game running on the SpatialOS platform. It enables you to leverage distributed computation for your games by “stitching together” multiple game engines and servers.
More specifically, it:
The immediate benefits of the new Runtime are mostly features related to performance and stability. However, we’re working on features in our development pipeline that focus on new capabilities that are only possible using the upgraded architecture.
The full set of benefits will only be available after completing the upgrade. However, with each step (except the first, which is a compatibility upgrade) you will get a few new features.
The new architecture is characterized by changes to three core components: the new entity database, the new load-balancing system and the new bridge architecture.
First, the new entity database. Whilst the Runtime has always been responsible for storing the state of entities, we have now split this into a separate software component, which we call the entity database. Simply, this is a sharded, scalable database for storing live entity data. We will cover these changes and their consequences in a subsequent post when this upgrade step is available.
The second change we’re making is to worker ‘load-balancing.’ This determines which workers should be authoritative for which components on which entities, whether more server-side workers should be started or stopped, and the recovery or restart of crashed workers. Our new load-balancing system is due in around a month and we will cover the changes in a subsequent post when this is available.
That said, the first change users will experience is to our bridge architecture. A bridge is a connection between a worker and the Runtime. Its purpose is to provide an up-to-date view of the world to the worker and to allow the worker to modify certain entities within the world.
The original bridge architecture was based on a message pipeline. Updates from within the Runtime were filtered into a stream of data to send to a worker. This was performed relatively well, but struggled to support more advanced features such as component-level diffing, update/bandwidth rate-limiting, dealing with stale data, and general robustness for poor connections.
The new bridge architecture is based on a ‘diffing’ model: the bridge holds two ‘views’ of the entities in the world that the worker is interested in: one view as they exist in the new entity database, and one view as they are seen by the worker. The bridge is responsible for making the two views ‘consistent’ with each other, by figuring out which updates to send to the worker’s view to make the two views agree on the state of the world.
The new approach is more flexible in terms of making various improvements in the future. But, fundamentally, it’s built to perform better with the new entity database.