I am trying to understand the most optimal way of storing customisation options within a game, or to be precise, to store all the possible customisation options for multiple different objects.

For example, assuming we are making a game about tanks and their customisation, there will be several available tanks that the player can choose from and each of the tanks will have multiple different parts available; some parts will be shared across a few tanks, while some will be specific to a tank.

I was thinking about a relational database, but I do not know web development, so I was initially thinking to have a table with all the tanks and a table with all the parts, then create a linking table between the two and load the available parts based on the chosen tank; but I'm not sure if that would work, or if it would be the most optimal way of doing this.

I tried looking for an answer, but I'm not getting any good results. People mention using files, and then parsing the data, but I'm not sure how that will work on a large scale; multiple tanks with hundreds of customisation options.

What is the most optimal way to to do this? If at all relevant, I am using Unity 5.

  • \$\begingroup\$ Welcome to Game Dev! I have performed a light edit to your question. We do not tend to favour "what is the best x" questions, as "the best" is often a matter of opinion. Instead, we prefer deliberate requirements; in this case, you mention wishing to find the optimal solution. That seems to work, I guess. \$\endgroup\$
    – Gnemlock
    Apr 28, 2017 at 11:17

1 Answer 1


With the notable exception of massive-multiplayer games (persistent world shared by thousands of players), relational databases are very rarely used in game development. In a single-player game, there is little reason to use one. You have only one user, so you don't have to worry about consistency or transactions. And the data is already on the user's hardware, so you don't need to worry about loading times, bandwidth usage or security implications of loading data into the frontend which the user doesn't need at the moment.

Fixed data (like the stats of different items) and player preferences (keybinds, mouse sensitivity, music volume etc.) is usually read from config files on game start and kept in memory while the game is running. Very few games have so much data that the target platform couldn't handle that. Regarding the structure of these files: I have seen people use JSON, XML, YAML, INI, CSV or some homebrewed markup formats. I would always recommend to use something you have a library for, because writing good parsers is far more work than you would think at first (and also it's boring). Savegames are also loaded in one go and deserialized to the game state when the savegame is loaded.

Unity gives you another option by allowing you to create types of custom data-based assets in form of ScriptableObject's. That means you can have a folder "Tanks" and a folder "Tank Parts" in your Unity project, create and delete entries in them and edit their properties right in the Unity editor which you can enhance through editor scripting. There is also a video tutorial.

The only place where a relational database could make sense is when you have a dataset which is so huge that it doesn't fit into memory. The only candidate for this is usually the geometry of the game world. But most games rather create a custom file structure for this instead of using a relational database, because most RDBMS are not designed for spatial data.

  • \$\begingroup\$ Thanks for providing the answer, it makes more sense now. I will check out the video and see what i can come up with regarding that, otherwise i like the sound of the XML or JSON. \$\endgroup\$
    – kamilios
    Apr 28, 2017 at 12:11
  • \$\begingroup\$ Do you have any information about practical usage of NoSQL databases in game development? They sound exactly what we need, key->value databases with loose structure. I am actually surprised there is not much information on their usage in this field. \$\endgroup\$
    – wondra
    Apr 28, 2017 at 18:52
  • 1
    \$\begingroup\$ @wondra One time I used MongoDB for a game, but that was an MMO. For single player games, the same arguments apply as they do for relational databases: They don't give you anything you couldn't do better by simply parsing the files at game start and putting the data into appropriate data structures. If you want a key-value in-memory database with loose structure, put the data into a Dictionary. \$\endgroup\$
    – Philipp
    Apr 28, 2017 at 19:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .