[MUD-Dev] Networking architecture overview

Brian Hook brianhook at pyrogon.com
Thu Oct 18 16:05:51 New Zealand Daylight Time 2001


Dave Rickey said:

>   1) It sends the same amount of data regardless of how much
>   activity is involved.

I don't quite know what you mean here.  If there's not much
activity, then not much state is changing, therefore the delta
states should be very small.

>   2) Seems like this could chew a *lot* of memory once you're
>   looking at maintaining the game state + deltas for 2K+ players
>   attached to a single server.  Especially if a problem in your
>   own network causes a few seconds of connection loss, and you're
>   tracking large deltas for all players simulataneously.

It does eat memory because of the number of buffers you load up.
But keep in mind that you can change the buffer snapshot interval
and/or the number of buffers you're willing to delta off (if too
much time elapses, you send a new state snapshot).  For an RPG, you
can have state deltas that are several seconds apart.  But for an
FPS, 100ms state change differences are barely acceptable.

Also, you don't send the ENTIRE game state to each player (not sure
if that's what you meant), only the state relevant to each client.
Assuming reasonable population density, this shouldn't be that much
data.  Keep in mind that Q3 is tracking button presses and fast
mouse movement almost constantly, an RPG should have significantly
less traffic.
 
> It's a really slick solution to the problems Q3 faces, but I don't
> think you could scale it efficiently.

That's entirely possible, it's sensitive to how much you buffer and
the number of clients and overall connection quality.

Brian

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



More information about the MUD-Dev mailing list