Hi guys,
I'm implementing interest management in my server/client based MMO so my message broadcasts are not geometric in the number of players.
I've got this problem that I can't find anywhere in the literature:
Player A is standing still.
Player B runs into Player A's interest zone and therefore Player A starts receiving messages about Player B
Player B runs out of Player A's interest zone and stops receiving messages.
Player A then follows Player B, catches up to the last position he knew Player B was at and sees Player B in the wrong place, but the on the server Player B is not inside Player A's interest zone because he ran way, way off into the distance...
What is the standard way of dealing with this?
Cheers, Paul.
Interest management in an MMO
Player A is standing still.
Player B runs into Player A's interest zone and therefore Player A starts receiving messages about Player B
Player B runs out of Player A's interest zone and stops receiving messages.
Player A then follows Player B, catches up to the last position he knew Player B was at and sees Player B in the wrong place, but the on the server Player B is not inside Player A's interest zone because he ran way, way off into the distance...
In that case Player A would probably have some sort of time stamp for the last information about Player B and if that was outdated he could request an update for Player B?
Do you have "Leave interest area" type event? When player B leaves the area you could send a message to player A, player A can then remove any info it has about player B (or at least not draw player B any more).
Author
In that case Player A would probably have some sort of time stamp for the last information about Player B and if that was outdated he could request an update for Player B?
That's certainly a possible solution, but it does mean bandwidth gets wasted on requesting updates when the player moves into and out of interest zones... I wondered if there was some other way to do it... Maybe not
Cheers, Paul.
Player A is standing still.
Player B runs into Player A's interest zone and therefore Player A starts receiving messages about Player B
Player B runs out of Player A's interest zone and stops receiving messages.
Player A then follows Player B, catches up to the last position he knew Player B was at and sees Player B in the wrong place, but the on the server Player B is not inside Player A's interest zone because he ran way, way off into the distance...
You need to have transitions both INTO and OUT OF the interest area. Player B becomes visible to player A when he runs into the area, then he becomes invisible when leaving the interest area. Thus, he won't see an old copy of B.
Btw: you need to do this both ways, too. Player B might be using, say, binoculars, and have a larger interest area than A, meaning B sees A but A does not see B.
Hi guys,
I'm implementing interest management in my server/client based MMO so my message broadcasts are not geometric in the number of players.
I've got this problem that I can't find anywhere in the literature:
Player A is standing still.
Player B runs into Player A's interest zone and therefore Player A starts receiving messages about Player B
Player B runs out of Player A's interest zone and stops receiving messages.
Player A then follows Player B, catches up to the last position he knew Player B was at and sees Player B in the wrong place, but the on the server Player B is not inside Player A's interest zone because he ran way, way off into the distance...
What is the standard way of dealing with this?
Cheers, Paul.
try this: when player B runs out of player A's interest zone, Player B's "isonline" flag is set false by the client, and set online again if we receive packets about player B.
Each object maintains a list of "subscriptions". Objects that have entered area of interest.
When an object moves, it checks all of its subscribers and see if any of them is out of range. If so, it unsubscribes. Hysteresis should be used: object subscribes at range_min but unsubscribes at range_max (perhaps 100m and 200m).
Now an interesting problem appears. While Frodo sees Sam who is 55m away, they do not see Sauron's Tower of Doom, 2km high and 1km away - it's further than 100m. A relatively important flaw in the approach.
So instead of letting objects subscribe base on their own range, let each object have a parameter "prominence" or "size" or "importance". Tower of Doom would have such parameter at 1000, Sam and Frodo at 100 and mouse at 20.
Whenever any object moves, every other object in the world checks this new position against their range and subscribes those that are close. This way, important or big objects will become visible from further away.
----
Idea above is computationally prohibitive. Fortunately, efficient algorithms exist for spatial queries and by checking objects only when they move (or perhaps even once_per_5_seconds_at_most), the above works very well.
AOI queries can be also implement very efficiently through use of sphere (circle) trees. They are rarely used in most real-time applications since they kd- or similar trees have lower constant factors, but they are a perfect fit for AOI problem with variable ranges. In most cases, range checks become O(1).
---
When an object is unsubscribed, client destroys its local representation. The object is simply assumed to be gone. This simplifies resource management since one doesn't need to track two separate life-cycles. Only objects currently in range "exist" for client to interact with. Hysteresis prevents excessive updates. Since realistic number of objects will be in hundreds of thousands, with per-5-second update rate this puts an upper bound on number of updates that need to be sent.
Special cases that need to be handled might be party members. One might still be interested into those far away, but those can be flagged to only send limited subset of information.
Advantage of such design is relative simplicity. Outside of spatial query structure, it's just a subscription list. And as an added bonus, same mechanism can be used for clustering on servers without much extra effort.
When an object moves, it checks all of its subscribers and see if any of them is out of range. If so, it unsubscribes. Hysteresis should be used: object subscribes at range_min but unsubscribes at range_max (perhaps 100m and 200m).
Now an interesting problem appears. While Frodo sees Sam who is 55m away, they do not see Sauron's Tower of Doom, 2km high and 1km away - it's further than 100m. A relatively important flaw in the approach.
So instead of letting objects subscribe base on their own range, let each object have a parameter "prominence" or "size" or "importance". Tower of Doom would have such parameter at 1000, Sam and Frodo at 100 and mouse at 20.
Whenever any object moves, every other object in the world checks this new position against their range and subscribes those that are close. This way, important or big objects will become visible from further away.
----
Idea above is computationally prohibitive. Fortunately, efficient algorithms exist for spatial queries and by checking objects only when they move (or perhaps even once_per_5_seconds_at_most), the above works very well.
AOI queries can be also implement very efficiently through use of sphere (circle) trees. They are rarely used in most real-time applications since they kd- or similar trees have lower constant factors, but they are a perfect fit for AOI problem with variable ranges. In most cases, range checks become O(1).
---
When an object is unsubscribed, client destroys its local representation. The object is simply assumed to be gone. This simplifies resource management since one doesn't need to track two separate life-cycles. Only objects currently in range "exist" for client to interact with. Hysteresis prevents excessive updates. Since realistic number of objects will be in hundreds of thousands, with per-5-second update rate this puts an upper bound on number of updates that need to be sent.
Special cases that need to be handled might be party members. One might still be interested into those far away, but those can be flagged to only send limited subset of information.
Advantage of such design is relative simplicity. Outside of spatial query structure, it's just a subscription list. And as an added bonus, same mechanism can be used for clustering on servers without much extra effort.
bandwidth gets wasted on requesting updates when the player moves into and out of interest zones
So, first, bandwidth is not "wasted" because it serves a useful purpose of avoiding a state bug that annoys the user. Perhaps "consumed" is a better word.
Second, you really don't need to request anything. The server knows when objects go into and out of interest range of each other, and each transition (in or out) needs to end up in an event where an object gets added to, or removed from, the world seen by the player.
It's really just one more message saying "client A left your space" in addition to the millions of position updates that had been sent up till that point
Author
You need to have transitions both INTO and OUT OF the interest area. Player B becomes visible to player A when he runs into the area, then he becomes invisible when leaving the interest area. Thus, he won't see an old copy of B.
Btw: you need to do this both ways, too. Player B might be using, say, binoculars, and have a larger interest area than A, meaning B sees A but A does not see B.
When you say 'becomes visible' do you mean this in a literal sense, i.e the player character on the client is made (visually?) invisible to other players?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement