imagine a massive multiplayer world, where the player should see other players in a certain radius from his position. (world of warcraft) how are the positions update in terms of messages? will the server send the new positions to the player in regular intervals? will the server send new positions only if someone moves? or something completely different? also, does anyone know how the movement of the player is usually handled in a 3D world? this is what i figured out: C2S i start walking in direction d1. S2C sends to all players in the radius the new direction. C2S i am at position p and change direction to d2. S2S regularly the new direction and position is sent to all players in the radius. C2S i stop at position p2. S2C sends all players in radius final position p2.

I think with every packet your actions (keys down) is sent along with a timestamp. This to players who are close to you. I would assume the update frequenzy is increased to nearby players. If they are very far away you only seem to get their position every second.

Little now and then the server also sends a ping message with the stream. If you are idle I would assume your client would send very little data to the server, still receiving updates of others like normal.

So I would assume you are mostly right, not sure if I answered your question, I do not know for sure.

Radius calculated visibility is often not the basis for update inclusion, and is left to the client.

Typically a zone is divided into sub-sections which allow much cruder calculations for determining whether or not something is visible to other nearby users. This is very similar to a room / area in a MUD. Entering or leaving these areas triggers a message that an entity has become visible, what it looks like, what it's doing. Bear in mind that this can lead to wall hacks, spawn detectors and numerous other third party apps listening in to any extraneous data you send. The most robust method is to calculate all visibility on the server, by means of a DPVS system. Robust, but prohibitively slow.

Figuring out a visibility system that works for you is a balancing act between the requirements of your game, speed (since many calculations will lower the number of players you can support), and considerations against exploits (again, dependent on the design of your game). For most games, a scenegraph style hierarchy works quite well, if there is a fine enough granularity. The fixed heirarchy also allows potentially visible (more correctly potentially *relevant*) sets to be calculated quickly, and cached on a per-node basis. I've rambled on about this in more detail in other threads (check my profile).

Movement messages will also be different depending on the game - a click to walk here (like diablo / runescape) will send messages very like the ones you describe. A tile based game might send different messages, perhaps constraining movement to a number of tiles in one of 8 directions. An FPS may operate a different scheme entirely.

thank you for your replies.

wave: if i understood you correctly, you mean that when i walk around the position is sent to the server and then distributed to the players near me depending on their distance? that sounds reasonable.

winterdyne: when you say "per-node basis", you mean per scenegraph node? in my game there is not really a PVS other than the fixed camera viewport which is of course a rectangle. :-)

the game i am talking about is not tilebased. its like world of warcraft, everquest, where you can walk around seamlessly in a huge (really huge) world. that means dividing the world into zones is not really an option, since, if a user approaches the border of a zone he wont see players in the nearby zone. and if he moves to the nearby zone, the players in that zone would suddenly pop up while the ones in the "old" zone would suddenly disappear.

Yes, per scenegraph node.

Of course a large seamless world is divisible into zones without popping.

It's simply an application of old-skool tilescroller techniques. You preload surrounding areas as players traverse the world. Updates occurring within the areas surrounding the one a player is in are potentially visible as far as more precise calculations are concerned - a tiered scenegraph is ideal for narrowing the search field, although quadtree and octree structures can also prove useful.

In some situations, where an individual machine is responsible for updates to clients of each zone, very efficient inter-server communication is required. Each neighbouring zone server then informs its clients.

If you're planning a large playing environment game, you MUST implement a suitable PVS system. However, on the server side, you have to consider that the player can in all liklihood turn around much faster than the network update, so line-of-sight or frustum tests have to be replaced with radial tests (at a fine level - use simple AABB tests to narrow your search field before doing expensive radial tests).

Something like this:

Players within duel range, send updates 5 times/sec with their movement and actions. When the player do a lot of actions (Ex. move rapidly ) then you send and receive more packets, perhaps up to 10 packets/sec or more, depending on how many players versus how action origented the game is.

Players outside duel range within the same zone, send position updates 1-2 time/sec. Also applies to party members even if they are outside the zone.

Players who are not in your zone are only sent if they are close to the zone you are in and you are close to their end of the zone. Those players on your friendslist and guild are updated each time they change zone.

thank you all for your answers!

this already helps me a lot, now in numbers, what do you suggest:

how many players should be per zone? so that i can estimate the physical size of the zone. for starting, players should only be able to move around, talk to players nearby and maybe exchange items in their inventorys.

how many zones can one server cluster handle? i know this is hard to guess, but just that i can imagine something. :)

The number of players per zone, and the number of zones per cluster node and cluster are 90% dependent on the mechanics of your game. It's like the vertex throughput on a graphics card - without complex transformations on the vertices you can pump more through. If there's a lot of activity (like for an FPS) you can expect to handle a much lower player count per cluster node (since it has to blast out more traffic, and perform many more calculations). With a slower pace of play comes a larger potential player base. Allowing large congregations in a single network collation zone generally will lag up the area (since updates are sent to more recipients). Some games disallow movement to an area which already has a high population.

A good starting point for calculating the zone size is the visible area of the game world (visual range) extended by the possible movement range in the time it takes to preload the next zones. Personally, though I dislike the association of specific, fixed size physical areas with update zones, or server authority, preferring the more flexible scenegraph hierarchy approach for general purposes. A fixed size division is however useful for outdoor areas and large terrains.

Don't think of zones as collections of players (ie I have 4 zones, each zone can handle 100 players). They are a (very) simple abstraction to allow a much larger game world to be divided amongst a number of processes. That they are often used for collating network updates is a beside - the actual networking collation 'zone' might be different to the zone definition used to govern server authority.

All this said, it's fairly futile to consider player load balancing until your networking code is set up and stress-testable. You can then factor in your packet overhead with an estimated average amount of game-specific traffic, and pile on automated processes to generate the traffic - see what happens. It's actually fairly unlikely that your network pipe will be the bottleneck or limiting factor if complex calculations (3d collision etc) are to be done per client. Without knowing every intricacy of what is calculated on your server, it's not possible to be any more specific.

thanks again!

i got the following idea now: as i have said, the camera is fixed, so the possible visible set is easily predictable. it looks a bit like diablo with a kind of top down look. only there is one huge world and not several instances of dungeons, so i will have to divide the huge world into zones. since the camera is fixed the size of a zone could be a bit larger than the viewport, so i will always see all surrounding zones. is this a good idea?

thanks!

That's pretty much the right method - although you have to bear in mind the movement rate of your characters in deciding the network update zone size. Some types of message (chat, shouts) may have a larger-than-visual-range area of effect in your design, so you also need to consider these in determining an update zone size. Within in an update zone, you can perform more precise calculations to determine what to send.

So long as you bear in mind that the purpose of the network zone is to cull non-essential traffic quickly, you should arrive at a system that works for your design.