# Hide game data from player?

I'm working on my first (C++) game, and I want to use a component based design. I've read a lot about this lately and yesterday I decided I wanted to store object data in external JSON files, to allow for more flexibility and ease of access.

Then it dawned on me that leaving these files in the game's directory tree would allow the players to modify anything they want very easily.

I'm not worried about showing the code to developers, because the game will be open source, but I'm afraid an inexperienced gamer might break the game or at least ruin the fun.

Am I missing something? What's the policy about hiding game data (in open source games)? Is it normal to leave everything plainly accessible to anyone?

If not, what is a good way to hide the data?

• Usually the ability to modify the game is a feature, not a bug, especially for single-player gaming.
– user5290
Sep 25 '11 at 16:57
• I wouldn't bother, really. Your time is better spent on making a good game. =) Sep 25 '11 at 19:15
• I'm inclined to think that (almost) anyone who downloads an open-source game knows enough to actually enjoy tinkering with game data and breaking the game in process. If it's a good game, you'd see a wiki explaining your JSON format pop up in no time! Sep 26 '11 at 4:25

If players tinker and ruin the fun I would say that's their problem. For tinkerers half the fun is seeing what breaks.

It's like getting worried that players would use a god mode cheat code and being worried that the player isn't challenged.

I wouldn't do anything more than putting those config files in a zip file (which you should probably do anyway for loading times) and making sure your code can handle corrupted data gracefully.

I'm afraid an inexperienced gamer might break the game or at least ruin the fun.

If they're meddling with the game data, then that is what they consider 'fun'. You don't need to protect them from this. Entity component data is hardly a spoiler, after all. Maybe if you had dialogue or quest data in there, it would be a problem, but probably not. Most gamers don't even know where to look for this sort of thing, never mind deliberately searching through it or editing it.

My advice is to zip it up and rename the file extension. This will keep out the casual looker but won't be difficult for you to work with. You can use something like PhysicsFS to work with the files.

• Yep. I remember playing Colonization on Amiga. Parameters of units were stored in a simple text file with standard txt extension. After playing quite a lot I decided that I'd make game harder by adjusting those parameters. Later I shared those settings with friends. It was fun... Sep 25 '11 at 18:21

You could store the data encrypted, using a symmetric encryption scheme (AES), but this is pointless: the software is opensource, so everyone can read the key and therefore decrypt the data. This would just "stop" the casual gamer from cheating.

And it would be kind of pointless even in closed source projects, since it is quite easy to find the key into the game binary.

So, you have two possibilities:

1. just leave the stuff unencrypted (but at least collect the md5 hash of every file, so that you can check it at runtime against any damage in the distribution of your game);
2. go closed-source, scramble the data (with a secret reversible multi-step algorithm like string reverse + byte swapping + xor with a constant string, etc...) and then crypt everything with AES. It will be harder for anybody to recover the data. A lot harder.
• Even your closed-source method isn't all that hard. The same people who routinely break the schemes used for copy-protection can probably break that too. The main difference is that they won't bother.
– user5290
Sep 25 '11 at 16:59
• @jprete: for sure. It's just a matter of time, but time is critical for people, so making it difficult and not profitable, sometimes, is just enough.
– gd1
Sep 25 '11 at 17:23

I would leave it. There is a huge mod community and players like changing/modding games. If they break something, it's on them. They could always reinstall.

Also makes it easier for other developers to work with.