[MUD-Dev] Re: DevMUD Objectives?

[Darrin Hyrup]

At 01:45 AM 10/31/98 +1100, Thandor wrote:
>On Fri, Oct 30, 1998 at 01:54:38PM +0100, Niklas Elmqvist wrote:
>> 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 don't want an instant diku ... if I wanted one I'd run a diku. ;)

But I think the point he was making is, you COULD if you wanted to.  And
any other Diku admin's could probably do the same thing and move their
codebase over without having to start over.  Thus getting all the benefits
of the new server design, with the familiarity of the Diku operation.

>I'm just of the opinion that a simple system isn't necessarily a bad one. A
>system that does a limited number of things well is a whole lot more useful
>than a system that does everything only so-so, is it not?

The 'overall basis' for this project is that it would be made up of several
simple generic code modules, and put together in a way that gives the mud
admin and programmer as much flexibility as possible.  Aside from the
kernel itself, almost all useful functionality will be module-based, and
abstracted enough that just about anyone could recode a module (or create a
new one) if they desired to do so.  Another goal of this project was
education... to raise the 'state of the art' in mud development a bit.  We
plan to document the progress of this design and implementation so people
who are paying attention should be able to follow along and pick up some
new skills along the way.  And new mud admins/programmers will have a solid
base to begin hacking on.

>Maybe I'm the only one who doesn't like the idea of components I don't
>understand running the show - I'd kind of like to think that if there's
>something missing from the system that needs to go at a low level I'd be able
>to do something about it. I'd hate my mud to be at the mercy of the server
>"vendors", even if the vendors are reasonable people from the mud-dev mailing
>list. ;) When it comes down to it, I'd rather write something of my own from
>scratch than use something someone else has writen but I don't understand, at
>least if it's for something like a mud. After all, I think opening a mud to
>the public is a serious step and not something to do if you don't understand
>what you're doing.

There is no reason you should have to be in the dark about the compenents
of the game environment.  Each should be simple, streamlined, designed for
a specific goal, and should have a source module that you could edit and
recompile yourself if you need to change something.  Of course, the kernel
itself (which should be very tiny, not much more than a signal/event
handler, message handler, module manager, and thread manager) should
probably not need to be tweaked itself once the core is solid, but there
would be nothing keeping you from doing so if you really wanted to.

>I guess I'll just never have faith in someone else's work if I'm going to be
>the one that's going to look bad if things go wrong. If I have a hope of
being
>able to fix the problems, then that changes my mindset quite considerably. ;)

The point is not to keep people from getting involved in the mud, but to
make the interface such that anyone could add any kind of functionality in
a generic manner, which you could then put up on a library site somewhere
so others could benefit from your work.  So, if you made a "D&D combat"
module, you could put that up for others to enjoy... if they wanted to.  If
you don't want to use a module, you are not forced to do so.  If you don't
like how it works, you can change it.

>> 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
>
>Of course there has to be some degree of abstraction. But I'd like to be able
>to have enough understanding of the black boxes to be able to change the way
>they work should I need to. I doubt anything anyone can say will ever
convince
>me I'll never under any circumstances want or need to change the way any part
>of the system works.

The abstraction layer is more along the lines of keeping the low-level and
high-level code seperated by a logical barrier.  That way,
newbies/non-programmers can come in and change things, using a simple set
of tools (perhaps the internal mud language) and not have to be aware of
the low-level details.  However, skilled programmers could then go in and
modify the modules themselves, at as low of level as they feel is
appropriate.  The kernel itself would be abstracting most of the really
low-level calls anyway, so the modules could rely on a set of
OS-independant abstracted interfaces to do their job.

>> 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.
>
>I realise that much. What I'm saying is that the fact it lets me avoid 30
>seconds downtime every few days isn't a compelling reason to bother with such
>a system. But if there's another reason to go for such a system, then hell
>yeah, I'll take this benefit.

In the commercial arena, you don't ever want a downtime... even a 30 second
one.  That pushes people away... and after the reset, you can usually
expect at least 25% of those people will have found something else to do in
that 30 seconds of waiting time... thus losing some revenue.  Of course,
this matters more in a pay-by-time system rather than a pay-by-month
system, but if you bave to reset your system a lot to make changes, it will
affect your playerbase since people don't like to wait for (or be
inconvenienced by) something they are paying for.

>> 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.
>
>I'll admit my bias is towards what I know and love - diku. From what I've
read
>on this list, it's kind of like a dirty word, but for whatever reason I like
>it. *shrug* But I'm not a fool, I can see the at times huge flaws it has, and
>want something better.

Well, thats a good attitude to start with. ;)

>I don't find interactions with the environment in any mud to be particuarly
>interesting, after a certain point. Lets face it - the AI you can implement
>given the constraints of the mud environment and the hardware it runs on is
>pretty limited. In many ways, I find the more that you try to cover that fact
>up, the more you notice how poor the interaction is. Hence making mobs
>"smarter" has never been something I've aspired to do.

