Additive scene loading and data persistence

I'm working on a Stardew Valley / Harvest Moon Esq project and I need to persist my game objects. I'm using additive scene loading to isolate areas within the game. Since this is my first time working on a serialization task, is there a preferred pattern I should adopt?

I was thinking of an event system where the tiles would send an event letting some manager know they've been changed, keep a list of these changes and write them out to a file when transitioning scenes?

I'm confident in my ability to implement, just looking for theory and software architecture advice.

Cheers,

Diaonic

 

You can also keep objects throughout all scenes by making them DontDestroyOnLoad(). You can use a static class with static variables to save values as global variables. These will not change between scenes. You can use PlayerPrefs to save data and load the required data in the next scene again (normally intended to load data between sessions).

How large will map segments be? If they arent exactly small i would refrain from having tiles be actual objects with scripts attached and so on. This works for small maps, but bigger ones will become problematic performance-wise. I played some Stardew. If i were to implement something similar, the map information would be layouted in a jagged array, where each index holds some id, refering to the object to be drawn and interacted with. If each value is a byte, a 300x300 map could be saved using only 90kB (Edit: fixed my sleepy math haha), which would also be fast to write and read. For the same reason tho, i dont think you ever need to unload it other than when the application is quit.
Why do you need to keep a list of changes? As i said i'm not too familiar with this type of game, but the only thing that should matter is what type of tile it currently is, plus maybe a state for plant growth or something?

Hope this helps and i didnt miss your point.

 

Additive scene loading is a HUGE win in Unity. It's absolutely the best way to work, especially with a team: each person can work without tripping over each other.

For instance I regularly have a UI scene, a player scene, and then as many content scenes as I need. Often content scenes all share an audio scene, and every popup and menu and overlay is a separate scene.

As far as persistence, you should manage your own persistence, such as with static game managers as @Yoreki suggested above. You don't generally want to keep a lot of actual state in the scene, beyond what you must.

I also use my Datasacks package for easy lightweight connections between multiple scenes, limiting how much drag-and-drop is necessary.

Datasacks is presently hosted at these locations:

https://bitbucket.org/kurtdekker/datasacks

https://github.com/kurtdekker/datasacks

https://gitlab.com/kurtdekker/datasacks

https://sourceforge.net/projects/datasacks/

 

I wouldn't write your scene's state to a file unless you were trying to implement a save/load system (basically persistence between game sessions instead of persistence between scenes). Same with PlayerPrefs.

Static variables and DontDestroyOnLoad objects are often good enough for persistence between scenes, though if your additive scenes are not memory intensive you could just disable all the GameObjects in the scene when you don't want them running, and reactivate them when you would return to that scene.