Archived

This topic is now archived and is closed to further replies.

Dreddnafious Maelstrom

To Database or Not to Database, TITQ

Recommended Posts

Ok gaming guru''s, i''m currently taking all of my data and writing it too a text file and then looping through a parser to load my maps, and other mesh object info. I thought about switching to binary to decrease the load times and then I began to wonder, do professional games do this or do they use a database to store there config files? Anyone want to spill their guts on this issue? It seems like i could use mySQL and have a much better, more secure Datawarehouse. NE1? Dreddnafious Maelstrom "If i saw farther, it was because I stood on the shoulders of giants." Sir Isaac Newton

Share this post


Link to post
Share on other sites
Usually, games make their own small databases or just load individual binary files. Using something like mySQL for a non-server situation is going a little overboard.

Share this post


Link to post
Share on other sites
"real" databases are optimized for a ton of data and/or complex queries. They would be overkill (and probably slower) for something like a config file unless the configuration is very complex.

Share this post


Link to post
Share on other sites
I don''t understand how you would use a commercial database like Oracle or Sybase without having the player having to have a copy of that database on their machine... Isn''t a bit too much to ask?

Easier to roll your own database. The only kind of database in my projects is a ResourceManager class. Maybe if you are doing a MMORPG you''d want all your data to be on a separate server and in this case you might want to use a commercial database. Commercial databases are really really high performance, but they''re very generalized and there are a lot of layers of drivers, FAPs, transaction monitors, and other junk going on between the client and the server. I''m not sure how this would compare performancewise to what you could produce in shop... If someone knows otherwise, please do say

I know lots of RTS companies keep Excel spreadsheets of all their unit stats and such, I''m not sure if they export the data into flatfile format to read it into the game or not ...

Share this post


Link to post
Share on other sites
Well mySQL is free so distribution isn''t a prob. (feel free to correct me if anyone knows otherwise) Which is why i based my example on this. By rolling your own do you mean writing to a file and reading from it? (text, binary, etc..) or could i use old ass FoxPro or something? Mostly just tired of re-writing my parser everytime i add a new function to my game that has to be saved. But i am also interested in doing it right. I know there are a hundred or so ways to do this but if i write a front-end GUI for a db, then i could have a really easy way to write an editor for maps and such. Performance isn''t that big of a deal, unless you are saying it would probably be slower than parsing text files, which is what i am doing now.

Share this post


Link to post
Share on other sites
Most of the time you write directly to binary files. Some engines, the Quake seires for example, use a pack file system that bunches all the individual files into one big file. This allows you to compress the entire thing and get better peerformace.

The engine doew all the work; opening the file, seeking to the right place in the file, reading the information into memory, then closing the file.

A file loading system is important for good performance.

Share this post


Link to post
Share on other sites
By roll your own database system, I meant you might want to write your own custom database system. Whatever file format you choose is up to you.

Honestly, I don''t see the need for a database for mesh objects and maps and stuff.

One approach is that your classes should know what data they need and be able to load it by themselves. Another is to have a ResourceManager class that all your data classes can "petition" to load the required data that it needs. The ResourceManager is a really handy concept, because it encapsulates all the file handling, loading data and allocating memory. It could even have more advanced functions like swapping out resources that haven''t been reused recently (priority queue) to make space for resources its trying to load. It could load some resources at the beginning of the level, and stream in other resources in the background on demand. Plus, because you have a centralizes ResourceManager class, its very easy to track memory leaks, and make sure all your resources get unloaded at the end of the level/game.

It sounds like what you''re asking for is a file system & resource manager, rather than a database. Maybe take a look at the 4th and 6th Code on the Cob series, this might give you some ideas:
http://gamedev.net/reference/articles/article825.asp
http://gamedev.net/reference/articles/article827.asp

Share this post


Link to post
Share on other sites
I raised a similar suggestion a while ago. I don''t know if it''s a good solution for your problem, but I find it interesting. It would include using MySQL, in such way that you include the server code (it''s open-source) into the game/program itself, and read it reads the data from MySQL table files. This would not mean that you need to install/run an MySQL server, you only include the part of the code that interpret the query, and extract the data from the table files. The main advantage is if you store much data in a complex way, as the MySQL code if very stable and debugged already. It could take you a year or so to reach that quality. Another good thing is that you can use existing tools to build the databases. You could probably save hundreds of hours and end up with a much better system. The downside is that it could be tricky to include this in a comercial game, unless you pay for a license (which I think is cheap).

