Member Discussions

Hypothetical here.

Let me preface by giving my opinion of the distinction
between 'complete' and 'evolving' code. A 'complete' mud is
a mud where further coding isn't necessary. All the skills,
classes, procs, and other coding are all complete and bug-
free. An 'evolving' mud is also declared open, but further
coding is always taking place in the form of new ideas.

Building is another issue as no mud is ever finished
building.

So let's say you have two muds, one that is expertly coded
and considered complete, so the coder leaves as he/she is no
longer needed. And the second mud that is evolving, it is
constantly updating the code with new ideas, but the code
isn't nearly as advanced or as far along as the 'complete'
mud. Builders are still building on both muds.

Which would you rather play, a complete or evolving mud? Is
a coder leaving a mud the kiss of death?

In most cases I'd rather play the evolving MUD because it'd mean being able to suggest things I wanted and have the possibility of having them added whereas any perceived flaws would just have to be dealt with on the completed MUD.

Can builders keep a mud alive without a coder, or will
interest wane? How pivotal is that coder?

Probably up to a point, it depends on how flexible the system is. An inflexible system will die quickly, while a flexible systems might be usable until whatever someone desires is beyond the limits of the existing code.

Stagnation is the kiss of death for a mud. Muds that have some sort of new content on a regular basis will do better at retaining players than those that do not.

I think a feature rich mud can survive longer and do better without a coder if it has dedicated builders to create new content.

I don't think the reverse is true. A great coder who produces terrific code but ads very little to the playable space won't be able to maintain an active player base.

And, while I've heard of players leaving a game because of change to code, I can't recall any cases of anyone leaving because they didn't like a new area.

Speaking from personal experience, back in about 2000 (and let's not forget, MUDs generally were a lot more
active and popular then, so the same thing might not happen today) I was a builder on a MUD whose owner/coder
eventually disappeared. The game starting out only had a handful of areas, but me and a handful of others kept
up with adding new areas, and doing a lot of creative things with the mprogs to simulate new features in areas
and objects. At some point, I was more or less one of if not the top active immortal, and along with new areas,
we held quests and big events quite often and such as well, and the MUD did relatively well for pretty much the
entire lifespan of it.

The MUD itself was really buggy, saw virtually no code changes over the course of the last two years of its
life, and until the server was being taken down and the owner not interested in finding somewhere else for it or
releasing the code to us, the MUD was active and thriving, all pretty much on the backs of builders.

As far as what I would prefer? Hard to say... if the coder had completely abandoned the game, that would turn
me off quite a bit. If a coder was handy to do things if necessary, but the MUD was otherwise "finished" and
most of the progress was just area wise, then that might be what I would prefer. But a MUD without a capable
coder isn't one I would trust my time to. It isn't necessarily the kiss of death, but it normally doesn't bode
well.

Well, this depends on quite a lot, and the answer is going to vary from mud to mud.

In lpmuds, for instance, builders are coders--we could say that the code is finished in that the underlying server is finished, or we could say that the mudlib is finished--in this kind of situation, an interpretted language is the entirety of the mud, and there's underlying software written in c, the answer depends greatly on definition and could be debated until the end of time.

Lpmuds and their oddities in this context aside, it depends quite a lot on the codebase/. I'd have to say you'll probably never be able to do this with a rom/diku/merc derivative, not without much more extensive mobprogs anyway, and that leads right back into the whole define coding versus building.

My opinion on this is that it depends on the powers of the builders--go look at coffeemud to see what I mean. If you give the builders the ability to expand skills and spells and such as well as areas, you could declare the underlying code finished, and players would be hard-pressed to notice the difference if you, as the head admin, decided not to differentiate between code and building changes. A new spell or skill or class is a new spell or skill or class no matter how it got there.

Can it be done? sure. Is it a good idea? That's going to depend rather a lot on the specific situation. Saying that there will be no more "code" updates will drive some players away (I am one of them, kind of--there's a few muds I'd call finished enough that I'd probably keep returning to), but a whole group won't care and a bunch won't even keep up with that anyway--they're on for the social aspect. I'd not do this, however, for a smaller game, anything written on rom or it's descendents, anything built up from scratch, or any mud without builders who either (1) have no idea how to use the powers they've been given or (2) can't actually do much besides generate new areas.

A fair warning: I have recently, as of a bit over a week ago, started coding for xrakisis over on cotn, with prior experience as a mud immortal being almost nil. Take this with a grain of salt, as it were.

I'd have to say you'll probably never be able to do this with a rom/diku/merc derivative, not without much more extensive mobprogs anyway, and that leads right back into the whole define coding versus building.

CircleMUD (tbaMUD, and possibly CWG anyway to a lesser extent) are the only public DIKU derivatives that I think any decently complex features could be added without "coding".

That'd be because they use trigedit which is basically an interpreted programming language as opposed to other DIKU derivatives standard o/m/r-progs.

There's some things that can't be done with trigedit, and there's also some things that can be done but simply shouldn't be done (due to inefficiency), but "most" requests a player would make could be done ingame via trigedit. Though as you mentioned that brings up the question of: If someone writes a complex script with an ingame editor does that actually make what they are doing building or coding?

LexiMUD uses LexiScript which is derived from Trigedit/DG, but is fully OO and is more flexible yet, but in my opinion it has two flaws:

1.) It's not a publicly available codebase - as such there are only a handful of MUDs at most that use it (three to the best of my knowledge).

2.) LexiScript is indeed more powerful than Trigedit/DG, but I think in becoming more powerful it also became less user friendly. I think having a building tool that is capable of doing things that are more complex in addition to simple tasks is great, but not when the side effect is it become so much more difficult to use that it is no longer easily accessible to builders for simpler tasks.

If you're looking for good scripting, look at lua or angelscript. Both are well documented, though lua has much more support--I only mention angelscript because it almost looks like lpc, and some might like it for that--it is pretty much readable by any c++ programmer fairly quickly.

My personal thought, if you're going to roll your own, is forth. It's tiny, you can probably write the basic interpretter in an hour and don't need lexical parsers, and, basically, you can compile to it directly.

But this is taking us off on a tangent.

Don't declare your mud finished if it's not documented. I'd never use trigedit or dgscripts for that reason--half the stuff is undocumented, including some important features. For programmers (myself included), writing helpfiles is difficult, but if you're going to leave your mud in the hands of a non-coder, you need them. Which is why I advocate lua--you've got access to a lot of stuff out of the box: network, strings, time/date, documentation.

But I'm going to stop here, because I'm quickly turning this post into my thoughts on the best scripting language and I think I've got my point across by now anyway: documentation is part of the being finished bit.

Don't declare your mud finished if it's not documented. I'd never use trigedit or dgscripts for that reason--half the stuff is undocumented, including some important features.

I can' think of a single undocumented feature. There may potentially be 1-2. but certainly by no stretch of the imagination even 5%, let alone 50%.