Database driven games
Author
What are peoples thoughts on database driven games? Most games have a fair amount of design time data and real time data that they have to manage, store, and maintain. Generally this is done with xml files, and in memory objects, but I'm curious about the use of databases to handle the game data.
What pros and cons do people see occuring when querying a SQL database for game data rather then directly accessing objects?
You use a database when you have large amounts of information that is not effiecent to access using "flat" files. If you have do much data in your game that you are getting a performance hit by directly access files then use a database, but if your performance is good then using a database solves nothing.
theTroll
theTroll
Quote:Original post by TechnoGoth
What pros and cons do people see occuring when querying a SQL database for game data rather then directly accessing objects?
pros you'd use your knowledge from non game company.
cons
SQL is S*L*O*W
SQL is badly designed. (It's optimalized to provide abstract way for any database like queries. There isn't too much database like queries in games.)
DMA runs circles around SQL.
SQL drivers problems.
Hash tables are beter than RDB, and you gain cache coherency by throwing avay an intermediate step.
Dipper (also called flywheel pattern) is much more confy way how to access data. So is virtual file system, and a proper library with a memory efficient arith/range coder on background.
Sometimes the right way how to change your code is a simple exchanging one 40000 Bytes .obj / .class and relink / repack, instead of being forced to change 20 MB of data.
Of course nothing wrong with PHP combined with SQL. However the more complex games are often better without it.
you could use SQL just fine for loading and storeing save data, as long as you arnt running a quere every frame it shouldnt be too much trouble, the problem is it adds a ton of complexity to your game and a binary saving of a struct would work just as well, so basicly inseted of weighing just dont use SQL unless you have a good reason to
Really, one of two things justifies a RDBMS on a small scale. Those are either adhoc query capabilities being critical or the structure of the data complex. You don't really have either from the users perspective in a single player game. The adhoc capabilities can be rather useful during development though. Similarly the data might be complex enough to justify it during development. Long term the short life span of a game doesn't justify it in terms of complexity. What data you need and exactly how it is accessed is known at release and it simply isn't going to change much.
When you get into a large scale, multi-user system such as a MMPORPG then concurrent access and maintenance become a major issue. Therein lies the true complexity of a RDBMS. You might well kill your game off by a slight oversight in concurrency management resulting in dupping on a massive scale. There's definitely going to be oversights and there will be those exploiting those oversights. Tracking down who and figuring out how to correct it causes how you need to access your data to evolve. That makes the ease with which you can change a database driven application important.
When you get into a large scale, multi-user system such as a MMPORPG then concurrent access and maintenance become a major issue. Therein lies the true complexity of a RDBMS. You might well kill your game off by a slight oversight in concurrency management resulting in dupping on a massive scale. There's definitely going to be oversights and there will be those exploiting those oversights. Tracking down who and figuring out how to correct it causes how you need to access your data to evolve. That makes the ease with which you can change a database driven application important.
Author
hmm, valid opinionns.
However wouldn't a database be a far more efficent way to access seldom used data and persist out of scope world data? None of this data should be stored in memory and I would think it would far more costly to read and write it from files then to run a few database queries.
However wouldn't a database be a far more efficent way to access seldom used data and persist out of scope world data? None of this data should be stored in memory and I would think it would far more costly to read and write it from files then to run a few database queries.
I often model my data into a standard relational model, mock it up with a SQL server and use this model to prototype and test the game design, then create custom in memory classes for use in the actual game.
The benifit of this is that when you analyze your program from different points of view, different possibilities, problems and optimizations occur to you. In SQL model I always find cases of redundant data very easily, and after normalizing and tweaking the database a few iterations, and expanding the model with hypothetical data for features I might get to, or might not, I can often see a really obvious class heirarchy that supports the features I need now efficiently, but can grow a few steps in the future - time permitting.
The benifit of this is that when you analyze your program from different points of view, different possibilities, problems and optimizations occur to you. In SQL model I always find cases of redundant data very easily, and after normalizing and tweaking the database a few iterations, and expanding the model with hypothetical data for features I might get to, or might not, I can often see a really obvious class heirarchy that supports the features I need now efficiently, but can grow a few steps in the future - time permitting.
XML is pretty good as long as the files does not get too large. Even for rarely used data, you can load on the fly. The nice part about using XML is it is easy to use and you don't need a database server to run it.
theTroll
theTroll
Author
True you could use XML, but depending on whether or not you are using sax or dom you have the issue of slow seek times or loading a large object into memory only to destroy it a short time later. It also adds further complications when spreading data over multiple files.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement