<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] Re: DevMUD Objectives? -->
<!--X-From-R13: @vxynf Syzdivfg <q97ryzNqgrx.punyzref.fr> -->
<!--X-Date: Fri, 30 Oct 1998 04:58:08 -0800 -->
<!--X-Message-Id: Pine.SOL.3.96.981030130106.12928A-100000#licia,dtek.chalmers.se -->
<!--X-Content-Type: text/plain -->
<!--X-Reference: 19981030194701.A32559#donut,dhis.org -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, [MUD-Dev] Re: DevMUD Objectives?</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="msg00590.html">Previous</a>
| <a href="msg00592.html">Next</a>
]
Thread:
[ <a href="msg00589.html">Previous</a>
| <a href="msg00593.html">Next</a>
]
Index:
[ <A HREF="author.html#00591">Author</A>
| <A HREF="#00591">Date</A>
| <A HREF="thread.html#00591">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>[MUD-Dev] Re: DevMUD Objectives?</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: DevMUD Objectives?</LI>
<LI><em>From</em>: Niklas Elmqvist <<A HREF="mailto:d97elm#dtek,chalmers.se">d97elm#dtek,chalmers.se</A>></LI>
<LI><em>Date</em>: Fri, 30 Oct 1998 13:54:38 +0100 (MET)</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 Fri, 30 Oct 1998, Thandor wrote:
[Diku popularity:]
> I'll tell you why I think it's popular - it's simple. The design is
> simple enough to quickly understand. The code is simple enough to skip
> to pretty much any place in any source file and quickly grasp what is
> happening. Heck, you can get some sort of understanding as to how diku
> works without really knowing C. The simple design makes it easy to
> understand, and easy to modify - which encourages people to modify it.
Well, Diku has the advantage of offering a large amount of players a
roleplaying system they are familiar with -- AD&D (quite close, at least).
While there certainly is some merit to the claim that programmers are
drawn to the simplicity of the Diku codebase, I think the most dominating
single factor of Diku's success is that players like it (and it is pretty
well-suited to powerplaying, too). Simple as that. If the players like
it, the developers will follow suit and satisfy the demand (in addition,
many developers also happen to be players).
I can easily envision popping in a couple of Diku-style modules (command
and DB handlers should suffice) into a DevMUD platform (which already uses
a generic TCP socket module, a parser and a few other things) and voila!
Instant Diku!
> I think that should be the number one thing to keep in mind when
> designing and coding DevMUD - make it easy for someone to come along
> later and change it to their liking. I think it's a far more important
> thing that say, wiz bang features, or brilliant code, or pure speed.
> Mere mortal programmers like myself would like to be able to use it too
> - if you don't have that you end up with something that is useless to
> the mudding community as a whole. Sure, it might be the most modular,
> fastest, most advanaced mud ever dreamed of, but what good does that do
> anyone if everyone sticks to their diku muds that they can understand?
Hmm, I think we have a difference in semantics here. DevMUD (at least the
way I envision it) is *not* a MUD server -- it is a MUD server *platform*
(or even an application server platform, like some people would like to
put it...). A more accurate name of DevMUD would be to call it a MUD
operating system, but, unfortunately, MudOS is taken. :( So, even if the
driver level is *extremely* high-tech and incomprehensible (which I would
like it to be -- a driver should be lean and mean), the average Joe (or
Jane) programmer would not need to bother with it. All s/he does is
concern himself (okay, I'll drop Jane from now on) with how to change or
tweak a module, which is on a level of abstraction a couple of orders
higher than the level of the driver, to realize his dreams.
Granted, building a module-based MUD can be somewhat different from normal
MUD codebases. That does not mean it must be more *difficult*. In fact,
"normal" people tend to think in terms of black boxes doing stuff and
sending it on to other black boxes (at least before they become
programmers and lower themselves to the level of the machine they are
programming for), so this architecture might be easier to comprehend than
one large source tree. We humans like to abstract complex systems into
simpler modles so that we can comprehend it all. Telling someone that
"this is the socket/network module and you generally don't have to bother
with changing that" is *much* better than this someone having to sift
through a lot of code and try to mentally delimit the different "black
boxes" in the system. Plus it allows people that otherwise would be
daunted with the task of writing or at least tweaking network code to
start developing MUDs and bring their talents to bear in their distinctive
fields.
> Next point, and maybe my opinion is tainted here from my heavily diku-based
> background, but what is the aim of the internal mud language? I can think of a
> few reasons to want it, but only one that is really compelling:
> - It makes things modifiable on the fly. This is something the diku world
> doesn't have, but I can't see the big deal anyway. So you have to reboot
> every few days to add changes, it takes 30 seconds and many muds these days
> have copy-over which means players don't even have to relog.
Well, with a module-based system, you would *never* (at least not in a
perfect world) have to reboot your server even if you add changes. All the
functionality of the MUD is contained in the modules which are dynamically
loaded at run-time, so adding new stuff is as easy as recompiling the
module, unload the old one and load the new one into the executable.
> - You can give "non-techies" the capability to "code". This sounds great in
> theory, but all reports I've heard of how it works in practice is that
> nearly all the code gets writen by people who would have been writing the
> code anyway. So you've now forced them to learn a new language, and then
> write code that runs slower, and gained nothing.
I've had *very* positive experiences with non-techie programming in a
(from-scratch) MUD called DUMII. No numbers like Petri, but I'm not
exactly adminning the thing.
The *real* potential of MUD languages is that they add a whole new
dimension to the world. I take it you have not played much in a system
with a MUD-language? I am not trying to start a codebase war here, but
let's face it; a vanilla Diku server, even one with mobprogs installed,
has a pretty stale world. Sure, mobs move around and repop, doors can be
opened and closed, you can search for hidden entrances and stuff, but
that's about it. Having guards attack fighting players in the city forces
the implementors (at least people with source access!) to write special
functions to handle this in a language (C) not designed for the problem
domain.
With a good MUD-language, a *lot* of life can be breathed into a stale
world. I am sure that a lot of the LP folks out there have some tremendous
examples of this, but I'll just go on to tell you that MUD-language
programmed quests can so be much more than the "find the mobile" or "kill
that guy" quests so common on hardcoded MUDs. How about having to track
down a criminal in a large city by asking people, bribing guards,
following leads and so on? How about redesigning the laws of physics in
the whole world or in a specific area? And what about the issue of
implementing the Mage2Mage spell design language so that you can attach
small snippets of code to objects (activating the fire-essence of this
brimstone might allow me to channel more fire magic, for example)? All
this is possible, and much more.
> - The real potential advantage I can see: It may be faster to write code in a
> well designed, purpose built language. However, I think this goes pretty
> much against the design goal some people are advocating of maximising the
> flexibility of the system. After all, the more you target the language at a
> particular style of mud, the faster it is to work with, but the less
> flexibility you have, no?
Well, the virtual machine of the MUD-language will not be built into the
DevMUD platform. They will be provided in modules, and you could probably
add as many VMs as you like to the game. So if you want a language for a
text-based MUD, you go to the module central and download a VM for this
(if you can't find one, then you can probably write one on your own).
Actually, there is nothing to stop us from using the same general-purpose
VM module and then just implement different compilers to support a wide
range of languages. The VM would be the back-end and the compilers the
front-end (a lot could probably be shared among these compilers as well),
so you use different language syntaxes but they are all compiled to the
same bytecode.
For that matter, if you have a dislike for MUD-languages, there is nothing
to force you to add the VM module to your server. The language is just
another module in the MUD operating system.
> Which brings me to the whole modularity and flexibility concept. Some
> people have been advocating a very pure sort of approach, with very
> generic modules. While I agree in theory that is a good thing, but in
> practice I think it's counter productive to be too generic. At least,
> don't go to the extent that some people have been talking about - I
> don't think you should be able to use a module from DevMUD in a
> thoroughly unrelated system. A mud has some specialised requirements,
> and I think it would be better off keeping those in mind when
> designing the modules, rather than just making generic
> parser/telnet/bootstrap/config/etc modules and putting all the mud
> specific burdon in the game module(s). Yes, it's probably not as pure
> an approach, but I think it would keep things simpler and more usable
> in the context we expect them to be used - running a mud.
Okay, you will probably receive some kind of response here from certain
people that we want "an application server not a mud server!" ;)
I will not argue with you here, as I also want to target MUDs. However, I
believe we can widen the perspective a little and say "internet game
servers". And we are not saying that you could take just any module and
pop it into a DevMUD system. We are saying that you could take just any
DevMUD module and pop it into a DevMUD (maybe this is what you meant?).
If the new module is ignored by the rest of the modules in the system,
that's fine. But we want to be able to write generic network I/O modules,
storage systems, parsers and event managers so that they don't have to be
written *again*. Sure, we all like to tweak these things, but would it not
be nicer if they were available for download and would work through the
principle of plug-and-play, allowing you as a MUD developer to pour your
creativity into areas which would make your MUD different?
Of course, there is nothing to stop a module implementor for targeting his
module for a specific type of game servers. However, I believe it is
important that there is a possibility to write very general-purpose
modules.
> Finally, graphical vs text based. I'm yet to be convinced that making a
> mud that can be either graphical or text based is the way to go. Even
> assuming that someone designs the "all encompasing graphical mud module"
> that means everyone can work with only one graphics module in mind,
> wont allowing for both the text based and graphical clients mean that
> everything needs to be done twice, with regards to output? To me, that
> doesn't sound like much of a fun environment to be creating a mud in,
> having to do twice the work everywhere. I think deciding on a text based
> or a graphics based system would again keep things simpler, especially
> given that most muds will probably only want one or the other. I guess
> this comes back to flexibility - making DevMUD all encompasing sounds
> great, but is that an achievable or even desirable goal?
AFAIK, there has been no general discussion of supporting *both* text and
graphics in one game. However, the mud development operating system (ie
DevMUD :) should certainly *not* restrict developers to what kind of a
game they want to make. And besides, this argument pertains to the module
side of things, which is not what most of us have been discussing (sure,
we've all examined what kind of modules we need, but not much about
implementation details). The DevMUD driver must be powerful enough to
allow for all kinds of things.
> Maybe I'm missing something, but DevMUD is sounding more like a cool geektoy
> filled with as many neat coding tricks as possible than something that anyone
> is going to be able to use. The number of times people on this list who seem
> to be very knowledgable when it comes to mud design have replied that they've
> been unable to understand something, even at the very sketchy design level
> being worked on at the moment sounds like a warning to me.
Well, that's the cost of being on the bleeding edge! I know *I* don't
understand half of the discussions on this issue. However, I think we can
agree that most of the discussions have been in relation to the DevMUD
driver which should be (everybody) *lean* and *mean*. That means using all
the talent of people on this list and taking advantage of their expertise
in different areas. So far, I've just been able to bring up designs which
have been scythed down, so I am not sure how much help I've been... (No,
I'm not bitter... Not much, anyway :)
> I hope I'm proved wrong though. With all the talent on this list maybe I just
> need to have faith and not question the wisdom being thrown about. ;)
Oh, questions are good. With this project, which made me delurk for more
than a few minutes, I'm trying to question things all the time.
> - Shane King/Thandor.
-- 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="00593" HREF="msg00593.html">[MUD-Dev] Re: DevMUD Objectives?</A></strong>
<ul compact><li><em>From:</em> Thandor <thandor#donut,dhis.org></li></ul>
</UL></LI></UL>
<!--X-Follow-Ups-End-->
<!--X-References-->
<UL><LI><STRONG>References</STRONG>:
<UL>
<LI><STRONG><A NAME="00587" HREF="msg00587.html">[MUD-Dev] DevMUD Objectives?</A></STRONG>
<UL><LI><EM>From:</EM> Thandor <thandor#donut,dhis.org></LI></UL></LI>
</UL></LI></UL>
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00590.html">[MUD-Dev] Re: openmud: open issues</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00592.html">[MUD-Dev] Re: DevMUD: Inheritable modules</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00589.html">[MUD-Dev] Re: DevMUD Objectives?</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00593.html">[MUD-Dev] Re: DevMUD Objectives?</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00591"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00591"><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: DevMUD Objectives?</STRONG>, <EM>(continued)</EM>
<ul compact>
<LI><strong><A NAME="00611" HREF="msg00611.html">[MUD-Dev] Re: DevMUD Objectives?</A></strong>,
Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Sat 31 Oct 1998, 02:45 GMT
</LI>
</ul>
</LI>
<LI><strong><A NAME="00587" HREF="msg00587.html">[MUD-Dev] DevMUD Objectives?</A></strong>,
Thandor <a href="mailto:thandor#donut,dhis.org">thandor#donut,dhis.org</a>, Fri 30 Oct 1998, 08:51 GMT
<UL>
<LI><strong><A NAME="00588" HREF="msg00588.html">[MUD-Dev] Re: DevMUD Objectives?</A></strong>,
Petri Virkkula <a href="mailto:pvirkkul#iki,fi">pvirkkul#iki,fi</a>, Fri 30 Oct 1998, 11:11 GMT
<UL>
<LI><strong><A NAME="00589" HREF="msg00589.html">[MUD-Dev] Re: DevMUD Objectives?</A></strong>,
Thandor <a href="mailto:thandor#donut,dhis.org">thandor#donut,dhis.org</a>, Fri 30 Oct 1998, 12:08 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00591" HREF="msg00591.html">[MUD-Dev] Re: DevMUD Objectives?</A></strong>,
Niklas Elmqvist <a href="mailto:d97elm#dtek,chalmers.se">d97elm#dtek,chalmers.se</a>, Fri 30 Oct 1998, 12:58 GMT
<UL>
<LI><strong><A NAME="00593" HREF="msg00593.html">[MUD-Dev] Re: DevMUD Objectives?</A></strong>,
Thandor <a href="mailto:thandor#donut,dhis.org">thandor#donut,dhis.org</a>, Fri 30 Oct 1998, 14:49 GMT
<UL>
<LI><strong><A NAME="00595" HREF="msg00595.html">[MUD-Dev] Re: DevMUD Objectives?</A></strong>,
Darrin Hyrup <a href="mailto:shades#mythicgames,com">shades#mythicgames,com</a>, Fri 30 Oct 1998, 17:05 GMT
</LI>
<LI><strong><A NAME="00631" HREF="msg00631.html">[MUD-Dev] Re: DevMUD Objectives?</A></strong>,
Travis Casey <a href="mailto:efindel#polaris,net">efindel#polaris,net</a>, Sat 31 Oct 1998, 19:11 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
<LI><strong><A NAME="00616" HREF="msg00616.html">[MUD-Dev] Re: DevMUD Objectives?</A></strong>,
Hal Black <a href="mailto:hal#moos,ml.org">hal#moos,ml.org</a>, Sat 31 Oct 1998, 05:43 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>
