(NOTE: I have no working code for this yet, so unable to post any...need help with DB unerstanding)

OK, So I have my initial layout for my game...being a noob when it comes to anything to do with DB, I do not understand what exactly I am looking at. I installed MySQL 5.0. Need to read a whole lot more on it because I have no idea how it is supposed to work. The problem I am running into with MySQL (or any DB for that matter) is what information it will hold.

I know this can store like usernames, passwords, emails, etc...but what about specific account information like inventory, stats and such for an RPG game. Is this stuff that the DB manages, or is it supposed to be managed in my code for the server like with the maps? Does someone know of a better way to manage these things for the client/characters?

Databases pretty much hold all information about objects (often called entities in the DB world) and their relationships between one another. For instance, your game may have the user account. The user would be an entity. You would keep track of their username, password, email etc. This user may have several game characters. A character in a game would be another entity. They could have things like hitpoints, gold, wood, stone, magic points, battles fought, battles won, battles lost etc.

The database will also hold relationship data. Tables that describe that user account 2 links to characters 4, 5, and 6 in the characters table. Such a relationship is said to be a "one to many" relationship. One user entity has several character entities. In this example user 2 has three characters in the game.

Any piece of solid "data" is in a database. Now information on the other hand is not typically in a database. Information is gathered by comparing and aggregating pieces of data. Remember how I said they had battles fought, battles won and battles lost? Well your code will use those three pieces of DATA to determine that on 10 battles fought and 3 battles won that they have a success rate of 30% ((3 / 10) * 100). Anything that can be calculated on the fly based on other data typically has no business being in a database.

Database tables typically contain things like user accounts, character attributes, settings, statistical data (not info that is calculated), counters, logging, maybe errors or bugs in the game and when they were made etc.

If is an object in your game and needs to persist across time (between logins etc) then you will find it typically in a database.

If you have MS access you will have a database sample called "Northwind" in a file called "Northwind.mdb". This is a sample database that shows you some types of information you may have in a typical relational database.

If you need a copy I believe you can download it from the following link...

MS Access 2000 Northwind Database Sample

Now while this is MS access and not MySQL the relationships and tables they form are very similar. The idea of relational database design is universal. So check it out and hopefully that will help.

You can also read MySQL books from the bookstore and they will tell you more. Good luck!

Thank you for that! It pretty much gives me the idea of what I will need to implement in the DB, and what I will need to hard code.

Yet another theoretical DB question. Have searched the forums, and all of the free e-tutorials I have come across. Going to the bookstore on Thursday to pick up something more instructional for MySQL...but until then:

While working on the layout for my client I came across the parts that deal with the Database such as the account creation method, and verifying the information versus the existing data. From what I am gathering the information transferred is going to be saved to a database file once the Entities and Tables are set up. However, once information is sent to the MySQL file, is it automatically updated and saved in the DB file, or does saving updated data need to be initiated in the loop of the program for every iterration?

Martyr2:



I had to re-read quite a few times before I knew I wasn't understanding fully...

If I am not mistaken, this would include inventory items as well. If so, all information for each character needs to persist across time, thus, would be in the database. Other than the win/loss ratio example that would not need to be calculated within the DB, is there another example of something that would not need to be included because I keep thinking that I am forgetting something.