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.
----- 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.
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).
----- Original Message -----
> >Pickle everything, use sqllite for your database. When you get
> >things
> working, then you can start measuring your performances and think
> >about
> clever implementation
> That was a bunch of information; sorry about that. what do you mean
> by
> using sqlite for the database? Currently I just drop everything into
> files. Is there a better way to do that?
> Thanks for your advice.
Please keep the discussion on list.
If you have a basic knowledge of databases, sure you could use a sqlite database to store you persistent objects. That's pretty reasonable.
Not to mention a lot of stuff can interface with that database. If you want to build a web app to manage the player database, you can, most of the frameworks handles sqlite. Actually if you don't need a web app, a lot of sqlite admin app already exists.
Note that the database is suitable only for the data. For serializing a python object with its code, you need pickle.
> 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.
On Tue, Sep 25, 2012 at 7:14 AM, Dwight Hutto <dwightdhu...@gmail.com> wrote:
> Also, If this is a browser app I'd go with phpmyadmin, and MySQL
> If a tkinter/wxpython/etc app, then maybe sqlite.
Out of curiosity, why? MySQL isn't magically better for everything
where data ends up displayed in a web browser. Unless you're planning
to also reference this database from some other language, it's going
to make little difference what backend you use; and even if you are
using multiple languages, it's usually not difficult to find overlap.
On Mon, Sep 24, 2012 at 6:19 PM, Chris Angelico <ros...@gmail.com> wrote:
> On Tue, Sep 25, 2012 at 7:14 AM, Dwight Hutto <dwightdhu...@gmail.com> wrote:
>> Also, If this is a browser app I'd go with phpmyadmin, and MySQL
>> If a tkinter/wxpython/etc app, then maybe sqlite.
> Out of curiosity, why? MySQL isn't magically better for everything
> where data ends up displayed in a web browser.
No, but phpmyadmin is a great GUI for MySQL
Unless you're planning
> to also reference this database from some other language, it's going
> to make little difference what backend you use; and even if you are
> using multiple languages, it's usually not difficult to find overlap.
Well this is python, but in the browser a little echo, instead of
print, isn't that bad for conversational php.
And in the end it's usually html, php, css, javascript in the browser,
atleast for me it is. I'm just starting to utilize python in that
area, so excuse the naivety.
>> Out of curiosity, why? MySQL isn't magically better for everything
>> where data ends up displayed in a web browser.
> No, but phpmyadmin is a great GUI for MySQL
Meaning, it gives a great web app, that sqlite doesn't have...yet.
It's the tools around MySQL for me, that gives it the umph it needs to
be a great DB, with the GUI (phpmyadmin)to match, and short
reference/learni8ng curve to use php in this instance.
On Tue, Sep 25, 2012 at 8:31 AM, Dwight Hutto <dwightdhu...@gmail.com> wrote:
> And in the end it's usually html, php, css, javascript in the browser,
> atleast for me it is. I'm just starting to utilize python in that
> area, so excuse the naivety.
In the browser it's HTML, CSS, JavaScript (ECMAScript, etc, etc); PHP
is just a way of generating that. Any language works on the back
end... and PHP isn't the best :) Python does quite well at that task;
I have a tiny little Python script that uses a web browser as its
front ent.
> is just a way of generating that. Any language works on the back
> end... and PHP isn't the best :) Python does quite well at that task;
> I have a tiny little Python script that uses a web browser as its
> front ent.
This stems from my limited usage of python in the browser(I usually
use it for prototype apps). It's usually going to be the difference
between echo or print html/javascript, and perform an iteration for
table, or formulaic computation within a standard function syntax.
On Mon, Sep 24, 2012 at 7:28 PM, alex23 <wuwe...@gmail.com> wrote:
> On Sep 25, 8:32 am, Dwight Hutto <dwightdhu...@gmail.com> wrote:
>> No, but phpmyadmin is a great GUI for MySQL
>> 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.
On Mon, Sep 24, 2012 at 7:52 PM, alex23 <wuwe...@gmail.com> wrote:
> On Sep 25, 9:44 am, Dwight Hutto <dwightdhu...@gmail.com> wrote:
>> What DB are you recommending, check out sqlite's:
On Tue, 25 Sep 2012 08:19:34 +1000, Chris Angelico wrote:
> On Tue, Sep 25, 2012 at 7:14 AM, Dwight Hutto <dwightdhu...@gmail.com>
> wrote:
>> Also, If this is a browser app I'd go with phpmyadmin, and MySQL
>> If a tkinter/wxpython/etc app, then maybe sqlite.
> Out of curiosity, why? MySQL isn't magically better for everything where
> data ends up displayed in a web browser. Unless you're planning to also
> reference this database from some other language, it's going to make
> little difference what backend you use; and even if you are using
> multiple languages, it's usually not difficult to find overlap.
For a desktop application, you can't expect the application user to have set up MySQL or Postgresql first, so you have to use something like sqlite.
For web applications, you're probably expecting (or at least hoping for) tens of thousands of users a day, and sqlite probably won't cut it. If your web app is only used by you, then you might not care.
I think it is perfectly reasonable to assume a web app and a desktop app might use different backends.
----- Original Message -----
> 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.
Given the nature of your project forget MysQL and phpAdmin. At most you may use sqlite. Sqlite data is stored in one file, locally, you can move it back it up easily. Sqlite doesn't need any server.
If you don't see How sqlite would benefit your mud, that would be strange, but then drop it and use pickled dictionaries if you're familiar with them.
> > 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.
Actually you mentioned a "player database" in your original post. Player with their stats are typically something that may ends up in a database, along with any object and its properties.
That's why people suggested to use a database. Databases provide then powerful tools to fetch, search and edit your data. Performances on disk access would be handled by sqlite itself, something you may care by yourself if you use dictionaries.
Or maybe your mud doesn't store anything on disk, every run start fresh, in that case just use dictionaries.
