[MUD-Dev] Net protocols for MUDing

[Chris Gray]

[Chris L:]

:Outside a simple, bugger forget the term, XOR where the XOR'ed against 
:value comes from a shared and seperate source (eg the contents of a
:file, or bytes on a CD (music CD's are incredibly popular for this
:in the heavy encryption market as as long as the choice of CD is kept
:secret, the cipher is effectively guaranteed secure as the key is
:indistinguishable from random)) would work well with negligable overhead.

Cool! If the MUD is shipped on a CD, you could use the sound samples and
textures, etc. on that CD - likely just as good.

:This is of course a variation on the colliding space ships, and
:suffers from the "who owns the decision" problem described above.  The 
:key point however is that prediction only goes so far.
:
:I suspec that it is safe for the client to ONLY predict motion, not
:the results of motion, or any side effects (eg Bubba walks the the
:waterfalla and the water splashes on him).  The client predicts
:already started motions only.	All actual decision making is left up
:to the server. 

That sounds right to me. You might be able to go further, too. Consider
simple NPC's, which are known to not have terribly complex behaviour.
You could try to run the behaviour script for those NPC's on the client,
allowing simple interaction with the character. Only when that script
actually had to write something to the DB would you have to interact
with the server to make sure all was well. Back when I was doing my
"effects" client stuff, and thought I actually had time to do all of
this, I had a vision of a pleasant pastoral scene, with trees swaying
in the wind, grass rippling, birds singing, bunnies hopping across from
time to time, maybe a deer wandering on-scene, feeding, etc. All with
no server interaction, since the player was doing nothing other than
watching the pretty stuff. I think you want the server to run all of
the same stuff, just not doing the graphics/sound, and not sending
anything to the client, so that if something the client doesn't know
about influences the action, the client can be informed.

How to do that? Well, from the point of view of the client, all is
well until something has to be written to the DB. Perhaps all that
matters is something written to part of the DB concerned with non-transient
things. I would consider the birds, bunnies, deer, etc. to be transient.
(I'm not suggesting partitioning the DB, just knowing what parts of it
are considered "transient".)

>From the servers point of view, perhaps the server simply needs to know
what all the client knows about. If something needs to generate output
to that client, and the server knows that the client is not running the
code that generates that output (e.g. some programmer has generated a
cougar, and it wanders into the scene, or a PC does something explicit),
then the server has to send explicit event information to the client.
In the case of the cougar, sending the script/description/skeleton for
the cougar, and any updates on the deer and bunnies, might be enough.
I suspect you would want to update the client's copy of the deer/bunny
code whenever the server's copy got updated by that programmer, however.

:  If Bubba happens to teleport in and grab the leaf shortly after the
:client takes over showing the leaf falling without server updates,
:then the server would do update the client.  The result (give big
:latencies) is that the user would see the leaf falling, possibly all
:the way to the ground, Bubba suddenly appearing and grabbing the leaf
:in mid air.

Exactly. If its a playful bear that wanders in and grabs the leaf, you
could update the client with the bear info, then continue running stuff
in the client.

:  I suspect that the lack of sync and logical consistency in the leaf
:position will be willingly overlooked by users.

I agree. Within limits, however. You also might want to add a message
to the text output area indicating that update delays were caused by
network delays, so you have a continual excuse to the player. Yes, I'm
serious about that!

:Programmatically determining what is and is not a significant state
:change could be interesting however.

<nod> Perhaps keeping track of what DB changes result, and asking if
the changes are to DB entities marked as "significant".

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