[MUD-Dev] DGN/TECH: Implementing server side spatial partitiongwas:(exploiting/hacking in MMOGs - sources of info?)

[John Buehler]

William Leader writes:
> Daniel.Harman at barclayscapital.com wrote:

>> Completely distrusting the client side strikes me as a far harder
>> problem as it becomes entirely dependant upon the quality of ones
>> client working set partitioning algorithm, on the server. That
>> makes it pretty hard to not broadcast updates to the client for
>> entities hidden through walls etc. I don't think this is by any
>> means solved yet, but given that spatial partitioning is a
>> reasonably well explored problem space, there seems a reasonable
>> chance that brute force is the only answer.

> I think tools like *cough* ShowEQ *cough* clearly demonstrate that
> not trusting the client is the only answer.

> As far as how to implement the partitioning algorithm, I do have
> and Idea about that I imagine that most server currently spew out
> a constant stream of data about players, mob, objects, ground
> spawns, etc. I bet these are usually broadcast packets (but that
> will have to change). Instead you take the current servers, and
> pipe all that data to a Line-Of-Sight (LOS) proxy server.

> The LOS server has the 3d map loaded in memory (no textures, just
> planes).  For each packet that comes in, it does a line of sight
> check between the player's location and the location of the object
> in the packet. If the client can't see it, it changes the packet
> to tell the client the object has disappeared. Worst cast the
> client still knows the last known position, but that's not
> unrealistic. This setup allows all the partitioning 3d calculation
> work, can be unloaded onto a separate processor. The client gets
> only what they need. They know what was behind door number 1 last
> time they looked, but there is no what to know what is there now,
> or was there before is still there.

And for those looking for something for the client machine to do,
there's the whole task of keeping track of what the client has ever
seen from the server.  That can be tackled both for both short-term
and long-term objects.

If my character walked through a door into a room, the client could
record the appearance of everything in that room.  The next time my
character returns to the vicinity of that door (or simply want to
mentally review the contents) the client can show the contents.
Perhaps they are shown in a faded color and/or with translucency to
indicate how old the memory is.

When the character can next see into the room, the visible areas
immediately revert to the server-supplied view, and the client again
remembers the new appearance of the room.  Which gives client
developers plenty of problems to solve.

On a shorter timeframe, if a moving character walks around a corner,
there's no reason that a more-rapidly fading image of the moving
character shouldn't be shown just around the corner.  The reason for
fading it out is to let the player know that the information is
probably not very accurate, especially after some time has passed.

> Personally I have a feeling that the LOS code could easily be put
> together by a client programmer that is decent with 3d. It may
> even be possible to use a high-end video card's acceleration
> abilities to speed things up faster. Adding this second server
> could also be strapped onto most existing servers without
> encumbering the code more, or causing massive changes to the
> existing servers. I think the only change needed to existing
> servers would be to have it stop broadcasting and send position
> updates only to the LOS server.

I've been wondering when we'll transition to a physics accelerator,
just as we have a video accelerator.  In time, I assume that we'll
have virtual reality accelerators.  I just don't know when that'll
happen.  Apparently not for quite a while.

JB
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev