Persistancy

Matt Chatterley root at mpc.dyn.ml.org
Mon Jun 16 21:53:02 CEST 1997


This is an issue that sparked quite a lot of discussion with some members
of Caffeine's wizard team, and proved to be really very interesting - thus
I thought I'd throw it to the 'lions' here, so to speak. Let me just say
that being a Lion is a good thing in this context :P

To define terms before I start: By persistancy I refer to the degree to
which playing sessions overlap, to clarify: How much of each playing
session is saved until the next. The parts below which refer to code bases
are limited to my experience, and do not really reflect on the issue at
hand, but are rather attempts to give examples of degrees to which this
can be done. I use the word 'he' in 3rd party references to the player
because I'm male, not because I'm sexist. :P

MUSH code bases have practically total persistancy - if you change an
object in room X, it is changed for ever, until someone changes it back,
and whereever you leave yourself with whatever you are carrying, does not
change between logins. Well, they have the capability for that, at any
rate.

Other stock mud types do not have this capability 'out of the box', but
have various stages of it's implementation.

One example is the standard LP (Foundation, Nightmare, etc) method:
Skills, stats, experience, and so forth are all saved in a player file,
but the players inventory is dropped upon logout, and he will log into the
village square, or somesuch, no matter where he left.

Some muds have lockers, where players can stash kit for a fee, and
retrieve it at any stage in the future, allowing the player to keep the
same kit over multiple playing sessions, and even over a long space of RL
time (I've had a sword in storage on one mud for months).

There are various mediums around and including the above, desirable for
different types of games. Each has different implications upon gameplay
and balance, and also the overall style and feel of the game. Some are
also open to flagrant abuse.

An example of abuse is in the LP case, where login location is always the
same, if you are stuck in a situation you cannot extracate yourself from
(without some application, ie solving a hard puzzle), you can simply quit,
and you are safe (at the cost of the equipment you are carrying). If
equipment were saved, trapping the player at any point becomes pointless,
since he has a free teleport home, effectively.

In more 'realistic' games (for instance, if you have a big game area, with
obstacles separating parts of it.. for instance an ocean), you do not want
players to be able to perform this 'teleport', and would at least wish to
keep them on the same continent!

The approach that I personally favour is 'total persistance', meaning that
inventories are saved, logoff locations become login locations, and so
forth, for everything that might vary with the use of 'quit'. The
associated issues are of course, balancing this so that there is not a
huge proliferation of 'short swords with a ruby in the hilt' (each player
gets one, yet they are still regenned!). Of course.. doing away with
standard regens/resets in this sense is instrumental to improving things.

Anyways, thats my piece for now, I'll be very interested to see what y'all
make of it.

Regards,
	-Matt Chatterley
	http://user.itl.net/~neddy/index.html
"He can't stop us, we're on a mission from Glod!" - Soul Music (Pratchett)





More information about the mud-dev-archive mailing list