Methods against Save Scumming

[kipar]

The idea with online server is good, but it means I won't be able to play it offline (or I will, but without all the achievements so the game will lose half of its appeal.) Imagine your server is temporary offline so everybody is denied to play. But ToME4 proofs this idea is working.

1. A saved file itself would contain a time stamp of the last save file modified time. If the modified time is mysteriously changed after the time stamp, it was scummed or edited externally. Encryption here also would help ensure the data confidentiality (from the user).

So I copied the savefile from desktop to laptop and it become "hacked". I don't like it. But once i know about it I'll just change date attribute of file and your method won't stop me.

2. The current state of the character (dead, loaded, playing, saved, hacked) is saved. If the character state is in playing state, and the game is loaded, it will flag a hacked state. Computers being unstable (including the app), I might allow a grace load for a character, which could be reset after a certain period of time ( maybe 1 hour).

I don't understand it. If you want to prevent savescumming by running two copies of the game - just don't allow running second copy of the game. It is much better then marking the savefile corrupt if I just accidentally clicked on the exe-file too much times. And i can always savescum by saving the game, exiting, then copying the file.

3. To prevent memory hacking, you can generate a CRC of the core statistics of the player. This value is checked after every change and then a new CRC is generated.

Well, if I'm supposed to use memory hacking I can just replace CRC checking to NOP. Or save the state with full hp (and corresponding CRC) and then restore it once i'm damaged. It's won't prevent real hacker (because every challenge is fun) but maybe will help against some lamers.

4. While playing the save system would stream data in the game to the save character file every 5-10 seconds including the above mentioned game state.  

So it wil scrap-scrap-scrap my old pc harddrive or vzhhhh-scrap-scrap-scrap my laptop harddrive while i'm silently playing it at night. It' s bad. Perhaps I'll install it to virtual drive in memory, so btw i'll be able to copy it's state at any time. Or just disable this mode\throw out this game.

On death, the character data when received by the server is checked to make sure it wasn't a hack. Things like time span of character life, HP, AC, items, kills, or whatever else I want checked. For example, a 1 hour life span of a level 50 character = fail.

So I will keep the game running all the night for increasing life span (maybe with macros to keep player walking up-down in the safe place for increasing turn-count).
Or maybe I'm just discovered an easy XP source in your game - of course it's abuse, but it's not my fail, it's your game fail.

[Psiweapon]

Well, let's remember that there will be a non-hardcore mode too.

The only advice I can give is formal because I really don't know shit about programming:

Use several redundant methods if you can. If you have let's say, at least two or three, and manage to make that tampering against one activates one or some of the others, it'll be even harder. Of course that will make *some* people even more eager to crack it, but if it's annoying enough, it'll deter a lot of people which hopefully will turn to doing something else.

You could also include an option something like this: This monster is going to hand you your ass in a silver plate, do you want to become a savescummer? (y) (n). Of course, the reverse option isn't available. But perhaps this idea goes against the original intent, or maybe it's just plain stupid ^^U But it would give the would-be savescummer an option to do it "legally" before having to resort to "I'm in ur gaem foldah, h4z0r1n ur savefielz lololol"

Another idea that comes to mind is feeding potential savescummers' e-pen0r: put an explicit statement in the line of "Hay guise. I'm trying to make this game as savescumming-proof as possible, so please go and try, and your discoveries will be used to develop the countermeasures in the next version" And then, of course, credit them, prominently if needed.

[willraman]

I should have specified more. The online server gives the user a KEY per character only if they want to save stats online (bragging rights). This however is outside the request of the OP, so completely unnecessary in this post and I'll not comment on it further.

Copying a save file from a desktop to a laptop it would be assumed you have closed the game anyway. Thus setting a "Saved" state inside of the save file for that character and it is not hacked (thereby allowing a move of the file). If you are in the middle of playing the game, then save to your laptop. Yes, it would be considered in a "playing state", then when loaded the game sees this and invalidates the character for online stats on that second save. Before you ask, this isn't reported to the online server, only when a player tries to upload the character.

I suppose a real hacker could "try" subverting the CRC check, remove the mode/throw and intercept the game state as it is being written into the character save file.  These are all good points you made, I'll be sure to obfuscate this CRC location and set up a honeypot variable to draw in attempts at hacking. Touching that variable in memory will allow the character data to send up to the stats server "Stupid hacker and wipe character account".

