{"id":955,"date":"2023-05-07T23:28:00","date_gmt":"2023-05-07T21:28:00","guid":{"rendered":"https:\/\/www.bellingo.de\/blog\/?p=955"},"modified":"2023-05-12T17:43:57","modified_gmt":"2023-05-12T15:43:57","slug":"realm-database-for-unity-games-devblog-31","status":"publish","type":"post","link":"https:\/\/www.bellingo.de\/blog\/realm-database-for-unity-games-devblog-31\/","title":{"rendered":"Realm Database for Unity Games (DevBlog #31)"},"content":{"rendered":"\n

Network Traders<\/a>, the game I am currently working on, stores parts of the game data in a central, cloud-hosted database. But some of the user-specific data is private in nature and therefore only stored on the player’s mobile device. Until now, I have just serialized this data to persistent storage. But as I needed to add new user-specific properties, I wondered why I should not use a database on the client as well. After all, they may provide benefits such as atomicity<\/a> or migrations<\/a> when the database schema changes. After some searching I found Realm<\/a>, which integrated nicely into my Unity project, although with some intricacies I would have liked to know beforehand.<\/p>\n\n\n\n\n\n\n\n

Why use a Database?<\/h2>\n\n\n\n

Working on a game with a client app and a backend server, I have a direct comparison between using a database (server backend) and serialized data (client). The server is written in .NET C# and connected to a MariaDB<\/a> database. I use Entity Framework Core<\/a> to easily access my data with LINQ<\/a> statements, so no hassle with SQL queries. When I need to add or remove tables or columns or move them around, I can do so easily with Fluent Migrator<\/a> migrations.<\/p>\n\n\n\n

On the client side, I did what people usually do, I serialized my data into files using the BinaryFormatter<\/a>. That is fine as long as your data stays the same over a long time or you only add new classes to be serialized. But, like in the backend, once you start moving data around between versions of your game, you need to start storing version information and convert the data for every new client version. Worse still, you never know what client version the players have out there, so all conversion routines have to stay in your code indefinitely. In other words, you need to implement migrations yourself. That was when I seriously started thinking about using a database for the client app as well.<\/p>\n\n\n\n

\n