Sign in to follow this  

how to handle Immensely large multiplayer worlds?

This topic is 418 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

The most common practice that I read about for overcoming floating point precision in video games with large worlds is by dividing the world into cells and load it with player's position and shift origin of objects with respect to player.

 

However this seems to be only valid for single-player games. As soon as you change to multiplayer with authoritative server scenario a lot of anomalies arises.

Since a authoritative server has to keep track of all of the world its not possible to base the origin off a single player

 

For a object that is halfway through two or more cell's co-ordinate system. which cell's part should it be ? and how should it react to it?

 

There seems to be extremely little to no information about supporting such worlds for multiplayer which are larger than what a common origin can support with enough precision.

 

I am working on UE4 so the common bottlenecks I see are physX being single precision and modern GPUs being feasibly performant only on single precision vertex data. 

 

Can anyone shed some light on the topic ? I am all in to learn it if its possible on current technology 

Edited by Commander Shepard

Share this post


Link to post
Share on other sites
Why not use a 64 bit integer for coordinates.

You could measure the game world in millimetres and still have a game world light years across in real terms, without overflowing the variables.

I really don't see why there would be issues segregating the world into blocks though.

What theoretical issues do you envisage? the physx thing is a non starter as you wouldn't run full physics on anything so far away you couldn't see it anyway, similarly a server wouldn't need full physx on everything, right?

Share this post


Link to post
Share on other sites

If you really want to use relative coordinates in a continious world, you could look at how Dungeon Siege did it in the early 2000's: 

 

http:/gamedevs.org/uploads/the-continuous-world-of-dungeon-siege.pdf

http://scottbilas.com/files/2003/gdc_san_jose/continuous_world_paper.pdf

 

 

But that's kind of an unusual situation. Most multiplayer games with big maps get by just fine by dividing the world into regions and handling boundary issues. (One way: do the calculations based on the coordinates of the originating object's region. If the regions are small enough to fit two into the valid space, and no effect can cross more than a region-width distance, it'll work just fine.)

 

Or, if you really want to include both small rocks and massive stars in the same coordinate system, you can go 64-bit, like braindigitalis suggested. Elite: Dangerous switched to 64-bit only when they added planet landing, as an example.

 

I think, though, that you might be under the misperception that everything in a video game needs to be simulated at full fidelity all the time. Especially when it comes to graphics, that's seldom attempted. For example, you'll probably never need to use more precision on the GPU for distance, because once you get past a certain distance it's probably cheaper to just render a sky sphere. Elite: Dangerous does this with its galaxy: the backgrounds are created from a model of the galaxy in a different coordinate system. This is pretty standard in FPS engines, too. 

Edited by ikarth

Share this post


Link to post
Share on other sites

Why not use a 64 bit integer for coordinates.

You could measure the game world in millimetres and still have a game world light years across in real terms, without overflowing the variables.

I really don't see why there would be issues segregating the world into blocks though.

What theoretical issues do you envisage? the physx thing is a non starter as you wouldn't run full physics on anything so far away you couldn't see it anyway, similarly a server wouldn't need full physx on everything, right?

 

in case you missed it I limited by the following:
 

I am working on UE4 so the common bottlenecks I see are physX being single precision and modern GPUs being feasibly performant only on single precision vertex data. 

 

 

As such changing the number systems raises two large problems:

1. Engine code needs to be changed extensively

2. Code performance would degrade due to larger bandwidth usage and in translating double to float for GPU

 

 

There would be issues segregating the world into blocks because of the following :

 

1. Unlike single-player games you do not have a single player reference you can have for origin shifting,Two players might be in completely different blocks at the same time , this would mean both blocks should be processed in the same level tick now without changing precision how would you keep one block away from the other without losing it's positional data (float would become in comprehensible after a limit)

 

2. Since block origins cannot move, when an object is crossing over from one cell to another how would you determine which cell's origin should be used for processing its position,physics and rendering ?

Share this post


Link to post
Share on other sites

If you really want to use relative coordinates in a continious world, you could look at how Dungeon Siege did it in the early 2000's: 

 

http:/gamedevs.org/uploads/the-continuous-world-of-dungeon-siege.pdf

http://scottbilas.com/files/2003/gdc_san_jose/continuous_world_paper.pdf

 

 

But that's kind of an unusual situation. Most multiplayer games with big maps get by just fine by dividing the world into regions and handling boundary issues. (One way: do the calculations based on the coordinates of the originating object's region. If the regions are small enough to fit two into the valid space, and no effect can cross more than a region-width distance, it'll work just fine.)

 

Or, if you really want to include both small rocks and massive stars in the same coordinate system, you can go 64-bit, like braindigitalis suggested. Elite: Dangerous switched to 64-bit only when they added planet landing, as an example.

 

I think, though, that you might be under the misperception that everything in a video game needs to be simulated at full fidelity all the time. Especially when it comes to graphics, that's seldom attempted. For example, you'll probably never need to use more precision on the GPU for distance, because once you get past a certain distance it's probably cheaper to just render a sky sphere. Elite: Dangerous does this with its galaxy: the backgrounds are created from a model of the galaxy in a different coordinate system. This is pretty standard in FPS engines, too. 

Nope I'm not about the visual effects here, My game is a space sim where I want the player to be able to fly at actual tremendous speeds of a jet aircraft (~1000 Kmph) at this speed the world space re-presentable by floats would run out in a few seconds. 

 

Most multiplayer games with big maps get by just fine by dividing the world into regions and handling boundary issues.

 

Cant find any details on any specific implementation of that when the situation is multiplayer , so far 100% of search results have pointed to how to handle that in single player which is comparatively way easier. (unity MMO fanboys posts, you know that's frustating)

 

only now am I got the dungeon siege details about multiplayer so this might be the first on point result I got , but you say that's an unusual case, so can you please direct me to a resource or research paper on the usual case?.

Edited by Commander Shepard

Share this post


Link to post
Share on other sites

 the physx thing is a non starter as you wouldn't run full physics on anything so far away you couldn't see it anyway, similarly a server wouldn't need full physx on everything, right?

Its not about what you can see or not , its about what exists on server, physics is not just decorative but say vehicle physics .

 

Like I said everyone misses the point , ITS MULTIPLAYER not single player, so even if one player cannot see it server still need to keep track of it since physics is part of gameplay and not decoration

Share this post


Link to post
Share on other sites

The same basic logic applies to both Singleplayer and multiplayer, the game engine also doesn't matter much in the logic.

 

You need to create an asset loader/unloader, split the map into chunks, create a way for servers to talk about near chunks, and allow players to pass through different chunks.

 

Chunks with no players can be unloaded.

Share this post


Link to post
Share on other sites

Like I said everyone misses the point , ITS MULTIPLAYER not single player, so even if one player cannot see it server still need to keep track of it
 

 

The things that exist on the server are different than the things that exist on the client.

 

There is nothing preventing you from using fixed point math in one representation --- as discussed with the world as a fixed point 64-bit integer --- and also having a floating point representation used for your client game engine.

 

The most common practice that I read about for overcoming floating point precision in video games with large worlds is by dividing the world into cells and load it with player's position and shift origin of objects with respect to player.

 

Note that this is extremely common because it is very effective.

 

Floating point works well for most games, assuming a meter scale, up to about a 4 km value from center. That's +/- 4km in x and in y, or about 64 square kilometers, or about 25 square miles.  That's an enormous area.

 

Occasionally, perhaps after you've traveled a kilometer or two, or a mile or so, you update the world so you're in a new center location.

 

 

Even for large worlds it is rare for RPG-style games to cover more distance than that in a single region.   WoW is currently on the order of 60 square miles of actual content. Most of the older areas are vacant ghost-towns. Skyrim and Dragon Age Inquisition are both on the order of 20 square miles of content. GTA 5 covered about 100 square miles, but the vast majority of it was fake/duplicate buildings. It was probably around 2-3 square miles of actual modeled stuff plus about 10 miles of modeled roadway segments.

Share this post


Link to post
Share on other sites

The same basic logic applies to both Singleplayer and multiplayer, the game engine also doesn't matter much in the logic.

 

You need to create an asset loader/unloader, split the map into chunks, create a way for servers to talk about near chunks, and allow players to pass through different chunks.

 

Chunks with no players can be unloaded.

Please no , you are completely missing the point . its not about loading unloading things , its about overcoming the location issues with multiple users on the server.


 

 

There is nothing preventing you from using fixed point math in one representation --- as discussed with the world as a fixed point 64-bit integer --- and also having a floating point representation used for your client game engine.

 

 

As discussed earlier it still means a major rewrite of the game engine and the physics engine add to that the loss of performance for using a different number system than the code was optimised for initially

 

Finally I repeat again , I have no issues with understanding how cell division and origin shifting works in single player, but the moment you add two players on the server all hell breaks loose. please read the question again for exact problems that would appear when applying this cell division logic on server

Edited by Commander Shepard

Share this post


Link to post
Share on other sites

Please no , you are completely missing the point . its not about loading unloading things , its about overcoming the location issues with multiple users on the server.

 

Each chunk has it's own centered coordinate that's used to do calculations, so that becomes a non-issue. 

Share this post


Link to post
Share on other sites

I think the issue you're having is communicating why you think multiplayer makes a significant difference here. It shouldn't. We're talking (basically) about a system where you chunk up the world and give each chunk its own local coordinate system. Everything in those chunks, including players, is tracked by a reference to its chunk ID and a local position within that chunk. It works just as well with one bullet in a chunk as it does a hundred bullets in a chunk, and it similarly works as well with one player as with a hundred players.

 

Where specifically do you see this falling apart with more than one player? Is it in this scenario below?

 

now without changing precision how would you keep one block away from the other without losing it's positional data (float would become in comprehensible after a limit)

 

 

 

What do you mean by "keep one block away from the other without losing its positional data?" They're separate chunks of the world with separate sets of objects (including potentially players) and don't need to interact until a chunk detects that an object is leaving its boundaries. At that point it figured out what chunk the object is going into and hands the object's current state over to that chunk. (As one possible example of how to handle the problem.)

Edited by Josh Petrie

Share this post


Link to post
Share on other sites

I think the issue you're having is communicating why you think multiplayer makes a significant difference here. It shouldn't. We're talking (basically) about a system where you chunk up the world and give each chunk its own local coordinate system. Everything in those chunks, including players, is tracked by a reference to its chunk ID and a local position within that chunk. It works just as well with one bullet in a chunk as it does a hundred bullets in a chunk, and it similarly works as well with one player as with a hundred players.

 

Where specifically do you see this falling apart with more than one player? Is it in this scenario below?

 

now without changing precision how would you keep one block away from the other without losing it's positional data (float would become in comprehensible after a limit)

 

 

 

What do you mean by "keep one block away from the other without losing its positional data?" They're separate chunks of the world with separate sets of objects (including potentially players) and don't need to interact until a chunk detects that an object is leaving its boundaries. At that point it figured out what chunk the object is going into and hands the object's current state over to that chunk. (As one possible example of how to handle the problem.)

oh we meet again! pleasant surprise

hmm I think , I might've just understood what you meant on SE. just now I think .

lol thanks mate. I'll give it a try this week and come back to you. possibly only gonna run into implementation kinks and no problems with the actual logic

Edited by Commander Shepard

Share this post


Link to post
Share on other sites

I think the issue you're having is communicating why you think multiplayer makes a significant difference here. It shouldn't. We're talking (basically) about a system where you chunk up the world and give each chunk its own local coordinate system. Everything in those chunks, including players, is tracked by a reference to its chunk ID and a local position within that chunk. It works just as well with one bullet in a chunk as it does a hundred bullets in a chunk, and it similarly works as well with one player as with a hundred players.

 

You shouldn't have to rewrite ue4 to do this either. UE4 has support for large worlds since early version 4, and has chunked loading, streaming of assets, and works well even with multiple players with absolutely [b]huge[/b] worlds. If you haven't already, read the section on open world tools, and how they relate to multiplayer and replication.

 

You'll probably need to create a separate authoritative server, not written in UE4, and have your players clients talk to it. This would make sense, as otherwise the 'host' can cheat, and the chunks would have to be loaded that all players are in - if you have lots of players, that's lots of chunks, lots of ram.

 

Hope this helps!

Share this post


Link to post
Share on other sites

 

You'll probably need to create a separate authoritative server, not written in UE4, and have your players clients talk to it. 

 

Well that's essentially writing entire UE4 engine module, since Ue4 server is actually same as the client game just with authority over the decisions of game rules.

 

Trust me I've been using UE4 for 2 years now and I know about its level streaming and world composition features, they are indeed cell division method that work with origin rebasing but both are supported for single player only right now. The missing multiplayer support for origin rebasing should give you a good idea of the troubles it takes to implement with handling  of edge cases being the worst contender

 

This is the reason I was head hunting so desperately about large multiplayer worlds, if you search UE4 forums and answerhub you'll see it as frequently being mentioned and the devs replying that they'll add it at a later stage (never) .

Edited by Commander Shepard

Share this post


Link to post
Share on other sites

I think the issue you're having is communicating why you think multiplayer makes a significant difference here. It shouldn't. We're talking (basically) about a system where you chunk up the world and give each chunk its own local coordinate system. Everything in those chunks, including players, is tracked by a reference to its chunk ID and a local position within that chunk. It works just as well with one bullet in a chunk as it does a hundred bullets in a chunk, and it similarly works as well with one player as with a hundred players.

 

Where specifically do you see this falling apart with more than one player? Is it in this scenario below?

 

now without changing precision how would you keep one block away from the other without losing it's positional data (float would become in comprehensible after a limit)

 

 

 

What do you mean by "keep one block away from the other without losing its positional data?" They're separate chunks of the world with separate sets of objects (including potentially players) and don't need to interact until a chunk detects that an object is leaving its boundaries. At that point it figured out what chunk the object is going into and hands the object's current state over to that chunk. (As one possible example of how to handle the problem.)

Ok I think now I know whats stumping me ,

 

When an object is at edge of grid 1 but still large enough so that part of it goes into grid 2 and then it hits an object in grid 2 , as such how would you handle the physics for physics engine? because for physics engine the objects needs to be tied to the same origin.

 

can someone explain this?

Share this post


Link to post
Share on other sites
say you drive through the edge into another / multiple others and crash you need to do the physics for all grids then in this case take the smallest change in all 3 directions as a collision has been made. That or create a mini grid for the object do the physics and then apply result to the object

Share this post


Link to post
Share on other sites

This topic is 418 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this