03 Jul, 2009, Sorressean wrote in the 1st comment:
Votes: 0
Hello,
I've started working on a mud from the ground up; I haven't quite found a mud base that I liked, and I would like to get down to coding rather than keeping trying to learn the multiple bases out there.
I'm looking for a good clean way to store player data and that.
I thought about using some sort of boost variant, but I'd rather my mud not need a bunch of libraries, if I can help it.
Does anyone have any good ideas for this?
I'd like to be able to store players with lists of objects, which would mean that either the object would get stored on them, or there would be a reference to the object somewhere.
This would work for example, for the player's inventory.
03 Jul, 2009, kiasyn wrote in the 2nd comment:
Votes: 0
I'd recommend chucking it into a database, such as MySQL. I'm currently using datamapper (ruby) for my work.
03 Jul, 2009, Sorressean wrote in the 3rd comment:
Votes: 0
I'll work on the mysql idea. I don't know much about it, so it requires a lot, but I guess xml would've been the same.
04 Jul, 2009, quixadhal wrote in the 4th comment:
Votes: 0
Quixadhal mutters about MySQL and puts in his 2 cents for PostgreSQL, which supports things like foreign key constraints and stored procedures.
05 Aug, 2009, Kintar wrote in the 5th comment:
Votes: 0
quixadhal said:
Quixadhal mutters about MySQL and puts in his 2 cents for PostgreSQL, which supports things like foreign key constraints and stored procedures.


