<!-- MHonArc v2.4.4 --> <!--X-Subject: [MUD-Dev] Re: PDMud, Gamora and Casbah --> <!--X-From-R13: @vxynf Syzdivfg <q97ryzNqgrx.punyzref.fr> --> <!--X-Date: Sat, 24 Oct 1998 16:31:29 -0700 --> <!--X-Message-Id: Pine.SOL.3.96.981025004610.6542B-100000#licia,dtek.chalmers.se --> <!--X-Content-Type: text/plain --> <!--X-Reference: 19981024123154.A7084#divcom,slimy.com --> <!--X-Head-End--> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <html> <head> <title>MUD-Dev message, [MUD-Dev] Re: PDMud, Gamora and Casbah</title> <!-- meta name="robots" content="noindex,nofollow" --> <link rev="made" href="mailto:d97elm#dtek,chalmers.se"> </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="msg00463.html">Previous</a> | <a href="msg00465.html">Next</a> ] Thread: [ <a href="msg00461.html">Previous</a> | <a href="msg00467.html">Next</a> ] Index: [ <A HREF="author.html#00464">Author</A> | <A HREF="#00464">Date</A> | <A HREF="thread.html#00464">Thread</A> ] <!--X-TopPNI-End--> <!--X-MsgBody--> <!--X-Subject-Header-Begin--> <H1>[MUD-Dev] Re: PDMud, Gamora and Casbah</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: PDMud, Gamora and Casbah</LI> <LI><em>From</em>: Niklas Elmqvist <<A HREF="mailto:d97elm#dtek,chalmers.se">d97elm#dtek,chalmers.se</A>></LI> <LI><em>Date</em>: Sun, 25 Oct 1998 01:28:23 +0200 (MET DST)</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 Sat, 24 Oct 1998, Jon Leonard wrote: > On Sat, Oct 24, 1998 at 07:19:46AM +0200, Niklas Elmqvist wrote: > > (Small voice: I still want to do it O-O. Wanto! Wanto!!! :) > > Those look like reasonable architectures, albiet ones that are fairly far > from the design I envisioned. It may be that we can't all agree on an > architecture (or implementation language, or mudlib, or...) and the > project will have to fragment at some point. Right. As it should, seeing that so many people with differing interests are interested in the project. The way I see it, the DevMUD effort is a project to accomplish the following basic goals: - raising the average MUD technology level in the community (i.e. advancing an unrealised future :) - give newbie MUD developers some good education material - providing a high-level platform ideally suited for MUD development (and indeed *any* kind of internet game server) I don't believe in creating "just another codebase" like Circle, Diku and so on. DevMUD should be a friendly environment for MUD development. Possibly the different module sets could be called "codebases". With these objects in mind, I am sure we can find a minimal set of primitives which allows us to do all this without limiting ourselves and the flexibility of the system. While I think Gamora seems to be extremely flexible, it is probably too flexible for our purposes. We need a "generic internet game server abstraction" not a "generic server abstraction". I am sure we can narrow down the specifications and lower the abstraction level (as well as the ambition level) to improve ease of implementation and efficiency. Of course, I realise that my own vision is likely to be different from most people's. :) Just my $0.02. > Some amount of fragmentation is good: We certainly don't want all MUDs to > be identical. The real question is where does DevMUD development fragment: > > Implementation language? Hopefully not as early as here. We are all above religious language wars. > Module format? > Module connection architecture? > Modules used? This is the point where I believe (and hope) development may defragment, but this is not an all-or-nothing step. Some of the modules (like network I/O, traffic directors, etc) are likely to be usable in just about any internet game server, while others (magic modules, on-line building, room-based movement, etc) are specific to MUD types. > In-game language? > Mudlib? These two we should at least provide examples for, such as a Diku-lib, a more modern coordinate-based model, perhaps, and, hopefully, also a graphical implementation. Of course, these are game world which will reflect in the module level, too. > Only in gameworld details after install? Perhaps we could introduce a "tech level" concept denoting how high or low a concept in the DevMUD project is located. That is, the driver would be at level zero, system modules (VM, module manager, garbage collector, etc) at one, game modules at two, etc. Just a thought. > What I'm trying to find is an architecture acceptable to a reasonably large > number of developers (including me!), so that we can more quickly build our > ideal MUDs. If there are people who don't like that design, and they form > an alternate development team, that's great. We'd wind up with more good > examples of MUDs, and it's still less total effort expended than without > collaboration. > > I'd be shocked if we all used the same collection of modules, and if we > fragment before that, at least we can still port code back and forth. > > So by all means, describe your ideal design. You may yet convince a design > team, and the rest of us probably want to see it anyway. Okay. I'll give a shot at describing it. It is a little rough around the edges and probably heavily flawed in some points. This design stems from my current project (MoleMUD, which I'll probably abandon/port if this comes to anything) and has taken form over a few months time with a lot of input from the list. - Implementation language is C++. - Design and analysis performed using OO A & D methods and notation. Use-cases, design patterns and UML strikes me as suitable (mainly because I'm reading a UML book right now :) Use-cases are especially useful when trying to come up with an adequate interface/mechanism for inter-module communication. I strongly recommend we use this even if we don't go for an O-O approach (I'm not talking Rational Rose here, plain pencil and paper has always worked fine for me). - Low-level core consists of a few basic primitives which are shared among virtually all types game servers: event manager - handles events (duh!) module manager - loads/unloads modules inter-module communication manager - The core defines a few very basic skeleton classes for redefinition in modules using external inheritance. Event (Execute(), IsRipe() methods, for example) Module (Connect(), Update(), HandleRequest(), Disconnect()) - Modules are, in fact, object instances of an externally inherited Module subclass. That is, when a shared lib is loaded by the module manager, it calls a factory function in the lib and gets a pointer to a Module object (which, in reality, is a subclassed Module object, such as class MagicModule). The module is provided with context by passing an instance of a Core class to it (which contains methods for using the event manager, the inter-module communication mechanism and module management). - Events, which are created by modules and passed to the event manager's scheduler, are externally inherited versions of the original Event class. This allows the event manager to treat them as Events, but to exhibit their own behavior when Event::Execute() is called. - Modules are boot-strapped by file name (from .devmudrc or whatever), and more may be added by sending signals or using in-game commands (and some kind of remote administration, but that's all contained in the modules). - Inter-module communication is carried out using a decoupled mechanism (cf Gamora Buses). IOW, modules do *not* know of each other at the beginning, but broadcasts their presence on a server-wide channel. Interested modules may create pipes or channels to the new module and use this for message passing. Pipes may be implemented in terms of a C++ class (neatest), function pointers (most efficient), or network sockets (for distributed systems). Possibly, all three could be supported. - Messages passed between modules are serialized according to a specification provided by the receiving module. That is, the magic module might say: "I first want a byte containing the spell code, then an int for the level of the caster, then a DB index for the target and caster." The parser module would follow this format when passing messages to the magic module. I'm not gonna go further up in the hierarchy than that, since this is the design I'm most interested in :) The lib, module sets and world I leave to others, at least for the time being (I'm still thinking about a graphical MUD using the Golgotha renderer...) > Jon Leonard -- Niklas Elmqvist (d97elm#dtek,chalmers.se) ---------------------- "The trouble with being a god is that you've got no one to pray to." -- Terry Pratchett, Small Gods </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="00473" HREF="msg00473.html">[MUD-Dev] OpenMUD: bus-based communications</A></strong> <ul compact><li><em>From:</em> James Wilson <jwilson#rochester,rr.com></li></ul> <li><strong><A NAME="00467" HREF="msg00467.html">[MUD-Dev] Re: PDMud, Gamora and Casbah</A></strong> <ul compact><li><em>From:</em> "Adam J. Thornton" <adam#phoenix,Princeton.EDU></li></ul> </UL></LI></UL> <!--X-Follow-Ups-End--> <!--X-References--> <UL><LI><STRONG>References</STRONG>: <UL> <LI><STRONG><A NAME="00459" HREF="msg00459.html">[MUD-Dev] Re: PDMud, Gamora and Casbah</A></STRONG> <UL><LI><EM>From:</EM> Jon Leonard <jleonard#divcom,slimy.com></LI></UL></LI> </UL></LI></UL> <!--X-References-End--> <!--X-BotPNI--> <UL> <LI>Prev by Date: <STRONG><A HREF="msg00463.html">[MUD-Dev] Re: PDMud thread summary</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg00465.html">[MUD-Dev] Re: PDMud, Gamora and Casbah</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg00461.html">[MUD-Dev] Re: PDMud, Gamora and Casbah</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg00467.html">[MUD-Dev] Re: PDMud, Gamora and Casbah</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="index.html#00464"><STRONG>Date</STRONG></A></LI> <LI><A HREF="thread.html#00464"><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: PDMud, Gamora and Casbah</STRONG>, <EM>(continued)</EM> <ul compact> <LI><strong><A NAME="00440" HREF="msg00440.html">[MUD-Dev] Re: PDMud, Gamora and Casbah</A></strong>, Caliban Tiresias Darklock <a href="mailto:caliban#darklock,com">caliban#darklock,com</a>, Sat 24 Oct 1998, 01:15 GMT </LI> <LI><strong><A NAME="00454" HREF="msg00454.html">[MUD-Dev] Re: PDMud, Gamora and Casbah</A></strong>, Niklas Elmqvist <a href="mailto:d97elm#dtek,chalmers.se">d97elm#dtek,chalmers.se</a>, Sat 24 Oct 1998, 05:22 GMT <UL> <LI><strong><A NAME="00459" HREF="msg00459.html">[MUD-Dev] Re: PDMud, Gamora and Casbah</A></strong>, Jon Leonard <a href="mailto:jleonard#divcom,slimy.com">jleonard#divcom,slimy.com</a>, Sat 24 Oct 1998, 19:36 GMT <UL> <LI><strong><A NAME="00461" HREF="msg00461.html">[MUD-Dev] Re: PDMud, Gamora and Casbah</A></strong>, Darrin Hyrup <a href="mailto:shades#mythicgames,com">shades#mythicgames,com</a>, Sat 24 Oct 1998, 21:46 GMT </LI> <LI><strong><A NAME="00464" HREF="msg00464.html">[MUD-Dev] Re: PDMud, Gamora and Casbah</A></strong>, Niklas Elmqvist <a href="mailto:d97elm#dtek,chalmers.se">d97elm#dtek,chalmers.se</a>, Sat 24 Oct 1998, 23:31 GMT <UL> <LI><strong><A NAME="00467" HREF="msg00467.html">[MUD-Dev] Re: PDMud, Gamora and Casbah</A></strong>, Adam J. Thornton <a href="mailto:adam#phoenix,Princeton.EDU">adam#phoenix,Princeton.EDU</a>, Sun 25 Oct 1998, 01:45 GMT </LI> <LI><strong><A NAME="00473" HREF="msg00473.html">[MUD-Dev] OpenMUD: bus-based communications</A></strong>, James Wilson <a href="mailto:jwilson#rochester,rr.com">jwilson#rochester,rr.com</a>, Sun 25 Oct 1998, 02:51 GMT <UL> <LI><strong><A NAME="00479" HREF="msg00479.html">[MUD-Dev] OpenMUD: bus-based communications</A></strong>, Niklas Elmqvist <a href="mailto:d97elm#dtek,chalmers.se">d97elm#dtek,chalmers.se</a>, Sun 25 Oct 1998, 08:39 GMT </LI> </UL> </LI> </UL> </LI> </UL> </LI> </UL> </LI> </ul> </LI> <LI><strong><A NAME="00432" HREF="msg00432.html">[MUD-Dev] Re: UO: Second Age</A></strong>, Koster, Raph <a href="mailto:rkoster#origin,ea.com">rkoster#origin,ea.com</a>, Fri 23 Oct 1998, 23:37 GMT </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>