Encryption is not authentication.
Protecting the contents of a file from being read and protecting the contents of a file from being modified are two separate tasks. This is particularly apparent when trying to secure the contents of your game's files - the game needs to decrypt them, so it needs to have the secret...which means the user, who has total control over their own machine, also has the secret! Even ignoring that, the files still need to be loaded into memory sans encryption at some point, so the data can be seen.
Authentication, on the other hand, could be done by signing the game's files with a private key (which never leaves the developer's clutches), and then later verifying them with a public key (which is distributed along with the game).
Now an adversary who can see everything is unable to modify the game's files. They don't even need to be encrypted; any change will cause the signature to become invalid.
...Unfortunately, of course, the end user can just patch out the routine that verifies the game files in the first place.
This becomes a game of cat-and-mouse. Ultimately, it's a losing battle for the developer; it's like trying to keep out robbers by asking them very nicely to stay away.
So what to do?
The client is totally untrustworthy. The client can lie and cheat and steal 'til the cows come home. If your game's logic lives on the side of the client, the game's logic can be subverted.
On the other hand, if your game is hosted on a system you control, you have some power. You can decide "hey, JimBob just moved fifty miles in two seconds; maybe that isn't right." The client can still be a horrible liar, and still abuse information they shouldn't have (like seeing enemies through walls), but you can at least verify that their actions are valid.
The same tenant comes up in all sorts of places. Web developers validate every input, even if the UI doesn't allow you to say you're potato years old.
So, at the end of the day, trust the client as little as possible.