Hi! I want to create a Resource script where I would save all my variables, but it seems too easy to modify. Is there a safer standard for saving variables like "hero_took_the_bait = true" or "secret_mission_1_discovered = false"?
P.S: I know someone with decent skills will still be able to access all my variables no matter how good I hide them. But I'm fine with at least make it harder so the regular can't just open a file and change the values.
Thank you!
Don't use Resource. Use ConfigFile, and use its methods save_encrypted_pass and load_encrypted_pass.
https://docs.godotengine.org/en/4.3/classes/class_configfile.html
DaveTheCoder But config files can't write on the game folder, right? I want to create a file that contains all my variables that some components can use as reference but the player can't see.
Also, I don't understand how I could make my password safe when my components would need to use it to load the file. I would need to write it in a script, right?
What do those terms mean? Here's where Godot stores persistent data:
https://docs.godotengine.org/en/4.3/tutorials/io/data_paths.html#accessing-persistent-user-data-user
The password would be in your script code in some form. A determined person could study the code and find it. But that satisfies this requirement:
Godoten P.S: I know someone with decent skills will still be able to access all my variables no matter how good I hide them. But I'm fine with at least make it harder so the regular can't just open a file and change the values.
DaveTheCoder So I made a tool that is supposed to "create" or remove variables as I'm making the game. I want those variables to be saved in a file that will contain all variables. The point is to be able to track all the variables I will be working with without allowing the players to access it. That's why I want to save it in the res:// folder, so it's saved with the rest of my game's files. I will need that file in order to know how many variables I will be using, their names, their values, and all that. Or is there a better way to track those variables?
What's the target platform for your game? In an exported game, the res:// folder may be embedded in the game's executable code and not writable.
DaveTheCoder I wanted it to be on PC and Android if possible. I saw a Unity Plugin called Aventure Creator that tracks all your variables and allows you to reference them to make conditional paths. Which I thought I could replicate with the system I described above. But maybe they do it in another way that doesn't involve writing in the game's executable code?
I don't know how that Unity plugin works.
But I don't understand your objection to saving the settings in an encrypted file in user://. The users won't see the file unless they go looking for it, and even then it will encrypted, so that modifying it would be very difficult.
The user:// directory and ConfigFile are intended for this purpose.
DaveTheCoder I just don't feel like the file that contains all variables in my game belongs to the user:// directory. Is that not a core parte of the game itself?
I guess I could manually create the file at res://Game/, but the point of my game is to use the interface I made to help me create the playable experience of the game. That means that at any point while I'm playing I could use the interface to add an event that sets a new variable after played. And I want that to be registered in the file so I can track all my variables that will be created by events.
So this file will be a core part of my game. If it's in the user:// folder and gets deleted for some reason, I will not have any way to track all the variables created by events inside my game. Unless I make another tool that iterates all events and run it every time I start my project, which feels harder to maintain than having a single all-powerful file where everyone dealing with variables writes on.
Godoten So this file will be a core part of my game. If it's in the user:// folder and gets deleted for some reason, I will not have any way to track all the variables created by events inside my game.
You could say that about any application.
The documents you create with a word processor or spreadsheet app are important to you. If those files get deleted, that's bad. So you make sure to back them up.
But those files are user files. They're not part of the app itself.
I recently added a feature to one of my Godot projects. It automatically backs up the app's configuration file, which is in user://, to a web server. The configuration file doesn't get automatically restored from a backup if it's missing; that has to be done manually. But it would be possible to do it automatically.
OP want to make level editor for the unfinished game so that he could add the level into the game build he is building from within the game?
If that file stores the state, the game should maintain one such file in res:// that represents the default state and is never written to, and optional other file(s) with the same structure in user:// that represent user generated state(s). If the game cannot find needed file in user://, it should fallback to loading the default state from res://
Alternatively you can just hardcode the default state.
There is one very practical reason for never storing any user generated stuff in res://. When doing a content update on platforms like Steam, its cm/versioning system will always make a direct clone of the newly uploaded directory/file structure. Meaning that everything your game saved in res:// will disappear when an update is made. You almost never want this. User generated data typically needs to survive updates. That's why you have user://
xyz Yes! I guess that's how it's called, the state file!
My idea is this: a game I can create while playing. My project right now is just a "master interface" that allows me to extend the game while playing it as if I'm in Minecraft's creator mode. For example, a simple button can add a new dialogue in that moment. I will be deleting this master interface from the final game, since it only contains creator tools.
The intention was to create, modify or remove events while playing, which I find more straightforward than those dialogue plugins.
So during the developing time (which requires to play the game) I already can create characters and dialogues using custom Resources. But I want to create that unique res:// state file that will never be modified after the game is exported without the creator tools.
This file will not be generated by users, but by me. I guess I will be an user during the development, but this file belongs to res://.
While I'm working in my game, some events may add a variable when I create them. For example, if I suddenly decide to add a fight, I can add "dungeon_9_fight = true" to the event creator, which should add it to the rest of variables.
Then the game reloads and the event can add that variable to the user:// file as the user's state, but I need it also in another file that contains all possible variables or states so I can keep track of this. It's kinda like when those dialogue plugins allow you to add variables using dialogues, but those don't need the game to be running.
Updates would not be a problem either, since any update include an updated "states sheet", or however it's called.
Godoten You can always change the location to which you save the state during the development process. When you as the developer are changing the state, maintain the state file in res://. Just before the game is finished and handed to players to continue to change the state, switch to serializing the state(s) to file(s) in user://, and keep what you've done in res:// as the default fallback, as I described in the previous post.
The logic is simple. Everything that developer changes regarding the game - goes into res://. Everything that user changes - goes into user://
For protecting from user snooping around the files, you have the same options regardless of where the files are situated - either encrypt or pack to binaries.
xyz When you as the developer are changing the state, maintain the state file in res://.
That's the "problem", that I want to change the state through my game (a part of the game, which is the "creator mode", modifies the rest of the game) but I can't maintain the state file in res:// if I can't write to res:// while the game is running.
How is it that I can write to res:// when it comes to custom Resources, but not with other files? Is serialization the key of all this?
DaveTheCoder Sorry, I think I didn't explain myself correctly. The file I'm talking about won't be user-generated. It will be generated and modified by me using the 'creator mode' inside my game. I explained it a bit better in my reply above.
Godoten You write to res:// only when you're running the game. When user is running the game it writes to user://
You need to write the complete state only to the default version that's in res://. The user's version of the state doesn't need to have all the state. That's why using something like ConfigFile is handy here. Not only it can encrypt but you can check if something is in there. If something is missing (e.g. you added new things via an update and user's state doesn't have those) simply fallback to what's in the default state in res:// and then resave to user://
xyz Yes! This is pretty much what I want to do! But this is what I can't do:
xyz You write to res:// only when you're running the game.
Nothing happens when I use config_instance.save(res://Game/data) for example. I guess it's because the game is running, which makes the res:// directory read-only. Although I don't have this problem when saving new custom Resources for some reason.
ConfigFile.save() -> doesn't work with res://path while the game is running.
Resource.save() -> It does work with res://path while the game is running.
Godoten When running from editor, res:// shouldn't be read only. Check the exact error code returned by save(). But it doesn't really matter where you save the state during the development, you can save it anywhere (including user:// or some absolute path) and put it into res:// once the whole thing is done and ready to be released.
