Thinking spatially: using dynamic interest management to create revolutionary game designs.
In multiplayer games of all kinds, it’s important for technical designers to consider the data load on the server, network and client. To avoid replicating all data across each server and client, designers establish areas of interest for each — and put in place interest management systems. With SpatialOS, where there can be multiple servers managing different elements of the simulation, effective interest management is critical.
Yet, with earlier versions of SpatialOS, there was very little flexibility to control what each client saw — what data was streamed to it. Each client had interest in regions of a SpatialOS world that was tied tightly to a square grid overlaid on that world. Everything was measured in terms of squares on this grid — what we call ‘chunks’. This interest region was fixed. And the interest region was the same for all participants in the world.
With the new Runtime, all that’s changed. We now support a whole range of types of interest for each worker, which we call query-based interest (QBI). This allows developers to specify a subset of entities or components in the world, selected by proximity to locations or through a query, that are relevant to the client’s current need. For example, a developer might specify that only entities that have a health component and are within fifty feet of the player are displayed on a client’s mini-map.
We should make it clear, though, that the initial release of the new Runtime won’t have all these interest management elements straight away — we’re going to unlock them over time.
Let’s walk through a longer design example, so you can see what has changed and what will be unlocked one day soon.
Design Example
So, your player’s character is in a multiplayer world. Currently, they’re working hard on a small physics puzzle on an in-game tabletop. Their friend is also in-game, crafting an item in the next room. In this example, all the objects in the world are constituted of entities, which themselves are made up of components that describe their different characteristics. These are changing frequently, and the player’s interest is only in their immediate surroundings.
By setting a high fidelity of interest with a very short area for this local environment, we can make it so that each player’s simulation can be updated from the server frequently enough to maintain the simulation, without overloading the Runtime.
Distant and wide.
Now, let’s say the player finishes playing with their puzzle and walks out onto a balcony. We reveal that they’re at the top of a tall tower, looking over some woodland.
Here, their client only needs low fidelity updates for objects they can see but not interact with. The developer can set more distant environments to have lower fidelity updates for a large set of entity components — so everything that should be visible is, but its canonical position and relevant status (health, etc) is updated less frequently.
You could also do other interesting things with this. For example, when a player equips a weapon, you could set this to trigger the player client to start receiving updates about the health of nearby creatures. This could even be a dynamic change, added to the Runtime whilst the game was live — something that only SpatialOS allows.
Distant but relevant.
Now our player finishes admiring the scenery and walks around the tower’s top, revealing that it’s a lighthouse, overlooking the ocean. They walk over to a telescope fixed to the railing and scan the distant sea, looking at ships, mermaids, islands and seagulls. Sailors on one ship spot the telltale glint of the spyglass, and wave at the lighthouse. The player sees them and waves back.
Using our previous Runtime, this example would have been prohibitively resource-hungry and impossible without very clever design — players would need to have interest in every chunk, not only in the direction of their view but also in a large cube extending equally all around themselves.
With Query-Based Interest, the developer can allow players to not only see distant objects but also have them interact so that the distant sailor’s interest also extends to the glinting telescope.
In more violent games, one can imagine a developer using QBI like this to build sniper rifle or archery functionality over long distances, or in situations where the player needs high fidelity updates at distance, but without needing any updates on the intervening space.
Ideally, this would be done as an extended cuboid, so the player’s view could be blocked by intervening objects, but in this case (where the player is high enough that objects can’t intervene) a distant circle could also do the job.
Universal relevance.
Now our player shifts their view up to the horizon and is met with a surprise. The distant sky brightens as a tiny, very distant island erupts into a volcano, and starts throwing rocks and pumice into the air. As smoke and ash fill the sky, it gets dark and cold, fast.
Objects like this are relevant to everyone in the simulation — in a traditional game, the developer would have to find some way of working around or faking this. Here, the client’s interest would be defined by a very large radius, very low fidelity query. This could also be used for objects like mountains (to block lines of sight and fire), large visible events (like thunderstorms or nuclear strikes), or simply for key data, like the location of a control point.
Non-spatial data queries
The player, terrified as rocks start to rain down from the sky, heads back into the lighthouse to warn their friend — but they’ve left their room and they’re not responding to in-game messages. Have they logged off? The player goes into their guild menu and looks at their friend’s data — they’re online and still in the same area as them.
Here a guild is treated as a special QBI data query that’s not linked to any location. The game logic here has medium fidelity updates over a set of entities that could be anywhere in the game world, defined by the game logic and design for a particular set of their components — rank, level, location, and whether they’re online, say. It might also list metadata about the world, like the guild’s wealth, player hierarchies, and leaderboards.
The player pulls up their mini-map to find them. To save on bandwidth, the mini-map only takes updates from a small set of components on each player and NPC entity — faction and position, say — in a medium radius around the player, but updates both regularly.
This tells the player that their friend is motionless at the bottom of the tower. They add them to a team, to see their health. Like the guild, a team is defined by game logic to have a limited selection of rapidly-changing components on a small set of entities, but they’re updated more quickly.
The player quickly sees that their friend is injured and unconscious, which means their in-game communications have been disabled by design. And their health is dropping quickly.
Stealth and anti-cheating
The player rushes downstairs to heal their friend. When they get there, they see the problem. An enemy player fleeing the volcano has entered the area, attacked their friend and knocked them out, and is still standing over them. The player goes into a stealth mode to get close to their friend.
Now, for the enemy player, the original player has been excluded from interest — they don’t feature in their client-side high-fidelity local game logic whilst they’re in stealth. This is to prevent the other player cheating by hacking his client — the client doesn’t have the information and can’t request it, so hacking it would be of no use.
Moving between areas
Whilst in stealth, the player quietly casts a town portal spell, to get their injured friend back to a safe place. Once the portal is summoned, they peer into it and see that the entities there are all passive and friendly.
Here, we have something like the telescope example before, but where the player has interest over a small area anywhere in the world. The summoning time allows the player client to preload the entities, components and local assets for the new area. When they’re looking through the portal, the player receives medium fidelity updates about entities in the area, enabling them to interact in a minimal fashion. Developers could make vision through this portal two-way or one-way, or restrict which components are relevant, to further reduce load.
The player pulls their wounded friend through the portal, before shutting it. Now they can heal them in peace.
QBI and the future
To reiterate, this is where we’re heading with our QBI technology — some of these designs are possible today, others will be possible in the future.
If you want to start experimenting today, you can sign up for SpatialOS now. We’ll be releasing the alpha for our QBI system soon.
