[MUD-Dev] Net protocols for MUDing

[Adam Wiggins]

[Stephen Zepp:]
> I don't know a lot about how the graphical muds work, but here's some initial
> thoughts I've been sort of synergisting from a couple of threads:
> 
> Basically, considering long ago threads talking about virtual room generation,
> combined with the thread talking about creating object instantiations at
> interaction time, plus most everyone's "large world" concept, and finally
> assuming a perfect world fully encrypted ( and unhackable, yeah, right ) I was
> thinking this:
> 
> Client: Handles _all_ interaction with the world, based on it's most current
> sync with the primary db at the server, and updates the server with information
> changes.
> 
> Server: maintains the primary db, posting changes sent from the clients, and
> routing update messages to those clients that are currently "live" with any data
> that has been changed by another client.
> 
> Basically, I'm going under the assumption ( in flying, we call it the Big Sky
> Theory ) that a large portion of your world isn't in use at any one time, and
> those portions that are in use aren't being used by very many people. At any one
> time, realistically, someone at the client level isn't using much of the total
> world db, and could d/l updates as things change.  You could even release your
> primary world information ( that's static ) on CD, and hold update files on the
> player's hard drive as things change.
> 
> When I interact with the world, I change things that eventually need to be
> posted to the db.  The client handles all of this, then sends an update packet
> to the server.  The server tracks who needs immediate notice of any db sections,
> and sends those update packets immediately to those clients that are holding any
> recently updated db "sections" live on the client side.  You would definately
> need to keep the client/server synced tightly, but not too tightly, I think,
> just enough so that several updates aren't missed, causing the client's world to
> deviate too far from the primary db. Since the client handles most of the work,
> instead of having to send _everything_ to the server for processing, we get the
> effect of distributed processing, with some additional overhead from db updates,
> but not nearly as much net traffic as a "normal", dumb terminal client would
> have.
> [snip rest]

I suppose it would depend on the type of game, but I don't think I like
this too much.  The first immediate problem I have is the hacking thing -
looking at what happened with Diablo, my faith in any sort of encryption
is pretty low.  The solution, it seems to me, is to have a central server
which approves any and all events that are to transpire before any other
clients except the initiating one recieve it.
Secondly, I don't like the idea of the complexity of the game being limited
by the client user's computing power.  UO suffers from this slightly; a friend
of mine found UO almost unplayable despite an excellent connection (cable
modem) because his one meg, unaccelerated video card made his screen updates so
slow that he couldn't keep up with characters he was trying to follow.  (I
recently gave him a Diamond Viper I had sitting around to get him to shut
up about it.)  In a related note, I'd like to be able to devote the user's
computer power 100% to the actual display of the data - keeping a nice high
framerate and response time.  If I want to make the game more complicated
on the server end, no problem - plug a few more processors or some more RAM
into our server machine.  (Or, do an ultra-distributed server - a single
firewall machine running an 'uncrashable' connection manager, and a potentially
infinite number of server machines connected by ultra-high-speed optic cable,
with the connection manager delegating out process handling by checkup
load averages on the various servers.)