The beauty of the system we are proposing in DevMUD is that the admin can
decide just how extensible they wish it to be.  If they don't want online
coding, they don't allow that.  If they want a programmer to modify
something in the game, the programmer only needs to worry about one module,
or writing some internal language code.

The other major advantage of an internal programming language is that when
changes are made, bugs won't crash the server.  The VM can catch exceptions
and pass them back to the coder with some debug information, and not affect
the rest of the players.  To me, this is one of the biggest advantages,
since even with the plug-in modules, if there is a bug, they can easily
cause the server to go down in flames.

>> 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.
>
>Yes, but you can do that with diku if you want to hack the code hard
enough. I
>guess it comes down to what I touch on later - will the mud language make my
>life easier? That's what *I* want from a mud language - I'd be interested to
>hear what other people are looking for.

Well, from personal experience I can say that a mud with online coding
capability is much more flexible (and thus has the potential for being much
more interesting) than a hardcode mud.  Now, I can say this because my
primary server is hardcode (and has been running for a decade now)... it
runs great and does what its meant to do, but I don't think it is perfect
by any means.  I've also worked on servers with an in-game language, and if
set up right, they can do things I wouldn't imagine trying to do in
hardcode.  Not to mention, online coding can relieve some of the
programmer's burden, since one (or rarely more) programmer is generally not
as productive as a team of online scripters with a mission, and together
they are a lot more productive.  It allows you to do things like have the
main mud programmer work on low-level aspects of the game core, while the
game staff (GMs, etc.) develop the world and write the mob AI, code quests,
create custom coded magic items, et al.  Both 'teams' working independently
and efficiently.  In a hardcoded mud, anything not available to the objects
in the game by way of flags or other settings requires the coder to get in
there and start changing things, which means more potential bugs and at
least some downtime.  Some hardcode muds have triggers and event scripts
and such, but those are another kind of online programming, just a basic form.

>In a very well maintained system, then I think yes it could save work. But
>only having hard code at least puts everything in one place, and
maintained by
>a relatively small number of people. I think that helps to reduce needless
>duplication of code. I could be wrong, I'm just speculating again...

It also means that the whole game (players and staff) has to wait for the
programmer to do code anything special that needs to be added to the game.
If the programmer is sick, or busy with work, or otherwise cannot devote
their time to the mud, the rest of the game suffers or has to 'make due'
without the change.  The alternative allows the game staff (and/or players)
to extend the game system themselves, and eliminate the 'single point of
failure' problem predominant in group environments when a team has stop
everything while they wait for one person to do something.

>> 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. 
>
>I think we have a difference of semantics here. I'm refering to DevMUD as
>pretty much the main module set - bootstrap, config, parser, network, virtual
>machine. And others I've no doubt neglected to mention. I think you're
talking
>about the DevMUD "core" so to speak. I assume that the plan is to release
>DevMUD with some sort of game language, as it would defeat the purpose to
just
>release a DevMUD core and make everyone write everything else from scratch.

Thats pretty much it.  The core/kernel of the system will be very tight,
streamlined, and simple.  Its whole duty will be just servicing the modules
in the environment.  Without the modules, the kernel will not be very
useful.  All the tangible functionality will be built into the modules
themselves, and the choice of which modules are used and how they are
combined will determine the appearance of the mud itself.  There will be
some modules that are probably used by everyone... network i/o for example,
but the choice of parser (if any), database (if any), internal language
compiler (if any), and other interface or environment modules (if any) will
be completely up to the person setting up the mud, and can be changed
without notice at any time.

>So the game language/virtual machine is a major part of the system, even
if it
>can be replaced by another, different but equivalent, part.

In my opinion, the VM should be part of the core system, but it doesn't
have to be, if you don't have any use for it.  Like if you want to use the
'diku mud plug-in' you wouldn't really have to have a VM to service it,
although it could be useful.

>> 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. 
>
>I don't dislike them. I want a mud language. I just want one that's going to
>be worth the effort to learn - preferably one that doesn't force me to write
>my own compiler to achieve that.

Ideally, I'd like to see a mud-language which is designed to act sort of
like stage directions for the actors in the mud... with some problem
solving capabilities too, of course.  It should be simple to understand,
written in a human interpretable language, and tailored specifically for
doing things in the mud.  This way I could give this to my game staff and
have them handle the monster AI, quests, and some parts of the mechanics
without really having to be programmers.

I expect we'll probably end up with several mud-languages, each with their
own goals and styles, yet all sharing the same virtual machine.  So, we
could have the 'actor language' above along with an 'implementor language'
for hardcore programmers to use to do more sophisticated programming with,
and perhaps add a simple 'player language' for their own things, etc.  All
on the same mud server, and completely invisible to the players.

