[MUD-Dev] Net protocols for MUDing

[Stephen Zepp]

Adam Wiggins wrote:
> 
> [Chris Gray:]
> > [Vadim Tkachenko:]
[snipped comments on complications]
> 
> No, the server doesn't process anything it hasn't received.  We're assuming
> here that the server is considered, for all purposes, 100% correct all the
> time.  (At least, if we lay aside my crazy ideas about packet insertation
> into the time line.)
> 
> The clients do all the same processing as the server, the difference is that
> they only have a small subset of the total objects from the server game world
> in memory to process through - those directly nearby the player.  They may
> determine that a collision has occurred between two ships and cause sparking,
> "collision imminent" warnings to the pilots, etc - but will not destroy any
> ships or display any actual collisions until the server sends the event.
> How you want to implement this sort of actuality masquerading depends on your
> theme.  For instance, naval battles circa 1800 would work well, because the
> ships move slowly and are difficult to turn, thus lagging connections and even
> dropped packets would have little effect on how the game looks to the player.
> The only difference might be that two colliding ships seem to merge together
> for a moment until the actual collision message is received, at which point
> the cracking timbers sound begins and whatever animations are going to take
> place actually occur.
> 
> So here's a question to you, Chris, and all those that have remained silent
> on this thus far: which do you prefer - a client whose speed is directly
> proportional to the speed of your internet connection so that you can rely
> on every client always being 100% "correct", or one which runs at its own
> framerate (hopefully 30fps or better) attempting to display what data it has
> about the world as best it can, resulting in some inconsistencies (or perhaps
> many if your connection is very unstable)?  I know which one I'd choose, but
> I wonder how many people feel the same?  Or perhaps there should be some sort
> of consistency sliders in the options screen which change how much prediction
> it does on its own, and how much it relies on the server for?
> 
> Adam

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.

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 just
assume ( as the player/client side ) that you had missed the ( new ) message on
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 ).

Instinctively, this seems as if it would be more efficient in the long term,
with some short periods of "lag" when large db updates ( moving into a different
db "section" would need a large update ), but mostly a smoother interface from
the client side, especially with a poorer net interface speed. From what little
information I gleaned from my pueblo interface work, VRML seems to work somewhat
similar to this, but I didn't research it much at the time.

With highly populated sections, the update overhead could cause more lag then a
direct feed from the server, but I think that in the big picture, this would be
overcome by the advantages in your more normal sparsely populated areas.  In
addition, you could almost use a live stream concept ( I'm not too informed on
socket level protocols ) to keep a constant information update connection going,
just not necessarily use it continuously ( everything goes through the server,
like most muds do now).

So, you graphics guys and gals...this sound familiar? :)  

Z