[MUD-Dev] MUD Wimping
J C Lawrence
claw at kanga.nu
Wed Aug 2 21:19:28 CEST 2000
On Mon, 31 Jul 2000 22:58:19 -0700 (PDT)
Dan Shiovitz <dans at drizzle.com> wrote:
> On Sun, 30 Jul 2000, Michael Tresca wrote:
> My reading is not that Tenarius wants a minimum static level of
> quality, but that he feels there's an implied guarantee that time
> investment by the players in certain areas is never wasted (the
> obvious area being skill gain; an obvious area where's there's no
> such guarantee is experience points, assuming you can lose those
> in the game).
This has a direct relation to Raph's often observed player
expectation of guaranteed profit (What do you mean I spent all day
fishing and they're not worth anything?).
More generally I was view Tenarius' assertion that you shouldn't
take things away from players. If a player has something, they have
something (even if that something is merely an expectation) -- don't
take it away from them. Taking things away is tantamount to
stealing, and yet again rubbing their noses (the player's) in the
fact that they are effectively powerless.
Consider:
What would your reaction be if Big Brother appeared tomorrow and
dictated (with absolute and divine enforcement at the level of
changing the laws of physics) that you could no longer possess
automobiles OR drive them freely about the land?
This done and explained of course as being, "in the national
interest".
I suspect you wouldn't be pleased.
What if you started to notice that this was just another
reinforcement and demonstration of the fact that you really had
nofactual control over your possessions or the universe and it was
instead utterly defined and mandated by that same Big Brother?
Demoralised yet?
> I think this is reasonable, but, ok, it's also absolutely the case
> that unbalancing stuff is going to be introduced into the game,
> either by bug or error.
Tenarius' assertions seems to give player expectation an almost holy
value, that once something becomes reasonably "expected" it also
becomes sacrosanct. I'm not comfortable with that. I'm also not
comfortable with the above questions. We're dealing with Human
Emotion and Reaction -- predictably fickle stuff.
I wonder if a grandfather approach wouldn't do better; where
expected values are retained and gradually merged with intended
values:
The GooGoo spell is vastly overpowered.
This fact is observed.
The game is watched for an extended period.
All players who have used the GooGoo spell in that period are
flagged. These are your grandfather players.
The GooGoo spell is redefined so as to not be overpowered. This
takes intant effect on all new characters and all characters that
have not used the GooGoo spell during the tracking period (tis
even better of course if you can determine what players ever used
the GooGoo spell, and how often they did so)
Th GooGoo spell is left exactly as-is for grandfather players,
with one addition: The "power" of the GooGoo spell is reduced for
all future invocations every time they use it (variations could
have this every N'th time, by a random factor, etc)
Each time the GooGoo spell is so weakened, this fact is stated to
the player, wrapped in a suitable in-game explanation.
After N uses of the GooGoo spell by a grandfather player it has
the same effect as it does for "new" characters.
After time T the concept of a class of grandfathered characters
for the GooGoo spell is disbanded, and all characters use the new
definition. This removes the problem of trailing members of the
set -- they are assumed to not use the GooGoo spell enough to
actively care about its definition (or to not be excessively
surprised if they find it different now than they did T months
ago).
The intent is to give adaptation time for those players whose "right
to expectation" would be broken by a sudden change.
--
J C Lawrence Home: claw at kanga.nu
---------(*) Other: coder at kanga.nu
http://www.kanga.nu/~claw/ Keys etc: finger claw at kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--
_______________________________________________
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