how to prevent save cheating? (for games where saving is NOT allowed)

It only takes a single person figuring out how your save system works and telling the entire world about it to ruin any client-side protection you try to use.

The only way to prevent the player from manipulating their save data is to perform all important actions (even gameplay) on a server you control. In other words, the way an MMO does it. The cost of actually doing this scales with the number of players you have, even if the game itself isn't an MMO. It will also piss off the players, because they will have to be online all the time.

It all boils down to: How much effort and money are you willing to spend to stop cheating?

The player has control of the executable and the execution environment. It is physically impossible to prevent while the player is in control. As an extreme example they could run as a virtual computer and if they are unhappy they can roll back the virtual computer to that earlier point.

You can deter savefile cheating by things like encryption on save files, online checkpoints against an online server you control, or perhaps a combination of details saved in multiple places that must all match, but even these can be overcome.

The only way to remove that ability is to move data from the player's equipment to yours. That means at least periodic online play requirements, and you only need look as far as Diablo 3 and the SimCity Reboot to see how well players react to that sort of thing. (There have been thousands of others, D3 and SC are just recent major examples.) There is a very vocal minority who can completely destroy your game's reputation and will happily take hactivist steps like DDoS attacks to sabotage your servers if you don't let them roll back their save files.

I miss the times where games actually came with cheats built-in...

no serverside stuff plz:)

I know its impossible to stop it completely for someone who really wants to mess with the files on their computer. But any concrete tips on making it less easy?

Can i hide files so the user doesnt see them? Or stamp them somehow so copies can be detected ingame and not be loaded?

Thanks again

These ideas will only make it more difficult for the casual user to tamper with your files, and putting more effort into protecting your files may actually be taken as a challenge to be overcome -- if your game is popular these will be bypassed -- but some ideas in no particular order:

• Hide your files from a casual inspection by storing them in an archive format. You could roll your own custom format, but to save time and effort it's pretty common practice to take advantage of an existing format such as zip or .7z archives, with the extension re-named to deter and misinform casual users; if you're up for it, you might also make some custom modifications to the format. The goal with this is simply that when Average-Joe Gamer browses to the game's directory he doesn't see a list of files to tamper with.
• Encrypt the data. Obviously because your game will be able to decrypt it this will pose almost no challenge at all to a skilled cracker, but may help to deter Average-Joe. To save your development time it's easiest to just use some simple and well known encryption method; remember that you're only trying to deter the average user anyway, so something more extreme is probably a waste of time and effort.
• Check if the data has been tampered with when loading by storing special values amongst the real data, hashing the file to check that it hasn't been replaced, etc.
• Store the data in multiple places and check that all copies match.
• Store some pieces of data in different places so that any tampering will involve changes to multiple files.

None of these will present any real barrier to a skilled cracker -- your game needs to be able to access the data, and they can simply hijack the game's functions to do so themselves -- but may help to deter a casual user. Note that if your game becomes popular some of the aforementioned skilled crackers will distribute patches or cracks that will let the casual user also by-pass these protections with a simple one-click procedure or file-replacement.

Take some simple measures that don't involve a lot of development effort on your part, but honestly I wouldn't waste a lot of time and effort on this.

...and sorry, I know you didn't want this particular suggestion, but why not let the player cheat if they really want to? If they've paid for your game, let them enjoy it however they see fit! :)

Hope that helps!

I don't think it's a case of making it less easy for them to do as less desirable. If you allow the player to save whenever and wherever they like they'll always be tempted to save just before a difficult bit and reload if they fail. Instead you could have a limited number of save locations that are sufficiently far apart that going back to a saved game would lose a significant amount of progress. This would at least discourage them from going back to a saved game even if it didn't prevent it.

Thanks guys! Some good points here for sure

Make it possible to get through the game very very easily if you have access to cheats. If the player uses cheats, all challenge is removed and the game is no longer fun. The player cannot easily limit himself to a "fun" amount of cheats because it would be a completely arbitrary limit controlled by the player and again challenge is removed.

The only option left is to play the game without cheats if you want to be entertained.

Make it possible to get through the game very very easily if you have access to cheats. If the player uses cheats, all challenge is removed and the game is no longer fun. The player cannot easily limit himself to a "fun" amount of cheats because it would be a completely arbitrary limit controlled by the player and again challenge is removed.

The only option left is to play the game without cheats if you want to be entertained.

People have fun in their own ways. Taking fun out of the game on purpose is not a good idea generally.

Breaking a game that was not paid for is one thing, and most players understand that even if they don't like it. But breaking a game as a consequence of natural play deviance doesn't make much sense.

It almost feels like childhood bullies who target any deviance from height to weight to clothing to anything else they can identify and punish just because it is different. I have always felt games should encourage variance and individuality and experimentation, not punish it.

Let someone cheat and break the rules on their own sandbox all they want. If they want to turn their own sandbox into a litterbox that is their choice. In multiplayer you don't want at allow griefing behavior unless it is available to everyone. Savefile cheating usually fits the first case.

The way nethack does it is by running the game with the s-bit set (as root). So when the player saves, the data gets written to /var/games/nethack which the user has no write access to. This means on shared systems where the user has no admin access, they effectively cannot interfere with the save file.

So some flaws...

1) Nethack is open source so you can modify the code to remove the requirement.

2) Copy the binary, drop the s-bit and hex edit it to point to your home directory

3) chroot to create a fake root environment where you have control over the save file

Again, this system is most effective when playing the game over ssh where only the game launches as the shell and you are locked into it.

So I guess the best option you have is to make it too "impractical" to backup the save file and restore it on error. Perhaps forcing players to use a specially formatted memory stick and note down the device ID. This means that the player would need to do a full disk image on the usb stick to restore the data...

Make sure your game is really graphical and 3D making use of almost every graphics card extension known.. Otherwise players could just run your game in a virtual machine and save the entire state.

I will not bother playing a game that is that much of a pain in the butt. My time is valuable; particularly in games where outcomes are governed by random die-rolls, the cost of losing hours of progress due to an unlucky roll is enough to irritate me to the point where I will close the game and do something else for the rest of my all-too-rare free time...

Imagine a game like X-Com (which I haven't played, but I know the basics of). Due to the use of random numbers to determine if an alien is hit, or if one of your troops dies, or even the A.I. decisions, replacing a save file can help because next time the random numbers will be different different. So, why not make them the same - load the state of the generator from the save file and continue to use it going forward. So the next time the player loads the game, the same stream of numbers is waiting to be used.

Now, because the order of generation requests will be different, for example the player choosing to spend action points on shooting rather than moving, etc, this results in the random numbers being used for different things. However, consider instead of having a single generator for all actions, you have a number of separate generators - one for user actions, one for enemy actions, one for random events, one of A.I. decisions, and so on. This way, if the player is due a "hard time" due to a particularly unfavourable sequence of numbers for their actions (e.g. a string of poor accuracy), or the enemy is due a streak of "lucky" numbers, replacing the save file won't help - it will just change some of the details of exactly when they appear.

I'm just making this up right now, I haven't tried it and someone might be able to spot a major flaw in such an approach. In particular, I wonder if it would even be obvious to the player that this is going on - they might try save "cheating" anyway while the game mitigates the effectiveness of the tactic. Such players might come away thinking that the game is just fundamentally unfair and stop playing.

Don't even bother. If a person wants to cheat, let them cheat. They bought the game. Let them play it the way they want.

This is of course assuming we are talking about single player games where cheating doesn't affect anyone else.

Imagine a game like X-Com (which I haven't played, but I know the basics of). Due to the use of random numbers to determine if an alien is hit, or if one of your troops dies, or even the A.I. decisions, replacing a save file can help because next time the random numbers will be different different. So, why not make them the same - load the state of the generator from the save file and continue to use it going forward. So the next time the player loads the game, the same stream of numbers is waiting to be used.

The latest version of X-Com that I've played has a "Save Scumming" setting for whether it saves its random number seeds. I don't know if it's one global seed, per team, per soldier, per action, or something else. Generally, if I reload after some bad dice rolls in a strategy game, I'd just retreat or find cover. I wouldn't try to do the same thing over and over. If I knew I was due a "hard time", I'd make sure I was in good cover and as far away as possible from the enemy, and I'd try to use up my inaccurate shots, so there's still a way to game the situation.

You could use an NTFS alternate data stream. Very few people know about them, and it would take someone with a disk I/O monitor to realize what you're doing.

To make it harder for someone to notice the ADS in a disk monitor, you can put the ADS *on the folder itself* with the same name of a standard, red herring file in the folder.

Example:

Folder:Save1.dat <- this is the ADS

Folder/Save1.dat <- this is the red herring (just write a ton of random bytes to it to make it look encrypted)

The : and / will be hard to spot in the disk monitor and it may appear to the cheater that only one file is being accessed.

Here's the fun part: Copy/pasting something with an ADS attached to it *does not copy the ADS*. This means that if the player makes a backup of their save folder, then restores it later, the original ADS will either be unmodified or completely lost.

The most obvious downside is that people unaware of the ADS will not be able to make any kind of backup of it. If they try to copy the game to a new computer, their game will be lost.

It's not perfect, but it'll probably confuse the hell out of people for a while. Still, it only takes one person leaking the information about how it works for the technique to be ruined.

The way nethack does it is by running the game with the s-bit set (as root). So when the player saves, the data gets written to /var/games/nethack which the user has no write access to. This means on shared systems where the user has no admin access, they effectively cannot interfere with the save file.

So some flaws...

1) Nethack is open source so you can modify the code to remove the requirement.
2) Copy the binary, drop the s-bit and hex edit it to point to your home directory
3) chroot to create a fake root environment where you have control over the save file

