[MUD-Dev] Re: DevMUD Objectives?

[Thandor]

On Fri, Oct 30, 1998 at 01:54:38PM +0100, Niklas Elmqvist wrote:
> 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).

Well, I can only speak for the way I play AD&D, but the similarity I see is
many dikus have a fantasy theme. Beyond that, not much. Meaning, race/class
names, and some spell/skill names have been adopted, but I'm yet to find a mud
that plays remotely like a tabletop game of AD&D. So I think that's more of a
theme issue than a server issue - you could take pretty much any mud and slap
a medieval fantasy theme on it.

I like diku because it's simple. Maybe I'm being too speculative when I guess
at that being it's reason for popularity. And do the admins follow players, or
players follow admins? I think that's a chicken & the egg problem. :)

> 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. ;)

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?

> 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.

MurpeOS? I don't know. :)

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.

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. ;)

> 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.

> 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.

> 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. 

Hmm, I must hang out at the disgruntled mudders club where nothing works as it
should then. Oh well, I take back anything I said about mud languages not
encouraging people to write code unless they'd write it anyway, that's
obviously highly dependent on the mud in question.

> 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.

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.

> 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.

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...

> 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.

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.

> 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.

> 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. ;)

> 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.

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.

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?

> 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.

> 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.

> 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. ;)

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.

- Shane King/Thandor.