4Game

Disclaimer: this post gets technical. I do not claim to know how the current implementation works, I was just thinking about how I would implement it.

​

With any game with building elements like this, the saving process can become a challenge to optimize. Players are virtually unlimited in the modifications they can make, and all of that has to be recorded. I'm a big proponent of changing the terrain manipulation to a data centered design instead of an object oriented one (and I love OOP). The challenge with that would be that you then have to save out the bitmaps containing all player made changes. It is sort of a trade off; an increase in initial memory requirements and save operations in exchange for scalability of player manipulations.

​

So how do we reduce those upfront costs? This got me thinking about how the game saves. It would appear that the whole world is saved down into one file, a process which takes longer the more manipulations takes place. What if the was saved in chunks? Any chunk that had active simulation (that is a player was close enough for things to happen) would be flagged dirty until the next save event. That way only the dirty chunks would have to save. So your network of bases wouldn't need to update its saved state while you are out exploring for an hour, because the game knows you haven't touched them.

​

Additionally, this opens up the possibility for threading. If the process is already divided by chunk, those can be executed on separate threads (you only want one thread doing the writing, but the rest can format the data and queue up the commands). The chunks that are being simulated still need to be saved from the main thread so that data errors do not occur, but for inactive areas that have been visited since the last save this may produce speed-ups. While I presented the idea as a solution to the volume of data that would be used for bitmap terrain manipulation, it would be just as applicable to the current implementation.

Anyway, this has just been a rough idea. If anyone with more experience with this sort of thing could chime in, I would be interested in the input. I do a lot of Unity dev, but not really big open world stuff with a lot of state to save. So I find this problem interesting and refreshing.