Designing a password system for video games
This is a translation of a Dutch article. Read the original here.
Imagine: it's 2002, and you are a video game developer. You are designing a game for the Game Boy Advance, but your publisher considers it too expensive to produce cartridges that include EEPROM, Flash memory or SRAM. Not unusual. And there is a common solution: a password system. You regularly give the player a password that he or she can input when picking up the game again to continue with retained progress. This way, it is the player's responsibility to save progress and no expensive components have to be included.
But wait: a password system isn't something to just throw in. It has the potential to work well, but it can also be annoying in many ways. This is a guide to creating a good password system.
Do not neglect the responsibility of implementing a password system.
If you your game won't get a cartridge that can save progress, do make a password system. Alright, it's not that necessary when you're making something like Tetris (1989), where the only thing to be retained between plays are high scores; a player can keep track of those anyway, of course. But if you are dealing with several levels or a longer story, don't be like the developers of Astérix & Obélix for Game Boy (1995), that did not include any way to resume play at a later time for a game that takes over 45 minutes to beat—besides an obscure cheat code that allows access to a level select, which was only intended for the developers themselves, if you ask me. No, when the game was rereleased for Game Boy Color in 1999, they did good to add not only colour but also a password system.
Make sure that the chance of accidentally inputting a working password is slim.
If a player is entering random passwords for half an hour and eventually finds a working one, that's no problem; as long as you're having fun, right? But if the player makes a mistake while inputting a password this should not yield another working password. If you work with static passwords, for example one password per level, this is easy: just pick the passwords so that they all differ from all other passwords in multiple characters.
But if your password needs to store more than just what level you got to, such as data about collectables, you need a more complicated system. It is bad if by entering the wrong symbol for one character you suddenly have 36 lives instead of 4. As a solution, implement a checksum, somewhere in the password. Metroid (1986), one of the most popular games that use passwords, has as last 8 bits of the passwords the sum of the other 136 bits. If the player inputs one character incorrectly the sum won't add up anymore, and the password won't be accepted.
Do not include vowels as symbols to avoid unfortunate passwords.
The most frequently used source of symbols to create passwords out of is the English alphabet. However, using the entire alphabet can have unintended consequences. Two especially saucy examples: in Metroid, mentioned earlier, ENGAGE RIDLEY MOTHER FUCKER is a working password (Ridley is a boss from Metroid). Well, working…? The checksum coincidentally matches, but depending on what platform you're playing on, inserting this password has various negative consequences. Apparently an old version of the 3DS-firmware could even be bricked completely by using it!
In the NES version of Metal Gear (1988) inputting FUCKM E1111 11111 11111 11111 transports you to the final boss without any equipment. In the European localisation of Metal Gear, that was released later, the vowels were exchanged for other characters (such as # and ★), and this is what I would suggest doing, if you do need as many symbols. Because while this kind of quirky passwords are funny, you do run the risk that a password that can be obtained through normal gameplay cruelly curses a young player.
Don't use multiple symbols that are similar to each other.
You know the infamous pair: lowercase l and uppercase I. In many fonts these are hardly distinguishable. Another problematic case concerns the trio 0, O and D. If you do want to use multiple of these symbols, at least make sure that they are easily distinguishable in the game. If we look at Metroid once more, we see that the capital I is displayed including horizontal bars, and that for the lowercase l the cursive version is used.
This doesn't solve the problem, however, because you can count on it that the player will use their own handwriting in noting the passwords, in which the letters might be very similar again. As you might have discovered while playing Rayman on GBC (2000), for some letters it is hard to tell whether you meant an uppercase or lowercase letter (C vs c, X vs x, S vs s…). So if you can think of alternative symbols to use, can do with less bits, or could make the password a bit longer: please just leave the confusing symbols out. One game that is very careful in this regard is Atlantis: The Lost Empire for GBA (2001). This game uses a proper subset of the union of the capital alphabet and the digits, and leaves out, for example, 0, 1, 2, 5 and 8.
Do not temporarily give access to the latest password.
One of the biggest disadvantages of a password system is that noting down a password takes the player out of the game. Although the chance is high that a player will want to note down a newly acquired password as quickly as possible in case something goes wrong, it is a good idea to give the player access to the password at all times. In Finding Nemo: The Continuing Adventures (2004), for instance, the current password is always visible on the world map. This means that you can note down the password when you stop playing, instead of having to do it after every level beaten. Rayman, mentioned earlier, is nice enough to give you the latest password again when you game over.
In Snow White and the Seven Dwars (2001), contrarily, you get to see each password just once; if you accidentally click it away you'll just have to play on until you'll get another, because if you go back to the main menu the password screen is empty. Automatically inputting the latest password there is the least you can do, but please also display the password on the pause screen, for instance, so that players will know that they don't have to be afraid they'll miss it.
This tip can be interpreted in another way, however. What you obviously should never do is displaying a password and then automatically removing it after x seconds. This is what happens in E.T. The Extra-Terrestrial (2001). Is the challenge getting your notes as quickly as possible to copy the password before it disappears?!?
Keep the password at a game over
In addition to the tip above, one simple way to improve the game experience: if you have a game with game overs, ensure that a player that decides to play on does not have to go through a lot of effort to be able to continue. Infogrames' games (for example les Schtroumpfs, 1993) do this right: to play the game you simply press Start or A. There is a separate option for inserting a password. If you inserted a password previously it stays stored, so that after a game over you only have to press A. This also mostly solves the problem presented above!
Alternatively, you might decide to give the option to continue play right away after a game over, without sending the player back to the title screen. Lilo & Stitch (2002) and The SpongeBob Squarepants Movie (2004) do this, for example. Fortunately almost all games implement either of these two options, or a reasonable alternative. The earlier mentioned E.T. does mess this up.
Implement a reasonable way to enter the passwords
A Game Boy of course doesn't feature a keyboard. But it is possible to make a virtual keyboard, and that greatly speeds up filling in passwords. In the earlier mentioned Atlantis inserting passwords is annoyingly tedious, because there is a sizable amount of symbols and to select the right symbol you can only press up and down. To make things worse it is not even possible to hold up or down. So you better tactically decide which way to go around the alphabet, if you don't want to press down 20 times.
If you do implement a virtual keyboard, it is strongly advisable to place the symbols in a grid. Follow the example set by Monsters, inc. (2001), for example. Not that set by Donald Duck "AdV@ncE"!*# (2001), where, to illustrate, in the lower image you would expect that if you press down while on 'M' you would go to 'Z'. But no, you'll be selecting '0' instead.
Monsters, inc.: below M is Z
Donald Duck "AdV@ncE"!*#: below M is 0
Remarkably, this is an area in which E.T. does something innovative that actually works quite well: the buttons on the Game Boy Advance are used for symbols. This might be somewhat confusing at first, but it does make inserting passwords rather efficient!
Do not use pictures as symbols
If you expect young children to play your game, maybe you would like to take into account that maybe they can't yet read. Many games that target young children use pictures instead of letters in its passwords. Personally I don't get this at all! Are children supposed to memorise the passwords? Because otherwise it will still have to be noted down in some way. And children aren't known to recognisably copy portraits. Thus, in my sister's notes, a password like the one below looked liked cat cat shoes man (Barbie in the 12 Dancing Princesses, 2006), where she did have to write a lot for. The only advantage of a system like this that I can think of is that in case the player writes one or two characters unclearly, the password will perhaps still be recognisable, which is not the case when using separate letters.
Yet I advise against using such a system: it is often confusing. I never watched SpongeBob myself, so while playing The SpongeBob Squarepants Movie I had to make up descriptions for the characters, that I would later be able to connect to the images, because besides Patrick and the sponge himself I didn't know any of the names. Of course something you should never do is use multiple characters that are very similar. Very nice that the colour version of Astérix & Obélix features a password system, but remind me what symbol I meant to refer to with 'meat'??
If you are too afraid that your players will have trouble with the letters from the alphabet, use symbols that are easily copied and recognisable. A game that succeeds in this is Tarzan for GBC (1999).
I hope you learnt something by reading this article! But I can imagine that you lack inspiration regarding the most important thing about a password system: determining the passwords themselves. This should of course happen in such a way that for each situation the password is unique, so that it can be decoded when the player enters it on the next play. And you don't want it to be so simple that entering a wrong character still yields a working password.
A game that has a fairly simple yet adequately robust password system is Ice Age (2001). I actually decoded this password system and know completely how it works. If you're curious, watch my video about it!