Early on in development, I moved from what was originally Unity’s PlayerPrefs storage to create a framework around a SQLLite database. Integrating the correct DLLs for both Windows and Mac versions of my game, I added an extensible set of classes for records, tables and storage controllers. I have included a caching system that works well to keep performance at an acceptable level.
There are a few drawbacks to my storage layer: the data records use inheritance for providing certain behaviours; the data is not serialised out of the box so needs to be tuned to play well with Unity’s multiplayer; it is SQL so structured upfront and will need to be careful when being extended (unlike NoSQL DBs like MongoDB).
Also since its inception, Unity has done a lot of work on its ScriptableAssets persistence. But something about ScriptableAssets coupling so tightly between editor, UI and game engine seems like poor design to me, effectively locking you into Unity’s ecosystem.
My database framework has been with me for a long time now, and it has served me well. It structures a lot of my thought in the backend, and helps me reflect more on separating out business, presentation and storage logic in an environment that seems to lean towards mixing all three.
Leave a Reply