[MUD-Dev] Net protocols for MUDing

[Chris Gray]

[Stephen Zepp:]

:Server: maintains the primary db, posting changes sent from the clients, and
:routing update messages to those clients that are currently "live" with any da
:that has been changed by another client.

I certainly agree with this as a way to go. What I have problems with is
when the server and clients are not fully in sync.

: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 o
: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 th
:player's hard drive as things change.

Yep. What I view as being on the CD is mostly multimedia things, models for
common NPC's and structures, etc. The world code is going to change over
time as fixes and extensions are done, so you may not get much gain by
having a fixed version on CD.

:Depending on the granularity of your world, I wouldn't need to update the
:primary db with "small" changes very regularly.  If someone inscribes a hidden
:message on a room wall, that wouldn't be a high priority update...you would ju
:assume ( as the player/client side ) that you had missed the ( new ) message o
:previous inspections.	The primary db wouldn't need to know that player X had
:pushed a particular table an inch and a half to the left right away,
:unless/until the movement of the table implied some more intricate world
:behavior ( like blocking a door ).

How do you define what a "small" update is, in a universe that is fully
defineable and programmable as it runs? Moving a table 1" might be
extremely important for some reason that has been created long after
your CD's were distributed. How can you know *what* is important at all?

I'm being extreme, yes, but that's because flexibility and expressiveness
are the most important things for me. I like a system that can be extensively
tinkered while it is running. Which is why my system has the world all
programmed in the MUD programming language, which is accessible to all
"wizard" and "apprentice" characters at run-time.

So, I guess maybe I should just stay out of this discussion, except on
an academic level, since it doesn't seem aimed at the kind of thing I
have experience with. I don't want to confuse what could be a productive
discussion for systems different than mine.

--
Chris Gray   cg at ami-cg.GraySage.Edmonton.AB.CA