keeping information about players around

[Jean-Michel Pichavant]

----- Original Message -----
> ytHello all:
> I've asked for a couple code reviews lately on a mud I've been
> working
> on, to kind of help me with ideas and a better design.
> 
> 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?
> 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?
> 
> 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?
> 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?
> 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 can be accessed, along
> with
> their contents.
> Thanks, and appologies for all the questions.
> 
> --
> Take care,
> Ty
> http://tds-solutions.net
> The aspen project: a barebones light-weight mud engine:
> http://code.google.com/p/aspenmud
> He that will not reason is a bigot; he that cannot reason is a fool;
> he that dares not reason is a slave.
> 
> --
> http://mail.python.org/mailman/listinfo/python-list
> 

That's a lot of questions, few specific to python.
I have one advice:

Don't think too much about performances. Focus on keeping things simple, work on your design and forget about implementation.
Pickle everything, use sqllite for your database. When you get things working, then you can start measuring your performances and think about clever implementation to speed up things **if needed** (<- key notion). 


JM