[MUD-Dev] Cans of Achievements and Quests

Sasha Hart Sasha.Hart at directory.reed.edu
Fri Sep 6 14:45:47 CEST 2002


[Sean Kelly]
>[Sasha]

>> data have other ways of being corrupted - deliberate exploitation
>> by users, bad memory and disks, etc...

> These are issues that have to be addressed with any game. 

Absolutely.

> I don't see any particular difference when the amount of world
> persistence increases.

I have sometimes heard people talking about moving parts as sources
of potential failures. Not certain failures, and certainly not
implying that moving parts are always unnecessary or
undesirable. And the fact is that each part has a chance of failure
which doesn't necessarily increase with the number of parts. It is
rather the chance of overall failure which is of concern, given that
multiple parts are being used, each with its own chance of failure.

The claim isn't that persistence makes memory go bad or users
exploit. It is that it multiplies the opportunities for failure in
comparison to non-persistence (e.g., reading the state of the world
from the same read-only files every day). If someone cheats in
Starcraft, that doesn't necessarily mess up future battles.  But do
the same in a persistent game and the cheat may persist. And because
it persists, it can be the input for other processes, whose output
is also affected and itself persists.  In both cases you want to get
rid of the cheater, but in one you still have data to heal. (Usually
not impossible, and a price worth paying for many MUD applications).
That's just a natural result of the added functionality, no more or
less.

Sasha

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



More information about the mud-dev-archive mailing list