MySQL supports foreign key constraints if you use the InnoDB engine (default for MySQL 5 and up). As for stored procedures, unless you're in an enterprise environment where squeezing every last drop of performance out of the database engine (for things like sorting and joins, which the DB does better than most application code) is a massive priority, you're really better off leaving all your code in the application. It's simpler to get it into some basic version control system (such as subversion), easier to maintain (new developers don't have to learn all the places where your app shoves processing off on the DB), and easier to debug (you don't have to do application debugging /and/ debugging for your sproc code).

Of course, I actually wrote a MySQL-based persistence mechanism for my codebase, then yanked the entire thing out and wrote a file-based mechanism. It's just simpler for the average mud admin to deal with text files than a relational database, and the implementation challenges are a pretty even trade off IMO.

Just my $1.50 worth. (I used to give $0.02, but I'm just not that succinct. :biggrin:)
05 Aug, 2009, Kintar wrote in the 6th comment:
Votes: 0
Oh, and one more thought: If you're using C/C++, using a database is going to be a bigger challenge than mapping your data to text files, as there aren't any really robust object-relational mappers for C/C++. (Well, not in my opinion. I'm sure there are OR/M systems out there for C++ that have a huge following.) Ruby, Java, Python and the like all have libraries that make mapping your objects into a database almost stupidly simple, but even then I stand by my previous statement about the ease of dealing with text files versus databases.
05 Aug, 2009, flumpy wrote in the 7th comment:
Votes: 0
Kintar said:
quixadhal said:
Quixadhal mutters about MySQL and puts in his 2 cents for PostgreSQL, which supports things like foreign key constraints and stored procedures.


MySQL supports foreign key constraints if you use the InnoDB engine (default for MySQL 5 and up). As for stored procedures, unless you're in an enterprise environment where squeezing every last drop of performance out of the database engine (for things like sorting and joins, which the DB does better than most application code) is a massive priority, you're really better off leaving all your code in the application. It's simpler to get it into some basic version control system (such as subversion), easier to maintain (new developers don't have to learn all the places where your app shoves processing off on the DB), and easier to debug (you don't have to do application debugging /and/ debugging for your sproc code).

Of course, I actually wrote a MySQL-based persistence mechanism for my codebase, then yanked the entire thing out and wrote a file-based mechanism. It's just simpler for the average mud admin to deal with text files than a relational database, and the implementation challenges are a pretty even trade off IMO.

Just my $1.50 worth. (I used to give $0.02, but I'm just not that succinct. :biggrin:)


Good god, he read my mind… :smirk:
05 Aug, 2009, Erok wrote in the 8th comment:
Votes: 0
Kintar said:
…then yanked the entire thing out and wrote a file-based mechanism. It's just simpler for the average mud admin to deal with text files than a relational database…

Second. Of course there are several libraries out there in several languages that will serialize text to and from objects, so you can save yourself the effort/pain of writing a file parser and its validation logic.
05 Aug, 2009, KaVir wrote in the 9th comment:
Votes: 0
Kintar said:
Of course, I actually wrote a MySQL-based persistence mechanism for my codebase, then yanked the entire thing out and wrote a file-based mechanism. It's just simpler for the average mud admin to deal with text files than a relational database, and the implementation challenges are a pretty even trade off IMO.

I went for flat files as well. I was considering using MySQL originally, but it would have increased my hosting costs, and seemed more complex than flat files, so I never really got around to it. However I've been thinking about it again since integrating the mud with the website, particularly as I fancy the idea of having a browser game that shares the same data as the mud.
05 Aug, 2009, Kintar wrote in the 10th comment:
Votes: 0
Erok said:
Of course there are several libraries out there in several languages that will serialize text to and from objects, so you can save yourself the effort/pain of writing a file parser and its validation logic.


If you find one that can produce pretty, human-readable data and then consume it again without any pre- or post-processing, let me know. All of the libraries I've worked with want to force you to a very rigid format that's not too friendly for admins who are looking to edit world data before restarting the MUD. Or, worse yet, they want to serialize to XML, and include all sorts of extra, pointless data that's nothing more than line noise to a user.

KaVir said:
However I've been thinking about it again since integrating the mud with the website, particularly as I fancy the idea of having a browser game that shares the same data as the mud.


Integration with websites is going to be part of my end-game plan, as well. But rather than storing the data into a central location (whether flatfile or rdbms) that both the server and the website can read, I'm going to expose RESTful web services from the game, and just consume those from the website. That way, I don't have to rework game state serialization, and I know exactly what data the website has access to, along with how it's managed.
05 Aug, 2009, Tonitrus wrote in the 11th comment:
Votes: 0
What about sqlite in C?

(Note: I'm asking because I want to know how much trouble it'd be to use)
05 Aug, 2009, Kintar wrote in the 12th comment:
Votes: 0
My previous statements about databases don't really change in regard to Sqlite. The only real differences in Sqlite and MySQL are Sqlite's manifest typing, and the fact that the server is embedded in your app. All the hassles and tradeoffs from flatfiles remain the same.
05 Aug, 2009, aidil wrote in the 13th comment:
Votes: 0
For data serialisation in a human readable and editable format you might want to look at yaml or json. The later would also be very useful for integrating web and mud.

Both can encode/decode pretty complex data structures similar to xml, but without most of the linenoise.

I personally prefer json for its apparant simplicity, writing a parser for it shouldn't take too much time, and they exist in many languages. Its JavaScript origins might make some want to avoid it tho :smile:
05 Aug, 2009, Runter wrote in the 14th comment:
Votes: 0
aidil said:
For data serialisation in a human readable and editable format you might want to look at yaml or json. The later would also be very useful for integrating web and mud.

Both can encode/decode pretty complex data structures similar to xml, but without most of the linenoise.

I personally prefer json for its apparant simplicity, writing a parser for it shouldn't take too much time, and they exist in many languages. Its JavaScript origins might make some want to avoid it tho :smile:


I give my seal of approval to YAML.
05 Aug, 2009, JohnnyStarr wrote in the 15th comment:
Votes: 0
Yeah, with YAML you could make a Ruby On Rails app super easy.
I guess it just depends on how extensive you want your DB front end to be.
05 Aug, 2009, Erok wrote in the 16th comment:
Votes: 0
aidil said:
For data serialisation in a human readable and editable format you might want to look at yaml or json.

http://www.yaml.org is one-stop shopping for YAML libraries.
05 Aug, 2009, Chris Bailey wrote in the 17th comment:
Votes: 0
I'm porting my system over to use Mysql with Sequel. I used Datamapper and ActiveRecord in the past (both are amazing!) but they are a bit heavy for something as simple as this.
05 Aug, 2009, Kintar wrote in the 18th comment:
Votes: 0
When it comes to plaintext storage formats, avoid the jihads. :wink: Just use whatever format you find that is clean and concise for your usage, and has a well-supported library for your programming language of choice. I've actually come to the point lately where I just define the bare minimum of what will be needed for my code, then use YACC or ANTLR to create a parser for it. It's a little more work, but it's typically a LOT cleaner than using YAML/JSON/XML/whathaveyou for files that will never need to be consumed by anything other than my applications. (Remember: XML, YAML and their ilk were created for data interchange. If you don't need other applications to read your data, you're just taking on extra cruft for no reason.)
05 Aug, 2009, quixadhal wrote in the 19th comment:
Votes: 0
Kintar said:
quixadhal said:
Quixadhal mutters about MySQL and puts in his 2 cents for PostgreSQL, which supports things like foreign key constraints and stored procedures.


MySQL supports foreign key constraints if you use the InnoDB engine (default for MySQL 5 and up). As for stored procedures, unless you're in an enterprise environment where squeezing every last drop of performance out of the database engine (for things like sorting and joins, which the DB does better than most application code) is a massive priority, you're really better off leaving all your code in the application. It's simpler to get it into some basic version control system (such as subversion), easier to maintain (new developers don't have to learn all the places where your app shoves processing off on the DB), and easier to debug (you don't have to do application debugging /and/ debugging for your sproc code).


Good on the foreign key constraints finally becoming part of the "normal" installation. That was always my biggest gripe. As for stored procedures, I don't use them so much for performance increases, as for simplicity of query handling and data transforms.

For example, I have an old mudlist cgi script that uses telnet to grab the login screen of the MUD that's being added and then transforms it from ANSI text to both HTML and a PNG graphic. While I certainly could do that on the script side, I didn't want to both escaping and sending all 3 chunks of data over the wire into the database. So, I just send the ANSI screen and have an insert/update trigger to run two tiny perl stored procs that do the transforms in place.

Most people won't want or need to do that, but I find having that kind of resources there useful. It's not a show-stopper though.

Kintar said:
Of course, I actually wrote a MySQL-based persistence mechanism for my codebase, then yanked the entire thing out and wrote a file-based mechanism. It's just simpler for the average mud admin to deal with text files than a relational database, and the implementation challenges are a pretty even trade off IMO.


To me, that depends on why you're using SQL, and why you're coding your MUD in the first place. If you're writing a codebase for the public, then yes… keeping it simple is usually best. If you're writing it for yourself, do whatever you want. I would never remove a feature from my game because the "average mud admin" can't figure it out… but I'm not writing my game as a public codebase I want people to adopt. I also don't want to use SQL as a simple data store… there are MUCH easier things to use for that purpose. I *DO* want the query power of SQL so I can analyze the game data and use it for balancing purposes.

One thing I'm considering is the idea of using JSON or something similar for file storage and then having a small utility script to upload that into a database for analysis. In truth, unless I had a fully running game with a handful of builders, having the data in a live SQL database isn't as necessary as just having a recent snapshot. If you DO have a small cadre of builders though, it might be nice to be able to build directly against the database (web building tools, what a concept!).
06 Aug, 2009, flumpy wrote in the 20th comment:
Votes: 0
Kintar said:
If you find one that can produce pretty, human-readable data and then consume it again without any pre- or post-processing, let me know


I use XStream which serializes java objects to xml format. Or JSON format. Or any other kind of format you can write a wossname for. The xml it produces can be re-serialized and is pretty readable and concise. You can alias certain things so they don't look so bloaty.

Kintar said:
When it comes to plaintext storage formats, avoid the jihads. :wink: Just use whatever format you find that is clean and concise for your usage, and has a well-supported library for your programming language of choice.


I agree entirely but the following seems to contradict that:

Kintar said:
I've actually come to the point lately where I just define the bare minimum of what will be needed for my code, then use YACC or ANTLR to create a parser for it. It's a little more work, but it's typically a LOT cleaner than using YAML/JSON/XML/whathaveyou for files that will never need to be consumed by anything other than my applications. (Remember: XML, YAML and their ilk were created for data interchange. If you don't need other applications to read your data, you're just taking on extra cruft for no reason.)


Well… to be honest.. when you persist data you are "interchanging" it with the hard drive and back off it again into your application. So I don't agree with you entirely on that statement but I get what you are trying to get at.

The trouble with proprietary formats is they are, well, proprietary, and once written even if you wanted to interchange them with other systems you then couldn't unless you wrote something extra in that system. XML is pretty human readable, JSON is a bit strange but still readable, and even a database can be human-read (once it's been processed by an intermediary program of some sort of course). Each have a semi-standard access mechanisms that (almost) everyone can use. Would your proprietary format be the same?

Then again if you are using something like ANTLR you may end up reinventing the wheel. Why not write your stuff out in "builder" format (e.g. a groovy builder?) or in a format your scripting language can easily and readily parse? Well I expect that actually might be too complex, as I have often pondered over this myself.

One thing I would like to say about this thing would be to keep "encapsulation" in mind. If you abstract a layer over the top of this kind of persistence it will mean that you should be able to swap your file system for a database without even blinking an eye, and that is what you should be aiming for.
0.0/55