05 Nov, 2011, Lundex wrote in the 1st comment:
Votes: 0
Well, I've been thinking about using a form of mySQL, for my saving, loading, and updating needs. I just ran into a few basic things I don't really understand how I would save in the format that mySQL uses.

Example:
Saving character's items, skills/spells, equipment and such things.
05 Nov, 2011, Exodus wrote in the 2nd comment:
Votes: 0
Pretty much the same way they are saved in flat files, with the exception that it's generally best practice to store entities in separate tables. Objects, for example:

1. Store the object's index data (reference, template, whatever your base object attributes are) in a table and call it something like index_objects and give each a unique identifier, such as vnum.
2. Store the character's data such as various states, attributes or whatever else you normally would save to a player file in a table and call it players or something similar. Give it a unique identifier as well.
3. Create another table and call it something like character_objects. In this table, you store the items the character has on them at the time of saving. Add fields such as an object_index_id and player_id to reference the object's base stats as well as the player it was located on, respectively. You can also store custom modifications to item attributes the player may have that differ from the base object data, such as a custom name or augmented stat bonuses.

That pretty much covers saving. As for loading, simply create a character from your in-game structure and load the data from the character table for the record that matches the name or whatever you want to identify it with. For loading objects, you would do something like this:

1. Pull records from the character_objects table where the player_id matches the id of the character they belong to.
2. Pull records from the index_objects table where the object_index_id in the character_objects table matches the id of the object they belong to and assign them.
3. Add any additional modifications necessary from data stored in the character_objects table (customizations, remember?) and load them on the character.
4. $$$ Profit.


You would essentially do the same scenario with most of your data structures.
05 Nov, 2011, quixadhal wrote in the 3rd comment:
Votes: 0
There are plenty of ways you can use SQL, some more useful than others.

A popular thing these days is to use an "ORM" interface (Object-Relation-Mapping), but those are usually easier to use in dynamic languages like perl/ruby/C# where your classes can be directly instantiated by a database object.

You can also do it the simple way Exodus described, basically treating each table as an array of records of the appropriate type. The common thing here is to use a "junction table" to handle what would be an array in your object.

For example, a player will generally have an inventory. The player data itself would be stored in a players table, where the primary key is either a unique ID, or the player name itself. To handle the inventory array, you would make an inventories table whose primary key would be both the player ID and an item ID, so each player would have multiple entries in the inventories table. Loading a player's inventory would be a query like 'select * from inventories where player_id = ?'.

To be a bit more robust, you could also make a proper schema that includes foreign key constraints and tables for valid values of constants (such as flags). In that case, your inventories table would be declared something like:

create table inventories (
integer player_id not null references players (player_id),
integer item_id not null references items (item_id)
);

and you'd have an item table with all your game objects in it. Because of the foreign key constraints, you can't have an invalid player ID or an invalid item ID… the SQL system will prevent such data from being inserted. You can even setup cascade deletes/updates so if you remove a player, the SQL system will automatically remove anything referenced by that player_id.

IMHO, MySQL is a poor choice because it lacks many of the features to allow for this kind of thing, but if you just want simple stuff, go for it.
05 Nov, 2011, Nich wrote in the 4th comment:
Votes: 0
This is a 30 second primer to mySQL. Google the terms for more information.

mySQL is an implementation of a relational database. There are other kinds of databases, but relational are currently really popular.

Relational databases work by creating associations between tables. Picture a spreadsheet. The columns of the "spreadsheet" represent properties. So, for example, if you have a table of weapons, you might have the weapon's name, the amount of damage it does, the type of the weapon (sword, spear, etc.) as columns. By convention (but it's a *really* strong convention) there is a column that contains a unique, usually numerical id. The rows of the "spreadsheet" represent individual weapons. When you read across the row, you can find all of the properties of the individual weapon.

