Savefiles and malicious code

[gritty mason]

As we know, using resources for Savefiles has the risk of code injection by a third party. While I could simply ignore the issue ("Why should I care if players want to cheat?"), I prefer to safeguard my players, within reason.
So, I would like to discuss any potential solutions here.
Addendum: While I have some knowledge about gdscript, anything more complex then that will need more explanation.

[brazen tulip]

two solutions i can think of would be:

1. use json or ConfigFile (https://docs.godotengine.org/en/stable/classes/class_configfile.html) files as your save files (there are ways you can obfuscate/encrypt the data, if that's a concern)
2. use a binary format (custom or otherwise. https://docs.godotengine.org/en/stable/tutorials/io/binary_serialization_api.html has some extra info on that)

both of these solutions have their pros and cons, so which is the best choice really comes down to your needs.

[gritty mason]

1. JSON was not on the table to begin with. I see it as an unprofessional way of handling Savefiles. May it be from having to convert the JSON information back into Godot, or the general outside viewpoint of a videogame developer using it outside of an purely hobby related field. However, pointing out ConfigFile is a helpful tidbit that will be helpful in the future, thanks.
2. From what I see, it is literally converting the variants manually into byte format and back, which is rather complex outside of an advanced programmer. Especially if it is an entire dictionary, like in my case. That being said, it could be an later solution if it becomes a real problem, so thanks for pointing it out.

As a potential third solution, I have been thinking of having a seperate save file that contains information about the other save files, and through some - currently unknown - action could check the savefile on its legality, before code can be executed. What do you think about this solution?

[pure mesa]

You dont need to use raw json files as your save game file, you can embed it. Most games use a binary custom file format, but apart from the byte header their main "gameplay data" to restore the gameplay state from the save file is just a big "json" dictionary of key value pairs.

the reason is, json has a standard, so if you read that save files in 20+ years you can still read it. If you use any Godot var a new Godot version might not be able to do anything with that old file.

[gritty mason]

First of all, I was not expecting an Developer to take time for my post. Thanks.
I'm a little confused / uninformed on your later statement on reading Savefiles 20 years later. Afaik, no game has that long of an development cycle, and wouldn't that problem affect the game itself as well?
In the end, I will use a resource for my savefiles. Reason being that I found a Youtube video about the subject, and it includes using an specifically made addon that checks the resource for any malicious code. I'm sure the development team will add a similar solution eventually without the need of an addon - not just because of Savefiles, but other external resources as well.

[pure mesa]

the 20 year examples was just to get the idea across to not add any dependency on your game engine version when it comes to save files, it should be just pure, generic data, that anyone who knows the file definitions knows how to read back in. So you store your "magic" version byte in the header of your save file and have some file definitions for the versions. Now you know how to read that save file no matter what age or engine. Like there are games that allow to import old save files from older games of a series made with entire different game engines years later. That is only possible because the data inside the save files was made generic and the format is known.

That is also why storing any kind of "full" Godot objects inside save files that can be potentially malicious when read back is so fundamentally wrong. Trying to add solutions to what is so wrong to begin with is just a waste of time in the end. The idea to store entire objects, resources and scenes with a single script call is just born from people being lazy or not knowing better, which is understandable, but still not a correct path to follow when it comes to save games.

like instead of storing the "gameplay" object in full, just store its internal id so when you read that id back you know what object and in what state you need to spawn at what position.

safe and sound, compatible with anything, no problems with malicious actors, downside is more work to implement.

[pure mesa]

it is also done for practicality, if you have a quick save/load you do not want to parse and inefficient format. With a binary custom format that only saves what is needed you can have very small save files with full embedded screenshots for your save game menu that all load very quickly and make your game not stutter when doing saves. Try to do the same save file with Godot resources and you have zero chance to keep things performant at scale when your project grows. The main problem is that Godot will read them always in full while on a custom format you can pick what you need and only load that.

there have been ideas and even prs to try to add a more accessible ways for users to do such kind of save game system like https://github.com/godotengine/godot-proposals/issues/7041 and https://github.com/godotengine/godot/pull/79644 , but it is rather difficult to make in a way that benefits most projects. Save game systems are deeply nested in how a project works so they will always have very large parts that require custom solutions.