|
Post by spiceboy on Dec 31, 2021 1:01:37 GMT
I've been working on a save system for a few weeks now, and I've figured out a lot of the infrastructure necessary. The use of the Unity package "Easy Save 3" has made a lot of this work rather straightforward, and I've gotten to a spot where I can save "most" Unit data, as well as "Scenarios", a data type I've introduced which basically bundles together some cutscenes/conversations with a map, spawn positions, a player controlled party, and enemies.
One aspect I'm struggling with right now is how to handle notifications. I want to be able to save and load in the middle of a battle, which means keeping track of notifications regarding stats, status afflictions, etc.,
I initially thought of just persisting the entire table of notifications, but I believe this is not even possible. While Easy Save 3 has great support for Unity types and quite a few System types as well, it doesn't have support for some of the architecture used like System.Action. I thought of perhaps serializing the Notification Center by reference, but this would involve significantly changing the architecture designed so that it lives within the Scene itself, instead of as a static reference.
I also thought of simply initializing common notifications I know will be in use whenever a load happens, such as the listeners for Stats. However, that doesn't take into account context dependent cases such as status afflictions.
Anyone have any experience building persistence into this framework?
|
|
|
Post by Cerulean on Jan 1, 2022 9:31:01 GMT
One option is to make a loop on all characters, and put everything into a string. Save and load it into playerprefs, easy save,Json, etc then parse it back out.
|
|
|
Post by Admin on Jan 3, 2022 1:00:12 GMT
If you're using my notification center, I would say that generally speaking you shouldn't need to save it. Notifications are fired and handled synchronously, so as long as you manage the flow of your game correctly (game states etc) such that you could make sure saving and loading happened at a specified time, then you will know you are not in the middle of handling some sort of event by notifications. In the event that you are tearing down and potentially rebuilding game object hierarchies, you can allow them to auto-register for notification handling at special times, such as on Start or as part of the load process itself.
In the event you still need to persist notification handling relationships for some reason I am not thinking of, then you might be better off using some variation on Unity's events, which are serializable already.
|
|
|
Post by spiceboy on Jan 4, 2022 1:44:46 GMT
If you're using my notification center, I would say that generally speaking you shouldn't need to save it. Notifications are fired and handled synchronously, so as long as you manage the flow of your game correctly (game states etc) such that you could make sure saving and loading happened at a specified time, then you will know you are not in the middle of handling some sort of event by notifications. In the event that you are tearing down and potentially rebuilding game object hierarchies, you can allow them to auto-register for notification handling at special times, such as on Start or as part of the load process itself. This ended up being the key realization - you are correct that there's no reason to save in the middle of any sort of event handling, and any subscription to events can be handled via discrete events. In my case, I was misunderstanding how Stat notifications work, particularly in conjunction with the leveling system - I was correctly serializing class information, but part of "Assigning" the class to a unit is the observer on leveling up that informs stats when to increase. If anyone comes across this in the future, I can highly recommend Easy Save 3, even in fairly sophisticated architectures like this. It has very minimal setup and seems to be very performant as well.
|
|