Temple of The Roguelike Forums
Development => Programming => Topic started by: DaedricPrime on March 23, 2011, 10:51:31 PM
-
In my RL I would like to provide varying difficulty settings. The combination of most of these settings will form a "score modifier". When you die/retire/win your base score will be multiplied by the modifier for a "final score"
One of these options will be under what conditions you can save. The hardest will be only while quitting [while still alive] which also brings with it the concept that the save game is "deleted" when loaded ( aka Permadeath ).
However, since I've played other RLs with most of them permadeath by default/only-option, I am familiar with the temptation to "Cheat". Considering my game will provide options to not have to deal with permadeath, when you are actually playing a game "with permadeath set ON" I would prefer for it to be as hard as possible to do save scumming. (After all, YOU ASKED FOR IT IN THE FIRST PLACE )
I have a few ideas, but I was hoping people would share their ideas on ways to make save scumming as difficult/painful to do as possible. As I don't have a lot of resources, methods that rely heavily on storing data across a network connection aren't ideal for me. Mostly i assume there will have to be a combination of tricks to hide "key files" required to decrypt the save file.
Any other ideas/tips?
-
Give each character a unique identifier when created, and have a separate data file record which are alive or dead. If you try and load a dead char then you are either disallowed, or the game is modified to work inexorably against the player (ADOM does this in a fun way if it detects save-file hacking).
Overall though I'd say don't bother, it's up to the player how they want to play. If they want to give themselves a stupidly inflating score by cheating... well, that's their own weird problem.
-
if it can be done, people will do it. dont waste your time or energy on it. search rgrd, there are lots of threads on this topic. imo, there are some people who will always do it, and others that dont bother. its a waste of your time and energy
-
[EDIT] Nevermind.
-
In my eyes a savescummed RL becomes boring =/ permadeath is half of the RL appeal.
Playing powder, the "save scum" feature appeared, and I used it because there was my best character evah (not that it was any good, mind you). The fun factor disappeared.
I concur: don't bother. Unless it's for a public scoreboard.
-
First of all, hiding 'secret' files in windows directory, keys in windows registry is wrong - such programs should be considered as trojan\malware.
All other methods that don't involve network communication aren't reliable. Player can savescum not single savefile but entire game directory (as I usually do when i'm not sure which files are required for savegame).
Don't forget about running a game in a virtual machine and saving state of VM - it's overkill, but it works always, even if the game doesn't allow saving at all.
So savescumming shouldn't be prevented - it's up to player whether use it or not.
-
While I do really appreciate the feedback re: "Don't do it", my intention for my post was to solicit ideas for preventive measures. I'm fully aware of the impossibility of making anything impregnable, but that doesn't mean a little effort can't help diminish the problem in a significant way. My intention is not to slave away on some obscure quasi-DRM-like functionality, but I also believe that if I can spend a day or two to make permadeath more meaningful and worthwhile when it is chosen, I would like to try doing so.
While it is possible for people who want to cheat to go to drastic measures, my RL will already provide them a simple convenient method for save scumming (e.g. "Revert to Save Game" ) as a simple keyboard/menu command [for non-permadeath settings]while you are playing. So I'm not attempting to remove choice/playstyle from those who are accustomed to it -- I'm just trying to experiment with something different. { And ultimately, these are just plans at the moment, nothing's been implemented yet. }
[ The claim that hidden files or the mere existence of registry keys are criteria for a trojan/malware is simply hyperbole in my book. But I understand the position, and anything I do end up implementing won't be drastic, and would only apply for permadeath games. ]
Lastly, I don't know what rgrd is, so I still hope people will be still be interested in sharing ideas for preventing save scumming. The "database" suggestion is an interesting angle, and gave me some good ideas.
-
Lastly, I don't know what rgrd is
It's rec.games.roguelike.development. For centuries it has been the forum for roguelike developers.
-
You're combatting a problem that doesn't exist.
edit - particularly if you're adding savescum functionality as a feature of the game. Why prevent people from doing something indirectly that you've already allowed them to do directly? It makes no sense.
-
It's rec.games.roguelike.development. For centuries it has been the forum for roguelike developers.
Ah! Thank you! I know about the newsgroup, I just didn't associate the initialism to it.
You're combatting a problem that doesn't exist.
edit - particularly if you're adding savescum functionality as a feature of the game. Why prevent people from doing something indirectly that you've already allowed them to do directly? It makes no sense.
I have to disagree. I'm sorry you don't understand what I'm attempting to do, all I can say is it's the same thing as to why people put locks on school lockers, or why roguelikes will bother to delete the savegame after loading it in. I'm simply attempting to go a bit further (but not drastically so). The savescum functionality you refer to that I mentioned is not a conflict. As I alluded to, that functionality is only available for non-permadeath situations, and I only mentioned it specifically to show I'm not trying to take away work-flows for some people. I'm only attempting to see if some ideas can help make permadeath more meaningful and make cheating harder. I don't think I need to explain why a "traditional rpg" difficulty setting should/is different in substance to a roguelike/permadeath setting. It's not my intention to resurrect philosophical discussions on permadeath/etc that are already on rgrd, as has been explicitly pointed out by others.
That being said, thanks for the input! =) Between the suggestions here and a search in rgrd, I think I have plenty of ideas to consider.
-
Can you explain the assertion that making savescumming harder makes permadeath more meaningful? You've said it a couple times but I'm not getting it. We've already established that people who want to savescum will do it anyway.
e - After considering a little more, I do see a bit of a point. Making it harder to do may discourage a subset of the savescummers from cheating and instead play the game in a way that is actually tense and fun. I still don't see how it makes permadeath more meaningful but I realize now it's not a worthless exercise. Still, as others have said don't put too much effort into this aspect :P
-
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
-
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).
-
You're trying to keep someone from doing something because your game would be more fun for them if they didn't do it. It is already understood that meta-game editing is not the way that developers intended users to play the game, so I don't see a reason to protect players from themselves.
Mostly i assume there will have to be a combination of tricks to hide "key files" required to decrypt the save file.
If all you need is something to stop file tampering, use hashes of save files.
That won't stop save scumming, but encryption wouldn't either.
-
I agree with fenrir, no need to do it for a single player oriented game. I'd only consider it if scumming interferes with someone else's fun.
I put a little bit of thought into this. I was thinking I might allow the player to save online stats. In which case a scum save can interfere with anothers' fun.
If the player wants to use online stats I would host an internet server. The server would generate a per character SSL key. The character on death has the option to upload the character stamped with this key.
Several things would be tracked for the online save option:
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).
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).
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.
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.
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.
Hrmm. Maybe this would be overkill too. Just a few thoughts off the top of my head.
-
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.
-
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.
-
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. ;D
-
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.
-
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 ))