L
Littlefield, Tyler
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.
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.