- Do you have any expertise in SQL?
Creating a post about setting up SQLite in Unity is a worthy goal for any self-respecting blogger. Still, for some reason, this post is about data storage methods that are popular in the community and offered by third-party products and assumed that technology descriptions make you think about the architecture of the project. Also, instructions for setting up any circuit described further easily found on the Internet.
Why any game must have data storage must be oblivious, so let’s describe this very fast.
A game is an action to change the source data for some purpose.
The community postulates quite often - the way to create source data in Unity is to prepare sets of Prefabs, ScriptableObjects, Scenes, and tools for managing them in the editor. Other config types are not needed.
Changes in Prefabs, ScriptedObjects, and Scenes cannot be saved, so after reloading of the scene, everything will return to its original state, respectively, any states that need saving require some data storage. Example: if you can put blender from the table into inventory, you must save the absence of it on the table and its presence in the inventory.
The only ready-to-use way to store data in Unity is PlayerPrefs; this is a prevalent solution in the community’s answers about storing something.
As a result, the name speaks for itself; it is a tool for storing settings and other not very large and unimportant information.
All other methods will require serialization, lets overview most popular of them:
The obvious way, it’s easy to implement, problems start with a large number of files, both manageability and performance are falling.
The only candidate will be:
There are other options in the Asset Store, which include the acronym SQL in the name, but they look very much like wrappers over the same SQLite. There are ORM solutions to make life easier, for example, sqlite-net. So if there is a need for a relational database, then it makes no sense to look for something else.
A popular topic of the last decade, and thanks to that, there is more than one option:
At the moment, the choice of NoSql solutions has become the standard, and one can hardly come up with an excuse not to use them. It is clear that SQLite looks the most popular solution here, and the rest do not have a hundredth of its popularity.
Recently there are many mentions of Realm.io and similar solutions that allow you to configure the synchronization of local and external databases, removing most of the work from developers. Unfortunately, Realm.io, although it claims to support .Net Standard 2.0, doesn’t want to start under the Unity of the latest versions, so it remains to expect when their new owner, MongoDb, will turn his attention to the gaming industry.
Alternatives worth paying attention to:
Of course, these are solutions for enterprise-level tasks and for those who make the next Hearthstone and understand why it is needed.
On the one hand, this article was not supposed to give a silver bullet to kill all the projects. On the other hand, the choice of options offered by the community is not so wide, and everything resolved in the old fashion way with binary/json + file/sqlite solutions. It seems like a community is so easy on this topic due to other performance issues. But, if you want to have some adventure, there are LiteDb and FlatBuffers awaits. I will try them, but this will be a completely different post. See you next time! =)
Update: also you can look at our new article LiteDB and Unity