keeping information about players around

[Littlefield, Tyler]

On 9/24/2012 3:14 PM, Dwight Hutto wrote:
>> 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?

> All of their contents are stored, which right now is done through Pickle. The stats is something different, as like I said, I don't want to unpickle an object every time I for example look at a zone and see what players have permissions on it.

Also, If this is a browser app I'd go with phpmyadmin, and MySQL If a 
tkinter/wxpython/etc app, then maybe sqlite.

PHPMyAdmin? Might I ask why? This is a mud, so it's all command based, 
so that's not even a question, but I'm kind of curious how PHPMyAdmin 
factors in there. It's a database creation tool from all I've ever seen 
of it, to define tables. Also, using it requires that I have it up on 
some server or another, and I'd really rather avoid that if I can.

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

> It is? I don't remember mentioning database anything in my thread. Unless I missed it, I mentioned pickle once or twice. But either way, I'd use a dictionary to keep a copy of {uid:object} for objects and {uid:player} for players. Makes lookup by uid pretty easy, as well as for any loaded objects.

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

> I was asking about scripting the rooms, more than storing it. I need to have python code somewhere, somehow that attaches to the onEnter event in a room and subtracts hp from the player. Obviously you want that to be object specific and not have that script on everything.

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

> That's cool I guess, but I'm not taking your road and doing it the hard way for experience. The setup is more of a game engine, but beyond that, I don't think I need everything i get from a game library, especially since IIRC, Blender is mainly 3d focused?

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.


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