Re: keeping information about players around
- 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.
JM
--
http://mail.python.org/mailman/listinfo/python-list
Re: keeping information about players around
On Tue, 25 Sep 2012 08:19:34 +1000, Chris Angelico wrote: > On Tue, Sep 25, 2012 at 7:14 AM, Dwight Hutto > 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. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: keeping information about players around
On Mon, Sep 24, 2012 at 7:52 PM, alex23 wrote: > On Sep 25, 9:44 am, Dwight Hutto wrote: >> What DB are you recommending, check out sqlite's: >> >> http://www.cvedetails.com/vulnerability-list/vendor_id-9237/Sqlite.html > > Are you _seriously_ comparing _four_ vulnerabilities to 60+? > Even less if you use your own DB structure, and evn less in mysql if you reject the injections of the known vulnerablities. >> Maybe just a parsed file with data, and accessing data that you design. > > Just stop. Why not suggest odbm or relational db's, this shows your lack of complexity in design, so please stop your own Dunner-Kruning. -- Best Regards, David Hutto CEO: http://www.hitwebdevelopment.com -- http://mail.python.org/mailman/listinfo/python-list
Re: keeping information about players around
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 d
Re: keeping information about players around
On Sep 25, 9:44 am, Dwight Hutto wrote: > What DB are you recommending, check out sqlite's: > > http://www.cvedetails.com/vulnerability-list/vendor_id-9237/Sqlite.html Are you _seriously_ comparing _four_ vulnerabilities to 60+? > Maybe just a parsed file with data, and accessing data that you design. Just stop. -- http://mail.python.org/mailman/listinfo/python-list
Re: keeping information about players around
On Mon, Sep 24, 2012 at 7:28 PM, alex23 wrote: > On Sep 25, 8:32 am, Dwight Hutto wrote: >> No, but phpmyadmin is a great GUI for MySQL > > If you're recommending MySQL use on the basis of phpmyadmin, you > should also make sure to mention: > http://www.phpmyadmin.net/home_page/security/ > > Great GUI, maybe. Huge security hole, absolutely. Most organisations > I've worked for won't allow it anywhere near their servers. What DB are you recommending, check out sqlite's: http://www.cvedetails.com/vulnerability-list/vendor_id-9237/Sqlite.html Maybe just a parsed file with data, and accessing data that you design. -- Best Regards, David Hutto CEO: http://www.hitwebdevelopment.com -- http://mail.python.org/mailman/listinfo/python-list
Re: keeping information about players around
On Sep 25, 8:32 am, Dwight Hutto wrote: > No, but phpmyadmin is a great GUI for MySQL If you're recommending MySQL use on the basis of phpmyadmin, you should also make sure to mention: http://www.phpmyadmin.net/home_page/security/ Great GUI, maybe. Huge security hole, absolutely. Most organisations I've worked for won't allow it anywhere near their servers. -- http://mail.python.org/mailman/listinfo/python-list
Re: keeping information about players around
> 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. -- Best Regards, David Hutto CEO: http://www.hitwebdevelopment.com -- http://mail.python.org/mailman/listinfo/python-list
Re: keeping information about players around
On Tue, Sep 25, 2012 at 8:31 AM, Dwight Hutto 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. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: keeping information about players around
>> 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. -- Best Regards, David Hutto CEO: http://www.hitwebdevelopment.com -- http://mail.python.org/mailman/listinfo/python-list
Re: keeping information about players around
On Mon, Sep 24, 2012 at 6:19 PM, Chris Angelico wrote: > On Tue, Sep 25, 2012 at 7:14 AM, Dwight Hutto 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. -- Best Regards, David Hutto CEO: http://www.hitwebdevelopment.com -- http://mail.python.org/mailman/listinfo/python-list
Re: keeping information about players around
On Tue, Sep 25, 2012 at 7:14 AM, Dwight Hutto 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. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: keeping information about players around
> 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
Re: keeping information about players around
- 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. JM -- http://mail.python.org/mailman/listinfo/python-list
Re: keeping information about players around
- 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 -- http://mail.python.org/mailman/listinfo/python-list
keeping information about players around
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
