[Spell] How flexible is a save/load system?

[Apheraz Lucent]

What would I need to save/load with the system is player's name, and about 30 up to 60 true/false Booleans, for an achievement system.

Is it even possible to flex a system that much?
Also, which system is the best for the job? CodeGen?

Thanks in forward!

 

[Ceday]

Try combining your booleans into an integer variable, for example assume there are 10 booleans

set Integer = 1001100001

boolean 10, 7, 6 and 1 are true, others false.You can even combine more booleans in a single integer variable by using a binary system(1 integer for 32 boolean)

 

[Zwiebelchen]

Use Nestharus Save/Load /w snippets. It has great security features and a very good compression.

The amount of stuff I managed to press into a single code with that is absurd.


Your code will probably end up having 10-12 characters.

 

[Ardenian]

In theory, you can store unlimited data in a code of a static number.

There are multiple ways to reduce the length manually. You can assign numbers for 'events' ( events = code combinations). 100 different numbers can be reduced to 3 characters then, for example. Writing efficiency is majorly the problem here.

So, taking Ceday's example, if you have 0000000000, then you add in your code 001 and 0000000001 would be 002 and so on. However you end up having a lot of combinations you never want to write manually.

The systems Zwiebelchen and Ceday suggest are probably better in that case.

 

[Zwiebelchen]

In theory, you can store unlimited data in a code of a static number.

There are multiple ways to reduce the length manually. You can assign numbers for 'events' ( events = code combinations). 100 different numbers can be reduced to 3 characters then, for example. Writing efficiency is majorly the problem here.

So, taking Ceday's example, if you have 0000000000, then you add in your code 001 and 0000000001 would be 002 and so on. However you end up having a lot of combinations you never want to write manually.

The systems Zwiebelchen and Ceday suggest are probably better in that case.

What you describe is called a "dictionary".

You basicly build sets of mutual-exclusive data that can under no circumstance happen together to give them the same id.

For example, if your character can only wear 1 item per item category, it makes no sense to index them by the maximum number of items in your map. Instead, you only consider the maximum number of items of each category.
For example, if there are 100 items total in your map, but only 10 weapons and you can have only 1 weapon with you at the same time, you can store the weapon item as a max-10 in your code instead of a max-100.


Also, the charset allows a huge amount of compression aswell. Using uppercase and lowercase vs. uppercase letters only will increase your base-36 system to base-62.

 

[Apheraz Lucent]

Well the code is supposed to store a player's name (so that one can only save and load the code he or she played so far), and nothing else but a set of achievements, which are marked by True or False (player got them or not, basically).

But, since there will probably be about 50 achievements in the end, the number of combinations will be too high to write out manually (For an example, a player can unlock achs 5, 24, 46 and 49 so far). I am not familiar too much with Jass unfortunately, so that's why I asked for help
Can it be done automatically by a script? Remember there's only two possible variations on each ach, which is true and false (got it already or didn't).

 

[Ardenian]

You don't have to store the actual name, You can save data related to it. How much characters it has, its first character and its last and so on. More complicated =more safety and you reduce the possibility of players exchanging the code, especially if they do not know your choice what is saved in the code.

I don't know professional ways, sadly.
However, you can replace certain data. Example: If Ach 1 and 2 equal false, not obtained, then do not create a 00, but a X, for example.
If any two following achievements are false, then replace the two 0 with a X.
If any three following achievements are false, then replace the three 0 with a Y.
If three following achievements are obfained, then replace 111 with A.
If two A follow each other, then replace it with Q, if a X and a Y follow each other, replace them with W.

This kind of coding, that would be my approach.

 

[Apheraz Lucent]

Aaaaaah, I get it now. Took me a while lol.

By using (T)rue and (F)alse booleans, I can do combos, where TT would become Q, TF would be W, FF would be E and FT would be R. Then I can make combos for Q W E R also, with each having other's letters. That shortens the code more I process it, awesome
And for 50 achs, the code is as big as 12 letters
Now I just gotta figure a way to crypt player names.

 

[Xonok]

Nestharus' system does that automatically.
Basically you give it an alphabet, which works essentially like the base for a number system. If it has 60 characters, the code size that you can encode is multiplied by 60 for every next character.

About the actual encoding, you pass it a number that you want to encode and how big it could be at most. The size parameter essentially says how many options of the code you want to allocate to this piece of data.
It's hard to explain properly how it works, but it's inherently very powerful.

 

[Dr Super Good]

In your code integrity check you append the hash of the player name. Such an integrity check value can be made by hashing the string of the code up to that point. When loading if the combination of the new integrity check and the hash of the player name applied to it do not match the one in the code then the code is corrupt so fails. This allows you to combine both error checking and name protection without having to store any information about the player name. Further more string hashes are not case sensitive, just like BattleNet names so you do not have problems with codes failing to work if their account case is entered non identically.

 

[Apheraz Lucent]

That would be awesome if dear Nes could document his code properly for us who don't understand such systems .-.

 

[Nestharus]

Save/Load with Snippets is documented very well : ). Look at the map before you judge : p. I think it includes 2-3 save/load system templates, ~8 dictionary templates, and maybe 15 tutorials as well as a bunch of systems to help you out.

Also, the player name does not need to be stored in the code in order for it to be unique to that player. There is something called encryption. When you encrypt something, you use a key to lock it. This key can be the player's name. You have to use the same key to unlock it. This means that if someone other than the original player attempts to load the code, they will get nothing but gibberish.

Also, your code with just the values will be 10 characters. With all security and 100 billion unique legality values, it will be 12 characters (11-13 after encryption because of how Scrambler works). Pretty good, no? : P.

max(log(2^60)/log(70)) = 10 (length of code)
max(log(100,000,000,000)/log(70)) = 2.

Scrambler mixes up the number in different number systems. This means that fractions of digits get moved around. This can split digits up into several digits or combine fractions that were apart into single digits. This is where we get the range of 11-13. AES also mixes up the numbers in fractions, but it doesn't change the length. AES encrypts in blocks of 128 bits, so it will give a minimum code of 21 characters.

 

[Dr Super Good]

Also, the player name does not need to be stored in the code in order for it to be unique to that player. There is something called encryption. When you encrypt something, you use a key to lock it. This key can be the player's name. You have to use the same key to unlock it. This means that if someone other than the original player attempts to load the code, they will get nothing but gibberish.

Also works if you apply it to the code security hash since then you may get sense out but it will fail the integrity check.

Due to the nature of security hashes they do not need to be encrypted with the rest of the code since they already appear as a sequence of random bits (cannot tell difference between the hash and the encrypted data). As such one can use the security hash to compute a dynamic encryption key. The advantage of this is that it means a single bit change will change the security hash and the encryption key so all bits of the code will change. This principle was used in my Imperial Bank system for SC2.