> 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 -- http://mail.python.org/mailman/listinfo/python-list