There are common and well-documented work arounds that don't involve root and don't involve anything particularly sneaky. You can copy the file from /var/games and overwrite an existing file if it came from there.

Even though the regular user cannot do much the file, they can read, copy, and move them with relative impunity. Keeping a collection of ascention-ready save files from /var/games/nethack is a common thing, as is keeping a backup save file of your current quest. Count me among the guilty on a shared system, especially after facing a group of randomly generated baddies with multiple wands of death. The first one fired and destroyed my amulet. The second fired and I resisted, then "would you like your possessions identified?" For a few years after that I kept copies of my save file that I updated after playing.

I would just like to point out that saving the game remotely adds complexity and further requirements to your project without providing a feasible return in most cases. Intercepting the call for a save game file and injecting your own is a lot simpler, in many circumstances, than performing intense decryption. Many forms of encryption, worth a lot more than any save game editor, have stood the test of time for dozens of years.

Hi
In many games such as xcom or others, there is a big point in the player not being able to go back if something went "bad". Actions should be permanent. The punishment/difficulty for "failing" something ingame can differ, but generally you don't want the player to be able to cheat.

However it seems to be hard to technically prevent save cheating (the user just finds and backups the "savefile" and restores it later). Any good way to actually stop this from being possible? Hide or nest files or something? I mean, if i save progress in the exe instead of in a separate "savefile" the player can just backup the exefile...

I was wondering the same thing but for single player games (will probably never make an mmo/mo etc.).
I guess i/you could implement an automatic autosave without the option for 'no autosave' and when the player opens the game, you can only load your career (like nfsmw).

Hi
In many games such as xcom or others, there is a big point in the player not being able to go back if something went "bad". Actions should be permanent. The punishment/difficulty for "failing" something ingame can differ, but generally you don't want the player to be able to cheat.

However it seems to be hard to technically prevent save cheating (the user just finds and backups the "savefile" and restores it later). Any good way to actually stop this from being possible? Hide or nest files or something? I mean, if i save progress in the exe instead of in a separate "savefile" the player can just backup the exefile...

I was wondering the same thing but for single player games (will probably never make an mmo/mo etc.).
I guess i/you could implement an automatic autosave without the option for 'no autosave' and when the player opens the game, you can only load your career (like nfsmw).

He's already stated that this is basically what he wants to implement. His question is "how to stop people from cheating?"