What type of database should I consider for creating a game which will be written primarily in C#? In my regular life, I'm a application architect that designs multi-tier business apps for supporting multiple users performing concurrent transactions. The architecture for this type of application is massive overkill for what I want to do, but that's my starting point. What I am looking for is a database that has a small footprint; but one in which I can continue to encapsulate in a data tier. Would a SQL database be overkill with enormous overhead? Is there a better choice? What about parts of the game that are I/O intensive, as compared to game load/save operations where a game is loaded into memory or vice versa. Thanks a bunch. - El

Don't ever use a database in a client-side game. It just adds to the frustration of debugging if things start going wrong. And if you ever work with other programmers who might not know SQL, then you're just adding obscurity where there doesn't need to be any.

(I say this from experience. Some wise-ass developer many years ago convinced the team to put an entire T-SQL database engine IN THEIR PS2 GAME. The effects: We were contracted to make a sequel, and 90% of our game development team didn't know how to write SQL queries. MUCH wasted time figuring stuff out. I was one of the few people who actually knew SQL pretty decently, so I had to waste time I could have been working on tasks helping set up the database, optimizing queries, etc. Debugging is effectively impossible and memory usage gets blown COMPLETELY out of proportion to what the databases are actually storing. Load times are unnecessarily longer.)

Probably the worst thing about using a database in a game is you have to create slow queries to join related data. Proper data structure design eliminates overhead and is more what programmers would expect to see in a game.

Many commercial PC style games are commonly using XML as well..

One thing a lot of games do, is they load in the game information based on the current level into RAM, a lot faster to access stuff in RAM then it is off disk, they only stream in things that are very large such as sound files etc. Consider you are accessing off a disc on console machines.

Quote:Original post by T1Oracle

Quote:Original post by deepdene
games are commonly using XML

I sure hope not [headshake]

Try the age of empire games, many strategy games etc.

Simple XML shouldn't be that much slower than text if you using some lightweight api like tinyxml etc. And in any case it's usually during the loading stage.

I know the PS2/XBox/PC game we were working on used XML for the gui layout etc.

I have many apps that generate XML and although it's easy to generate and work with, I'd never consider it as a database because it is a slug.

I'll investigate SQLLite; as it has a ADO library. I use a framework generator to encapsulate the SQL, so developers don't actually need to know anything about SQL to load/save objects.

Thanks.

As someone who works with databases for a living, I'd also recommend SQLite, it's by far the best client driven database out there in regards to speed, functionality, size (code) and licence. The only shortcoming is if you want client driven, but multiuser or multithread. In those strange situations (no server but need multiple clients accessing at once) JET (Access) actually becomes a possiblity, despite it's serious speed limitations and sometimes odd SQL syntax (not nearly as bad as MySQL, but it still deviates from SQL-92 frequently enough to not be considered standard)

I look at a database as primarily a way to store data. I know a lot of developers who use the internal procedural languages to store and execute logic, but that to me breaks so many good software development rules. I've seen software projects budgets ballon out of control when then want to change the data structure, because they coupled things together.

Fundamentally I'm after a small footprint, and if it becomes a requirement to move up to something more complicated such as Access, then all I have to do is replace the data tier.

All of my "logic" sits in the domain and I use an MVP pattern to get it to the UI. I'm hoping that this kind of design philosophy is equally applicable to game design and implementation.