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

[John Buehler]

Brian Hook writes:

> 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).

Consider that if the developers are far more qualified and insightful
and have put far more work into getting a complex behavior nailed
down, that players will have far less hope of reverse engineering it.
As things stand, the systems involved are so simple, and their
internals are so evident, that players easily reverse engineer them
and then 'game them' into the ground.  Which is particularly annoying
if a game is attempting to produce an illusion of a virtual world at
all.

When I think about system development, I always fall back on the use
of simulation techniques.  One of the really nice things about
simulations is that they are very tuneable because they more easily
permit continuous solutions - as opposed to discrete or stepped
solutions.  And when multiple continuous solutions are brought
together, you get a nice, complex result.  But one that the original
designers can understand because they have the original functions that
went into producing the result.

For qexample, literally using the intersection of various period and
amplitude wave functions in order to generate terrain.  The net result is
complex, but the inputs are fairly simple and straightforward.

>> 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.

Encounters today tend to be *very* controllable because the games can
be 'gamed'.  I belonged to a very good guild in EverQuest and we could
efficiently tear up a dungeon or any spawn.  If you tackle the game
situations the same way, the result is the same.  There are no
surprises because of the few number of variables.  If you're aware of
the variables, then you can control the situations as they progress.

Many groups of players in EverQuest kept changing the way that they'd
approach spawns and that would produce variability.  Typically, it
meant having to run away because of terrible mismanagement of the
situation.  In EverQuest, running away usually has bad implications
(trains).  But the point is that the interactions had few enough
variables to keep them manageable.

>> 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.

I think we can assume I want something that vastly exceeds EverQuest.

For me, significant impact means that the players remember the
encounter as distinct from previous or future encounters.

  "Remember that time we thought that orc was running away, but it
  just went to his wounded buddy and got his crossbow?  I thought we
  were toast."

  "Remember that time we were sneaking up on the orc outpost and Bob
  sneezed?  Every orc in the place locked on his position instantly.
  I couldn't stop laughing."

  "Remember that time when Bob was cornered by those three guys in
  town?  He was diving through windows to get away from them."

>> 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").

My stance is that hiding the numbers

  1. Limits powergaming.  I'm trying to attack this from a number of
  directions.

  2. Aids in immersion.  Players aren't invited to ponder out of game
  numbers while playing the game.  It also encourages the developers
  to come up with in-game ways of presenting the same information.  To
  me, that means more entertainment than reading numbers.

  3. Permits system changes.  If I want to alter the scale on which
  weapons do damage, or I want to split up the damage effects in to
  blunt and edged weapon damage, or any other refinement, I can do it
  without confusing the players about the numbers they're seeing.

In short, I believe that qualitative information provides far more
opportunities for entertainment of the sort that I'm after.
Quantitative data is far more appealing if the sort of entertainment
that you're after is letting the players reverse engineer and min/max
your systems.  And some players are certainly after that kind of
entertainment.  I contend that many are interested in that because the
mainstream 'immersive' entertainment that games attempt to provide
isn't all that entertaining.  Something like the difference between
fighting monsters versus fighting other players.

> 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".

I suppose that's one way of looking at it.  Personally, I look at it
from another direction: what has exposing the innards of the game got
do do with the experience that the game is supposed to be presenting?
I find it an odd concept.

> 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.

Uh, how about the idea that the game system that is being used has
actually had some investment into it, and the game company doesn't
want to hand over their game systems?  This is something pretty well
in advance of most game systems out there, but the day will come.

> 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.

I'm working on creating a world in which there are many goals that
characters can pursue, and many variables that apply as they pursue
them.  As a result, nobody will have any idea who is better than
anyone else.  Some situations will call for strength, others for
agility, others for any number of skills.  I'd like players to stop
worrying about who has a bigger #### and just play the flaming game.
Much of my posting here has been positing that it is possible to
attract players who will do that very thing.

> 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.

Sure.  And that balance has to change.  One way to do that is to
develop systems that a game company likes so much and provides so much
entertainment that they will actually reuse them in the next game.  Or
they will just keep piling more and more entertainment and depth into
the game world.  As long as games are being developed from scratch
they're just not going to have the depth that will be able to blow
away the players.

JB


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