[MUD-Dev] Maintaining fiction.

[shren]

On Sat, 16 Jun 2001, Matt Mihaly wrote:
> On Fri, 15 Jun 2001, shren wrote:
>> On Thu, 14 Jun 2001, Matt Mihaly wrote:

>>> You guys keep throwing around concepts like "If you die and
>>> don't come back it's permadeath." Define 'you' first, otherwise
>>> the statement is pretty meaningless. Permadeath revolves around
>>> the definition of a character, and so far, I haven't heard any
>>> persuasive argument that a character is held exclusively in a
>>> database.

>> I'm formally coining the phrase, "Absolute Death", or ADeath, for
>> situations where:

>>   A) The character database entry is unusable (closed).

>>   B) The close came from a game feature and not a game bug.

> So the intent of the designer comes into play? There's not a fine
> line between game feature and game bug. I often find things in
> Achaea that were implemented as features at some point but when
> pointed out to me years later, realize I don't want it in
> there. Is that a feature or a bug if it kills you in the game?

There isn't a fine line between a game feature and a game bug, true.
However, if you have bugs in the death system, and sometimes people
die permanently and sometimes they don't for no reason you can
discern, then you should still be in beta.

Absolute Death is a design matter.  It's what you want, not what you
have.  It's a description of your design document, not the current
state of your code.

>>   C) The close is always irreversable.

> This condition cannot be satisfied.

It can as a matter of policy.  Place no methods for player
resurrection in the game, tell your management never to resurrect
anyone, and inform them that anyone who uses a database editor to do
so without your permission is risking termination.

>>   D) Should the conditions that cause this close come about, the
>>   character always becomes closed.

> This depends on a definition of character that has been
> demonstrated is not valid, ie that the character resides solely in
> the database.

A small but valid nit.  Make that:

D) Should the conditions that cause this close come about, the
character database entry always becomes closed.

>>   E) The player may, through interaction within the mud, build a
>>   new character, and this character may be both technically and
>>   behaviorally identical to the old one.

>> A is simple - the character is dead, databasewise.

>> B is simple - the death came about because the game intentionally
>> made the character dead - say, he ran out of hit points.

>> C is simple - there is no resurrection.

> C is not simple at all. What if resurrection is later implemented
> and the database entry is restored? Irreversable means
> fundamentally not reversible. That's never going to be the case
> with a database.

See the policy vs reality, above.  It's a statement of intent.  If
character database entries that run out of hit points become closed,
always, then I have implemented an Absolute Death mud.  If I change
that later, and add resurrection and so forth, then it's not
Absolute anymore.

>> E addresses that the players, using the MUD and playtime, can
>> build up the exact same character again in the same way he built
>> the dead one.  This faces the issue that Matt brought up - that
>> you can make the same character again.

> What if in the meantime a feature has been implemented that lets
> me recall my 'dead character' by doing some quest with my 'new
> character'? Saying that they can be built up exactly the same
> doesn't preclude things like what I described. And if you require
> that the person be able to build up the character in exactly the
> same way, then you preclude absolute death from anything but a
> world that exists and behaves exactly like the world did when the
> person built up his character the first time.

You have a mud that implements Absolute Death.  You add a quest that
allows resurrection.  You don't have a mud that implements Absolute
Death any more - you have a mud that is "Absolute Death, except
there's a quest you can do to recall your dead character."

Oh, I see what you're getting at.  If you have a new character, and
he can walk into a room and pull a lever to change his stats to that
of his old character, then you've technically met the Absolute Death
rules without the intent.  Except you haven't, because to do this
the old character record must be usable, which it isn't, as per
provision A:

A) The character database entry is unusable (closed).

Copying parts of the database entry from the old character to the
new character constitutes use.

>> Absolute Death, as a term, means "as dead as you can get within
>> the system database", in the same way that absolute zero means
>> "as cold as you can get".  (Please don't bring up quantum
>> mechanics - I know that things can get colder than absolute zero
>> in limited ways.)

>> Is there anything else that needs to be added to the definition
>> to make it completely clear?  Is there any way that a character,
>> database-wise, can be deader?

> Heh, see my objections above. Sorry to be so picky! (Well, not
> really. Anyone who doesn't like it doesn't read my posts I'd
> imagine.)

No problem.  I just am trying to create an unambiguious term.
Permadeath is ambiguious.  I would like Absolute Death not to be, so
it's suitable for use on design documents and so forth.

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