I tend to store a lot of data in .json files. Level layouts, enemy spawns, items etc.
It sort of "concerns" me (not really concern, just something that I think about), is that these files are easily edited. A player could edit these files to "cheat" at the game.
I know it doesn't matter, they can do that if that's what they want to do. But I would rather remove this ability.
I suppose I could store these tables in lua files, and create some system for accessing them. But I like the sensible functionality of loading .json files.
Any thoughts about this?
To prevent editing you could save a hash of the JSON file and then during execution load the file as string first, create the hash from the string, and only parse the JSON if the hashes match.
The only thing that’s missing for this is a hash function because Lua doesn’t ship any by default as far as I’m aware.
in a similar vein, you could also encrypt the json file and hard code the key needed to decrypt it into the code. then when you need to load the file, unencrypt it first and then parse the file. bear in mind that this is still and imperfect solution since you'd also be leaving the key in the program's code, which can be remedied by obfuscating it, splitting it up, stripping symbols from your binary, etc. you could also pair this up with coming up with your own file schema to define this data, but this all really just delays the most determined of people from getting at it, while increasing complexity for you and processing power required from the device.
if you asked me what my opinion was, i'd say go for the lowest effort thing that prevents the casual user from tampering with this data. of course, be more protective of any actual sensitive data (eg. if you had something like an api key stored somewhere), but for something that isn't as serious you'll stop most people by putting up a small technical barrier.
Yeah, it's not really a security risk or anything.
Are people able to recover source code from .pdz files?
Another option would be to read your JSON in, and saving out as a Lua structure which you would then use that. This will also give you increased loading speeds of that data.
A similar "concern" is files in datastore taking precedence over files in the game pdx. I won't go into detail, but you can look into it yourself.
I'm not familiar enough with lua to say how it's compiled (if it is compiled) for the playdate, but I can say that it won't be more secure than compiling with c using the appropriate means to strip symbols and such.
but in short: maybe? someone can't (at least easily) decompile to the same code you wrote. I think maybe they could use something like ghidra to get most of the way there, but I'm afraid my reverse engineering knowledge when it comes to decompiling to c mostly ends there.
they could fairly trivially disassemble it to the native assembly language though if they wanted to, and also read any strings you left in the program code (among other things). I wouldn't say you should be concerned about that though, because it takes a lot of effort/know-how to get anything meaningful from that, and again if it's enough to stop the most general of users then I think that it's good enough.
If they'd rather do all that, than play through my game properly, then good luck to them : D
Where could we find some detail on that? Our game was considering a certain functionality that may actually benefit from some sort of "secured" JSON file (or whatever secure solution for saved user data).
I think the part that Matt was saying he won't go into detail bout was actually about the precedence of which file will get read if you have two files with the same name in two different data storage areas.
I think the idea being that a user could inject their own version of a file to be read, instead of your original game code.
the brief details of it are here....