[MUD-Dev] "Doing a dungeon" (was: Permadeath or Not?)

Brian Hook bwh at wksoftware.com
Thu Feb 22 18:06:17 CET 2001


At 04:35 PM 2/22/01 -0800, John Buehler wrote:

> I agree with you about the negative side of static encounters.  This
> is why I'd like to see many variables contributing to the outcome of
> a situation.

But if you have too many variables, invariably the designer becomes
overwhelmed and loses track of what variables contribute in a
meaningful way.  Predictable, repeatable outputs from a set of
variables are vital when you're trying to balance an encounter (or
anything, for that matter).  So minimizing variables is actually
something I strive for.  Alternatively, you can have a large amount of
variables however they homogenized through a network of functions that
give reasonably predictable output (for the designer, not necessarily
the player).

But that's neither here nor there =)

> Situations can be revisited, but the outcome is never the same
> twice.

No encounter today is the _exact_ same twice.  If you want to have
meaningful differences, then it becomes quite a bit more complicated.

> A small change in skills, items, number of opponents, condition of
> the ground, condition of the player characters, etc, can all have a
> significant impact on the outcome of the encounter.

This is an admirable goal, but you need to quantify what a
"significant impact" on the outcome of the encounter may be.  Right
now encounters in EQ (which is the only MPRPG I'm really familiar
with) tend to range on three axes:

  - mob killed <->  mob survived
  - party killed <->  party survived
  - high reward <->  low reward

Not much room for significantly different outcomes.  You can increase
the length of the axes, but in the end you're only altering three
criteria.

> Conditional to all that is that game system quantities can't be
> displayed to the players.

Why?  Console RPGs show #s and stats.  Pen and paper RPGs show numbers
and stats.

Traditionally I've seen some developers defend obfuscation of game
mechanics because it makes things more "immersive" or it "prevents
powergaming".  I strongly disagree with this sentiment (partly because
of my prior interest in crytopgraphy, where Rule #1 is "obfuscation is
not cryptography").

To me, obfuscation of game mechanics is basically a thinly disguised
way of saying "We're not comfortable having our mechanics put under
scrutiny because we know they're kind of ad hoc and ill designed".

Published mechanics, like published crypto algorithms, are open to
analysis and criticism from a lot of people that, collectively, are
much smarter and thorough than the person designing the original
system.  This makes the system far more robust than one that relies on
obfuscation.

If you look at a lot of the stuff that caused outcries about class
balance in EQ, you'll see a trend: empirical discovery of internal
game mechanics led people to realize/perceive that certain imbalances
existed.  If those mechanics had been published and scrutinized early
on, then they could have been fixed much sooner and robustly.

While I don't think that a game should always consist of "You rolled a
16, critical hit!  You did 14.82 points of damage!", specifically
hiding what's going on behind the scenes has always alarmed me as a
player, simply because I don't think most designers and developers are
really THAT rigorous about balance and playtesting.  I mean, the
players generally care WAY more about the minutiae than the
developers, simply because a player can focus specifically on the
items for his character, race, skills, class, etc. whereas a designer
or developer can't overfocus that much.

- Hook


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



More information about the mud-dev-archive mailing list