i'm asking for a more clever encoding algorithm to retrieving game stats which generates a shorter and more clear password

for example i have this information's to be saved via a short CODE

Health                    0 - 99
Armor                    0 - 99
Ammo                    0 - 999
Shells                     0 - 99
Rockets                  0 - 9
Weapon1                0 - 1 // picked or not (boolean)
Weapon2                0 - 1
Weapon3                0 - 1
Weapon4                0 - 1
Level                       1 - 3

what i did :

an inline example of above information's : 99 99 999 99 9 1111 3

the encoded result with base64 as String : OTkgOTkgOTk5IDk5IDkgMTExMSAz

the encoded result with base64 as Decimal : Y2PPp2MJ0ZcD (good but long yet)

what i know is to handly encoding some part of the code for example for boolean part, there is only 16 states, 0000 0001 0010 0011 ...etc

so it can be reduced to only 16, information could be reduced to: 99 99 999 99 9 16 3

then result will be still same : Y2PPp2MJEAM= (ogly and long)

i used this website for decoding and encoding

  • \$\begingroup\$ Why don't you just create a save file? Is this a web-based game? \$\endgroup\$
    – Philipp
    Jan 12, 2017 at 16:04
  • 1
    \$\begingroup\$ @Philipp i need a share able way for saving stats of the game, which comes as cheating feature in future \$\endgroup\$
    – payam_sbr
    Jan 12, 2017 at 16:09
  • \$\begingroup\$ If you want to do it just for nostalgia and not for any technical reasons, you could fake it: Store the gamestate in your server-sided database, but give the player a "passcode" which is just the savegame-ID in the database. \$\endgroup\$
    – Philipp
    Jan 12, 2017 at 16:24
  • 1
    \$\begingroup\$ Related, possible duplicate: gamedev.stackexchange.com/questions/104562/… \$\endgroup\$
    – user1430
    Jan 12, 2017 at 16:28

2 Answers 2


First, consider the alternatives. When this is a game running as an executable application, you should be able to create a savegame. When this is a web-based game where you don't have access to the user's filesystem, you could store the information in a database on the server or in the user's localstorage.

But if you really want a passcode solution, you need to look at how many bits of information you really need. n bits can store 2^n different values. So the least number of bits you need to represent your game state is:

Variable Range     Required bits

Health   0 - 99    7
Armor    0 - 99    7
Ammo     0 - 999   10
Shells   0 - 99    7
Rockets  0 - 9     4
Weapon1  0 - 1     1
Weapon2  0 - 1     1
Weapon3  0 - 1     1
Weapon4  0 - 1     1
Level    1 - 3     2

Sum               41

41 bits encoded with base64 is just 7 characters. If you find base64 ugly, you can encode it using less characters, but then you will need longer passcodes. You could, for example, use hexadecimal, but then you will need at least 11 characters (might want to round that up to 12 by adding an additional character as checksum to prevent players from guessing passcodes).

For more information about how to get and set individual bits of data in byte-oriented data-types, look up the bit-operators of your programming language of choice, namely bitwise shift, binary-and and binary-or.

  • 2
    \$\begingroup\$ you can compress this down to 37 bits using arithmetic encoding \$\endgroup\$ Jan 12, 2017 at 17:17
  • \$\begingroup\$ so there is no exact way to reducing Password length when we have using only a-z A-Z 0-9 (base64) characters, thank you it helps,and now when i'm thinking around old games, i'm guessing that they shall not stored for example Health with range of 0-100, but shorter chunks, like 10 - 20 - 30 ..., rounded numbers and same techniques to compressing their informations \$\endgroup\$
    – payam_sbr
    Jan 12, 2017 at 17:23
  • \$\begingroup\$ What nostalgic game saves that kind of data using this technique (short code)? I remember those save codes only remembering what level / stage you achieved, not specific game state variables. \$\endgroup\$ Jan 17, 2017 at 18:38
  • \$\begingroup\$ @Doug.McFarlane That depends on the game. Some opted for longer passcodes in order to store a bit of game state. NES Meteroid, for example, saved not just progress but also how many missiles and how much energy the player had left. Some Mega Man games didn't just store the cleared levels but also the number of extra lives and e-tanks (they traditionally had their pictographic passcodes, but that's just a different method of visualization). \$\endgroup\$
    – Philipp
    Jan 17, 2017 at 19:46
  • 1
    \$\begingroup\$ Ha, that TasVideos.Org link resembles manually entering QR Codes. QR Codes could work for encoding game save data too, but wouldn't be very nostalgic. Or instead of only binary states, you could have four states using RGB and off for a more compressed 'QR Code'. Fun stuff. \$\endgroup\$ Jan 17, 2017 at 20:42

I'm not going to suggest a way to re-hash your hash in a shorter fashion. I'll suggest an alternative.

What you could do is extract all the possibilities, let's put them in the vector SaveHashes.

Then come up with a list of random names, such as [Potato, Fire, Cloud, Mug, Wig], and a similar list of random adjectives, such as [Blue, Light, Frowning, French].

You see me coming, right?

Then for each of the hashes in SaveHashes, generate a unique random 'new hash' by combining an adjective with a name.

Put that in an associative array, and your good to go! When a player enters "BlueMug" as their password, fetch the associated 'real' password Y2PPp2MJEAM=, and from there, reset the stats.

This has the advantage of making password easy to remember, and bring a smile on the face of your players, because the concept of a HairyPotato or DancingBanana is funny. You could even cheat as a game developer and add 'artificial' save games that would give you super-powers not available to normal players.

The only drawback of this technique is that it's potentially going to take up a lot of disk space.

This alternative is based on comments from @Philipp and @RatchetFreak (thanks!).

There is a way to reduce quantity of data used.

As calculated by @Philipp, you need 37 bits to encode the information.

You find a list of 2048 English words, and you link each of these words to a unique 11 bits value (2^11 = 2048).

To generate the 'password', you inspect the bits of the compressed data that you have, left-pad with zeros, split the bit string in four 11 bits parts, and find the word associated with each of these. This will generate a four words 'password'.

You can regenerate the savegame data by simply doing the steps in reverse order.

  • 2
    \$\begingroup\$ Extension of this idea: When you use four words from a 2000 word dictionary, you don't need the hashtable anymore because you can cram the information into the passcode itself. correct horse battery staple has 44 bits of information. That's 3 more the OP needs. \$\endgroup\$
    – Philipp
    Jan 12, 2017 at 16:29
  • \$\begingroup\$ @Philipp I guess I don't have a clue about what bits entropy is, so I have no clue on how one would achieve this :P \$\endgroup\$
    – Vaillancourt
    Jan 12, 2017 at 16:42
  • \$\begingroup\$ that's a solution for getting ride of the ugly codes like "Y2PPp2MJEAM=" but the number of names to be stored with its hash codes, will be 99 * 99 * 999 * 99 * 9 * 2 * 2 * 2 * 2 * 3, a huge range of possibilities \$\endgroup\$
    – payam_sbr
    Jan 12, 2017 at 17:09
  • 1
    \$\begingroup\$ @payamsbr that's "only" 37 bits with a 2048 word dictionary that's a bit more than 3 words \$\endgroup\$ Jan 12, 2017 at 17:17
  • 1
    \$\begingroup\$ @AlexandreVaillancourt Yes, that's what I mean. \$\endgroup\$
    – Philipp
    Jan 13, 2017 at 14:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .