Sign in to follow this  

Updating clients - Best appeoach

This topic is 3853 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 in the process of implementing the cilent update section of our game server and am not 100% sure of which would be the best approach to take for a player base of around 500+ players. I can see the following possible routes: a) Every time the server ticks it notifies each client of players / objects that are within range of the client. My problem with this approach is the demand placed on the server each tick for so many players. b) Every so often the client will send a request to the server to ask for a list of players / resources hhat are within range. My problem here is that clients can be running on some out of date data, as the server may not have ticked. Im leaning towards b) as it seems that it may lighten the comms load on the server a little. What do you guys recommend? Thanks for any advice Mat

Share this post


Link to post
Share on other sites
How is b) going to be any different from a) in terms of server load? Server still has to perform the exact same task, right? Only know the client decides when, so if you have a hacked client it can receive ticks as fast as it wishes, leaving no room for other clients. Either I'm missing something or this is a bad idea.

Share this post


Link to post
Share on other sites
Quote:
Original post by Omid Ghavami
How is b) going to be any different from a) in terms of server load? Server still has to perform the exact same task, right? Only know the client decides when, so if you have a hacked client it can receive ticks as fast as it wishes, leaving no room for other clients. Either I'm missing something or this is a bad idea.


I was thinking in terms of the upstream on the server. Instead of having to send a mass of data all at once (every server tick) it would only send it when it was requested. Im hoping that this would stagger the amount of data that the server has to deal with at any one given point in time. e.g.

a) Sending all at once, would require collating all of the data for all of the clients then sending it back to them all
b) The server collates only data needed by the client that has sent a request for it. Client 1 may send a request at 10ms into the servers life, client 2 may send a request it at 15ms into the servers life, client 3 20ms into the servers life and so on.

A hacked client could receive more ticks than other clients, but it wouldnt make any difference as it would just get back the same data as last time. In addition, the server can check for clients making requests too quickly and ignore them if they are coming too often.

Im also hoping that b) will help to deal with clients that have slower connections.

Im pretty new to MMOG coding so if what I am saying sounds a bit silly then forgive me :)

Share this post


Link to post
Share on other sites
Having the client ask for the data is no better; in fact, it's usually worse.

If each player needs to get information about the world X times a second, then that's a constant bandwidth and CPU load, no matter where the decision to send data comes from.

What you're asking about, by the way, is one of the (several) bottlenecks in MMOG programming, and is why MMOG programming is often more challenging than your typical 8-person deathmatch.

Share this post


Link to post
Share on other sites
I'm not sure that I fully understood the question.

But what I do is that I let the client send a request to do an action, the server accepts (or denies) it
and (the server) sends informations to the players (clients) which is in range of that player.
That keeps all the surrounding players up to date. (If they do not miss a packet.)

Share this post


Link to post
Share on other sites
Your clients need to keep their state updated on the server. The server will decided when and who gets what. If you want to converse bandwidth and cpu resources you will need "smarter" algorithms than the ones you have suggested.

Share this post


Link to post
Share on other sites
I can see how (B) would potentially be beneficial in thinning out the data output, but why do you need client requests to accomplish this? I would just have the server stagger the output on its own, mixing client updates with data processing. How best to do this really depends on what other processing the server needs to do, but it can't be too hard - just set a limit on how many client updates can be outputted before the server needs to do some other processing, and set limits there too so that the server will soon return to updating the clients.

Share this post


Link to post
Share on other sites

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