1) By including the version number in the exe/project name every version creates new subfolders, requiring you to start over or manually copy the save from the old path. Simply always using the same filename for the exe/project should avoid that by using the same folder each time. If the game structure doesn't change too much, the saves could maybe work fine for newer versions.Hello Everynyan!
I want to say a huge thanks to everyone who took the time to play the game!
I've read most comments and I've decided instead of replying to each one, like I did in the past, to just have one single paragraph at the end.
[...]
2) You can implement settings as globals (Or autoloads/singletons as they are called in Godot). Depending on scripting, that would allow you to manipulate OS functions (I think in godot 3.x.x stuff like that is all OS. functions) like fullscreen, master volume, etc. at any time as well as carry over between scene changes and saving the custom user settings as cfg or json file, somewhat similar to the save function you already have.
6) It's your choice of course how to deliver your content, I think making different executables for patreon/non-patreon content additonally complicates development and the game structure, as well as having to debug and fix multiple versions. At least during development, simply making bonus content available separately but not as different game versions could streamline and simplify development.
Try to use latest LTS as well (3.5.2) if upgrading doesn't break any scripts (I'm assuming you are using 3.2 like in the tutorial, if you are already up-to date ignore this of course).