[MUD-Dev] Embedded languages, object persistance... ack.

[Kevin Littlejohn]

>>> icecube at ihug.co.nz wrote
> On Tue, Jan 18, 2000 at 01:17:25AM -0800, J C Lawrence wrote:
> > On Mon, 3 Jan 2000 15:20:42 -0500 
> > Jay Carlson <nop at mitre.org> wrote:
> > 
> > > The big lose of persistence is that it's harder to get things back
> > > to a known state if your code screws up.  
> > 
> > In general this is a function of transaction and logging models.
> > Given a well implemented transactional model rolling back the log to 
> > the last set of compleat transactions *should* be cheap and fast.
> 
> I read Jay's comment more along the lines of "if your code screws up and
> creates 50,000 Swords-o'-Death scattered across the world" rather than a
> transaction issue. If your world is persistant, you can't just "fix the code
> and reboot" to get back to an undamaged game state.

That depends on your persistance, tho.  Most muds maintain at least enough
persistance for the above scenario to be a problem one way or the other -
chances are killing the mud will either save the characters (and the 50,000
swords'o'death), or won't save both - either way, you've got a data
cleaning problem.

Cleaning up problems like that might be easier in a text file, with vi, or
easier in an sql database, or easier in your proprietary bytecode-type
persistant database - it really depends on the type of fsckup, and the
tools you've built to micro-manage your data.

The advantage of transactional stuff is that you know, if the mud dies
part-way through something, _everything_ is going to be in either one state
or another - not half-way through changing states.  While that doesn't help
for the 50,000 swords'o'death problem, it at least means that crashes,
spontaneous reboots, whatever, aren't going to leave your data in an
"unknown" state - you'll at least be able to bring the engine up and carry
on, albeit maybe with one or two transactions that 'never happened'.

Of course, engineering all this to happen in a sane way without demanding
in-depth knowledge on the part of the builder-coders (those people who
write little mob scripts and so forth) is another trick again...

KevinL
(Persistance doesn't necessarily mean you can't make backups, and restore
to them, either...)



_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev