Hi. May I know why tres / res format is not mentioned at here? Is it due to tres format is less recommended compared to the save formats described here? Besides, performance wise, will binary format save method take the longest time? Do we need to consider this for a game that need to save a lot on game progress?
Here are the answers to your questions.
May I know why tres / res format is not mentioned at here?
The .tres format represents a serialized Resource object, so the question is "why not use a Resource to save games?"
You could try. I think they only pack data so they could be safe.
I tried back when working on Open RPG, but at the time, resources had bugs that made them really finicky to use compared to alternatives. And so I haven't tried again. But we should look into this.
Resources come with more than just data: they also pack absolute paths to their dependencies. That's one potential source of trouble to test on every platform when it comes to savegames.
Because the main advantage of using a resource is you could directly reference, say, your character stats resource, your game settings resource, etc. and share them with relevant game objects. That way, when the character's stats increase, the savegame resource's data automatically updates.
performance wise, will binary format save method take the longest time?
No, it's theoretically the opposite, binary's generally the fastest format to read and write. In binary, you can write information with fewer bytes compared to text, and you don't have to parse key-value pairs and the extra characters in text format (spaces, line returns...).
The main aspect to consider is that if you manually write all the binary data in GDScript, it may be a bit slower compared to using the JSON parser or str2var because these functions, even if they run many more operations, run on the engine backend and use optimized C++ code.
But the difference will most likely be negligible. Loading a savegame of even a few hundreds of kb (big game) is nothing compared to loading textures, meshes, creating all your game world... So the important considerations are mostly the ones explained in the guide.
And I'll get in touch with François to think about resources for savegames.
Note I also took the liberty of updating your post's title to make it easier for other students to find it.
François and I discussed the use of resources and it seems that there is a good use case for it.
The idea is that if your game is really heavy on the use of the resource class, you can directly reference resources from various parts of your scene tree into the save game object and let Godot serialize it for you.
The biggest advantage here is that you need to define extra functions on the nodes or data that you will save: as long as your save game resource has a reference to all the other resources, they will automatically be saved in it.
I took a note to update the save game guide with information on that.
Your team are awesome. Thanks!