Porting games made with Adventure Creator to consoles - have I found all the places it saves data?

darbotron

Hi.

I'm just posting here to make sure I've found all the ways / places that Adventure Creator persists data:

So far I have found:

• iOptionsFileHandler which is used by Options
• iSaveFileHandler which is used by SaveSystem

I just wanted to check if there were any other places that I'd missed

Context: I'm currently porting a game made with Adventure Creator to multiple consoles (can't say what console(s), or which game because NDA).

I have a mature in-house console porting library for Unity which I've made over the last decade or so, and which only writes a single save file to the console's persistent data storage (for good reasons relating to passing console submission requirements).

If a game I'm porting saves > 1 file then I just add an abstraction layer into its save code which handles the multiple files as a single cached data object and then I read/write that out.

Thanks,

Alex

ChrisIceBox

Welcome to the community, @darbotron.

Yep, you've found them both - those are the two methods that AC stores data.

The Manual's "Custom save formats and handling" chapter covers how custom implementations can be hooked up to override AC's default save behaviour.

If you have an in-house library that can store things in a single file, having custom handlers refer to this should be possible - just be aware that AC will read/write the options and save data sets at different times.

darbotron

Thanks for getting back to me Chris - all good info and appreciated :

Yeah writing options and slots at different time is fine - I've done exactly this approach with a bunch of games

Actually the options / progress at different times is pretty much the least of my save data related problems - this game uses two other asset store packages which save their own data as well as AC...

ChrisIceBox

I don't know if it's helpful here, but it is possible for AC to store custom global data within Global String variables. Perhaps the other assets can store their data within these, so that you can store all data within a single AC save-file?

darbotron

Thanks for the info dude, appreciated.

What I usually do is make an intermediate class which holds a bunch of json strings (or byte arrays) one (or more) for each save system I subvert.

The save system writes only write to their part of the class, and the whole object is serialised to a fixed size buffer which is then written to the console's (user level) persistent storage.

Using a fixed size save means you reduce your risk profile for "save space related edge cases" to time of initial save creation, since from that point you are only overwriting an existing save of the same fixed size.

All the console save APIs use atomic writes for their save data (or some equivalent variant) so you never have to worry about hardware level corruption**

(** unless the user is silly enough to turn off their console whilst it's saving - but even then most consoles have some variant "revert corrupt save to last good save" functionality hidden in their save APIs so it's all pretty safe).