# Client Tells Server What Gamestate Data to Send Back

I'm just stepping into the world of MMORPGs and how they function, so assume I know very little.

in a game, a client doesn't see everything that the server does. For example, the client can't see through mountains, walls, etc. So why send them data that's not relevant?

My question is: - If the Client was designed to tell the server what gamestate data would be relevant to them, then the server sent back only what was relevant, could you minimize lag / amount of data downloaded?

You would have to find a way for the server to discern what data the client needed, maybe this is where it becomes inefficient?

• This is called "area of interest management" or "relevance filtering". Check out ee.ucl.ac.uk/lcs/previous/LCS2011/LCS1121.pdf. In short, it prevents some kinds of cheating, and reduces bandwidth. In large worlds, this is absolutely required, and typically the server calculates what is relevant to a client and sends that. – user41442 Mar 6 '15 at 8:11

First of, don't ask client "what is your interest", that equal to just send them the knowledge about every object. Instead, when server updates the world, check where the player is, decide "area of interest" for that client, gather data for it and send it.

In very simple example, that is no where fast enough for object amounts that MMORPG's have, it could go something like this:

// List of all objects in the world
List<MyObject> allWorldObjects;

// Max distance to objects, which data is sent to client
int clientInterestDistance

updateClientWorld(Client client)
{
List<MyObject> clientInterestObjects;
for(MyObject obj in allWorldObjects)
{
if(DistanceBetweenClientAndObject(client,obj) < clientInterestDistance)
{
if(obj.IsHidden)
continue;
if(!CheckLineOfSight(client,obj))
continue;

// ETC

}
}
sendWorldUpdateMessage(client,clientInterestObjects);
}


So, in this example, we update would gather client data, making it as compact as we can so that we don't send huge amounts of data AND to make it little harder to cheat. Obviously List is not the best way to go, if object count moves up to hundreds or thousands. Preferable, you should always keep objects categorized so, that they are easy to fetch as a group. Meaning, that when you update object, you check position and add it to somekind of collection that helps you to get objects around coordinates x,y. Thus, avoiding you the performance problems, when looping 10000 objects for each client, 20 times in second.

The client and server have two different notions of visibility, by the way.

The sever is generally going to avoid visibility checks using actual geometry and at the most naive level may not implement visibility at all. In past work, I have re-used parts of the graphics engine's dynamic PVS system to implement agent (AI) pathing on the server, however position update filtering is not something that would benefit from that sort of complexity. More than likely, relevant game state updates will be established based on a simpler metric such as distance.

EverQuest sends position updates for every PC and NPC in a zone, but it varies the frequency of these updates for mobs that are distant from the player. In EverQuest, the client will resort to delta prediction much of the time to figure out where distant mobs are and that is usually adequate unless the player is moving extremely fast (e.g. on a boat). Even then, there is next to no gameplay that goes on at hyper speed so the lack of state updates will only affect rendering. So distance turns out to be an extraordinarily simple and effective metric.

As a point of trivia, EverQuest did not always work that way. For about the first year of its existence it sent out updates in equal frequency regardless where the player was in relation to everything else. This made cheating programs like ShowEQ (which displayed a radar with every mob in the zone) extremely effective, and also did not balance bandwidth effectively.