Improbable Icon

Ask about worker and main design of Spatial OS


#1

Hello !

I’ve got a little ask about Spatial, and the way we can manage multiple-world/maps.
I read a huge part of the documentation, and asking my-self :

The goal we want to reach for our project, is a semi-mmo game,
meaning we want

  • Regional server
  • “world lobby”, meaning the game is splited into multiple simultaneuous worlds. Each realms can host something as 200-300 players. We can imagine this as “small mmo server”, a bit like rust do, but in bigger size.
  • Persitant Data

For the first point, i think the idea is to see with SpatialOS to have multiple-plan for different region, and allow the client to swap between EU, US… correct ?

Second point is a bit hard, what is the best way to manage “small” instances with spatialOS ? one worker (who is the same as others) by instance ? Or may be it’s better to have ONE big world, and move “instance” in different position and let the boundary ‘isolate’ the network flow ?

See nothing about storing data on a long terme, should we just go with a SQL solution or SpatialOS have it’s own solution ?

Thanks !


#2

Hey there!

SpatialOS’ strength lies in one continuous world. Splitting it up is certainly doable in the same world but I haven’t tried it yet so your mileage may vary; and still: it is one world. So as you said: you would need to put worlds in areas of the larger world.

Regarding persisting information: SpatialOS persists the information of your simulation as long as it is running but you are probably better off writing and reloading persistent information from an SQL Server or from a BAAS such as Playfab or GameSparks


#3

Thanks for the reply,

I’m using Unity,
So how we can manage “big map” with unity ? i mean if spatialOS is designed to do huge and open world, unity is not. What is the solution to deal with this ?


#4

SpatialOS allows you to essentially “stitch together” multiple instances of unity servers to be the back end of your game. So if you wanted a world 4 times wider than Unity could natively handle, you could create a SpatialOS world is that simulated by a grid of 4x4 UnityWorkers. The idea here is that each UnityWorker is only given the information (by SpatialOS) about the part of the world that it is responsible for, so none of them need to simulate more than they are capable of.


#5

Yes, i think i understand this part (and if there is only few people/entities, the load balancing will switch to one big unityWorkers to manage the entire area, i’m right ?)

What i ask is more about unity itself, I know unity have some trouble to manage big openworld, i mean the player should suffer from big FPS issue if we go on it, except with some tricks as plugin of streamable world, or agressive occlusion, etc etc…

The ask is “what is the best way to do this” ?

For our project, we want split area into flying islands (nope, it’s not world adrift clone project =D), i read in the doc we can use multiple unity scene, but the doc talk more about using scene to manage UI part, or menu, not really for “game environnement itself”, what is your advice ?

Thanks

edit : after re-read the doc, yes, clearly, multiple scene is not the “good way” to manage big open world for Spatial/unity


#6

For the load-balancing question, it seems like you are referring to our dynamic loadbalancer. Currently the dynamic loadbalancer always has the same number of workers, but dynamically alters their areas of authority to adapt to how load is geographically distributed throughout your world. This being said the dynamic loadbalancer is still experimental, and in most cases you can do better with smart usage of static loadbalancers. For instance, if your world is made up of islands, depending on how big they are it might make sense to use a point of interest loadbalancer to put one worker on the center of each island.

The rest of your question seems to do with client side performance. There are some factors at play here that aren’t necessarily Unity specific, like client bandwidth. Obviously you don’t want your clients to have to receive updates for everything happening to every entity in the world. To control this, we allow you to configure a radius of entity interest. Your client (and any other worker) will always have the entities it is authoritative checked out. But generally you will also want the client to see other entities around what it is authoritative over. This radius allows you to specify how far the client can see, which means the client won’t receive any updates about anything outside of this radius.

So as an example, in a FPS game, your client will generally only have authority over some components on the player character (like the controls component). Then if you set the entity interest radius to 100, your client will receive component updates for other entities only within that 100 meter range. This is still a somewhat limited solution. We’re aware of that and will have some even better options that we hope to share soon.

