Pixel Crushers Forum

Hi Tony,

I'm working on a turn based RPG which is structurally similar to the old Fallout games. I've read the documentation on saving and started working on it, and was hoping you could help me out with some basic info.

1) In previous games, have used easy save by Moodkie and have a fair amount of legacy code which can be modified for use. Would it be sensible to use easy save to save character and inventory data, and use your system to store the information for player actions, quests, etc?

2) The area I'm most uncertain about is configuring scenes based on the player's actions, or when they are revisited. In the case of a particular character getting killed or a container being looted, I was planning on storing the data in the variable section of dialogue database, then retrieving the data and having a configuration script for each scene, which will enable or disable the character/add the loot to the chest as required. Does this seem sensible?

Thanks!

Hi,

Timeslip wrote: ↑Tue Jun 25, 2019 12:50 pm1) In previous games, have used easy save by Moodkie and have a fair amount of legacy code which can be modified for use. Would it be sensible to use easy save to save character and inventory data, and use your system to store the information for player actions, quests, etc?

If you're comfortable with Easy Save, might as well continue using it. To save Dialogue System-specific data, you have two choices:

1. The easy way: Use as described in this FAQ. This will save Dialogue System variables and quest states (and any checkboxes you've ticked in the Dialogue Manager's Persistent Data Settings section).

2. The complex way that can save additional info: If you want to leverage the Dialogue System's other save system components, such as the Position Saver which saves a GameObject's position and -- for the player -- also allows you to specify spawnpoints when calling SaveSystem.LoadScene, then set up the entire save system. To save it to Easy Save: (The SaveSystem class is in the PixelCrushers namespace.)

Personally, I prefer #2 for my own projects. I can get the best use out of the save system's components and scene transitions.

Another option is to record everything as in the first line of #2 above, but then write a small SavedGameDataStorer to store it using EasySave instead of using one of the built-in data storers which store to local disk or PlayerPrefs.

Timeslip wrote: ↑Tue Jun 25, 2019 12:50 pm2) The area I'm most uncertain about is configuring scenes based on the player's actions, or when they are revisited. In the case of a particular character getting killed or a container being looted, I was planning on storing the data in the variable section of dialogue database, then retrieving the data and having a configuration script for each scene, which will enable or disable the character/add the loot to the chest as required. Does this seem sensible?

Yes. If you go with option #1 above, pull the data from Easy Save and apply it to the Dialogue system. In your configuration script, use DialogueLua.GetVariable() to get variable values and apply changes to the scene.

This part is easier if you use option #2 above. Just add an Active Saver component. It will keep track of whether a GameObject was active or not when the game was saved and/or the level was left and returned to. Similarly, use an Enabled Saver to remember whether a component was enabled or not, an Animator Saver to remember an animation state (e.g., chest open or chest closed), a Destructible Saver to remember if a GameObject was destroyed/disabled, etc. You can also write your own Savers; they only require two methods (Record and Apply) and there's a starter template in the Templates folder.

Thanks for the information, Tony.

Have had some trouble in the past with save data becoming invalid when the fields of an easy save class are changed (extra data, changing data type), resulting in save files not working for players. I'm guessing that if you save the data in the dialogue database as a string, this won't cause the save game to break as a result of new database variables being declared/removed/changed? I'd really like to minimise the number of times saves become incompatible during early access.

That's correct. It's pretty good about save version compatibility.

Updated: Easy Save Support.