[MUD-Dev] The Player Wimping Guidebook
Matthew Mihaly
the_logos at achaea.com
Thu Aug 3 20:36:33 CEST 2000
On Thu, 3 Aug 2000, Greg Underwood wrote:
> Matthew Mihaly writes:
>
> > Sure, adding whole new skills falls outside of the scope of minor tweaks,
> > but I'm not sure I see your point.
>
> Part of your confusion is probably a result of my confusion... I'm
> formulating my point as I write. Forgive me if it takes a few posts to get
> things worked out in my own head. ;)
Confusion all around then!
> > Any good mud is always adding major new
> > things. Achaea's been out of beta for a year and a half, but yesterday we
> > added an entire new class (consisting of 90 completely new abilities), for
> > example. That's just part of running a good mud. A good mud is always
> > having features and content added to it in my opinion.
>
> I'll borrow a phrase from JC: "Assumed Orthodoxy!"
>
> Why does it have to be that a MUD is "evolving"? I'll agree that minor
> tweaks are warrented, probably even required to maintain a playable game.
> But do we have to have games that change on such a large scale as to be
> called "Evolving"?
A mud doesn't have to be always evolving, but I think it's pretty clear
that the players like that. Anyone have any stats on sales of Ruins of
Karnak EQ expansion pack?
> Don't get me wrong, I realize that player and admin tastes change.
> However, that doesn't mean you should go off and make every little
> "imporvement" you think up. Heck, you probably shouldn't even make half of
> them. If you really think it's time for a change, maybe you should start
> up another game somewhere else.
Doing every improvement I can think of would take more time than I have in
my life. =) I take maybe 1% of suggestions (from my mind and from others)
and implement them.
> I guess my point is, if it's going to be a game, design it with certain
> goals in mind from the get-go, and don't alter those later on, w/o d*mn
> good reason. IMHO, most MUDs suffer from the philosophy of "constant
> evolution is a good thing."
I'm not trying to create a game so much as a place for people to live out
their virtual lives, with game-like aspects to it. As such, I tend to feel
that more options for players in the world is simply a good thing. Plus,
players simply like constant evolution, or at least, my players do (and
the players of most muds I've seen). They get grumpy if they think we
aren't working on anything.
> > Players do view them differently though. We make changes on Achaea every
> > single day. Most players don't notice most of them, but quite often they
> > do. Games you buy in the store don't get the nature of them changed daily
> > for two reasons: 1) It's not practical to ask people to do daily
> > downloads. 2) In the case of big graphical multiplayer games, a major
> > patch is a chance to a) get some more box revenue and b) make a publicity
> > splash.
>
> I think you missed the most important reason of all: c) people don't like
> change. Part of what makes the great games great is that the rules are
> established and known. Pac Man is still an incredible game. MUDs are
> different beasts from arcade games, but that doesn't mean we can't learn
> from what arcade games, and other off the shelf games, have to offer.
You don't see Pac Man on the bestseller list for a reason, you know. It's
old and stale to many people.
> > Text muds that run entirely server-side and are accessed through telnet
> > are not under the practical restrictions imposed by client-side software
> > in terms of frequent updates.
>
> True, but that "freedom" is also a curse. Just because you can tweak it
> daily doesn't necessarily mean you should.
Well, all I can say is that my players, and the playerbases of every mud
I've ever been on, like to see additions being made regularly.
--matt
"He that is wounded in the testicles, or have his penis cut off, shall not
enter into the congregation of the Lord." Deuteronomy 23:1
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list