On Topic
While I've never implemented a password system, I do have a few suggestions as to how to build one.
The first one is to implement some sort of bit packing. There are a lot of cases where you don't need a full eight bits to store data. Even if you have that data in bytes for easy access during gameplay, every little bit matters when trying to keep passwords a reasonable length.
As you mention that this is for a generic framework, try to be flexible with the format of the packed data. A preset combination, like this...
slobu wrote:6 8-bit (0-255) variables
6 4-bit (0-15) variables
5 3-bit (0-7) variables
9 1-bit (true/false) variables
...is sure to be exactly the wrong option for some game or programmer at some point. An ideal solution would be for it to handle arbitrary bit-strings without preconceived notions as to what the bits mean. Of course, some bit packng utility routines would be helpful, so that one doesn't have to write their own every time. But the more generic, the better.
As for password length and symbol set size, again, I think the more generic the better. Some games need to store lots of data (RPGs), others, not so much (arcade games). Therefore, password length is highly dictated by the game's requirements. Basically, an N length bit-string is stored in an M length password. The (linear) relationship between M and N is dictated by the size of the symbol set (plus overhead, if any).
For the size of the symbol set, there are really two broad methods. The simple choice is to choose some 2**n value (such as 16, 32, or 64). This has the advantage of being easy to translate between the password and the binary data. Using 16 symbols may be convenient for the developer as it allows for plain hex. (Whether used in the final product, or only in dev builds.)
The other method (as mentioned by Bregalad), is an arbitrary base-N encoding. This allows the developer to choose any size of symbol set they desire. This can be used to tune the size of the set (such as 26 for plain alphabetic, ~36 for alphanumeric, 46/48 for kana, etc) or password length (using 16 symbols in a 4 by 4 grid, for example). The downside to this is that the encoding and decoding are more complex. However, as saving and loading aren't timing critical, this isn't much of an issue.
As for the actual symbols themselves, I think that should be left up to the developer. The target language dictates which symbols will be comprehensible or comfortable for the player. The password system should allow for localization, the same as any other part of the game.
Finally, there is the matter of checking and or encrypting. The first thing to consider is that either will add to the complexity of the password system and make the password longer. Neither of which is desirable. That said, some sort of checking is basically required for a good user experience. A typo should lead to an error message, not some random (and possibly broken) combination of values.
Encryption is largely useless in my opinion. It's not as though you're going to make a system that's unbreakable, so it's mostly a waste of dev and CPU time. The bit spreading effect of a good hash may be aesthetically desirable (though that is a matter of opinion, and it may sometimes be undesirable, for instance when using straight hex in a debug build). Either way, I wouldn't get too carried away. Use something simple or nothing at all.
It probably sounds like I've waffled a lot and answered basically "It depends." This is sorta' true. When one asks "What is the best?", that's usually the answer. However, don't take this to mean that you can can't or shouldn't implement a concrete solution. I think the best system would have a lot of flexibility and allow the developer to set (compile time) options to tune the system for their specific needs.
For instance, I might have to save 27 bits of a data. I want to use 16 symbols (0-F) for dev builds (so it's hackable), but 26 (A-Z) for production builds (to reduce password length). Being able to set this all up with a few defines would be great. Of course, there has to be some limits, but offering a reasonable range should be doable.
All of this assumes you want to build a generic framework. If you're doing a one-off for a specific project, it might be easier to just build what you need. Then again, it might still be worthwhile to build something flexible. (After all, you never know exactly what you need in the beginning.)
Slightly Off Topic
The idea to just use the Dpad directly to enter a password has some merit. As discussed above, it's liable to lead to long password lengths unless the number of bits stored is quite small, but the core idea is sound. As I see it, the key advantage isn't (Zack's motivating itch) the elimination of the need to move one's view between the screen and the saved password (paper/phone/etc), but economy of data entry.
When the user enters a password in a traditional password system, they actually provide the system with more bits of information than the system utilizes. Each character of the password requires them to hit some number of Dpad directions plus some an action button. As stated in the original proposal, each Dpad press actually provides two bits of data, most of this data is ultimately unused and mapped to a smaller number of bits. This alternative utilizes all of these bits.
Using all eight buttons of the controller would allow for 3 bits to be gathered per input. Of course, this means that no buttons can be utilized to edit the entry if an error is made. If the password is short, such a simple scheme could work. (As a bonus, you could also check for the Konami code.) If you reserve one button for backspace, you can get ~2.8 bits per input. If an additional button is reserved for entry confirmation, this is reduced to ~2.6 bits. Encoding and decoding these fractional bits is the same as the base-N password decoding. Whether the resulting password lengths would be unwieldy depends on how many bits one needs to store.
Alternatively, one could adopt a
chording scheme for even more efficient input. A simple system using just A, B, and the Dpad, would provide ~3.3 bits per entry and still reserve start and select for meta functions. This has two advantages. The first is that the ten total combinations map to the 10 decimal digits, allowing one to reuse existing number base conversion code. The second is that these sorts of button combinations are already second nature to most gamers. (I think this would be an especially nice fit for a fighting game.) More complex chording schemes could be even more efficient, but the added complexity may outweigh the benifits.
Way Off Topic
In regards to alternatives such as various non-volatile memories, I have some ideas, but I'll not derail the thread further.