So, a good practice would be to have a table that contains all of the types of weapons, and the information about them (sword, spear, knife). Then you have a table of all of the weapon instances… sword1, sword2, sword3, spear1, spear2, knife1, knife2 … which reference the type table. Each one of these items has an item id. The table would have a column whose rows contain the weapon type id. Then, to make an inventory, you create an inventory table, which has a column for player id's, and a column for item id's

For spells, have a table of all the spells, and a table that lists all of the spells a player has (very similar to an inventory). For equipment, it's pretty much the same

And that's basically everything you need to know. As quixadhal mentioned, most systems have some nice features that prevent errors (such as preventing adding items that don't exist, and automatically handling cases like an item which is deleted being deleted from all tables that reference it, so you don't end up with weird things like a player having a sword without stats).

To get started, I would recommend looking up a tutorial on MySQL. Don't try to integrate it right away, just play around with some samples so that you can get a good idea of how querying works (Particularly joining).
05 Nov, 2011, Runter wrote in the 5th comment:
Votes: 0
Quote
IMHO, MySQL is a poor choice because it lacks many of the features to allow for this kind of thing, but if you just want simple stuff, go for it.


I don't think this is really true any more. mySQL has came a long way. Many popular configurations of mySQL do come with foreign key constraints, for example.

To the original poster: I'd go with whatever you find easiest to set up and get your feet wet with. I'm not even against sqlite3. It has to be a step up from what 99% of muds are currently doing. Echoing Voltaire, try not to let perfect and good solutions be enemies. You'll find there aren't many perfect solutions.
07 Nov, 2011, nfa wrote in the 6th comment:
Votes: 0
Would not a document-oriented NoSQL database be appropriate for this? It would map so beautifully over. Eg. using something popular like CouchDB or MongoDB.
07 Nov, 2011, arholly wrote in the 7th comment:
Votes: 0
And when you start, start with something much easier, like help files. Those don't really need any other cross-references or joins and are simple queries.
07 Nov, 2011, Runter wrote in the 8th comment:
Votes: 0
nfa said:
Would not a document-oriented NoSQL database be appropriate for this? It would map so beautifully over. Eg. using something popular like CouchDB or MongoDB.


I think both would be great.
08 Nov, 2011, Kelvin wrote in the 9th comment:
Votes: 0
Minor disclaimer: Using NoSQL means you're going to need to enforce some constraints yourself, whereas many SQL DBs will provide a lot of that for you. Examples are enforcing foreign keys, unique IDs, data types, and etc. Saving and loading are much easier with NoSQL, but you do end up doing a lot of cleanup on object deletion.

That said, I am using CouchDB for my project. The choice of data store is a very boring discussion. Just pick something and get this over with so you can move on to more interesting stuff, like actual game design.
08 Nov, 2011, Runter wrote in the 10th comment:
Votes: 0
Kelvin said:
Minor disclaimer: Using NoSQL means you're going to need to enforce some constraints yourself, whereas many SQL DBs will provide a lot of that for you. Examples are enforcing foreign keys, unique IDs, data types, and etc. Saving and loading are much easier with NoSQL, but you do end up doing a lot of cleanup on object deletion.

That said, I am using CouchDB for my project. The choice of data store is a very boring discussion. Just pick something and get this over with so you can move on to more interesting stuff, like actual game design.


That's a scatter shot of things you mentioned there, and certainly not true in all cases. For example, couchdb does have and enforce unique ids. Lumping all nosql solutions into the same featureless bin is silly. I mean, not all databases are concerned about the tabular approach. Look at something like Redis. The entire thing is a datatype-database. So I think the overall thing to take away is that nosql will be vastly different from a sql database, because, well, its not a typical sql related database. Features of one to the next will swing wildly.
08 Dec, 2011, klink wrote in the 11th comment:
Votes: 0
we're starting to integrate TPL for saving and loading, i dont know how well that would integrate for your needs but for saving and loading pfiles its working out very nicely.
0.0/11