Share this post


Link to post
Share on other sites
I'm quite sure it would be simpler and easier to write your own file system.

[edited by - smanches on August 30, 2002 6:22:05 PM]

Share this post


Link to post
Share on other sites
Maybe i have this all wrong, but my understanding of a data driven game means that the exe initializes, the first line of code initiates my devices, and my gui runs. The user says. i want to start a new game. etc.. now it's time to load level one.

I am currently iterating through a loop of variables that loads the data from text into virtual memory, mesh paths, texture paths,(mostly using .x which archives the texture path on it's own.) initialization of current enemy states, world position, camera position, et. al. What i am thinking is i could use a DB(not stuck on a particular one) to store it, and then create a ManagerResource Class that would really just be a Data Facilitator or Data Provider, or whatever you want to call it. So my front-end editor could just script the appropriate query for any level and BAM, now i can upgrade my functionality at will, and the only code change will be in my scripted query(or stored procedure, depending on where you went to school)

I'm not advocating it, as much as tossing the idea around. I can write a in-house file format, but it seems like it so far it is very non-modular. If i were to do a completely different type of game, i would have to re-write about half of it. Keep the comments coming though, i am open to any ideas.

@ Z01, thank you for your thoughtful response.

Dreddnafious Maelstrom

"If i saw farther, it was because I stood on the shoulders of giants."

Sir Isaac Newton

[edited by - Dreddnafious Maelstrom on August 30, 2002 7:32:48 PM]

Share this post


Link to post
Share on other sites
If all your storing is game parameters and other data that could change from level to level or even game to game, then XML is a great choice for that.

http://www.fh-frankfurt.de/~igor/projects/libxml/

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I use XML and I feel Great!

I lost thirty pounds and my sanity!

(don''t use Microsoft''s XML SDK until they can straighten out the documentation and add C++ examples)

Share this post


Link to post
Share on other sites
A full DBMS is total overkill for simple tasks such as games.
Come on, it's like killing a fly with a shotgun.

Also, no need for mySQL, MSDE (Microsoft Data Engine) is the exact same thing as SQLServer without the interfaces and limited to one user and 2Gb. And it's freely distributable. But still, I wouldn't use that for a game.

As jonnii and others said, why not XML?

EDIT : Typo

[edited by - Coincoin on August 31, 2002 1:44:06 AM]

Share this post


Link to post
Share on other sites
Frankly, take access :-)

Advantages: No installer - available o all Windows runtimes (not the access product, but a devent copy of the JET engine). If not, there is a pretty small merge module.

Advantage: it is pretty ok for small data (<500Mb) and little users (whoch you have).

Advantage: it is not a server. Whow - MSDE. Means that after this, in the standard config, the MSDE engine is automatically starting on every reboot. Thats not something you want just for a game - simmilar to MySQL.


Regards

Thomas Tomiczek
THONA Consulting Ltd.
(Microsoft MVP C#/.NET)

Share this post


Link to post
Share on other sites
I didn''t agree about using a DBMS for a game. I said that instead of using MySQL, you could go for MSDE

I must admit I was off topic tough

___________________________________
Oooh, you found the horadric cube!

Share this post


Link to post
Share on other sites
Most commercial games (like Q3A) use a few large package files (.pk3 in Q3A, .pak in HL, .mpq in Blizzard games, in Serious Sam, there are some, too). At least in HL and Q3, I think they are somehow derived from the ZIP standard. It has some advantages:
- You don''t have to code your own package / Database format.
- You can compress the whole thing
- The many small files don''t eat up a lot of cluster overhead
The files in that packages are normally treated as if they were in the same dir the package is in; while the package itself can contain subdirectories.

_________________________
"Reality is merely an illusion, albeit a very persistent one." (Albert Einstein)
My Homepage

Share this post


Link to post
Share on other sites