[MUD-Dev] Re: clients anyone?...

[Bruce]

On Wed, 12 Aug 1992, Hans-Henrik Staerfeldt wrote:
> On Tue, 11 Aug 1998, Adam J. Thornton wrote:

> > >     All this happens without my being interrupted by the flow of
> > >     information from crab to ELIZA.  I don't see the messages, and
> > >     I don't need to be in the same room as the crab when people
> > >     speak to him.
> >
> > Nice!  This sounds like a good way to implement relatively simple
> > scriptable NPCs, actually: if they just have their own client, can parse
> > the incoming data, and respond appropriately then I don't have to build
it
> > explicitly into my server or my database model; I can just create an NPC
> > object and let its client script handle its responses.
>
> If you want complex scripting, it would be a good idea to extend the
> protocol to handle pre-processed data. In reality, your in-game model
> of the world is translated into nasty ambigous text for reading of humans,
> or even worse - graphics. Unless you want to do some very nasty AI attempt
> at understaning the messages (graphics!) intended for the player you
> should extend your good flexible protocol with an AI stream mode that
> allows for nicely formatted events to be parsed to the remote NPC.
>
> Player> Buffy pick up the hammer.
> AI> Pickup((Player 52364),(Object 23647)).
>
> or something to that affect.


Why not use a protocol described by an XML DTD?  This would allow you to
parse it easily with standard libraries in multiple languages and validate
the data fairly easily.

If you were to move to having all events from the server be broadcast to the
clients in this protocol, you could support various types of clients off of
the same server, with each one interpreting the data as it could best handle
it.  For clients that might need only a tiny subset of the data involved
(like a text-only client), one could set up a proxy server that connected to
the server and would filter the event messages in a way specified by the
client.  Users that required telnet-style access to the game could be
satisfied by another proxy server which would 'render' the event messages
into a more traditional textual format.

For robots, NPCs and AI, they would be receiving the same data available to
any user and could be hosted anywhere, not requiring the main game server(s)
to be bogged down by AI.  Logging mechanisms could even be handled this way
to provide a more intelligent AI-based log monitoring system.  You could
even stick a weather control system on the client side of this (albeit, a
different type of data headed down that pipe).

 - Bruce (who plans on starting a Cold-based core to do stuff like this
after he gets the next version of Genesis well under way)