# Should I use a database for storing game content? [closed]

I have a 2D Game written in C++ using SFML. I want to make the game expandable in such a way that content like items or entities could easily be added by adding a line/entry/row to a file or database.

I am looking for something that does not need to be compiled into the program, but instead can be read from and written to at runtime. When would it be appropriate to use a database?

• Please clarify your needs more. Databases are quite fast, but very complex. Do you really need the speed? Why not just use a text file? Have you run a benchmark? – Anko Dec 14 '15 at 12:33
• How many items are you going to have? Is it more than a million? That's about the threshold where I would consider using a database over text files. – Philipp Dec 14 '15 at 12:34
• I would say a database is overkill for this, just use some kind of definition list. Perhaps just plain text. Consider XML or JSON. – Hugo Zink Dec 14 '15 at 12:45
• I recommend XML or JSON as well. I prefer XML because it's more readable to me, as a human, but JSON is a good choice as well. – Draco18s Dec 14 '15 at 15:42
• I won't claim to have much knowledge of datasystems, or how they're implemented in games, but I will say that Microsoft tends to use micro-database implementations for many of their simple apps (ones that don't have a lot of data, or outside-database needs, but tend to have "relationships" etc). Just as long as you keep ease of use in mind it may make sense. (Bad idea: Using a super-formalized XML namespace mandating data correctness) – Katana314 Dec 14 '15 at 21:43

Only use a database if you need a database. That is:

• If you need to perform complex queries often.
• If you have complex data relationships.
• If your data is huge and is not likely to fit in memory.

If your game's data satisfies any of these conditions, you might benefit from using a database. Note that these are not very common, and you probably don't satisfy any of them. If you do, I would go with SQLite or something with a similar idea of not requiring a running server and being just a library.

Otherwise, use files and load data in memory on startup. If you want the game to be moddable, load this data from both your game's directory and from mods' directories and define how conflicting information might be merged.

Also note that, if you do use a database, it might benefit both you and mods' developers to still use files to read initial data and construct the database only when the game loads. Unless the potential size of this database is huge (i.e., more than a few dozen MiB), you might want to use an in-memory database, which is possible in SQLite by specifying :memory: as the database path.

• I'd highly second considering SQLite, even if your needs are NOT "complex" or "huge". There are actually a lot of reasons why with something small and embedded like that, you can highly benefit from having a database at your fingertips. – wjl Dec 14 '15 at 17:23
• Also, mobile plataforms use databases to store some informations. Android uses SQLite. This means that most of your work for mobile plataforms is already done (in terms of data handling). Also, it is really easy to setup SQLite and to edit SQLite data (with programs like SQLite Studio or similar). If it is to use SQLite, the best bet would be to use V3. But other than that, spot on! – Ismael Miguel Dec 14 '15 at 18:10
• @wjl: Agreed, the benefits of normalization and referential integrity constraints are well worth it even for smaller game data sets. (Now if only it wasn't such a pain to get SQLite to do proper referential integrity constraints...) – Mason Wheeler Dec 14 '15 at 19:59
• This is an argument against using a relational database. A simple indexed key-value store may still be worthwhile. – Mark Dec 14 '15 at 21:14
• @Mark If you're going to use a key-value store in a game you might as well just have a hashmap or similar in memory. – Darkhogg Dec 14 '15 at 21:22

I really like MongoDB for game develpoment, it has a really good performance and it's really flexible, easy to use and json-based.

You can just add any field you need in any collection due it's NoSQL Arch, so it fits really well in any "dynamic" enviroment like games.

Give it a peek.

If you are developing some kind of MMO Turn based strategy game, probably you should read about CouchDB, it's an NoSQL Database that has a really good versioning system.

• Not a good answer. The question wasn't "which database should I use" but rather "should I use a database at all". – uliwitness Jan 19 '16 at 10:42

CastleDB is a good option because it is simply an editor that converts a database to a JSON file afterwards. I have seen lots of answers saying a plaintext file is best, so CastleDB is probably the best of both worlds.

• Not a bad answer, but misses the question. The question wasn't "which database should I use" but rather "should I use a database at all". – uliwitness Jan 19 '16 at 10:43