Sign in to follow this  

Sending player status to lots of others

This topic is 4254 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

Hi, I'm wondering what the best way is to get the status of other players in a game. For example, each player can send a package with his current move and position. Normally, I would send that package to the server, and the server broadcasts it to everyone. But now, there are hundreds, maybe thousands of players. However, each player only sees a couple of other players, and its not nessesary to know the status of other people outside their view. In fact, players can walk in different sectors, so the status of players outside their sector is not important at all. So, I was thinking about this: - Each player sends it status to the server (x times per second) - The server calculates the distance with other players for each player (inside a certain sector). - If player A is close enough to player B, A and B will receive each others status via the server This way the client only gets nessesary data, which is only from a few players probably. However, The server still needs to receive and send hundreds/thousands of packages in total, and I'm wondering if the server is capable of doing that. So maybe there are smarter ways? For example, how does a MMorpg update all this stuff? Greetings, Rick

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
The server needs to know everything. It's just the nature of the beast. This is where compression, and deciding how to send your data becomes more important. Make sure to send the server only things that have changed, avoid flooding it with the full client state every frame.

Send the server small input packets with keypresses and controller vectors, and let the server determine absolute state. controller data is nototriously small.

Share this post


Link to post
Share on other sites
Ok, thanks for the tips! Lucikly the game is rather simple, so you don't have to send bullets, explosions, health or whatever. The key input could be 1 byte, maybe 2. But I also think I need to send the actual positions once in a while, otherwise people are starting to walk through walls and stuff like that. Probably I can compress the position as well. Since the world is not that big per sector, I could convert a float coordinate to 16 bit, without too much loss.

If there really are many players online, its probably still gonna be a big pile of data. But I guess companies like Blizzard don't have 1 simple server computer to run the whole thing of course...

Greetings,
Rick

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
you really shouldn't have players send their positions. Thats a huge hole that can be exploited for hacks.

You should simulate movement on the client side, but send the actual control commands to the server, have the server do the colision detection etc, and have the server tell the player where they should be, and have the player's client resolve it's position using the server's response as authorative.

Otherwise you will be vulnerable to warp and speed hacks.

you could do some work on the client side if you want, and send commands to the server like "run pressed - this direction vector"

the server can then simuylate the player runnign in that direction.. it can determine the player's run speed, if they are in a state where they can be allowed to run, etc..

Do you see why the server needs to do this? Otherwise if the client dictates his position, he can perform tasks at times they should not be allowed.


Share this post


Link to post
Share on other sites
I understand your point, but is this accurate enough? For example, if the game runs on 60 frames per seconds, it could receive 60 different key input states. So I need to send the state for each frame, which makes it pretty big packages I think. But of course, I could reduce the control refresh state. And I don't have many buttons to push. But then I also need to be sure everything arrives properly, and how to take care of speed differences at clients?

I agree positions are relative big chunks of data, and are vulnerable to hack. But since I'm not making an action game or something, I don't think it will be hacked. And even if players are cruising around in hyperspeed, well, that's not really a problem for me. I just want to make sure everyone is seeing each other on the right positions.

By the way, how many times would you send a 'status package' per second for proper results? I never did a network game before, so I have no clue what's acceptable.

Thanks for helping again!
Rick

[edit]
Ow wait, clients don't have to calculate positions of course, only receive them from the server, including their own position. That should prevent synchronization problems. However, the player controls might feel to react slow. If I understand you right, this is what happens:
1- player A hits 'move forward' and sends that action to the server
2- server calculates player A's new position and sends it to everyone who needs it. Including player A.
3- Player A receives the new position, and applies it.

But of course, there's a time delay. So player will stand at the new position too late. But therefore there's interpolation of course, to fill the gap.

But how many times should a player sends it controls, and receive new coordinates from the server to get an acceptable result? If it would be 10 times a second for example, the server still has to send lots of data (in case there are many players).

Rick

[Edited by - spek on April 18, 2006 3:06:52 PM]

Share this post


Link to post
Share on other sites
If you're doing this to learn, my advice is: Get it working first; worry about hackers later. You'd be very, very lucky to be in a position where your game is popular enough that someone wants to hack it!

When it comes to servers: yes, the servers need to receive data from all players (N copies of data for N players, per tick), and send data to all players (N*M copies of data for N players who on average see M players, per tick). That's why server scalability is hard and server bandwidth usage is typically more than a cable modem uplink.

Most games solve this problem by running multiple server machines; typically one for each sector.

