keeping information about players around

[Dwight Hutto]

> I have yet another design question.
> In my mud, zones are basically objects that manage a collection of rooms;
> For example, a town would be it's own zone.
> It holds information like maxRooms, the list of rooms as well as some other
> data like player owners and access flags.
> The access flags basically is a list holding the uid of a player, as well as
> a bitarray of permissions on that zone. For example, a player might have the
> ability to edit a zone, but not create rooms.
> So I have a couple of questions based on this:
> First, how viable would it be to keep a sort of player database around with
> stats and that?
Well, what are the main items you need to retain for the player to
return to the game?

Also, If this is a browser app I'd go with phpmyadmin, and MySQL

If a tkinter/wxpython/etc app, then maybe sqlite.

> It could contain the player's level, as well as other information like their
> access (player, admin, builder etc), and then when someone does a whois on
> the player I don't have to load that player up just to get data about them.
> How would I keep the information updated? When I delete a player, I could
> just delete the entry from the database by uid.
> Second, would it be viable to have both the name and the uid stored in the
> dictionary? Then I could look up by either of those?
>
Why would you use a dictionary, when it's DB manipulation you're after?

> Also, I have a couple more general-purpose questions relating to the mud.
> When I load a zone, a list of rooms get stored on the zone, as well as
> world. I thought it might make sense to store references to objects located
> somewhere else but also on the world in WeakValueDictionaries to save
> memory. It prevents them from being kept around (and thus having to be
> deleted from the world when they lose their life), but also (I hope) will
> save memory. Is a weakref going to be less expensive than a full reference?

For any case, you're going to have a DB field with a value, so it
doesn't look like a high value memory cost in the DB.

> Second, I want to set up scripting so that you can script events for rooms
> and npcs. For example, I plan to make some type of event system, so that
> each type of object gets their own events. For example, when a player walks
> into a room, they could trigger some sort of trap that would poison them.
> This leads to a question though: I can store scripting on objects or in
> separate files, but how is that generally associated and executed?

Well, the event doesn't need to be stored unless there is a necessity
to store the event, but if it's poisoned, then it's just a life
penalty, then no need to store the event, just the score loss.

> Finally, I just want to make sure I'm doing things right. When I store data,
> I just pickle it all, then load it back up again. My world object has an
> attribute defined on it called picklevars, which is basically a list of
> variables to pickle, and my __getstate__ just returns a dictionary of those.
> All other objects are left "as-is" for now. Zones, (the entire zone and all
> it's rooms) get pickled, as well as players and then the world object for
> persistence. Is this the suggested way of doing things? I'll also pickle the
> HelpManager object, which will basically contain a list of helpfiles that

I might suggest you take a look at the Blender Game Engine(python API)
at this point, unless you're just liking doing it the hard way to gain
experience(just like I have).

Design the DB, and let the scene render what needs to be rendered, or
list data  for, and those are the necessities to be stored.

-- 
Best Regards,
David Hutto
CEO: http://www.hitwebdevelopment.com