Encrypting memory

[Dagger]

I think data in memory must be encrypted in NSS4. Otherwise, cheating is possible with a memory editor as I just told in NSS3 forums.

[statto]

Well there are other simpler ways of doing it too.

For instance, in game checksums. When the game loads, take a tally of all the skills and maybe the money. If the skills don't account correctly then the game won't save properly, for instance, but this takes diligence on the part of the programmer and the hope that hackers don't figure out the checksum memory databit.

[Fry Crayola]

Arguably, it's not in the interests of Si to prevent cheating in this way. After all, if people want to cheat, they can do so.

Unfortunately (or indeed, fortunately) there's a very competitive community here, so integrity is a good thing. A checksum will solve save game editing, but not in-game memory editing. Encryption can slow the game down, depending on how it's carried out.

[statto]

I would argue with Fry Crayola as well, but with prizes such as Goal of the Month being given out, and numerous stories being written about individuals' careers, cheating should be considered.

However, I merely stated that if you have a checksum when the game is loaded, and a checksum when the game is saved (which includes all the points added), and you don't disclose the variable, you can avoid this problem by corrupting the save file for the user not to use.

For instance:
I load my game. I have say 30 overall skill points.

I gain a skill point in game. I now have 30 + 1 skill points. Game keeps track of 'natural increases'.

I cheat. I now have 60 skill points.

Game checks to see if first variable (30) + natural increases (1) = 60. It doesn't, so the game does not permit the game to be saved, or saves the game in an unloadable format.

Unfortunately it would be very easy to add a random increase here or there in coding and unintentionally corrupt save files, so there is a downside if this type of thing needs to be dealt with. Also, if the user finds out where these values are stored they could manually change them using the same program. If there is a simpler solution than encrypting memory, and a simpler solution than what I have just described, then it might be worthwhile, but for now it's simply an interesting debate.

[Fry Crayola]

I think Si already uses a checksum in the save/load code. Dagger appears to be specifically getting at those that use real-time memory editing.

[statto]

I understand that... I was talking about in game checksums.

[Dagger]

Chekcsum can cause some errors and it is not so possible to calculate the maximum amount of increase.
Encriypting just players Skills, energy, money and value won't cause any slow downs.

[Fry Crayola]

I understand that... I was talking about in game checksums.

Ah. I misread.

Drat and blast, and so forth.

[adam_the_scouser]

Anybody who cheats is just lying to themselves and wasting their time doing nothing!!!

[Marc Vaughan]

I'd personally suggest avoiding 'corrupting' save games or preventing saving if someone cheats ... simply put some people enjoy cheating and so preventing them from doing so might mean they don't bother playing the game (which will in turn reduce the revenue Si recieves and possibly prevent him from making future versions).

With FM I don't encourage 'save game editors' or support them, but for this reason don't actively encrypt things to prevent them being created.

(I'd err on the side of putting a 'Cheat' moniker somewhere on the game screen to show that the user has cheated and prevent boasting screenshots, but nothing more than that)

[statto]

Hey Marc,

I can tell you that the NSS3 save game file is already easily corrupted, so no save game editors can exist. The 'Cheat' thing isn't a bad idea as this community is competitive (Goal of the Month, stories, etc), and we'd like to keep it so. In any case Si has the final word.