Open CG-Tespy opened 3 years ago
danac78
commented
3 years ago As far as Async, I think Fungus is already heading that direction because I think the minimum Unity is 2018 (which is the minimum for addressable, which uses Async). There has been plenty of mentions of redoing the code to move up to 2018 to take advantage of features. ;)
CG-Tespy
commented
3 years ago @danac78 That'd be great!
CG-Tespy
commented
3 years ago Added suggestion for the game object positions
CG-Tespy
commented
3 years ago Added suggestion for the way loading is handled
breadnone
commented
3 years ago As an ex long time user of Renp'y, I really enjoyed the rollback feature of their save system
I just put this as reference https://www.renpy.org/doc/html/save_load_rollback.html
Apparently, this was mentioned long time ago in Fungus' forum as well
https://muut.com/fungus#!/general:rollback-using-the-new-save
I thought it'd be good to compile and maintain a list of features I think would be good for the new official save system to have. Of course, I intend to help implement at least some of these in the future, like I have with the Save Slot Views.
Event Handlers for When Saving Begins and Ends
This would allow Fungus blocks to respond to those particular times. For example, the mainline pokemon games have a cute sound effect when they finish saving data. Other games also show a progress bar when saving begins, or at least give the player some notification along the lines of "The game's being saved, please wait a bit."
As things are now, the saving just happens instantaneously and synchronously.
Make Saving/Loading Asynchronous
This would require making the minimum required Unity version be one that supports the async keyword. This would be great for little notices letting the player know the game is saving, and can even increase performance as things are split more across multiple frames.
Unsingletonify the Save Slot Manager
This would make the system less restrictive in the types of UIs that it would support. As it is now, you can't have separate Save and Load menus without a hacky solution.
Let the User Define their Own Categories of Save Files
Not all game devs want only regular saves and autosaves for their games. They may want to have more for specific gameplay segments. Fire Emblem Three Houses, for example, has 3 types: normal, auto, and battle.
This could perhaps be implemented with Scriptable Objects, which you'd pass to the Save Slot Manager(s) so they know which slots to display. I imagine we'd also need to add a Category field to GameSaveData, and significantly refactor how the Save Manager manages the saves.
Give the User Control Over Where the Save Data Is Stored on Disk
Some might want it to be in the game's folder, others might want it somewhere in AppData. It would also be good to let the users decide this on a per-platform basis without having to alter the source code.
One way to implement this would be to add fields to the SaveManager that the user can play with to do just that, with one of said manager's jobs being to put the save data in its proper place. Of course, to minimize any violation of the SRP, it'd be best to have this be handled by a submodule of the SaveManager... in this particular solution, anyway. There may be better ways of going about this...
Have a System File Containing Info for Save Slot Views
One of the concerns for the new system is having too many huge JSONs in memory, hence why GameSaveDatas aren't all loaded right away anymore. Yet, you'd think those huge JSONs would be where the Save Slot Views' info would be stored...
One solution would be to have a separate file in the save folder that contains all the info that the Save Slot Views would need. For this example, let's call it _SlotViews.dat. Having it loaded right away shouldn't take up too much memory, since for most games, they shouldn't even go above 100 kilobytes per save... especially if we write _SlotViews as a binary file.
Let GameObject Positions Be Saved
This is a pretty important feature for games like RPGs and Metroidvanias. It'd be good to let the user set which objects get the positions saved and then loaded.
Have Specialized Classes Handle the Loading
I did some digging around in the source, and noticed a big problem... you know the Decode methods of the classes implementing ISaveDataItemSerializer? They have a side effect that has them violate the SRP: loading the data they decode. It'd be a lot better if, like the save system in my repo, it had classes specifically for loading various types of save data.
Having those functions return the decoded data would also make it easier to unit test the functionality.
Have The Default UI Be Very Renpy-Esque
Meaning the slot holder would be a grid with each slot having a screenshot, a number, the game's title, an optional subtitle, and a date.
Make the System Flowchart-Friendly
Meaning it'd be easy to have the system handled mainly through Flowcharts, without too many direct function calls. It'd certainly help make save categories and UI-action-customization easier to implement in a flexible way, while also being very appropriate for this asset package. Flowcharts are its bread and butter, after all.