<!-- 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, 16 Dec 1998 19:31:34 -0800 --> <!--X-Message-Id: 199812170331.TAA10828#under,engr.sgi.com --> <!--X-Content-Type: text/plain --> <!--X-Reference: 3674C665.832CE7E2#bigfoot,com --> <!--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="msg00974.html">Previous</a> | <a href="msg00976.html">Next</a> ] Thread: [ <a href="msg00964.html">Previous</a> | <a href="msg00979.html">Next</a> ] Index: [ <A HREF="author.html#00975">Author</A> | <A HREF="#00975">Date</A> | <A HREF="thread.html#00975">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, 16 Dec 1998 19:31:22 -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 Mon, 14 Dec 1998 10:03:50 +0200 Thinus Barnard<thinus_barnard#bigfoot,com> wrote: > I am sure that it does not need to be codebase specific. You can > do different HOWTOs for the core parts of a MUD. Say HOWTOs on the > following: > Networking and sockets: Just a basic explanation of what routines > you need. Say you need a NewCnct routine that informs the library > that a new connection has been established and a new player object > should be created and a login handled. Then you need a routine for > when an error occurs, a routine for when a connection is dropped > and a routine to send a message to the socket. This document can > then also take a look at what pitfalls to avoid, general problems > with sockets, binary approach, etc. An excellant idea that is absolute murder to do in practice without great self discipline in yourself and all the other code maintainers. (Don't imagine for a second that commercial code shops haven't faced and lost to the same problems). It is too easy to fix or extend the current code and not update the design docs accordingly. That's why maintenance programmers are so scorned and get (sometimes) get paid the big $$$. It is already tough enough to get code maintainers to keep the comments updated with the code -- you think they are going to keep a secondary and physically unrelated document up to date as well without threats of bodily harm? It is exactly this problem that most of the literate programming tools and standards were evolved to solve: essentially specially formatted and tagged comment strings embedded in the code which a standard tool can extract and create useful documentation from (Knuth IIRC did one of the early ones, extracting TeX documents from the subject source). There are quite a few such. The only requirement then is that code maintainers (and the original developer) keep the comments up to date with the code -- a far more reasonable demand than that they maintain the source, the comments, and the design doc, human nature being what it is. I actively dislike such code documentation tooks as I find they make the code too difficult to read as _code_, and not very easy to read as _documentation_ without extracting the documentation from the code. YMMV. I prefer embedding large blocks of discussionary comments in the code which attempt to explain what is going on and why at an algorithmic/design level, and then let the revision control system comments track the minor stuff (context diffs are a wonderful friend). > Command handling: How to implement commands in your mud. When and > where should a command be handled? This assumes that you have a central command processor, and implies that commands process within a larger inherited command or process context. Neither is necessarily true. Murkle, for instance, rune commands as independently scheduled stand-alone independent threads with no synchronisation between threads and precious little inherited process environment (specious argument as to whether they even *have* a process environment). As such commands are not handled, they are run as autonomous competing processes. $ fgrep fprintf *.c & > Should NPCs and players have different command sets? 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 about free text commands? Some questions to address in a > command handling doc. Can also be more specific with a design of a > command handling system with the focus on how easy is it to use > and add new commands, how easy is it to customize commands and how > much can code duplication be reduced. 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? Rules for genating precedence and grammar rules with dynamic vocabularies? Is grammar a dynamically inherited structure across objects? Single/multiple inheritance with what precedence rules? > Timing: The first time you need a timing system will probably be > for combat. Combat for me is still largely an untimed system. It also doesn't work they way I'd like (see the lsit archives for very extensive threads on my various thoughts on combat systems). Roughly the common models break down to: 1) Timed action 2) Timed rounds with action limits per round 3) No time controls 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. > Also for weather, seasons, scheduling of mud events, etc. How to > implement a system that can handle all these timing issues and > still be flexible enough to add custom timing routines? There are two definitions of time: -- in-game in-world time -- real time They are typically not synonymous, and their ratio need not be fixed and need not be explicitly depended on. This is an early design decision which affects a very large range of other bits of the game. In fact, you don't actually need to define that there *is* a universal in-game in-world time. A side effect of the system I'm working with for Murkle is that the rate of time passage is individual and dependent on what is happening about that character at any instant. Yes, this means that the following is possible: > 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 > Combat system: This will be more specific. The combat system will > integrate with the timing system. Ahem. It *may* integrate with the timing system. It doesn't have to. > The combat system must determine what amount of damage is done, > what messages to display to the different characters involved in > the combat, what attibutes is necessary for weapons and for > armour, etc. Not so fast. No, the combat system does not need to decide what messages are displayed, and it is easy to argue that in fact it *NEVER* should be involved with presentation layer concerns like message texts. Another approach is to have the individual character objects receive messages (message in the programming/massage-passing-architecture sense) from the combat system and then derive from there how or if to present present that data to their players. The combat system is a set of mechanics that controls how combat is processed. You can muddle the presentation layer in there, but it is exactly that, a muddle, and that approach removes significant flexibility. Further, the details of the machanics of armour and weapons really are not the concern of the combat system either. That's data computation stuff, not process mechanics. Think "algorithms", and "process flow", not "how does the plate mail affect the war axe?" > This will differ a lot from mud to mud. Maybe a few different > systems can be discussed in this doc. Aye, we've hit many of them here in this list and haven't come anywhere near to exhausting the field. I *still* haven't come up with a combat system I think is usefully playable. > Skill system: Also very specific. There will be several designs > dealing with classes, races, skills, spells, levels, experience, > etc. The core of a few systems can be listed to give an insight to > the different types of approaches. Skill trees, single or multi-rooted, or skill webs, or a hodge-podge of intersecting trees and webs, or simple linear progressions of names sets with current state being an amalgamation of all the scalars. > Player object: What should all go into the player object? Should > it be very different than your NPC object? Should you have a > different login object and a different player object? What > physical statistics do you need for a player object? Other levels of seperation enclude: login account from player character player character's family/clan/regiment from individual player character player character from character body I, for instance, seperate the account from the character from the body/bodies it controls. I also don't distinguish at all between NPC's and player characters. The bodies of course are all the same between them.. > NPC object: How to do guards. How to do mobiles. How to do AI. Are guards really a special case? Are mobiles any different than NPC's? Are NPC's really any different from any other object? Why? There's a fairly obvious difference between an inanimate and uninteresting rock in a game, and a ferocious dragon. But, at the code and design level, need there be any difference between that dragon and a magical intelligent sword? > PS: Another example of a design doc can be found at > URL:<A HREF="http://www.cd.chalmers.se/project/so2403/so2403_toc.html">http://www.cd.chalmers.se/project/so2403/so2403_toc.html</A> Ahh, good one. -- 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> <ul compact><li><strong>Follow-Ups</strong>: <ul> <li><strong><A NAME="00979" HREF="msg00979.html">[MUD-Dev] Re: MUD Design doc (long)</A></strong> <ul compact><li><em>From:</em> Emil Eifrem <emil#prophecy,lu></li></ul> </UL></LI></UL> <!--X-Follow-Ups-End--> <!--X-References--> <UL><LI><STRONG>References</STRONG>: <UL> <LI><STRONG><A NAME="00964" HREF="msg00964.html">[MUD-Dev] Re: MUD Design doc (long)</A></STRONG> <UL><LI><EM>From:</EM> Thinus Barnard <thinus_barnard#bigfoot,com></LI></UL></LI> </UL></LI></UL> <!--X-References-End--> <!--X-BotPNI--> <UL> <LI>Prev by Date: <STRONG><A HREF="msg00974.html">[MUD-Dev] Re: AFAP: As fast as possible, non linear...</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg00976.html">[MUD-Dev] Re: DIS: Client-Server vs Peer-to-Peer</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg00964.html">[MUD-Dev] Re: MUD Design doc (long)</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg00979.html">[MUD-Dev] Re: MUD Design doc (long)</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="index.html#00975"><STRONG>Date</STRONG></A></LI> <LI><A HREF="thread.html#00975"><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: small dev-mud invite</STRONG>, <EM>(continued)</EM> <ul compact> <LI><strong><A NAME="00961" HREF="msg00961.html">[MUD-Dev] Re: small dev-mud invite</A></strong>, J C Lawrence <a href="mailto:claw#kanga,nu">claw#kanga,nu</a>, Mon 14 Dec 1998, 03:42 GMT </LI> </ul> </LI> <LI><strong><A NAME="00955" HREF="msg00955.html">[MUD-Dev] Re: Hex grids.</A></strong>, quzah [softhome] <a href="mailto:quzah#softhome,net">quzah#softhome,net</a>, Sat 12 Dec 1998, 18:58 GMT <LI><strong><A NAME="00952" HREF="msg00952.html">[MUD-Dev] Re: MUD Design doc (long)</A></strong>, Benjamin D. Wiechel <a href="mailto:strycher#toast,net">strycher#toast,net</a>, Fri 11 Dec 1998, 18:36 GMT <UL> <LI><strong><A NAME="00964" HREF="msg00964.html">[MUD-Dev] Re: MUD Design doc (long)</A></strong>, Thinus Barnard <a href="mailto:thinus_barnard#bigfoot,com">thinus_barnard#bigfoot,com</a>, Mon 14 Dec 1998, 07:51 GMT <UL> <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> </UL> </LI> </UL> </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>