[MUD-Dev] RE: Knowledge Modeling -- WAS: -- Interesting EQ rant (very long quote)

[John Buehler]

Zak Jarvis writes:

>> Perhaps you misunderstand what I'm after.  I'm after entertaining
>> my players, not in getting them into an alternate reality.  I've
>> been trying to articulate this delicate balance point in another
>> forum and have been failing miserably.  Perhaps I'll be a little
>> more successful here.

> Then what this all comes down to really is implementation. How much
> character knowledge is "fun" to model?  > In my opinion, the "fun"
> modeling of character knowledge would be having a character that
> won't do things that are stupid or life threatening until the game
> is quite certain that is what I want as a player. Brian Hook's
> earlier example of the city Kelethin is a perfect illustration.

[snip nice list of nice-to-haves for character capabilities]

> I agree with you completely that modeling character knowledge is a
> great way of attracting the magical casual gamer.

Okay.

> I'm really not so keen on the idea of special commands to trade
> knowledge with other characters, unless all communication were
> equally abstracted.  It adds a needless layer of complexity to
> communication.

I'm not keen on it either.  To be honest, I haven't spent more than
about 20 seconds trying to solve the problem at the implementation
level.  The quickie technique of a special command was offered only to
illustrate the idea.

> A far better solution (though more complex from a development
> standpoint) is not using puzzles or quests that lend themselves to
> OOC 'spoilers'.  >From the simplest form where each character gets a
> different password, to the slightly more complex method of each
> character gets a randomly generated constellation of NPC's for his
> personal quests, to the significantly more difficult broad, deep
> random quest generation.  (Emphasis on broad and deep).

I'd argue against the different password approach because it
eliminates the possibility of transferring the password to another
character.

I'd argue against the constellation technique because of the
single-player attitude that it fosters.

> The latter approach is the one I'm personally most interested in. I
> keep threatening to do a write up about this...

I'd be very interested in hearing your thoughts.  The task of
providing puzzles for a large player base is a very challenging task.
I assume from the start that they cannot be hand-generated.  This
means that they will run to some kind of a form.  This means that the
entertainment derived from solving the puzzles cannot be as simple as
completing the puzzle itself.  There have to be more axes to the
entertainment surrounding the puzzle.

>>   The case of an in-game secret password is the topical example.  I
>>   don't want to present a piece of information as a password
>>   (implying secret) when the actual use of that password by the
>>   game and the game community completely eliminates its secrecy.

> It seems to me that the more elegant solution here is the 'Eyes Wide
> Shut' solution. The people you would give any such password to know
> you shouldn't have it because you didn't receive it in the normal
> way and set the 'I've got the password' bit. So giving the password
> isn't effective. Sure Bob can tell you that the password is
> Porkmelon, but you just aren't Bob and they know that.

As I suggested earlier, I dislike that because it doesn't appear to
provide a way to share a password, which is a perfectly reasonable
thing to do.

>> multiplayer environment.  Other players are liable to ruin a
>> player's entertainment completely by accident.  Often, it's just a
>> side-effect of the game design that nobody saw coming.  In this
>> analogy, the

> Hmm. I'm unsure how the method you seem to have been describing
> effects this. If a players entertainment is ruined by another player
> knowing something he or she shouldn't be able to know, how do you
> prevent other and potentially significantly more intrusive OOC
> issues?  I'd be far more annoyed by a player talking abortion
> politics than one who knew the secret password. In fact, there are
> about a million things that it would be outright impossible to
> prevent -- short of totally restricting communication -- that I
> would find far more disruptive than the commodification of
> supposedly scarce knowledge.

I really don't worry about the ones that are impossible to prevent
when it comes to game systems.  I'm facilitating an action in the game
world that is typically invalidated with characters being able to act
on player knowledge.  As I've suggested before, once characters know
information, it becomes possible to start doing things with that
knowledge - such as morph it slightly when transferring it to another
character.  I postulate this for character descriptions of other
characters (an offshoot of an introduction system) and for character
descriptions of map directions.

JB

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