On Wed, 7 Apr 1999, Patrick Dughi wrote:
> I disagree with this. I don't think the amount of time spent on
> developing a mud is a good determinate of how good or bad it will be. A
> mud can be stellar in as little as a few weeks, just as a mud can still be
> poor after 2 years.
Every rule has an exception or two. While development time might not
always tell you how good a mud is, I feel it will do so the vast majority
of the time. Sure, there are probably a handful of muds out there that
have very simple play mechanics and a small, interesting world that are
very good and were developed in very little time. But I don't know of
any. Especially not MUDs based upon an available code base, since the
distance from stock is often used as a determinate in figuring how
entertaining the game is.
> As much as I would enjoy it being so, rarely does good, unique,
> exciting, fast, efficient, diverse code make the mud good. Mostly,
> people would say a mud is good if it has a wide and varied
> environment, the gameplay is balanced, and if it is stable.
I disagree. People are too much inclined to extremes. Gameplay consists
of one part code and one part environment. One without the other is
nothing, despite how many people would like to say otherwise. The
environment needs to fit the code and gameplay, and vice versa. I cannot
see a MUD with fifty thousand rooms but barely any new gameplay succeeding
any more than I can see a MUD with 1000 rooms and very diverse gameplay
succeeding. (Note that diversity doesn't necessarily equate complexity,
as overly complex gameplay will drive away most people, too.)
You might have a good MUD with a diverse world, balanced gameplay, and
stable code. But the great MUDs have a diverse world, balanced and unique
gameplay, and stable and "exciting" code.
Of course, as mentioned above, for every rule there is an exception. A
diverse world isn't necessarily good for many types of MUDs. Many PK MUDs
based upon the deathmatch concept have a very small, non-diverse world.
They are made by their code and gameplay concepts.
> to summarize;
> Code development very rarely causes massive changes in the
> affinity one has to a mud.
As a linguaphile, I have to wonder where this new meaning of "affinity"
arose. Affinity literally means, "Related, as with marriage, through some
bond other than blood." (As a noun it has a meaning of, "A similarity,
close relationship, or connection," which is clearly derived from its
meaning as an adjective.) I was taught affinity's original meaning, so
when I first heard someone use it in this way, I was confused. It was
also quite humorous: "I really have an affinity to dogs," the bespectacled
girl told me. I blinked twice and walked away confused but bemused.
-dak
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST