[MUD-Dev] Maintaining fiction.

[Matt Mihaly]

On Mon, 18 Jun 2001, shren wrote:
> On Sat, 16 Jun 2001, Matt Mihaly wrote:

>>> I'm formally coining the phrase, "Absolute Death", or ADeath,
>>> for situations where:
 
>>>   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.

So a game that has no death at all can claim to have Absolute Death? 
What you're saying is that the only thing that matters is the intent
of the designer, not the actual world. You're free to define
something that way of course, but it's a pretty poor way to do it in
my opinion.

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

You assume that the management making these decisions is incapable
of changing its mind. There is no way to make this irreversible.

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

What if I've got a mud whereby old character databases are kept
around for the sake of legacy, but once a character has died your
"absolute death" no one can access the character again? Is that
absolute death or not? Do any datasets that are identical to the one
in question have to be erased also? For if a dataset is defined
solely by the data in it, then two identical datasets are the same
thing.

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

Ok, so you're commenting on the policy of the MUD then, not a
feature a MUD has. From what you're saying, I could have absolute
death today, but not tomorrow (cause tomorrow I'd let all the people
get resurrected), and then have it again tomorrow, resurrect
everyone the next day, etc. So as long as the people are not
resurrected during a period I claim to have absolute death in my
world, it's still absolute death??

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

What I disguised isn't resurrection. It's cloning. The two are not
the same in-role. Is a clone of a character the same 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.

Easy enough. Before closing, an exact copy of my character was made,
except that there is one thing different (something trivial, like
the name). The new character can pull a switch and restore himself
from the clone's stats (who isn't the same character if you define
characters by database entries).

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

I don't think you can do it by referring to what happens with
database operations. Everything you've said can be worked around in
such a way as to render "absolute death" meaningless, but still
satisfy your literal conditions.

--matt

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