Sign in to follow this  

Online game networking

This topic is 3675 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 am trying to minimize data sending by only sending data to those players who need it. Therefore, each player has a std::list of players which are 'subscribed' to them. Every time a player moves, he sends the info to the players on his list and only those on his list. Heres what I need a bit of help with: When a player moves, the server doesnt check everyone in the area for new players to subscribe, but rather only checks the new locations the player can now 'see'.
Example: the o is the player and the x is what he can see, and everyone standing on an x should be subcribed to o and subcribe o to their own list.

xxxxxxxxxxD
xxxxxxxxxxD
xxxxoxxxxxD
xxxxxxxxxxD
xxxxxxxxxxD

If o moves to the right, then I am ONLY checking for new players at the D's, because those are the only new locations that could be added.
Now thats how a player can get 'subcribed', and now I need to know how often to check to see if one player is too far away and thus should 'unsubscribe'. I was thinking about doin it just every 3-4 moves, but I'm not sure!

Share this post


Link to post
Share on other sites
That's impossible to tell without knowing how many players you're going to support, what network capabilities they have available, what amount of data is usually sent, and so on.

I'd say, get it to work first, then run some tests to see how much optimization is required, and where it is needed most.

[Edited by - Captain P on November 25, 2007 6:16:15 PM]

Share this post


Link to post
Share on other sites
Well Crazyfool, first of all, it sounds like you're on the right track. Emphasizing accuracy with respect to subscription and lazily unsubscribing is a not a bad idea at all. You'll also need to consider instances when one player just sits there like a lump, and other things zip by them [they aren't moving, so new areas are not subscribed to as they move], but that isn't so much important to minimizing data sent as much as it is assuring that enough data is sent, so your approach to solving this problem likely wasn't included in your original post.

What is relevant here is the method by which you determine visibility. Checking if something is within a certain distance is something that is cheap enough to be done every update. Checking to see if something is visible without obstruction is substantially more costly, and should likely only be done whenever you have some spare cycles, or when it has become obvious.

Something else you might want to consider is instead of subscribing to the actions of individual players, subscribe to the things that occur in specific regions [and just have a longer list, with mostly empty and thus event free regions]. You can aggressively precompute various visibility sets under those conditions [what regions are visible from what regions], and use those sets as the basis for your tests [perhaps even calculate out subsets from those regions to get a entity-subscription list if the granularity is not fine enough for you in the form of regions]. This would make subscription and unsubscription a trivial matter [just a subscription to a precomputed or easily computed] at the cost of increased memory overhead [which could be the site of some optimization in the form of computing and caching subscription lists for heavily populated areas, speculatively constructing and caching subscription lists in lightly populated or rarely traveled areas, etc.]. This is actually the approach I usually take with respect to only matters, and I personally have found this added layer of indirection makes a lot of things a lot easier to deal with.

Just things to consider. Also if you're looking at minimizing bandwidth you might want to take a look at compression methods. Sending a regular string across the line will look wasteful really fast.

Share this post


Link to post
Share on other sites

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