>> Okay, you will probably receive some kind of response here from certain
>> people that we want "an application server not a mud server!" ;)
>
>Then you've no longer got a mud OS at all ... and you may as well base your
>kernel on the linux kernel or something. ;)

We've been looking into that idea.  Using a real OS microkernel as a basis
for the server core.  I've looked at several myself, for example.  Muq uses
the same concept, although I think their microkernel is custom, not based
on an existing microkernel.

>> 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?
>
>Plug and play mud? Hmm, the natural evolution of "a stock mud with snippets",
>is it not? Internet game server is a pretty large scope. That ranges pretty
>much from a quake server to net-tamagotchi. Neither of which really come
close
>to being muds. Personally, I don't think being a little more specialised than
>that is going to hurt.

Why worry about it?  If we leave the details of the game up to what modules
are connected to it, what is there keeping us from running a quake like
game next to a net-tamagotchi, next to a generic text frp, next to a full
blown 3d virtual immersion game?  Nothing but the imagination of the people
putting the server together, and how much custom code they want to write. :)

>What I was referring to with the taking modules was that I recall someone
>saying something about people being able to take the DevMUD telnet module
(for
>example) and write some non-mud related program around it. I'm saying that
>while if that works out to be possible, then that's all well and good, but I
>don't think it should even come close to being a design goal.

The modules themselves should be independent but the server kernel supplies
an API layer that allows them to communicate if needed.  That way, anyone
could write any kind of module they like and use that to communicate with
the rest of the modules in there.  If they want to make a non-mud based
game, thats up to them.  We're primarily aiming at the MUD world, but that
doesn't mean we should exclude anyone else.  We're just providing the
workbench and the tools, and its up to others to use them, or make new
tools if they don't see one they need.

>And who's saying that stuff like storage systems can't make my mud different?
>If my mud's storage system consisted of /dev/null it'd be pretty
different. :)
>Seriously though, I can imagine tweaking the parser module and storage system
>module as part of the customisation process. Network I/O and event manager
are
>harder to imagine, but still a possibility. Maybe I'm not thinking generic
>enough?

You should be able to customize any module you like, however you want to do
so.  But in most cases, most things I would expect people to change would
be more suited for their own modules than changes to the low-level modules
or server core itself.

>> 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.
>
>Thinking about it again, it's probably a requirement to try to be as generic
>as possible with the low level stuff. After all, I'm guessing that stuff is
>going to get writen that is dependent on the idiosynchrisies of other
modules,
>effectively forcing you to use X if you want to use Y. The only thing worse
>than being forced to use X is being forced to use X and X doesn't do what you
>need.

Yes, the system is supposed to be generic as possible, but the way the
module system is invisioned, modules should be self-contained (as much as
possible) and if they do require another module for support, then that
module serves a purpose that you do need, otherwise you wouldn't need the
original module.  We don't want to see server bloat based on over-use of
module inheritance / module dependancies.  At least, none of the code
modules should suffer from this, but there is no way to keep other
developers from making poor choices.

>> 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. 
>
>Maybe I was misinterpretting that then. My mistake. Though I think no matter
>what you do, you're going to restrict developers somewhat. It's chosing how
>much restriction is reasonable that's the challenge.

Most things in life require decisions... any time a decision is made, you
are imposing a restriction of some kind.  Ideally, the restriction is a
beneficial one, but not always.  The goal is to try to make the decisions
that offer the best tradeoff of restriction vs benefit.  Software
development is no different.

>> 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 :)
>
>hehehe. Well, I'm glad you say half the stuff is over your head, I don't feel
>quite so stupid now. ;)

I don't think any of us really understand all the concepts that have been
thrown around in here.  I always learn new things based on what I read
here, links people post, etc.  Thats why part of the goal is to document
the project as an educational experience, such that anyone who wishes to
can learn how every aspect of the game works, and why.  And by going
through the archives, they can find out the history of how things ended up
they way they did.

>Maybe it's a good thing. I'm a worrier though. What if someone goes ahead and
>implements their brilliant design, that only they understand. What happens
>when they lose interest in DevMUD? Who want's to try to decipher what the
heck
>they did to fix any bugs there? You go too far out on the bleeding edge and
>you cut yourself, you know.

Thats why we're working together... it isn't a single person's design or
concept.  Its a group project with many contributors.  If someone bows out,
their work will remain credited, but the team will make up for the loss by
spreading the load or someone else will step up to replace them.
Hopefully, we can maintain the group cohesiveness long enough to get a
basic server toolkit together, a running test server with a simple world,
and then people can break off to work on their own extensions.

Changes will be documented, so there should be no need to try and decipher
what one person does.  Of course, any 3rd party modules may not follow this
design goal, but we can't worry about them.

<whew!> long post.

>- Shane King/Thandor.

Best,

Darrin