Hiding the Numbers (was Re: [MUD-Dev] Maintaining fiction.)

[John Buehler]

Travis Nixon writes:

> And that tangent is marginally related to the original idea which is
> this: If you're going to hide the numbers, hide them.  If you're
> going to show them, show them.  Don't do both, because you just piss
> people off when they can't look at numbers that you've already shown
> them because you're "trying to keep fiction, and hide the numbers
> because seeing the numbers somehow reduces immersiveness" even
> though you've already shown the same numbers, or shown other numbers
> that obviously lead to being able to determine "hidden" numbers.
> (For example, in EQ you can determine approximately how many
> hitpoints a monster has by watching how much damage it takes to
> kill.)

My way of thinking about this is to consider character knowledge
versus player knowledge.  If my character is going to learn the
combination, then the character learns it and that is accomplished by
setting a bit somewhere on the character to indicate the fact.  When
the character is then faced with the use of that knowledge, either the
player controls whether the character will use it or the character
automatically uses it as appropriate.

One of the more annoying examples of this is tree dodging.  Games
require player knowledge in order to dodge trees while the character
is moving around in the wilderness.  Certainly characters should have
the 'brains' to dodge trees and to use that knowledge automatically.

> And most importantly, if you're going to hide the numbers, for god's
> sake, never, ever, under any circumstances, send them to the client!
> If you're going to represent health by a bar, then all the client
> needs to know is what percentage of the bar is full.  The client
> does not for any reason need to know what the maximum and current
> health is, so it can figure out how full the bar should be.  All you
> accomplish by giving the client access to information you're trying
> to hide is insuring that hackers will have access to a lot more
> information than those who play fair.

Agreed.  Note that the fact that hackers can gain by knowing the
numbers is indicative of a specific mindset: one where 'getting ahead'
is valued by the game.  As I've said a number of times, if the process
of moving through the game is the real entertainment provided, and the
goals are entirely secondary (provided for the purpose of giving
players something to work towards), then the desire to accelerate
gameplay should be diminished.  By analogy, hackers are using a sports
car to drive through Yellowstone instead of hiking it.  They can do
it, but it's not as entertaining as going elsewhere with that sports
car (read: another game).

> Of course, I'd prefer if you just didn't hide the numbers.  Then you
> don't have any of those problems.  And you have the added benefit of
> thousands of people, some of whom are sure to be smarter than you
> are, pounding on your systems and finding imbalances that you can
> then (hopefully) fix. :) Surely they'll exploit those advantages
> when they find them, but if your systems are published, they'll find
> them early.  In fact, they'll very likely find most of the problems
> during testing, as opposed to 3 years down the road, when they've
> figured out how your systems work anyway.

The balance in current games is that they aren't all that entertaining
to play, but they're very entertaining to figure out.  This is because
advancement is the primary goal of many of these games, and figuring
out the game provides an accelerant to advancement.  The balance needs
to change.  Make them far more entertaining to play (within the game)
and drastically reduce the role of advancement in gameplay.

Simulation of real world processes is my primary approach to both
making the games more entertaining and more complex to figure out.
Further, making character knowledge prominent means that more of the
game fiction remains in the game.  Less knowledge is transferred out
of the game, making it more difficult to 'game' the simpler bits and
pieces - such as the keypad combina tions.

JB

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