As for advice for what you can do now, on the spatial side you can play around with the entity interest range as well as chunk size. Currently, when you check out one thing in a chunk, you get everything in that chunk. So bigger chunks will mean you might be having to send extra stuff, but on the other hand if you are walking back and forth you aren’t going to constantly need to re-check out the whole entity over ahead.

As for Unity’s side, I believe they provide a profiling tool that allows you to view where your performance bottlenecks are, including asset load times. You can use this to figure out if anything is costing you a lot more CPU time than you thought it would/think it should in order to optimize your game. Also the more assets you can store or cache on the client side, the less bandwidth of your clients you will take up, which means you can support a higher entity count overall on your clients.


#7

Thanks for the complet answer, 3 last question and i’m done ! :grinning:

When you mean “run back and forth”, spatialOS don’t have a system as Photon who let load multiple chunk if a player overlap on it ?

A) Imagine the scenario as a player is near the frontere of two chunk A and B. He is on A side, can he receive B informations ? do the raduis of entity interest move with the player or it’s defined area on photonside, like fixed square chunk ?

B) SpatialOS look like a smart solution, but as you host the server part, what happen if improbable have issue or being abandonned and should stop distribuing service ? (it’s an hard question, but important for the perenity of a long term project)

C) If we go on procedural generated island, and we use one worker per island, how instantiate/duplicate a worker ? Imagine we got a worker “island” who hold to manage everything happen to one island, i don’t found on the documentation the way to make instance of him (basically a fork) dynamically. This is possible ?

Thanks a lot !


#8

A) I’m having a little difficulty understanding exactly what you are asking in this question. If I’m not answering the question you meant to ask let me know.

First I should disambiguate between chunks and workers, in case that is a point of confusion. Workers are the things that are doing the computation and simulation, and can have knowledge of entities across many chunks. Chunks are square sections of your world, that are the smallest amount of area you can check out any any given time. In a certain sense, if you think of the world as a hashtable, the chunk would be the key and entities would be the values. If your worker is checking out an entity, it will also check out all other entities in the same chunk.

As for the radius of interest moving with the player. Yes this is how it works. Again if we assume that your client has authority over some component on the player entity, as the player moves that radius will define a circle around the player. The client will then be granted read access to any entities in any chunk that is contained within that circle. Often the chunk size is much smaller than the interest radius, so a client will have many chunks in it’s checkout radius at any given time.

B) From a timeline side, we’re happy to say that we have a lot of runway, especially since last year’s $502 million investment from SoftBank. In addition to that, there are an increasing number of important studios that we have partnered with to make games. We would hope that this demonstrates our reliability as a service provider. However, if you have more serious concerns about this, you can talk to us privately and we can go through what backup plans that there are in place.

C) Here are the docs for the point of interest loadbalancer. All that you need to do is write your worker code once, and then spatial and the loadbalancer take care of spinning up copies of your worker and placing them where you want them to be. Honestly the easiest way to understand this is to try it out yourself. If you haven’t already, check out the pirates tutorial. If you want to see what it’s like to configure the workers, then try modifying how many workers spawn in the default_launch.json file and then use the SpatialOS inspector tool to see what your changes did.

Here’s an example of what that might look like with two workers. It’s a bit complicated with the overlap here. Essentially the solid areas are where each worker has authority, whereas the areas with the dotted line shows the boundaries of the worker’s read access (which is defined by it’s entity interest radius). You can also see that in the areas where there are no entities, no worker is authoritative, and this will change automatically as entities move around. Furthermore on your final question, these workers are just copies of each other, that spatial is automatically starts up when you launch your deployment.


#9

Thanks a lot, you cover all my question and more,
Sorry for the bad english, it’s not my native language can be tricky for me sometime :wink:

I already do tutorial, en push further with my own test/and try. Thanks for this wonderfull and fast support :slight_smile: