<!-- MHonArc v2.4.4 --> <!--X-Subject: [MUD-Dev] Re: clients anyone?... --> <!--X-From-R13: Oqnz Ivttvaf <nqnzNnatry.pbz> --> <!--X-Date: Thu, 20 Aug 1998 11:25:04 -0700 --> <!--X-Message-Id: Pine.SGI.3.96.980820104951.3866G-100000#zazu,angel.com --> <!--X-Content-Type: text/plain --> <!--X-Reference: Pine.SGI.3.95.980811234105.26545E-100000#genome,cbs.dtu.dk --> <!--X-Head-End--> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <html> <head> <title>MUD-Dev message, [MUD-Dev] Re: clients anyone?...</title> <!-- meta name="robots" content="noindex,nofollow" --> <link rev="made" href="mailto:adam#angel,com"> </head> <body background="/backgrounds/paperback.gif" bgcolor="#ffffff" text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000"> <font size="+4" color="#804040"> <strong><em>MUD-Dev<br>mailing list archive</em></strong> </font> <br> [ <a href="../">Other Periods</a> | <a href="../../">Other mailing lists</a> | <a href="/search.php3">Search</a> ] <br clear=all><hr> <!--X-Body-Begin--> <!--X-User-Header--> <!--X-User-Header-End--> <!--X-TopPNI--> Date: [ <a href="msg00789.html">Previous</a> | <a href="msg00791.html">Next</a> ] Thread: [ <a href="msg00697.html">Previous</a> | <a href="msg01064.html">Next</a> ] Index: [ <A HREF="author.html#00790">Author</A> | <A HREF="#00790">Date</A> | <A HREF="thread.html#00790">Thread</A> ] <!--X-TopPNI-End--> <!--X-MsgBody--> <!--X-Subject-Header-Begin--> <H1>[MUD-Dev] Re: clients anyone?...</H1> <HR> <!--X-Subject-Header-End--> <!--X-Head-of-Message--> <UL> <LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI> <LI><em>Subject</em>: [MUD-Dev] Re: clients anyone?...</LI> <LI><em>From</em>: Adam Wiggins <<A HREF="mailto:adam#angel,com">adam#angel,com</A>></LI> <LI><em>Date</em>: Thu, 20 Aug 1998 11:26:05 -0700 (PDT)</LI> <LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI> </UL> <!--X-Head-of-Message-End--> <!--X-Head-Body-Sep-Begin--> <HR> <!--X-Head-Body-Sep-End--> <!--X-Body-of-Message--> <PRE> On Tue, 11 Aug 1998, Hans-Henrik Staerfeldt wrote: > On Tue, 11 Aug 1998, Adam J. Thornton wrote: > 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. Absolutely. This is, I think, a pretty fundamental part of any highly extensible game world. I usually refer to them as "events", although this can be somewhat confusing as it overlaps somewhat, but not completely, with the traditional notion of events as a device in the code. On your typical codebase this is handled by the very simple: Player->Send("%n smile%s happily."); Problems with this are numerous. First is, of course, the lack of any context. Some implementations try to add extra parameters to help account for this deficiency, like so: Player->Send(SEND_TO_ROOM, VISION, "%n smile%s happily."); or possibly extra parameters in the markup language: Player->Send("<Radius=10m><VisionRequired=75>%n smiles%s happily."); This can work, but as you mention above, doesn't help out our poor NPC AIs much, plus it's at the whim of the person creating the message to include all the relevant parameters, which can turn into a mess if there's a lot of them. Simple things like some sort of priority level (so that you can cull out someone smiling in the midst of a chaotic battle sending tons of messages), concatination rules (so that you can do "Bob smiles, and draws his sword."). Check the archives for posts from Nathan for more examples in this vein. The solution that Orion and I can up with is actually having a fixed list of events that can occur. A potential downside is that you make it difficult to add new messages, since you can't just toss out a one-liner; however, we actually saw this as a good thing. An event has several standard parameters. A type (EVENT_PICKUP, in the example dicussed above), actors and direct objects, and extra parameters such as intensity. The type array itself actually encodes data like what sense(s) you need to detect the event. The message itself is not a simple string like "%n picks up %o"; there was usually a number of phrasings to keep it from getting too repetative ("get", "take", "pick up", for a simple example) as well as special phrasings for extra parameters ("snatches", "grabs", "carefully picks up") and parameters for where each message would fit into a sentence, so that we can arrange multiple messages properly. Getting it to display on the screen properly is a bit tricky, but mostly just coding the various special cases (which English is full of). The *good* part about all this, besides output which doesn't look quite so canned, is the ease of manipulating the events once they are encoded this way. Someone using the event (ie, EVENT_MUSHROOM_CLOUD for the 'nuclear blast' spell) doesn't have to worry about the targets of the event, what senses they have, or anything else. They just launch the message. From there, various entities receive the event. If the entity is player controlled, the event is put on a queue to be concatinated with other messages and finally sent to the player. If the the entity is AI controlled, the event is sent to the AI and it can deal with it how it likes, without having to worry about checking "am I blind?" "am I deaf?" "am I close enough to hear this?" "is the door between me and the person that sent the even closed?" special cases. These are also the same events which are then stored in the NPCs' memory. I've posted a few times on this part of the functionality, which is a whole other can of worms (and requires an event type heirarchy, so that multiple events that are similar but not identical can be grouped together). However the benefits of this are obvious immediately - instead of storing a string like "Bubba gets the sword" which has to be parsed over and over again, the NPC stores specific information (local id's for Bubba and the sword, so that it can associate the event with other events involving the same people and things) as well as a single word for the event id (EVENT_PICKUP). Adam </PRE> <!--X-Body-of-Message-End--> <!--X-MsgBody-End--> <!--X-Follow-Ups--> <HR> <!--X-Follow-Ups-End--> <!--X-References--> <UL><LI><STRONG>References</STRONG>: <UL> <LI><STRONG><A NAME="00690" HREF="msg00690.html">[MUD-Dev] Re: clients anyone?...</A></STRONG> <UL><LI><EM>From:</EM> Hans-Henrik Staerfeldt <hhs#cbs,dtu.dk></LI></UL></LI> </UL></LI></UL> <!--X-References-End--> <!--X-BotPNI--> <UL> <LI>Prev by Date: <STRONG><A HREF="msg00789.html">[MUD-Dev] Re: Standard Mud Room Format?</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg00791.html">[MUD-Dev] Re: UBE/high: Re: FW: UBE/high: Re: W IRED: Kilers</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg00697.html">[MUD-Dev] Re: LinuxThreads and SIGUSR1 (Ref: [MUD-Dev])</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg01064.html">[MUD-Dev] Re: clients anyone?...</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="index.html#00790"><STRONG>Date</STRONG></A></LI> <LI><A HREF="thread.html#00790"><STRONG>Thread</STRONG></A></LI> </UL> </LI> </UL> <!--X-BotPNI-End--> <!--X-User-Footer--> <!--X-User-Footer-End--> <ul><li>Thread context: <BLOCKQUOTE><UL> <LI><STRONG>[MUD-Dev] Re: clients anyone?...</STRONG>, <EM>(continued)</EM> <ul compact> <ul compact> <LI><strong><A NAME="00689" HREF="msg00689.html">[MUD-Dev] Re: clients anyone?...</A></strong>, Andrew Wilson <a href="mailto:andrew#aaaaaaaa,demon.co.uk">andrew#aaaaaaaa,demon.co.uk</a>, Wed 12 Aug 1998, 17:41 GMT </LI> <LI><strong><A NAME="00690" HREF="msg00690.html">[MUD-Dev] Re: clients anyone?...</A></strong>, Hans-Henrik Staerfeldt <a href="mailto:hhs#cbs,dtu.dk">hhs#cbs,dtu.dk</a>, Wed 12 Aug 1998, 18:08 GMT <UL> <LI><strong><A NAME="00692" HREF="msg00692.html">[MUD-Dev] Re: clients anyone?...</A></strong>, Adam J. Thornton <a href="mailto:adam#phoenix,Princeton.EDU">adam#phoenix,Princeton.EDU</a>, Wed 12 Aug 1998, 18:37 GMT <UL> <LI><EM>Message not available</EM><UL> <LI><strong><A NAME="00697" HREF="msg00697.html">[MUD-Dev] Re: LinuxThreads and SIGUSR1 (Ref: [MUD-Dev])</A></strong>, Adam J. Thornton <a href="mailto:adam#phoenix,Princeton.EDU">adam#phoenix,Princeton.EDU</a>, Wed 12 Aug 1998, 23:09 GMT </LI> </UL> </LI> </UL> </LI> <LI><strong><A NAME="00790" HREF="msg00790.html">[MUD-Dev] Re: clients anyone?...</A></strong>, Adam Wiggins <a href="mailto:adam#angel,com">adam#angel,com</a>, Thu 20 Aug 1998, 18:25 GMT </LI> </UL> </LI> </ul> <LI><strong><A NAME="01064" HREF="msg01064.html">[MUD-Dev] Re: clients anyone?...</A></strong>, J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Fri 18 Sep 1998, 20:51 GMT <UL> <LI><strong><A NAME="01081" HREF="msg01081.html">[MUD-Dev] Re: clients anyone?...</A></strong>, Andrew Wilson <a href="mailto:andrew#aaaaaaaa,demon.co.uk">andrew#aaaaaaaa,demon.co.uk</a>, Sun 20 Sep 1998, 00:58 GMT </LI> </UL> </LI> </ul> </LI> <LI><strong><A NAME="00651" HREF="msg00651.html">[MUD-Dev] Re: async i/o and threads (was: Re: lurker emerges</A></strong>, James Wilson <a href="mailto:jwilson#rochester,rr.com">jwilson#rochester,rr.com</a>, Tue 11 Aug 1998, 04:20 GMT <UL> <LI><strong><A NAME="00655" HREF="msg00655.html">[MUD-Dev] Re: async i/o and threads (was: Re: lurker emerges</A></strong>, Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Tue 11 Aug 1998, 06:58 GMT </LI> </UL> </LI> </UL></BLOCKQUOTE> </ul> <hr> <center> [ <a href="../">Other Periods</a> | <a href="../../">Other mailing lists</a> | <a href="/search.php3">Search</a> ] </center> <hr> </body> </html>