Large open and sparse world

strich

Hi,

I've been doing a lot of heavy research recently on whether it is possible to develop the following game type in Unity without too much custom coding:
Players per world: 50-200.
Active NPCs per world: 100-1000.
World size: 200-250km2.
The kind of game we're developing is a fairly massive multiplayer hunting/survival FPS game. So the key components to it are:
- Persistent world size - World needs to be quite large and entirely seamless. As players will have various zoomable tools the area of vision must be able to go reasonably far (500-2000 meters?).
- Physics - We need to be able to simulate physics server-side across the world for various basic physics interactions (rigid body, realistic bullet physics, vehicles).

So far my research has found that our requirements aren't too bad, however they appear to be just over that threshold that make things pretty difficult. The main problem we're facing right now is that due to the size of the world we are predicting that we will run into floating point precision issues when calculating physics further out from the origin point.

I'm wondering if I can get advise on some potential solutions from the community and devs here.

From what I've been able to gather so far it looks like the most prominant solution is to implement a cell-based approach to cutting up the world. However I've found very little documentation on it and how it affects things like LoD, physics, etc. As our server needs to simulate the physics (To avoid hackers) it looks like we need to find some way of running the world chunks in their own instance of unity, with the server subscribing/unsubscribing players to the instances they need. That way physics are isolated to smaller world scales and don't loose precision.

I would love some more discussion around this. Specifically whether Photon is capable of such things and if not the extra work required to make it so.

dreamora

Depends on a single factor only: Can you bake Occlusion Culling for the area or can you make it spread enough that this will never be a topic.

If thats achievable then yes its definitely possible using Unity + Photons opensource MMO layer.

But the persistence is a thing you will need to implement yourself. There is no solution for that in Photon (nor any other networking library that offers similar scoping mechanism to the InterestAreas in the MMO project) and even if it would not work out of the box as each game has different needs.

strich

The bigger problem is simulating physics server-side for such a large world. How can you cut that up so we don't run into floating poitn precision errors?

dreamora

As you want to do it server side, you can use multiple distinct subgrids when handing it over. As you are likely not gonna use Unity but C++ + physx or similar , thats rather easy

strich

Why wouldn't I simply use say a headless Unity instance to simulate the world?

dreamora

You can but you will need to write your code accordingly. But the main problem is the limitations on threading in Unity which might definitely become a problem depending on what you wanted to do.

If you go with unity as simulation node you need to ensure to not load audio and animations and to have code in place that either kicks them from game objects where present or alternatively uses different 'server prefabs'

Headless gets rid of the device bindings related to audio and rendering but not to the heavy hitters under the hood.

Also you would need to structure your world accordingly so the server can load it in in pieces cause if every of these instances that would handle a sector has to load the whole world it aint gonna work.

Also its not that simply to write such a backend within unitys paradigms. Its definitely possible but on average it requires a good level of expertise and it will definitely be no 'out of the box experience'. That being said: that will not exist anyway if you want server side simulations as thats a custom thing that will need a lot of effort.


Question is: whats a large world for you?
up to +- 50k around the 0,0,0 point you are normally somewhat save on the floating point problems (optimally 30k if you can limit it to that), especially when you do not render it anyway. Potentially you do not need multiple distinct unity instances per world which would make it much easier to achieve (which you would always be able with a C++ + physx based one as that can use threading to use the full cpu with all its cores), as multi instance handling will require that you also implement 'instance boundary transitions' etc with all the data transfer and 'server to server firing / interaction' problems you have to solve.