Open world game state saving Android

Question

As a hobby project I'm building a 2D game with a custom game engine in Android. Currently I can render a json map, and let the user interact with objects on the map. The game should be an open world map, with multiple maps. One of my current maps has a 150 x 150 tile pattern, with on every tile one or more objects. Thus, the map has 22.500, multiple layers, and more attributes. The player can edit objects (like fish in water object, plant seeds in soil, etc.), so every object needs to be stored separately. Some objects, like growing plants, need to be updated over time, even when the player is not playing the game.

My question is about efficiently saving and loading the game state. I think I need to store all the attributes of the maps, together with the objects, player progress, npc progress, and so on. Since this is a lot of data for a mobile device, I can't think of a good way to store this on the phone (or in the cloud).

I've tried the following: - Store the entire game state in a serialized file. The parsing of this file took way to long while loading, and when one object's state changed, the whole game had to be loaded. - Store every object in a sqlite database, with for every attribute a column. This was even slower than the first option, so not an option either. - Store every object serialized as a blob in the database. This option wasn't much faster than the previous one.

I've been looking at ObjectBox, but in order to create the entity values for this database, I need to change a lot of reference values to ToOne<> or ToMany<> objects, which will take a lot of time and since I am using the map attributes to render the maps, the wrapping and unwrapping of the objects would cause (unnecessary) delay. (This is an assumption)

How do I save the game state without causing a 20-minute loading delay?

Answer 1

A common solution is to divide your game world into rectangular chunks which have about the size of one screen and only load those chunks which are currently needed.

Store each chunk in one serialized file or in one database entry.

When the player enters the game, only load the chunks which are in or around their viewport.

When the player moves to a different chunk, load the chunks around them and save and unload the chunks they moved away from. This is not just important for loading times but also for conserving memory and CPU cycles for updates.

When you want things to happen to chunks even when the player isn't present (like plant growth, for example), process these for the chunk when that chunk is loaded. When the player returns to their farm, check how long ago you unloaded that chunk, and then process the plant growth accordingly.

But you might also want to take a close look at how exactly your serialization format looks on the byte level. 150x150 tiles really isn't that large. I've worked on games which could easily handle much larger maps without having to use chunks. Think carefully about how much data your really need to save. You haven't wrote much about how your data structures look, so it's hard to give any concrete advise. But usually a tile is just an integer representing the type. When you need to store more information per tile, look at how to store that information in the least bytes possible.

I'm looking forward to playing your game.