Sign in to follow this  
freezzo

client/server player info question?

Recommended Posts

freezzo    138
I was curious how to go about setting up the server client relationship such that each client knows where and what to render of other players. I came up with a crude idea, and was curious if this would work(I'm thinking real basic just for tracking purposes, no security/landscape clasping) Basically every x ms, the server broadcasts each players position followed by player information(animation sequence, etc.) The client takes this and checks to see which players are inside of there "view", if they are, display them using the player information sent. This seems like it would be extremely lagging provided a great deal of players were joined. Any ideas?

Share this post


Link to post
Share on other sites
Antheus    2409
Unless you're dealing with very limited applications, transmitting current view data from server usually isn't viable.

Common aproach is for each client to maintain local copy of all or part of objects on server.

When client connects, server sends descriptions of each object within client's range (circle or box of given size). After that, whenever these objects change, client is notified.

Another aproach is to partition your world into sections (similar to how FPS split the scene into polygons). Then you can pre-calculate visibility data for each such polygon (someone standing in a corridor cannot see objects hidden behind a corner).

As clients move through such scene, whenever they change the section they are in, server sends all objects located in potentially visible areas. But, in order to cope with latency, they also send a bit more info, so objects that are not currently visible, but would be visible if client moves to neighboring area.

Final clipping for rendering purposes will of course be done by the client. Doing that on server is not viable and also redundant. These methods merely ensure that server doesn't send too much data that client has no use for.

Share this post


Link to post
Share on other sites
hplus0603    11356
How many players? For 8 players, that'll probably work.

For a "massive" amount of players, you need interest management, where the servers sends, to each player, only those players who are close enough to be "interesting." Additionally, the server should send messages when objects go in/out of scope, to avoid the "dead period" problem.

Share this post


Link to post
Share on other sites
oliii    2196
If you play CS:S, check out the minimap when you are dead and following someone. You will see the player not visible on screen (but visible on the map) 'ping' around every second. The server does a broad culling of what you can see and cannot see, and send updates of non-visible players less often. This is also the cause of some infamous 'teleport' bugs, where you see someone suddenly teleporting into view. This is usually due to packet loss and the server not sending the updates of that player fast enough (update was still in 'slow' mode).

So, to keep it simple, send state of every players to every other players. The bandwidth requirements will be pretty huge (say, for 16 players game, 40 bytes / player * 20 fps * 16 players * 16 player states) -> 204KB / s. That's not counting stuff such as pickups, grenades, ect... This is why peer to peer can be useful, to spread the load over each clients, since each client will be responsible for his own players (and grenades, rockets, projectiles...), the bandwidth requirements then drops to (40 * 20 * 15) = 12KB / s. But obviously, there are other things to consider in a peer to peer game (very open to exploits).

Then if you have a culling system already in place, where you can query the visibility of an entity from a observer/listener, only send states of objects the player can see, or hear. Then the benefits are pretty awesome.

Secondly, you can use a pre-computed huffman compressor, to further reduce the size of the final packets.

On the client side, you will need some interpolation system, to 'smooth' the updates received from the server. The send rate maybe regular, but you will receive updates at an irregular rate, loose packets, or get them out of order. To keep things smooth, the interpolator is usually run 'behind', but around 2 x the update rate. This accounts for packet loss or out of order packets, and make sure you are always interpolating between two received entity states, and rarely extrapolating.

Then the next step is writing a protocol that sends only relevant changes of enttiy states to each players. See the Quake3 networking model for that. Then theoretically, when nothing is moving, the bandwidth requirements will be 0.

So, from 200KB+ / s, the bandwidth can be reduced to between 1% to 10% of that pretty easily.

Share this post


Link to post
Share on other sites
hplus0603    11356
Peer-to-peer does not necessarily help with the bandwidth, because each client will then receive 15 separate updates per tick, instead of one, leading to significantly higher packet overhead. It does help spread the upstream bandwidth requirement out, at the cost of overall bandwidth usage.

Share this post


Link to post
Share on other sites
Afr0m@n    100
This is how the professionals do it (from description of World of Warcraft protocol on non-disclosed wiki):

'Update Fields and Objects

Objects are the most important part of WoW World. Everything that "exists" there is an Object. Example: a bag is "an evolved" Item which is also "an evolved" Object. Same concept applies to almost everything in the game.

I will consider Object and it's inheritors as Classes in my overview. An inheritance tree can be found at: Update Fields.

What does such an architecture give us? Low bandwith usage and an unified method of reporting updates of the specified Objects to the Client. Let's consider a Player surrounded by N number of Objects. Let's now consider that in 300 msec 50% of them have changed some internal states and need to report those changes to Player. If all of them would have sent separate packets for all Updates, it would greatly increase bandwith usage. The concept used in WoW is to Cache all the updates in each object and send those updates once every N msec of time, constructing an SMSG_UPDATE_OBJECT that would contain updates for all Objects surrounding Player. Now, in case the size of the Update Packet is greater than 100 bytes, it would be compressed and encapsulated in SMSG_COMPRESSED_UPDATE_OBJECT. For example a Client can receive a 9Kb packed update packet which decompressed would be of 40Kb size. That is what I call bandwith saving.

Update Packets can also contain info about objects that "entered your cell". It would contain objects' X, Y, Z ... Speed and other similar info.




So, let's see when Player enters a new Cell and the Server decides to notify him about all the Objects in his vecinity:

Server will collect all the data about the Objects about to enter Player's vecinity, selects the important fields for every Object that the Client should know about. Then the Server will contruct a SMSG_UPDATE_OBJECT or SMSG_COMPRESSED_UPDATE_OBJECT with Objects' important fields, position, speeds ... and other things like that ... and will send it to the Client.
Would someone please edit this to elaborate on how field constants and object update bitmasks works?
Client will receive that packet, decode it and start "Spawning" Objects around it ( Note: I'm not using term "Creature" because an Object can be more than just a "Creature" ).
On every change ( e.g. NPC flags, Visible Items ) of the surrounding Objects, the Client will receive an update packet and will do the changes accordingly.
When an Object is out of Player's reach, Server will send an SMSG_DESTROY_OBJECT containing the GUID ot the Object to destroy. The Client will receive the packet and will "remove" the Object from the game'

Share this post


Link to post
Share on other sites

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