Note that it's not good enough to not send an update to a player when he can no longer see another player, because the player's machine will then still believe that the entity keeps going the way it was going. You have to either time out after a while on the client end (when you haven't seen any updates), or send an explicit "remove from view" packet from the server when someone goes out of view, or (probably best) do both.

Share this post


Link to post
Share on other sites
spek i agree with you,I think that the player should send his postion every intervall and not only at changes so the server always knows the correct position of a client and clients can interpolate their non local players to that positions.
but the time it has to sent depends on the game type, is it an RPG, a fast paced game? I think you will get the best result after testing.
@hplus0603: you are right, when a player is outside a sector, the server should send a packet informing the client to stop updating that players. When the server detects that a character is in a client's sector, it should send a packet to that client to resume updating (locally) that character.

Share this post


Link to post
Share on other sites
Thank you all!

It's not an fast paced action game, so accuresy is not really a must. But nevertheless, I would like the players to walk on correct positions, without too much lag. I'm reading the Unreal network page now, from the FAQ here. It has some nice tips about interpolation, but again, Unreal was ment for managing only 16, maybe 32 players.

My project is some sort of online chatbox, where players walk in city(which they build themselves, but that's not the issue now). I'm not expecting hunderds of players, but you never know. It's better to code it right from the start, than adjusting the whole thing later because of bad net code that can't handle it anymore.

I did some rough calculations, and came on this. For example, I'm running the stuff with 100 active players:

- Each player will send his controls to the server. I think it can fit into 1 byte, since you can walk only 1 way at a time. But there's also a header that is taking 6 bytes now(but maybe I can reduce that). So, 700 bytes will be send by all players for 1 update (is that called a tick?).

- In case hundred players are all seeing each other (worst case scenario), everyone needs to know the status of each other. So the server has to send 100 status packages. This package include position, and probably some stuff for interpolating. I put the status of all players into 1 package, so there's only 1 header. With the help of packed floats, such a package would be approximately 6 + 100 * 6 = 606 bytes(!). Multiply it with 100 (all players receive this) and the server sends ~59 kb. For only 1 update!

- I think I can reduce those big packages by compressing them (RLE or something?). I have no idea how much I will win, but I guess it helps a lot.

Well, that's a bunch of numbers, and I don't have an idea if these are common. Maybe I'm doing something very wrong and I could do with far less?

Greetings,
Rick

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Here you are assuming that all 100 players in the level are moving at the same time. In reality, when you get a group that big, most of them will be sitting still.

You need to just send delta information

If a player has not moved since the last update.. don't send an update. Each update you don't have to send saves you 600 bytes per frame.

Only send out delta information for things that have changed. Has the player changed his orientation? No? Don't send it!. Has he changed his velocity? No? Don't send it!

Send updates at a much slower rate. Sending updates 4 times a second, with interpolation, is not going to look that bad. it adds a bit of latency, but 250ms is not going to make that much of a difference in a non-twitch game.

scale your update rate based on population.. if there are 100 players in an area, and your bandwidth is being saturated, send less updates.. even 1 update a second is going to convey smooth movement if you interpolate.

Have you ever played warcraft, and been in a very big city, and see people running, and sometimes "snap" back to a position? That is caused by an extremely low update rate. The prediction algorithm is happily moving the player along, and gets an update from the server telling it that the player has stopped. In order to reconcile the difference, the player is snapped back into position.

(If you use interpolation instead of prediciton, this won't happen.. But latency will be added that equals the update rate)




Share this post


Link to post
Share on other sites
If you find your bandwidth getting out of hand, you could rotate the updates, so for example in each frame a third of players were updated and broadcast. While a player has to get instant response for his own movement, he won't notice if those he are interacting with are a bit slow since it's not an action game.

But yeah, basically, you've come across the reason that hosting online games gets expensive. In the end interaction updates are always going to be an x² problem.

Share this post


Link to post
Share on other sites
Ok, I think I know enough to proceed now, thanks!

It might indeed be a good idea to give other players a lower priority, especially when it gets crowded.

@Anonymous Poster
If I ever seen people snapped back to another position? Maybe when I was drunk... Oh wait, you ment Warcraft? Never played it, but I get the idea. Players that aren't moving will not sent updated indeed. And probably this often happens, since people are standing still and chatting with each other. But I calculated it from a worse case scenario, with everybody moving like mad.

Oh, and by the way, does someone knows a network example/demo that uses interpolation/extrapolation with movements?

Greetings,
Rick

[Edited by - spek on April 19, 2006 11:17:29 AM]

Share this post


Link to post
Share on other sites
606 bytes to update 100 players in one tick? That's not crazy at all; that's pretty well packed. Note that you only get position, not velocity or heading or any other information (gestures?) in those updates. On a 56k modem per player, with those numbers, I'd aim for a tick rate of about 4 ticks per second. That comes to 2.5 kB/s per player, which leaves some data left for chatting, introducing new players, etc.

The server itself would of course need 250 kB/s of upstream bandwidth, which is more than a single T1, to serve those 100 people. That's standard for online games.

To reduce bandwidth consumption, I would decide on a tick rate that has a latency you can live with (say, 2 ticks a second for a chatting application), and send the N closest entities at that rate (say, the 10 closest). The other entities would be sent more seldom, the further away they are.

Share this post


Link to post
Share on other sites

This topic is 4254 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