hey all could anyone elaborate a little on databases for games and how i could create/use one. im using c++ (to which im still a newbie at) and have extremely limited knowledge on them.. mysql? lol thanks ;)

Firstly, you need to think about why you actually want one.

For example you may just want a database to hold a list of highscores for a pong clone through to a database holding all kinds of info on stats/inventory/character detail etc etc etc for an RPG.

Once you've figured out what information you want to hold, you've then got to figure out how you want to group the information.

A highscore database could just hold one table with a list of highscores. At the end of each game, you'd run some code to check the player's score against the scores held in the table and insert as appropriate.

For an RPG it'd be ALOT more complicated. For instance, you could have a table with information on weapons, holding a weapon's type, its hit strength, any special features etc.

Depending on how many different weapons you have though it could be a better idea to separate out the tables i.e.

a table that holds the names of all the different weapon types

for each weapon type there could be a table that holds its name and some stats about it

on the other hand, the weapon name table may just hold the weapon name, with a further table linked in to hold the weapon's stats

It really does come down to what type of game you want to make, what type of information you want to hold and you will have to make some choices on how to structure the storage.

For any sort of large scale use, like the RPG example, you will need to read up on using table keys and normalisation, they will give you an idea of when/why you should hold the data in different tables instead of in one giant one.

As for creating and using one, there are better people than me here to suggest what to use, I use SQL Server simply because that's what my employer uses, there could be free stuff out there.

http://www.w3schools.com/sql/default.asp

has a nice guide to working with SQL.

That's about all I can think of, apologies if I'm unclear in anything I've said but just post back if there's anything you'd like me to clear up.

You need to decide if you really need a database. If you are just storing static information or high scores then you really don't need a database. Databases are best when the data is changing a lot.

If you just need to store game information, such as RPG quests information, world information, ect. then there are many other ways of doing it.

If you do decide that you need a database then you really need to look into database design and database normilization. The design of the database is a huge part of the project. A badly designed database will make your programming a lot hard and also be a huge proformance hit.

theTroll

Also, it's not usually feasable to write a non-online game that needs a database. You can't usually deploy a database on a client machine, (With the exception of SQLite which just runs in a DLL) since most databases run as Windows services.

If you're running a database, you usually want the database and application running on a server machine, and have the clients connect to the application to request information from the DB. Allowing client applications to connect directly to the DB is just asking for trouble.

Quote:Allowing client applications to connect directly to the DB is just asking for trouble.

Why?

Quote:Original post by 3dnewbie

Quote:Allowing client applications to connect directly to the DB is just asking for trouble.

Why?

one reason I see is that you have a direct link to the database from the client application, now if you connect to an app - which will filter any crap coming in, this seems to be taking better precautions for security reasons.

You don't want your clinets to directly access the database for secruity and performace issues. First you want to make sure they are not changing things they should not be. You should always assume the client is not secure, so you need verify everything that is sent by the client. So if you had a database that stored the player's money, the client could be hacked and the person could give themselves as much money as they wanted to. Next, you do not want hundreds or thousands of connects to the database becuase it degrades performance.

theTroll

Connecting to a database is resource intensive, plus I think there's a limit to the amount of open connections you can have at a certain time, so it's best to let the client connect to an app that manages all this instead. Plus adding a layer of abstraction to connecting to the database helps with security.

Or so my head leads me to believe anyway

Sorry if i rub people the wrong way now, but these are all b*s reasons as far as i can see.

1. The database and server it is running on should _already_ be secure. Having middleware as an arbiter in the middle filtering out 'bad' stuff is just making things more bloated and obscure, not to mention you add an extra bottleneck to the infrastructure.

Not for security and performance reasons, i think that should be thus the other way around. You _want_ them to access the db server directly, _because_ of those very reasons.

You can put all those limitations (connection throtteling, security etc.) on the server and in the db itself. If you really dont trust the sql security itself, sure you can add some filter in between but i don't i would do it. Instead, first time the sql servers get hacked, -> more work for the sql team to fix something.

3dnewbie, you are missing a few things here. Well a lot of things. First of all there are two types of security we are talking about here. One is the secruity of the database. Yes that can somewhat secured using other methods. The other is data securtiy. Who do we make sure that the data being sent from the client is valid? Well you can't do that unless there is something between the client and the database to make sure people are not cheating.

Next each database connection is very very resource intensive. The goal is to use as few as you can to keep things moving along nicely. The more connections you add the move the db has to deal with locking issues and with polling issues. These slow the db down.

theTroll