[DGD] Persistent Users

[Schmidt, Stephen]

It's been quite a while since I thought about this, but I had also observed
the possibilities of persistent player bodies stacking up.

One different is that a player body has a significance in the world of the
game (assuming we're talking about a game environment here). The player's
body takes actions, it can be acted upon. In particular, maybe something
happens to player bodies when they're not being inhabited - they become
zombies, or if this is a vampire game they go back in their coffins, or if
this is a build-your-empire game then they become passive rulers until the
user comes back to re-animate the body. Some of those things might cause
the player bodies to go away if they're not inhabited for a while. The
zombie eventually decays, the vampire's coffin is opened in daylight, the
empire is captured by another empire. The point is that because the
player's body is part of the game world, things might happen in the game
world that would remove that body in a natural way. And then they wouldn't
tend to stack up.

Whereas a user object is not part of the game world, and it's hard to
imagine things happening within the game that would get rid of them. For
users, you probably do need an artificial "users who are inactive for 30
days will cease to exist" rule.

So one problem (player bodies lying around) can be solved by game means,
but the other (user objects) probably requires an arbitrary solution.

Steve


On Wed, Sep 21, 2016 at 11:59 AM, Gary <gary at mups.co.uk> wrote:

> Hey all,
>
> Assuming a mudlib has separate connection, user and player body
> object(s) (Phantasmal for example has a separate player body)
>
> For persistent muds, the player body never needs to be saved out when
> the user disconnects. It just remains where it was left (or moved to a
> meat locker etc).
>
> What I was pondering earlier today is whether there's any reason to not
> also make the user object[^1] itself persistent.
>
> This would avoid the need to save out the password (and any other user
> account data that is added). Cloning of the user object would then only
> occur when no user object exists in the userd for that name. Destroying
> would only occur for actual account deletion.
>
> Over time you could end up with a number of inactive user object hanging
> around in the swap unused. However, that would appear to be the same
> problem you face with unused player bodies and could likely be dealt
> with via the same mud policies.
>
> Other than the increase in inactive objects am I overlooking a major
> flaw with this idea?
>
> Cheers,
>
> Gary
>
> [1]: The hard-coded kernel "admin" user would continue to use a .pwd file.
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd