Should I use an SQL database to store data in a desktop game? [closed]

Question

Developing a Game Engine

I am planning a computer game and its engine. There will be a 3 dimensional world with first person view and it will be single player for now. The programming language is C++ and it uses OpenGL.

Data Centered Design Decision

My design decision is to use a data centered architecture where there is a global event manager and a global data manager. There are many components like physics, input, sound, renderer, ai, ... Each component can trigger and listen to events. Moreover, each component can read, edit, create and remove data.

The question is about the data manager.

Whether to Use a Relational Database

Should I use a SQL Database, e.g. SQLite or MySQL, to store the game data? This contains virtually all game content like items, characters, inventories, ... Except of meshes and textures which are even more performance related, so I will keep them in memory.

Is a SQL database fast enough to use it for realtime reading and writing game informations, like the position of a moving character? I also need to care about cross-platform compatibility. Aside from keeping everything in memory, what alternatives do I have?

Advantages Would Be

The advantages of using a relational database like MySQL would be the data orientated structure which allows fast computation. I would not need objects for representing entities. I could easily query data of objects near the player needed for rendering. And I don't have to take care about data of objects far away. Moreover there would be no need for savegames since the hole game state is saved in the database. Last but not least, expanding the game to an online game would be relative easy because there already is a place where the hole game state is stored.

Answer 1

An SQL database is not nearly fast enough to use for realtime reading and writing game information. Such data is almost always kept in memory, in traditional data structures.

There may be some benefit to using an embedded database such as SQLite for certain types of data, eg. static data that doesn't change during gameplay but does change during development. This could then be deployed as part of the final game where SQLite is only really used when loading up the game for the first time, or when starting a new level, etc.

However there are many downsides too - it is hard to patch individual parts of the data when they're stored in a single database file, it is not ideal for many types of complex data that games need (and which you said you'd store outside - but will have references to and from things inside), it is not very flexible when you need to change the schema, it is not necessarily backwards compatible after you change the schema, etc.

For these reasons, most game developers will just use their own format. Professional developers who are performance conscious sometimes go one step further and save the in-memory data structure directly to disk so that it can be loaded in with a minimum of processing.

And if you really need text-based tabular data that is easily edited, you could use a simple text based format, such as CSV, XML, JSON, YAML, etc.

Answer 2

A database isn't fast, using a database is a whole lot slower than traditional memory access. The reason is simple, a database is dynamic, there is a bunch of overhead attached to it, the queries need to be parsed, hashes need to be computed and other stuff.

There are is only one advantage from using a database and that's persistence. You can run one or multiple applications with one database over a long period of time without having to fear data lass. But game clients have absolutely no need for that.

So, you want to get every object which is less than 1000px away?
That would be:

List<Entity> retVal;
for(entity in entities)
  if(Distance(entity.pos(), to) < 1000)
     retVal.append(entity);
return retVal;

Now what would you think would a database do if you asked it to get every object less than 1000px away?
It would do exactly the same! Just with a bunch of overhead which would make this one extremely simple operation cost about 100 times the processor time (depending on how many entities you have). Databases ain't no magic.

Don't use databases for anything else but server applications.