My understanding is that their twist on the problem is some kind of dynamic sharding of game entities across a cluster of servers. Different games seem to try to deal with this in different ways:
- WoW - Several servers hosting copies of the main game world, dedicated party servers for instances
- Second Life - A server maps to a specific volumetric "box" that is estimated to be able to handle whatever activity and whatever entities end up in that box
- Eve - A server maps to a star system, local game time can slow down to accommodate more activity
My understanding is that these guys do something else, where they determine sets of entities (players, NPCs and non-player entities) that are likely to interact and shard off the controlling logic to a server. As the world-state changes, the clustering and mapping of entity groups to servers changes and they have some kind of way to move likely interacting clusters of entities seamlessly within the infrastructure.
This has the possibility of supporting huge persistent game worlds with tens of thousands of players at a time without the kinds of ill effects we see with the other approaches.
Interesting, so I guess this still limits the number of entities that can interact with each other on one server but allows for much more non-interacting entities spread out over a large world. But couldn't then lots of players (maybe by accident) meet in one spot and then slow that server down?
We deal with such a situation through the fact that SpatialOS dynamically scales the zones that each game engine is responsible for. So if you have many players gathering in the same reduced area then there will actually be multiple game engines allocated to that specific zone and extra engines might even be started if the load requires it. This also works in reverse so that if your player density falls drastically and a single game engine would suffice for your entire world you will only have one running, so you always have the right amount of resources at your disposal.
Such game engines are what is referred to as workers in SpatialOS (https://spatialos.improbable.io/docs/reference/10.3/getting-...) and workers can be of many types: game engines like Unreal or Unity to manage the physics of the simulation, custom workers based on one of the language SDKs that implement AI-like functions, or any other behaviour you want to put in your world: it's entirely up to you to take this as far as you like.
How does this handle a load too large for a single server in an extremely small area? Say, the Halloween War in Eve or just a bunch of morons - say 10k people - gather within a single small valley in a game?
Sure, you can subdivide it as small as you want, but that just increases the overhead by requiring the servers to communicate more. But even if the servers can figure it out, what the client sees seems like a hard problem too.
To answer eximius. In your valley battle example there would be multiple game engines handling the valley.
Whereas it is entirely true that you can always find a counter-example that would break a given technology, troymc is absolutely right in the fact that those counter-examples still leave an overwhelming majority of use-cases that we can handle perfectly well with our approach.
I don't mean to disparage the technology, but I disagree with that my examples are unrealistic. I think people would love large scale battles like that.
No problem. You should definitely ask such questions. If you want to dive into the technicalities, see what people are already doing with SpatialOS and ask your own questions I really recommend having a look at the forums (https://forums.improbable.io).
That said, my previous response was actually targeting your example as being a use-case that falls into the 'realistic' category that we want to address with SpatialOS.
Again, I am not suggesting that you can and should pile-up 1000 players onto 10 square meters, but if you take care when defining your world's characteristics (SpatialOS's entity & components) you will be able to scale up your player density in your battle scenario to a level that significantly exceeds anything that you could achieve with any existing monolithic game server and for a fraction of the trouble as you do not really have to deal with any of the usual networking issues because SpatialOS takes care of that.
This sounds exciting for large multiplayer games. Are there any games coming out soon that you can share with us that use your technology? (Please be Destiny 2!)
I honestly have no idea. Clearly given the number of smart people and amount of money being thrown at the problem (without being able to produce a real seamless massive persistent on-line world without compromises) this is very hard.
I also wonder how it handles very large entities that might span across clusters (say a large spaceship with thousands of entities spread across multiple decks and in different area). Since all of those things are entities in a sense, and there might be many ships, how does it handle this?
No idea, but the fact that this can be asked at all is pretty interesting.
> Clearly given the number of smart people and amount of money being thrown at the problem (without being able to produce a real seamless massive persistent on-line world without compromises) this is very hard.
It's just not worth it. The technical back-end challenge isn't the hard part here, it's the game design. WoW with 10,000 players idling in Orgrimmar isn't fun. WoW with 100 players in a single dungeon isn't fun either, for that matter.
Do those simulations need to be real time and massively multiplayer?
I don't see the need for this tech in the high fidelity city simulation cited in the linked article: that would much easier to implement as an offline simulation.
Training seems like the most likely usage: eg. disaster response or large scale military scenarios.
I have to agree with the earlier poster that tech is not the limiting factor for massively multiplayer games.
No the simulations don't have to be real time or massively multiplayer. A simulation has no players at all so I'm not sure how it could be massively multiplayer.
It would most likely be used to test infrastructure or policy decisions. For example, what happens to your traffic in your city if you add this bus route, or how would a contagious bioweapon spread under certain conditions.
If you don't need real time then why use improbable?
If you want to simulate a new bus route then run an offline simulation using whatever tools you like with as much complexity as you like.
In fact you'd likely want to run your simulation much faster than real time to answer specific questions quickly, like finding traffic or passenger hotspots.
I doubt you'd want to sit there watching virtual buses driving around a 3d city, but rather quickly see heat maps change as you play with parameters.
- WoW - Several servers hosting copies of the main game world, dedicated party servers for instances
- Second Life - A server maps to a specific volumetric "box" that is estimated to be able to handle whatever activity and whatever entities end up in that box
- Eve - A server maps to a star system, local game time can slow down to accommodate more activity
My understanding is that these guys do something else, where they determine sets of entities (players, NPCs and non-player entities) that are likely to interact and shard off the controlling logic to a server. As the world-state changes, the clustering and mapping of entity groups to servers changes and they have some kind of way to move likely interacting clusters of entities seamlessly within the infrastructure.
This has the possibility of supporting huge persistent game worlds with tens of thousands of players at a time without the kinds of ill effects we see with the other approaches.