Our goal with SpatialOS for Unreal is to provide the fastest way to create, launch, and operate an online game with Unreal Engine. We want to help teams focus on gameplay by providing all the building blocks of a modern online game while preserving native Unreal Engine workflows.
Today, we’re delighted to announce 2019.1 - a collection of product releases which provide our biggest step yet towards this goal. This release contains:
This is a release of our Unreal Engine plugin, fork and Example Project, containing:
2019.1 also includes the release of our first Online Services - providing infrastructure around your game's SpatialOS cloud deployment:
The GDK now enables you to offload the computation for classes of Actors, such as all AI actors, to an Unreal server-worker separate from your main gameplay server-worker.
In this architecture, SpatialOS runs another Unreal server-worker which has authority only over this specific group of Actors, while your main Unreal server-worker maintains authority over all other Actors.
Since the game state is stored in SpatialOS all server-workers can use state updates. To call RPCs on a different server, they use the GDK’s cross-server RPCs.
The biggest gains in this architecture occur when you offload computationally expensive but latency-tolerant systems, such as advanced AI or large-scale background physics simulation. This is computation that the Unreal gameplay server-worker won’t have to do, meaning it can run other systems at a larger scale, such as state synchronisation with clients.
To validate this, we created a demo containing simulated players and complex AIs. The AIs are running expensive pathfinding operations using Unreal’s Environment Query System, and seeing other AIs and players using Unreal’s Perception System. They run the EQS query every 0.5s, and map contains 42 moving barriers which go up and down every 30 seconds to change the navmesh.
We ran this demo, on the same hardware, in a native Unreal dedicated server and in a SpatialOS deployment with a main gameplay server and an offloading server authoritative over all the AI. The aim was to understand whether this architecture enables us to exceed native Unreal’s performance.
We fixed the simulated player count at 64 players in each case, but slowly increased the number of AI to see at which point the main gameplay server would no longer cope (that is, where it dropped below 20 FPS).
We observed the following results:
Max AI count to maintain Server FPS > 20
Dedicated Unreal server with native Unreal networking
SpatialOS deployment with an Unreal server-worker for the main game loop, and AI offloaded to another Unreal server-worker
This is one of many tests we are planning to run and publish in the coming weeks.
To help you get started with offloading, the GDK’s Example Project now includes an AI Offloading Gym. The gym has turret AIs offloaded to one server, humanoid AI offloaded to another, and a main Unreal gameplay server.
For more information about how Offloading works and how to use it in your project, check out the reference documentation.
The GDK for Unreal replaces Unreal’s native networking driver with a SpatialOS integration, which will enable us to preserve almost all Unreal’s features, workflows and APIs. In this release, we have added support for:
This completes our support of Unreal’s Gameplay Framework.
We have also improved the day-to-day development workflow with the GDK through:
You can now add in Simulated Players - an Unreal client instance controlled by simulated player logic rather than real player input - to any GDK project. This can help you scale test your game, as well as figure out game balance issues when you don’t have your target number of players on hand to join playtests.
Simulated Players are launched in another SpatialOS deployment and connect in to the target deployment that is being scale tested. We’ve introduced a new Deploy button in the GDK’s Unreal toolbar to help you easily launch these deployments.
Just like other SpatialOS deployments, the deployment running Simulated Players has all the usual observability tooling (inspector, logs, metrics) to help diagnose a scale test.
We added simulated players to the Example Project for you to try out - follow the tutorial here.
We have released our first services for authenticating, grouping and matching players into SpatialOS game instances. These services provide a framework for developers to write their own completely customizable matchmaking logic. These could also be used to build completely different tools related to getting players into game instances, such as players transferring between worlds or entering dungeons.
In this first iteration, this is a suite of example services that users can download, edit and deploy to a public cloud - the services are not managed by Improbable. This is so we can provide as much flexibility as possible for developers to tailor how the services work.
The matchmaking service consists of:
In addition, we have released a Playfab auth service enabling you to easily authenticate players for your SpatialOS game.
This all runs in the public cloud, using Kubernetes and Redis, scaling the resources it needs appropriately. The system diagram below explains how this works after the system has been deployed to a public cloud:
Another area in which we want to help you to save time and to focus on gameplay is in storing data between player sessions. With our new Database Sync Worker Example, you can easily synchronise game data between SpatialOS and an external database.
A simple example of this might be the players’ permanent data, which could contain persistent character unlocks, stats and customisations. We believe that when this data needs to be read and modified by SpatialOS workers, it should be presented in the same way as all other SpatialOS data: in terms of components, component updates, and commands. This lets you keep your game’s logic using the same data models that are already established.
With the Database Sync Worker Example, we’re demonstrating the ability to easily map a hierarchy of data back and forth between a database and a SpatialOS deployment’s workers and clients without restructuring the data on either side of those interfaces. Our example demonstrates how to add the worker’s schema to your project, configure it, interact with the database, and receive update notifications to re-broadcast notifications from the database to your workers.
To help you get started with the Database Sync Worker in a GDK project, we’ve released a new tutorial which takes you through synchronising kill/death counts from the Example Project with a Postgres database. All source for this project is available in a branch of the Example Project for reference.
Finally, we are releasing a new C# Worker Template, which was used to create the Database Sync Worker. This template can be used to create workers for functionality that doesn’t require all the power of a game engine, for example, chat systems, high-level AI or game logic, and analytics workers. These standalone workers benefit from C#’s fast build times and ecosystem of tools. This template is based on the .NET Core platform for easy cross-platform development.
To summarise: this release introduces offloading to the SpatialOS GDK for Unreal, enabling you to start building richer worlds by offloading computation to separate dedicated workers. For faster iteration through the development of your project, the GDK’s local workflow and support for Unreal features has improved, and you can now easily add Simulated Players to any GDK project for scale testing. Finally, our new matchmaking services and the Database Sync Worker Example provide the basis for building the online services that sit outside of your game deployment.