[DGD] Persistent Users

[Gary]

On 21/09/16 17:55, Schmidt, Stephen wrote:
> It's been quite a while since I thought about this, but I had also observed
> the possibilities of persistent player bodies stacking up.

[snip]

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

I agree and have given a limited amount of thought to what should happen
to player bodies when they're inactive due to logoff/link loss as well
as accounts that are inactive long term.


The issue as I see it has two sides, game design and technical.

>From a design point of view, it's what happens when a player logs off,
do their bodies just remain there, turn to statues, vanish to a holding
room and return when they log back in...

There's been discussion on this before about that and I think the final
decision will ultimately depend on the theme of the mud. So I'm punting
that one for now.


The other issue is one of technical limitations. Assuming a given user
account can have multiple characters, or that players are allowed
multiple user accounts. The number of users and player bodies to persist
will (on a successful mud anyway) continue to grow.

DGD appears to limit array_size to a maximum of unsigned short / 2,
32768 items[^1]. That looks like a compile time limit and a prior post
by Dworkin said:

>  The limit exists for muds with guest programmers.

So increasing that would solve for all practical purposes the limit of
user accounts in userd without changing the kernel library to use a
mapping of arrays on the assumption that malicious or innocently
negligent guest programmers are not an issue.


Some policy would need to be in place to prune accounts should the
number of inactive accounts grow so large that the storage space or
sheer object count begins to cause issues.

I don't see disk storage as a realistic issue, whether object count
would be however I'm not sure at this time.


As for why I'm considering persisting users rather than saving password
and other account information to files is partly that it just avoids
load/save and permissions.

To upgrade accounts or do other processing you can just loop over all
users in userd (likely spread over execution threads if user counts are
high enough that swapping out would be important). As opposed to looping
over all the account files and creating/destroying objects.


Ignoring the array size limit under the assumption that a rebuilt driver
with increased limits will solve that, the issue I can think of is that
should a state dump need to be reverted for any reason, users who
changed their passwords may suddenly find they need to use their old
password rather than latest. They may not remember the old password.

I see that as a minor issue as long as there's any form of password
reset support which would be useful for general forgetfulness anyway.


Thanks for the replies everyone,

Regards,

Gary

[1]: Realistically I'll be shocked if I ever release this mudlib as an
actual mud, let alone hit 32k accounts (active or not). But as there's a
chance others will take the code and run with it and perhaps have a more
successful mud, I'd prefer to not be too overly pessimistic with the
design :)