Issues with a seamless world

origamii · 2014-03-12T01:15:37

Hi all,I've been planning to start running some tests (for hardware/bandwidth usage) to determine the feasibility of my game design since it is multiplayer (100-200+ players depending on various factors and the server's hardware), and I want to use authoritative servers. The engine I'm using is Unity and I am thinking of using uLink for the networking aspect.Anyway I want the game world to be decently large, and seamless. I've been doing a lot of research on this (including in regards to the floating point issues, etc) and have been working out some solutions before I get to coding, but I have reached a sort of hitch.The solution I have at the moment is a general method that breaks the world up into chunks that exist in a database only and are pulled up on demand as a player gets near them. This could be small chunks near the player or larger chunks.With uLink, each server instance should be able to handle a 10km2 or smaller area (depending on the physics tests I run for FP issues). This will act as a container for a number of chunks inside. Multiple containers can potentially exist in the same server instance if they are on different physics layers.The issue is, for example, if one player is in chunk 57 in instance (or layer) A and at the edge of instance A's container, and another player is in chunk 58 in instance B and at the edge of instance B's container and they shoot each other, how is it handled?The idea of having your projectiles/lasers/whatever hit the edge of your chunk, and then having them be recreated in the other chunk with their state intact seems far from optimal, if even feasible for fluid gameplay.I did think about dynamically grouping players that come near each other into their own container to avoid this altogether, but even then this issue can arise depending on the layout of the players. One nasty example of this is if there is a chain of players spread out, each ~1-2km apart, the rules for grouping would basically crumble and then it goes back to the cross-boundary shooting issue again. Actually with any case where there are a number of players spread out over an area that is larger than 10km2 and are in decent range of each other, this becomes an issue.If anyone has any thoughts on this, I would greatly appreciate it.TL;DR - In a seamless universe that is divided into isolated containers with various chunks in each container, how do you handle the issue of shooting into an adjacent chunk that happens to be in another container (another container could be on a separate server instance even though in the world they are adjacent).

Networking and Multiplayer Programming

Started by origamii February 21, 2014 02:12 AM

10 comments, last by Norman Barrows 10 years, 1 month ago

hplus0603

11,916

March 10, 2014 09:36 PM

Right. Having integrated with a variety of DIS and HLA systems, I'm familiar with simulations where blue death is a serious thing.
This is gamedev.net, though :-)

binding a new texture is slowest

In my experience, binding a new shader with a different input stream signature is more expensive than binding a texture with the same size and format as the previous texture.
But, probably a different forum for that discussion :-)

enum Bool { True, False, FileNotFound };

Norman Barrows

7,180

March 12, 2014 01:15 AM

In my experience, binding a new shader with a different input stream signature is more expensive than binding a texture with the same size and format as the previous texture.
But, probably a different forum for that discussion :-)

i have yet to get seriously into shader's - i know! i'm lazy! but i haven't had a desperate need yet. so far, a little alpha blending for clouds and flames, and some 2 stage texture blending for snow cover, along with optimized state changes has gotten me by. as for later versions of directx, i defer to your greater experience. but as you say, a good topic for another forum.

Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php