Saving large amounts of data? Serialize objects or use SQLite?

Hi @lxknvlk !

Honestly, I don't start or manage a DB for these kind of stuff. I mean if you have millions of records maybe it worth it otherwise you just create a new problem and complexity for yourself (but this is just a personal opinion).

Regarding to the serialization, do you need all of that fields what you mentioned?

For example, you have an RPG game with many characters in the world. What you need here is not much info (of course it depends your needs). Just an example, you want to save the current state of the game and you need to think through what you really need, for example saving the characters position is a good one, because they are changing all the time and you want to load them back.

But saving all of the available spells of an enemy mage character, like 20-30-40 spells are unnecessary, because it is probably not a changing thing, it is a fix set of spells for a specific character type. You should store these info in a ScriptableObject or inside the Mage class or EnemyManager or somewhere else and when the game startsup and you load the level, it should load these values from there instead of a save game.

Another example, your character's inventory. You should save what is inside the backpack of your character?

Absolutely!

But how you save them? My first try is to save only the ids of the items inside the inventory, instead of storing every bit of details of every bit of items, which are not changeable and fix things.

Of course, if you create a Borderlands type of game and every weapon is generated an id will not be enough, but you can create something like the hashing mechanism and you can add the weapons parameters to this solution which will create a unique id, hash or something for that weapon. This solution also capable of get an id / hash and it will decrypt it and run-time you will get all of the details according the id.

For example, you have a weapon with 5-10 fire damage and 120% reload speed. 5-10 fire damage and 120% reload speed will be hashed into AZrg67532jkfhdj and you need to store this only for the weapon in the save game. And when you load the game and pass this AZrg67532jkfhdj into this mechanism it will decipher it to 5-10 fire damage and 120% reload speed.

So you should find out your own solution to decrease the size of the saved details.

If I misunderstood your question and you want a solution to save the whole map as is with the buildings and items and trees and everything I think the serialization still can be good, think about that Unity do the same and save the Scene with everything in it into a simple scene file.

But if you have a large amount game objects, probably you will found out yourself that this will need some kind of batching or some optimization solution where the player can see only a part of that huge map. And if you need some kind of solution, probably you can save the whole map into chunks instead of a single and huge save file.

But again it is not a save game, because it is the map itself. But if the map or buildings or trees and these kind of things are important in your gameplay and you need to load them back as you left you can also think through what you really need. I mean if you placed a building at X:10,Y:20 in an RTS game, probably you should not store the whole building with every little bit of details, instead just store the id of that building with the position and with the actual health (and everything what you need and what can change).

For example, the mesh of the building should not be stored inside the save game, it should be loaded back run-time based on an id or some logic from the memory or from the disk (although the latter is expensive compared to the memory one).

I hope, I could provide you some help or clue about how you can think about this problem.

P.s. I just checked a .unity file and it was stored /serialized into a YAML format and not JSON. You can also check it by create a simple Scene with a few cube in it and open up the scene.unity file in a notepad or somewhere else and you can see how Unity store all of those data.