[MUD-Dev] MMORPG/MMOG P2P design

Ben Hoyt Ben.Hoyt at SilverPlatterSoftware.com
Mon Mar 3 17:34:50 New Zealand Daylight Time 2003

From: Caliban Tiresias Darklock

> For each action, two clients are randomly selected and told to
> calculate a result. The two results are compared, and if they
> match, the result is used.  If they do not match, the result is
> calculated by the server, and whichever doesn't match *that*
> result is the one in error. If a client is consistently in error,
> it can be evicted. By load-balancing the client requests, you can
> effectively split the CPU load among all the players, and at any
> given point in time you don't know which two clients will be
> calculating the results of any given action -- so the only way to
> reliably cheat would be to mod every client in the game
> identically, in which case everyone would be on equal footing and
> could be assumed to have *agreed* on the cheat.
You're on the right track.  Our system basically takes this basic
dynamic of having players double check each other and takes it to a
more thorough level in which groups of 5 players form "Virtual
Servers" who are managed by a hierarchy of player servers which
ultimately reports to the central server.  These groups of 5 players
are responsible for executing regions of the game world in which
none of them are players.  The composition of the Virtual Servers is
shuffled on a regular basis in order to prevent collusion.  Voting
is done by passing lightweight cryptographic hashes of the game
state back and forth between members on a frame-by-frame basis.  If
an inconsistency is found, the correct game state can be pushed to
the affected players.

> It's not a perfect solution, of course, but it has practical
> potential. The problems start to show up when someone distributes
> a modified client that will give *his* character an advantage, but
> we can also operate under the assumption that the community will
> police itself on that matter and blacklist clients that are known
> to be unfair.

In this system, a modified client would have to find its way into at
least 3 of the 5 voting members machines without the developer
finding out it exists.  Even if this happened, the developer would
immediately be notified of the incorrect vote (3 versus 2 should
otherwise be extremely rare) and could take investigative action.
Moreover, this advantage would only exist for a couple of minutes,
until the Virtual Servers is reshuffled.

MUD-Dev mailing list
MUD-Dev at kanga.nu

More information about the MUD-Dev mailing list