The scrap-scrap-scrap on your old hard drive only happens if you are making active changes to the character. You take a turn, your gamestate is queued for saving. Why wouldn't you want an up to date save?  I don't complain that firefox caches pages from an RSS feed in the background while I surf the net or that windows itself pages out memory. I have had my laptop overheat once and was pissed when I lost an hour of gameplay on other games.

Yes, there are some holes in the implementation and I appreciate that you brought up some ideas on what to protect against. It gave me further ideas on how to prevent hacking attempts. 

[Bear]

I think that the savefile should record games so that they can be replayed and observed.  Firstly it's a good way to sort out bug reports and see what actually happened.  Secondly it allows players to observe games that racked up highscores, etc, and learn from each other's moves. 

But thirdly, it does prevent one kind of cheating. When players edit the game, changing the probability of getting good equipment or meeting favorite/least-favorite monsters, they produce a stream of keystrokes that may get them a win on the local version but which will not correspond to a win on an unmodified version of the game.  So if the server checks savefiles for integrity, then when they upload their savefile and it replays the keystroke record, it can see that the game is not a win on an unhacked version of the game.

I think I'm going to echo the advice others have already given; it's not worth it to try to prevent savescumming on the local machine.  Make the game go to enough effort to make it clear to players that they are not supposed to do that, and that's enough. 

It is worthwhile, though, to have your game support a server mode where people *CANNOT* savescum when playing from remote locations. 

[DaedricPrime]

I still don't see how it makes permadeath more meaningful but I realize now it's not a worthless exercise.

It's the only thing that makes permadeath meaningful in the first place

Permadeath isn't a thing if it's not permanent

Yes but making cheating harder doesn't affect that at all. For the people who don't cheat permadeath is just as meaningful as it was before and for people who do cheat it will also be just as meaningful (i.e. not at all).

Well, the presumption is that there is actually a third group you're not considering.  Those who would have cheated, but now cannot.  Considering my roguelike will be on the Mac only, in general this group will be bigger than you may think.  First, the stereotype is that Mac users in general are less sophisticated when it comes to technical details of the OS.  Secondly, many of the players will never have even heard of roguelikes, so there will be less accomplished save scummers and many more "casual game players".

However, I believe that there is such a group in the Windows and Linux crowds too.

The experiment for me then, is to implement some "low hanging fruit" that will help this group play permadeath as it is intended, as permanent death. 


As for the "online" part I had always thought that if I had the resources/inclination for a server, that I would simply implement a remote-key system:

1) Split the "Secure save" into at least two files:
     a) the essential character file ( Payload_0 )
     b) the rest of the save state (vendors, dungeons, etc)

When saving a permadeath game for the first time, the client sends up Payload_0 in plaintext* to the server. The server then sends down Payload_0 in encrypted form* [using a "master key" generated at random on the server] along with a subkey for Payload_1 -- client then creates Payload_1 file(s) in encrypted form on disk using the key from the server.  (Payload_0 from the server is saved as-is on disk by the client).   [* network traffic could be obscured/weak-crypted if desired ]

When loading a permadeath game, client sends up encrypted Payload_0 from disk to server, which then decrypts and "increments" the keys associated with this save game [for next use].  Payload_0 and the previous subkey are sent to the client for decrypting/loading.    On next save/load the newer keys are used (which is stored on the server only)

So saving a game, and they making a backup will only be valid until that save game (or it's copy) is loaded.  Once loaded, the backup files will no longer be decryptable by the client.

Of course, Payload_0 has to be pretty small to keep ISP costs down for this system to be realistic, and as someone mentioned it means if you're offline you can't load/save your "hardcore" character.  However, if your server also tracks "non-secure games" you could offer an option to "move a hardcore character offline" which would move that save game into the "non-secure" bracket, etc.



In-memory hacking (which I wasn't really worried about with the OP) is "easily solved" by storing critical values using a simple custom obscuring algorithm.  Players can feel free to search for "0x0012" for gold, but they won't find "0x34FF" which is the actual value stored in var.  I'd also combine that with limits on stats via the mechanics.  You can also do some clever things with CRCs so that simply "replace CRC checking to NOP" won't work.   But I'm not so concerned at that point.  If someone is navigating memory and altering code execution, they aren't in the target group for me.  The main goal/proposal was just about reverting to backups to cheat death.


Great ideas, pretty good discussion!  =)

 ((  In retrospect, I probably should have mentioned, I'd also make non-trivial effort to make death in those situations interesting, carrots to the sticks, as it were.  Because I think that is one major reason for save scumming is that there is too much investiment vs no reward for not cheating.  So consider that along with the "counter measures" there would also be incentives. Perhaps that aspect would make a better thread.  ;P ))