[MUD-Dev] Client side simulation

[Amanda Walker]

On Apr 2, 2004, at 3:56 PM, dienw wrote:

> Is it worth to design a client side simulation model?

> Contrast with common server side simulation, and clients receiving
> states update only.

> Means it's a client/server model, but server only passing events
> (and maybe validating and control some central issue like timing).
> Real implementation is in each client. If everything runs well, it
> will run in sync. If any out-of-sync happen, server should
> invalidate the session.

> The reason behind is to reduce server load to the clients.

If you can rely on the integrity of the client code, this can work
very well.  This, for example, is how military training and testing
simulations work: each player has a computer running their piece of
the simulation, so that the amount of CPU power scales up directly
with the number of players.  And even if there's network trouble
somewhere, the rest of the simulation is unaffected.  This concept
can also be extended to what are called "federated" simulations,
where two different simulation networks can interact in real time.

However, this breaks down as soon as someone modifies their part of
the simulation.  In some contexts, this doesn't matter: the Army,
for example, has ways of giving players incentives not to crack open
their player units :-).  In a small gaming community, people can
agree to play by the rules.  But in a commercial consumer
environment, this is pretty hard to ensure.  "Closed" systems like
the XBox or PS2 are more resistant than generic PCs, but there are
still no guarantees.

However, if you are interested in distributed simulation, there are
a lot of resources out there.  A google search on "distributed
simulation" should turn up a lot of stuff.  Most of the work in this
area has been done in academia and the military, rather than in the
commercial arena.

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