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]

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/

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]

OK, i''ll check it out. Your also right about MSDE, i should have thought of that.

Dreddnafious Maelstrom

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

Sir Isaac Newton

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)

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!

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