<!-- MHonArc v2.4.4 --> <!--X-Subject: [MUD-Dev] Re: MUD Design doc (long) --> <!--X-From-R13: X Q Znjerapr <pynjNhaqre.rate.ftv.pbz> --> <!--X-Date: Wed, 23 Dec 1998 23:57:20 -0800 --> <!--X-Message-Id: 199812240121.RAA12387#under,engr.sgi.com --> <!--X-Content-Type: text/plain --> <!--X-Reference: Version.32.19981217101607.00e6b600#sendar,prophecy.lu --> <!--X-Head-End--> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <html> <head> <title>MUD-Dev message, [MUD-Dev] Re: MUD Design doc (long)</title> <!-- meta name="robots" content="noindex,nofollow" --> <link rev="made" href="mailto:claw#under,engr.sgi.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="msg01050.html">Previous</a> | <a href="msg01051.html">Next</a> ] Thread: [ <a href="msg00985.html">Previous</a> | <a href="msg01054.html">Next</a> ] Index: [ <A HREF="author.html#01049">Author</A> | <A HREF="#01049">Date</A> | <A HREF="thread.html#01049">Thread</A> ] <!--X-TopPNI-End--> <!--X-MsgBody--> <!--X-Subject-Header-Begin--> <H1>[MUD-Dev] Re: MUD Design doc (long)</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: MUD Design doc (long) </LI> <LI><em>From</em>: J C Lawrence <<A HREF="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</A>></LI> <LI><em>Date</em>: Wed, 23 Dec 1998 17:21:54 -0800</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 Thu, 17 Dec 1998 11:57:36 +0100 Emil Eifrem<emil#prophecy,lu> wrote: > At 04:31 AM 12/17/98 , J C Lawrence wrote: >> Should there actually be *ANY* distinguishing features between >> NPC's and players other than the source of their actions? There >> are good reasons for both approaches and reasonable design >> methods to salve most of each other's problems. > What good reasons are there for separating NPCs and PCs? The usual argument is simplicity and performance. By making them the same you remove the possibility of using short-circuit logic in your NPC's or their AI's, thus imposing extra logic which is really only needed for players and their typoes, command goofs, guess-the-verb-games etc. By devolving NPC's to a simpler form you can bypass that and present a much simpler and in many ways more elegant API to the NPC AI's. George Reese IIRC has written articulately on this in rec.games.mud.*, but I'm unable to find the reference right now. >> A well defined inheritance model can do wonders as can a good >> grammar, which brings up the questions: >> >> Central grammar and vocabulary? >> >> Standardised grammar at all? >> >> Per-object dynamic vocabulary? > Per-object dynamic vocabulary was quite extensively discussed in > an earlier thread that I read up on in the archives. Did you guys > reach a conclusion on a reasonable design? No. It has the advantage of simplicity on the server side, and the disadvantages of fostering bad-reuse, guess-the-verb games, and logical vocabulary inconsistancies. Both *can* be done equally well. The problem is the everlastingly fallable maintenance, area, and user programmers. > It may be too game specific a problem for a generic solution, I > guess. Quite. > I'm pretty ambivalent on this issue. It's a 'flexibility vs > consistency' matter for me: I want the flexibility of letting a > builder add the verb "smell" to a mob's (or character or any > Living) vocabulary when the mob picks up a flower. But I strongly > dislike the fact that if I drop the flower and walk into another > room, "smell" would give a "Huh!?". Ditto. My current approach is a global vocabulary and grammar, and local overloaded definitions. > The other consistency problem (which that thread opened my eyes > to) is the case when you have a zillion buttons in the world which > all add the verb "push" to your vocabulary and respond > accordingly, except one tiny little one built by NewbieJoeBuilder, > which responds to "press." No fun. Bingo. > The last problem can be solved administratively. One approach is > to maintain a list (a physical document, not a data structures > list) of different types of objects and the verbs they shall use > for different actions. (Such as "buttons: if a character push it, > add the 'push' word to its vocab".) Allowing vocabulary to be part of the inheritance tree (cf Cold) such that objects inherit their verbs from the parents can go a long way. There are ugly problems with multiple inheritance and verbs of course, as well as multiple base objects, but that's another crusade. > That approach would soon get unreasonable -- both for the > NewbieJoeBuilder who needs to look through a monstrous file for > every lil object he builds and for > ExperiencedJackMaintainerOfTheList who has to maintain the dang > thing and update it as new object types come along in the game. <nod> Making a useful set of base verbs on your base classes and then inheriting them into the instanced children *can* do a lot to handle this. It can't do it all, but it helps. > One could also have a head builder that walks through all areas to > check the dynamic vocabulary but that does tend to hamper > productivity. And such administration scales wonderfully. > What solutions are there for #1? I had some thoughts along the > line of instead of removing the verb from vocabulary, just cancel > the action and replace it with a can't-find-it message. So typing > smell in the other room (w/o a flower in it) would give you a "But > you've dropped your flower!" or whatever message. It took me a lot of brain beating, but I finally game up on per-object vocabularies (I was a big proponent for its simplicity effects). Using a global vocabulary with default (crude) definitions and well defined and dynamic contextual overloading of those base definitions current seems the way to go for me. I haven't cut code there *yet*, but the design seems basically sound once I get a decent context analyser mapped out. > Or maybe just for every character (/mobile/etc) object keep track > of the item last associated with a dynamically added verb. So > "smell" with an absent flower would give a "You don't see a flower > here." message. Uhh huh, > l There is a flower and shot cow pies here. > smell The cow manure smells something horrid. > get flower You pick up the flower, kneeling in the manure in the process. > drop flower > n > smell You don't have the flower any more. >> Rules for genating precedence and grammar rules with dynamic >> vocabularies? >> >> Is grammar a dynamically inherited structure across objects? > So Sword would inherit the grammar of Weapon? Hmmm... Bingo. See Cold/ColdX for a working example. > I'm not even sure how, and why, having dynamic grammar attached to > objects would work. Pros and cons, anyone? And how? I'll bow out here to the various Cold people on the list. > [timing in combat:] >> In #1 each player action (eg "bash buffa") takes a preset length >> of time, and prevents the player character's motions/actions >> during that time. >> >> #2 is a little different. Players submit the actions that their >> characters are going to perform in the next "round", where a >> round is a known and predefined length of time. At the end of >> the round all the various actions by the various players are >> resolved against each other (the action and round resolution >> logic can be quite complex -- see the combat package threads in >> the list archives) and the final results computed and reported >> before the next round starts and the players again submit their >> intended actions. It is common with round systems for player >> characters to operate under a quota system, where each of their >> proposed actions has a quota value and their total must not >> exceed some maximum. See Jon Lambert's posts on his (IIRC) round >> based combat system for some interesting design notes on this >> area. >> >> #3 is where I've been heading, while mixing in generous dollops >> of #1 and #2. Loosely, each character does whatever he can as >> fast as he can with the limiting factor being the execution time >> of his various actions and the speed with which he can submit >> them. Arguments about fairness are of course rife with this >> approach. > Ack. Haven't your players heard of tintin? Yes. Its not necessarily a problem with untimed combat. One of my pet criteria is that any game which can be usefully automated has demonstrated the failure of its design. > Surely you must have some way to delay a player's queing commands > while they're busy doing something else. For example, say you have > a spell that causes damage. According to the above, a fight > between two people with this spell would basically be a fight > between their clients and connections -- whomever gets through > most "cast my damagespell" messages would win. Not quite. Wiggins has already given simple cases where this is not the case. > This doesn't sound feasible, so I assume that you do have > individual delays after commands. I think that's what you mean > with the limiting factor being the execution time of various > actions. So the execution time for cast damagespell would be > pretty high and thus not unbalance the game. I don't see how > that's different from 1? Aside: One of the reasons I'm not concerned about inter-client/lag_balance wars is that I actively encourage and support free user programming. As such, players are free to program their own combat code/scripts/packages to automate whatever they may wish. The result? Yes, many combats will derive to who has the better/faster/luckier combat automation. I don't see this as a problem. As for timing of individual acts, no I don't control this, and I do assume that similar actions performed by two characters are likely (this is not true BTW, but I assume it anyway as the exceptions are either generally realisitic or prone to amusing and interesting abuse by players) to execute in similar lengths of time. Further, while a player's commands normally execure serially, they can execute in parallel (player character doing multiple things at the same time). I do very little to restrict this other than factoring it into the luck and sloppiness fields (a parallelly executed command suffers runtime penalties). The result? Yes, from one viewpoint the question is who can enter the most commands most rapidly. However that's a false viewpoint as the combat structure is heavily predisposed to tactical reactions (ie very interactive and supportive of prior preparation) as versus a simple pile-on-the-hp's. A player character coming in swinging a broadsword as fast as he can might get a couple whacks in -- until his opponent freezes him and then disects him at leisure while the attacker's command buffer empties. Even if the attacker notices the freeze, by the time he cancels his command buffer and usefully reacts it is likely to be too late as his opponent now has the timeing advantage. > [independent time ratio:] >> > stats You are 10 days old. >> > stats bubba Bubba is 10 days old. >> > stats boffo Boffo is 10 days old. >> ...play the game for a while... >> > stats You are 50 days old. >> > stats bubba Bubba is 30 days old. >> > stats boffo Boffo is 168 days old. >> >> I don't however see this as a problem > This is the approach used by most DIKU-derivatives. There are two main differences: 1) Nobody logged off in the above example. 2) I don't remove characters from the game when their players logout. > In my experience, players will acccept unrealistic things as long > as they are consistent and at least somewhat logical. Most of our > wacky magical systems being a good example. Quite. For me time is one of the things a player can causitively affect in his game environment, both for himself and for other characters. Temporal inconsistencies are the expected norm. -- J C Lawrence Internet: claw#kanga,nu (Contractor) Internet: coder#kanga,nu ---------(*) Internet: claw#under,engr.sgi.com ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... </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="00979" HREF="msg00979.html">[MUD-Dev] Re: MUD Design doc (long)</A></STRONG> <UL><LI><EM>From:</EM> Emil Eifrem <emil#prophecy,lu></LI></UL></LI> </UL></LI></UL> <!--X-References-End--> <!--X-BotPNI--> <UL> <LI>Prev by Date: <STRONG><A HREF="msg01050.html">[MUD-Dev] Re: Graphic design, client questions</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg01051.html">[MUD-Dev] Terragen</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg00985.html">[MUD-Dev] Re: MUD Design doc (long)</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg01054.html">[MUD-Dev] MUD Design doc - Combat</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="index.html#01049"><STRONG>Date</STRONG></A></LI> <LI><A HREF="thread.html#01049"><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: MUD Design doc (long)</STRONG>, <EM>(continued)</EM> <ul compact> <ul compact> <LI><strong><A NAME="00975" HREF="msg00975.html">[MUD-Dev] Re: MUD Design doc (long)</A></strong>, J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Thu 17 Dec 1998, 03:31 GMT <UL> <LI><strong><A NAME="00979" HREF="msg00979.html">[MUD-Dev] Re: MUD Design doc (long)</A></strong>, Emil Eifrem <a href="mailto:emil#prophecy,lu">emil#prophecy,lu</a>, Thu 17 Dec 1998, 11:00 GMT <UL> <LI><strong><A NAME="00984" HREF="msg00984.html">[MUD-Dev] Re: MUD Design doc (long)</A></strong>, Adam Wiggins <a href="mailto:adam#angel,com">adam#angel,com</a>, Thu 17 Dec 1998, 20:14 GMT </LI> <LI><strong><A NAME="00985" HREF="msg00985.html">[MUD-Dev] Re: MUD Design doc (long)</A></strong>, Mik Clarke <a href="mailto:mikclrk#ibm,net">mikclrk#ibm,net</a>, Thu 17 Dec 1998, 20:27 GMT </LI> <LI><strong><A NAME="01049" HREF="msg01049.html">[MUD-Dev] Re: MUD Design doc (long)</A></strong>, J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Thu 24 Dec 1998, 07:57 GMT </LI> <LI><strong><A NAME="01054" HREF="msg01054.html">[MUD-Dev] MUD Design doc - Combat</A></strong>, Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Tue 29 Dec 1998, 08:28 GMT </LI> </UL> </LI> </UL> </LI> </ul> <LI><strong><A NAME="00980" HREF="msg00980.html">[MUD-Dev] Re: MUD Design doc (long)</A></strong>, Koster, Raph <a href="mailto:rkoster#origin,ea.com">rkoster#origin,ea.com</a>, Thu 17 Dec 1998, 15:15 GMT </LI> <LI><strong><A NAME="00988" HREF="msg00988.html">[MUD-Dev] Re: MUD Design doc (long)</A></strong>, Caliban Tiresias Darklock <a href="mailto:caliban#darklock,com">caliban#darklock,com</a>, Thu 17 Dec 1998, 23:12 GMT <UL> <LI><strong><A NAME="00991" HREF="msg00991.html">[MUD-Dev] Re: MUD Design doc (long)</A></strong>, Thinus Barnard <a href="mailto:thinus_barnard#bigfoot,com">thinus_barnard#bigfoot,com</a>, Fri 18 Dec 1998, 12:57 GMT </LI> </UL> </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>