[General] Save/Load: The Next Approach

[Nestharus]

When I first began in save/load, the primary concern was the code size. This was because players had to copy the code and then paste it into the map later on. Another issue was that codes could only ever be up to 120 chars long (the max amount of chars a player can type into chat). Speed was only a secondary concern: it only needed to be fast enough to not cause a fps drop when the -save/-load commands are used.

With local saving (file i/o) now being a very viable option, the concern is no longer size, but rather speed. Using the max compression approach, save/load is only fast enough to handle around 240 chars. With local saving, 20,000-100,000 char codes could easily be achieved, meaning that the old approach is not fast enough. Furthermore, the save/load process is different. The encrypted data should not be sync'd as it will be bloated. The final data, the stuff used to create units etc, should be sync'd. This means that decryption is done locally. Furthermore, save/load should be done every time a change to a character occurs: get an item, get xp, etc. Also, various characters should be linked together on one profile so that a player can't keep old save codes w/o losing all of their other chars.

saving steps-
1. serialize the data into a stream of characters (used to be done with BigInt, now should be done using the old approach).

2. generate a checksum, key, or crc value for that data (use a 1 way hash algorithm or something that gives perhaps a 50-100 char key, generating a checksum will simply take way too long with a 10,000 digit number. A hashtable would also have to be used in order to manipulate that amount of data).

3. encrypt the data (scrambler can't be used as changing the base would take way too long. Use AES instead http://www.cs.bc.edu/~straubin/cs381-05/blockciphers/rijndael_ingles2004.swf)

4. write the data (120 chars per line, 12 lines per file)

loading init steps-
1. read the data (local)
2. decrypt the data (local)

upon char select, load-
1. validate the data (local)
2. interpret the data (local, break it up)
3. sync the data (compress into blocks of 32 bits)
4. implement the data (create hero, etc)


Essentially, 10 different resources need to be made to handle each of the above steps. More resources are required when you consider the substeps.

 

[baassee]

I guess this will be very useful for RPGs due to the amount of data most RPGs have to store that cannot fit in a normal series of code. However there's something that bothers me but cannot find the proper words at the moment to describe it.

 

[Nestharus]

Ok, I've been working on AES and this is what I think should be done for data validation and data encryption

password -> cipher 1, cipher 2
data, cipher 1 -> encrypted
data, cipher 2 -> key

You take a password and get 2 ciphers from that.

From here, the data is encrypted using cipher 1. A key is generated (like a checksum) using cipher 2. From here, you store the encrypted data + the key to the file.

decryption - decrypt the key, decrypt the data
validation -> password -> cipher 2, encrypt data using cipher 2, compare to key. It not equal to key, invalid data.

This ensures that the data is extremely secure and can't be manipulated ; D. On top of all of this, to ensure that the data and key can't be seen, a third cipher will be used to encrypt both of them together ^_^.

This is just my first idea for encryption atm. I don't know if the overhead of doing all of this every few seconds is too much : |. If it is, it'll have to be simplified, but doing all of the above is my goal.

edit
actually, I can simplify the above a bit

password -> cipher1, cipher2
data, cipher1 -> key
key, data -> encrypted

=)

edit
nvm, SHA512 or something should be used or the key =O.

 

[baassee]

I think it will be too much doing all this every few seconds. I'll rather do something every minute as minimum but I'd say max 2 times a minute or else I guess the wooden computers will fail before even they even opened the map.

 

[gorillabull]

when would anyone need to save 20,000 to 100,000 characters

 

[muzzel]

Also, various characters should be linked together on one profile so that a player can't keep old save codes w/o losing all of their other chars

pointless since players can just backup the old files

Also the encryption is useless, if someone wants to cheat a code he can just deprotect the map. Hacking codes is NEVER done by encrypting the code, deprotecting the map and editing it is much easier.

There is no protection against cheating heroes in orpgs, except for storing the code server sided using a hostbot. Accept that.

 

[Nestharus]

If they make backups, they lose their other heroes ; P. They could have 1 profile for each hero, but that'd be a pain :\.

Encryption discourages people. It takes less time to crack a simple code than it does to go through a map. I can crack a simple one by handle in about a minute >.>. There are some maps with simple codes, and in those maps, I gave myself 1 mil gold etc.

Anywho ;o

 

[muzzel]

They could have 1 profile for each hero, but that'd be a pain :\.

swapping a textfile before you start the map? Compared to losing a hero code that contains months of playing progress its not so much of a pain i guess.

It takes less time to crack a simple code than it does to go through a map.

No, adding a cheatpack to a map requires deprotection (automated deprotection takes few minutes, depends on the map) and adding a few lines to the map script (takes 2 minutes using mpq editor).
The result is a map that can be used to create any hero code you want.
People dont crack single codes, cheating in orpgs is done by editing a map and playing it (usually the cheaters dont make the maps, they just download it from some websites i prefer not to mention at this point).

I like your idea, just leave the AES part out.

 

[Nestharus]

I like your idea, just leave the AES part out.

It's all split up into dif things, so the AES etc is optional, just like it was with save/load w/ snippets.