[MUD-Dev] The Player Wimping Guidebook

[Matt Chatterley]

On Wed, 2 Aug 2000, Greg Underwood wrote:

> rayzam writes:
> 
> > 
> >     Why I change skills, by an Administrator.

[Snip]

> I think this might fall into what Tenarius would call an extended Beta
> period.
> There's a difference between tweaking a game design and adding whole new
> skills.
> It's a fine line to draw, aye, but I think adding whole new skills falls
> outside
> the scope of minor tweaks.

When I read the 'extended Beta period' post/reference, I thought to 
myself that most Muds probably fall into that category, and only a few 
may have reached a point whereby the main core of the game is not in 
active development.

The line between a tweak and a more major change is very fine indeed; it 
can't even be classified by the amount of code changed, in player terms. 
To me, as a developer, if I change a single line of code, no matter what 
the implications of that change, it falls into the realms of 'tweaks' - 
it took me a few seconds, rather than hours to do. For a player, 'tweaks' 
are essentially surface changes (for instance, modifications to the UI, 
and other more cosmetic things - such as colours in room descriptions). 
Major changes are those with a noticeable impact on gameplay.
 
> >     Of course, this goes against Tenarius' claim that if players have used a
> > skill for a while, it should never be changed. But the converse would be,
> > even if the mud changes, a skill shouldn't. That is, even if new abilities
> > or features are added, a skill should never change and do more, or do
> > something else. That would make for underused, underpowered, obsolete
> > skills. 
> 
> [...]
> 
> Again, I'd argue that any system that allows for the possibility of
> "underused, 
> underpowered, obsolete skills" is not in a stable state, and could probably
> be
> considered still in Beta.  How many games do you buy in the store where
> they
> change the nature of the game w/o some kind of major patch, etc?  Aye, MUDs
> are
> not typical games, but that doesn't mean the players will or should view
> them
> any differently.

I would argue (or perhaps propose is a better word) that the nature of 
Muds - the number of developers who tend to be working at any time, the 
number of players with different motivations and approaches, and the 
evolutionary nature of game development (JC - how much have the 'non 
stock' Muds changed in the time this list has been running? How many 
things that were then 'revolutionary' are fairly normally desired now?) 
dictates that Muds will be subject to gameplay changes from time to time.

Of course, at the same time, for the sake of the players sanity, I would 
personally try to implement sweeping gameplay changes over time, so that 
they could settle into them slowly, and also to reduce the complaints 
received - some players might not even notice if you were sneaky enough! ;)
 
> BTW: Raph, I agree with your devil's advocate post... whether we as admins
> want
> to view things this way has no impact on the players, and they're the ones
> that
> will leave if we mess things up.

Aye. Some players whine all the time for stupid reasons. I tend to ignore 
those as much as I can (although loud, they are generally inconsequential 
to me). Its when the good, law abiding, polite, friendly players start to 
point out that they're unhappy, that you have a problem. ;)
 
> >     It seems reasonable to think that modifying shove wouldn't be considered
> > 'mudwimping', except that what may happen is that it is changed to use the
> > new code, without knowing how to tweak it into balance. And then it's
> > tweaked later, and that causes a cry of 'mudwimping!' or 'blunting!'
> 
> Aye, but your argument ignores the key to Tenarius' argument.  It's not
> what
> you consider wimping, it's what the players do.

Very much a public relations and marketing exercise, in some ways. :)
  
> >     As long as a mudlib expands, there will be reasons to modify skills.
> 
> True, but the players probably won't know, won't want to know, or even care
> what
> those reasons are.

However, such changes *can* be packaged in a way that the player will 
accept. Or which reasonable players (the more valued ones?) will accept. 
"This skill has been removed, because it is never actually used, and you 
are wasting your time training it. You've been refunded the exp which it 
has cost you to train; feel free to spend it on something else!" or, 
other options such as swapping it for a new skill which the player might 
want, depending on how your game runs.
 
> > When a mudlib becomes stagnant, that's when there will be reasons for
> > players to leave.
> 
> True, but players will also leave if you're changing things too often. 
> It's a
> very fine balance to achieve, and requires a lot of conversation between
> the
> players and the admin to get right.  It's just like any other relationship.
> Communication, communication and more communication are required to keep
> people
> from feeling hurt, etc.

Yup. Its an incredibly thin tightrope indeed.

-- Matt Chatterley
".. You live for the fight, when its all that you've got .."
		Jon Bon Jovi; Livin' on a Prayer, as always.




_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev