Best Password System

Best Password System
by slobu on 2012-02-25 (#90515)

So, I'd like to come up with a password system that stores 8-bit values. It should involve the least writing/inputting by the end user.

I thought I was onto something with using 99 characters plus 3 "accents" (none, line above letter, line below letter)

The accents would denominate the hundreds place so:
none = 0
underline = 100
line above = 200

and the characters 0-99 would represent that numerical value.

Okay, so I guess that would be 0-299 for each place in the password. The player could press up-down to select a letter. Left-right to traverse the place in the password and A button to toggle accent. With a button press the first place to the left would back out of the password entry screen and the last place to the right would confirm password entry.

Any better method you can think of?

by Zack S on 2012-02-25 (#90519)

Wouldn't that mean the user has to scroll through up to 255 characters for each byte you have stored in your password?

Have you considered using 16 symbols and have the user enter 2 symbols for each byte of your password. Basically you'd be using hexadecimal notation, but you could use different symbols than 0-f to make it more passwordish.

You could even consider dropping down to just 4 symbols and have 4 symbols per byte. They'd have to enter more symbols, but each symbol would be easier to select. Plus you could use shapes or icons instead of alphanumeric characters.

by Kasumi on 2012-02-25 (#90521)

I'd use fewer than 99 symbols for sure, regardless of underlining or whatever.

What I'd do is ensure that maybe every other character is a vowel, and then pick consonants where you wouldn't get lewd passwords (FUKU for instance).

FKJLEM

Is probably tougher to remember than something you can pronounce like

RIKUME

This might even mean the password ends up longer since there aren't even 16 vowels for what Zack recommended, but they should be easier to just remember.

Edit: Also keep in mind, you don't NEED to store a value of exactly 256 in a single character in the password.

A, E, I, U allows for two bits, so a string of four of those letters gives you a byte. If you choose 16 consonants, then each of those gives you 4 bits.

Two consonants or a consonant and two vowels gives you a byte, and the player only has 20 characters to choose from.

You could even use this system for basic error checking.

Say A = 00 and B = 0000

BABA
and
ABAB
and
ABBA
would obviously all give the same byte stream, but you could check which parts of the password are consonants and vowels as well and reject the password as a "guess".

Also, some things don't need a whole byte. For instance if you have 8 worlds, but they can't be beaten out of order you only need 3 bits for that.

by 3gengames on 2012-02-25 (#90523)

SRAM.

by bunnyboy on 2012-02-25 (#90524)

Kasumi wrote:
What I'd do is ensure that maybe every other character is a vowel, and then pick consonants where you wouldn't get lewd passwords (FUKU for instance).

I like that!

What I have heard from lots of Battle Kid players is they just use a cell phone to take a photo of the screen instead of writing or remembering the password. So having something that is more readable in a fuzzy pict would be more important, and small things like accents could be missed. Password entry would then be a better thing to optimize than the password itself.

However having the separate button for accent would cut down on the scrolling through letters. Having a grid instead of just a line would do the same too.

by 3gengames on 2012-02-25 (#90525)

Bunny, I don't know about what you think of it, but Sivak won't make a 2 pixel wide font, why don't you force him to? That'd probably help writing down passwords as 1 pixel wide fonts aren't used by anybody who' a quality game designer. That probably would help people write down the password as it'd actually be legible.

by bunnyboy on 2012-02-25 (#90532)

Other than a couple of the letters (which were fixed long ago) I haven't seen any complaints about the font, so I won't be forcing him to do anything

by tepples on 2012-02-25 (#90534)

PROTIP: If you have CHR RAM, you can afford to display the password with 16x16 pixel glyphs.

Anyway, a long time ago I made a demo of password entry, scrambling, and descrambling. The alphabet is 32 characters (thus 5 bits per character), the password is 8 characters long, and eight of the 40 bits are used as check digits and should be zero if a password was descrambled correctly.

Case Study: Simon's Quest
by Bisqwit on 2012-02-26 (#90549)

Case study:

Simon's quest (USA) has a password of length of 16 characters, with a 32-character alphabet.

The password encodes 16 bits of item on/off flags, 8 bits of item counters, 8 bits of day counter, 2 bits of crystal level, 3 bits of weapon level, 3 bits of player level, 8 bits of crypting specification, and 16 bits of checksum, for a total of 16 bits remaining for redundancy (they must be zero).
In addition, some of those levels / counters have a maximum value, e.g. a weapon level 4 is permitted but weapon level 6 is not.

The crypting specification has 4 bits of "xor" and 4 bits of "add". The "xor" is an index to a hardcoded table of per-byte xorring constants, and the "add" value is internally created 0..4 and depends entirely on the xorring value (despite larger and independent values supported in decoding). Because 0..31 + 0..4 may produce values in 0..35 range, the alphabet actually has 36 characters. The last 4 characters are synonymous to the first 4. In effect, though there are 256 distinct possible ways to crypt the same password, only 16 are generated by the game.

However, when they ported the game to PAL systems (for international English release), they had realized that there is at least a theoretical possibility for accidentally obscene passwords in the game. It was highly theoretical, because I have calculated it and found out that there are actually only about 90 passwords, total, that consist entirely of English words, and most of those cannot even be generated by the game (because of the rigged add-generation). One of them is “PORN VOLT DEAD WHAT”, and you can see another in the screenshot above.

So they removed all the vowels and some of the most common consonants.

The password generator engine was kept absolutely identical to the NTSC version; only the font was changed. If you enter the password by tactile & aural feedback only, you can enter the same password just fine in both versions.
Removing the vowels worked perfectly in eliminating any chance for obscene passwords. Well, unless you allow L337 spelling, in which case you might get something like in the above screenshot. Not very obscene, though. (And the game never can generate the above password, though it successfully decodes it.)

The large 16-bit checksum in this game works very well in ensuring that one does not easily stumble upon valid passwords by chance. In addition, even if you manage to match the checksum, there are a number of other things that may go wrong: You may have specified an out-of-range value in one of the fields. For example, the player level is encoded in 8 bits in the password, but its limits are 0-6 (and thus checked).

Internally, the password encoding & decoding process works like this:
To encode:
1. Poke the game data in 7 bytes of a 10-byte array (each byte 8 bits)
2. Place the checksum in the array (it occupies 2 bytes of those 10). The checksum is simply a sum of preceding bytes.
3. Decide the xor & add values, and place them in the array (it occupies 1 byte of those 10).
4. Convert the password from 8 bits per byte into 5 bits per byte. This means that 80 bits gets stored in 16 bytes.
5. Crypt the first 14 bytes of the password according to the xor&add values.
To decode:
1. Read the last 8 bits of the password (from the last two characters containing 10 bits of data), to determine how the password was crypted.
2. Decrypt the password.
3. Convert the password into 8 bits per byte (length decreases from 16 to 10).
4. Verify checksum.
5. Read the data from the password, and verify that they are within limits.

Conclusion: Simon's Quest password system was very well designed, compressing the necessary data (which did not feel like a small amount) into concise passwords that could actually be remembered.
It was also extremely cracking resistant.

It did not however save all of the game's data.
- Heart counter and experience level were zeroed. Justifiable: The same happens on gameover.
- Hours and minutes are reset to 12:00 pm. Minor inconvenience.
- Player's location was reset to the first town. Though the password has enough spare room in it for the player's location (I've tested successfully adding it), there are difficulties in restoring the position exactly. In some places, Simon might spawn in a location with no way out (for example, water-breakable platforms in ceiling, where Simon cannot throw bottles, or cornered by tough enemies). If the password is generated next to the ferryman, Simon is spawned above the lake with no boat under him, instantly drowning him.

More case studies
by Bisqwit on 2012-02-26 (#90551)

Here are samples of some other password generators.

Metroid passwords are 24 characters long, with an alphabet of 64 letters, for a total of 144 bits of data.
That 144 bits includes a 8-bit checksum that is calculated from the other bits (as bytes), and 8-bit roll value that rotates the bits of the password around. What remains is 128 bits of payload, which includes the missile counter, the starting land, and numerous flags on doors opened and items taken.
The lowercase letters are shown in a very thin font.

Guardian Legend has the most intimidating password system that I know.
Its passwords are a whopping 32 characters long, with an alphabet of 64 letters, and the alphabets contain accents (umlauts). Admittedly, those accents are only used to make the distinction between capital and lowercase letters clearer (and was probably added only at moment's inspiration to reuse the dakuten feature from the Japanese version), but it's still quite nasty.
Naturally, such a mammoth password password would not have been used, unless it also encoded a ton of data. And it does. The password encodes a total of 192 bits of data, and includes the following:
- 68 bits of progress flags at various locations
- 4 bits of chip level
- 20 bits of corridor flags
- 20 bits of player's score
- 12 times 2 bits indicating status of different weapons / equipment
- 8 bits of ammo
- 8 bits of key acquisition flags
- 3 bits of firing rate, maxes out at 5
- 5 bits of shield amount
- 3 + 3 bits of weapon and shield strengths
- 5 + 5 bits of X and Y coordinates on the game map
For a total of 176 bits. Then comes 8 bits indicating a xorring value to be applied to the password, and 8 bits of a checksum to be applied to the password data, for a total of 192 bits. There are no unused bits in this password system.

Then there's Battle of Olympus.

The password contains an unexpected number of 26 characters, with an alphabet of 64 letters, for a total of 156 bits.
The password entry dialog is very slick and makes even the long passwords easy to input, with fast-reacting autorepeat and wrapping at edges. The password font is very clear, with no problem distinguishing O and 0 or I and l and 1. The numbers are in italic typeface; the capital letters are in a serif typeface and the lowercase letters are neither. It is up to the player's pen to follow similar clear conventions.
Among other things, the password encodes both the player's name (up to 6 letters) and the heroine's name (up to 6 letters), the two of which together already amount to half of the password's length.
In my experience back in the day, this password system was extremely cracking-resistant. I don't remember if I ever managed to successfully produce a fake password. Now that I have a generator source code available, it still defies my understanding. Apparently, it has xorring, adding, rolling and checksumming. Most systems have at most three of those.

Finally, there's Faxanadu, which is different from all of those, in that Faxanadu passwords are variable length:

You may first notice that it also has a thin (but very clearly readable) font.
The maximum length for the password is 32 characters, and the character set is 64 letters, for a total of 192 bits. But most passwords are considerably shorter than that.
Faxanadu uses a stream based encoding for the passwords. The password encodes the following:
- 8 bits checksum
- 5 bits of password length
- 3 bits of town
- 4 bits of rank
- 16 bits of key items and quests
- Optional 2-bit weapon, 2-bit armor, 2-bit shield, 2-bit magic and 5-bit item
- Numbered 4-slot weapon listing, each weapon 2 bits; same for armor, shield, magic.
- Numbered 8-slot item listing, each item 5 bits.
With optional encodings, the actual value is prefixed by one bit which tells whether the particular value is included or not. With numbered encodings, the actual listing is prefixed by a 3-bit or 4-bit number telling the number of elements in that list.

3gengames wrote:
1 pixel wide fonts aren't used by anybody who' a quality game designer.

So yeah.

by tepples on 2012-02-26 (#90601)

3gengames wrote:
1 pixel wide fonts aren't used by anybody who' a quality game designer.

Granted it's not on a password screen, but Kirby's Adventure pause screens? Earthbound 0? Willow? The Simpsons? Pokeymans?

by Dwedit on 2012-02-26 (#90608)

Maniac Mansion (J) is laughing at you.

by tokumaru on 2012-02-26 (#90609)

Holy shit!

by lidnariq on 2012-02-27 (#90624)

66 different symbols per slot, 104 slots, probably 624 bits if two of the symbols are either unused or special. Ow.

by tokumaru on 2012-02-27 (#90632)

An adventure game does have a lot of things to remember: the items you carry, where the characters are, events that already happened... It's not surprising that the password is that long, the surprising part is that they went with passwords rather than battery backup or any other method to keep the data.

by tepples on 2012-02-27 (#90635)

tokumaru wrote:
An adventure game does have a lot of things to remember: the items you carry, where the characters are, events that already happened

Which is why a lot of early adventure games were "railroaded" to an extent: to minimize the combinations. If a game is divided into chapters, only those items and event flags relevant to a particular chapter (along with such as money and a character's experience level) need to be stored.

Quote:
... It's not surprising that the password is that long, the surprising part is that they went with passwords rather than battery backup or any other method to keep the data.

Replication cost is probably part of it. Would it have turned off gamers to have to pay $10 more for a battery pak after Nintendo's markup, distributors' markup, and dealers' markup? The Japanese version of Maniac Mansion is UNROM, while the U.S. version went to SNROM (MMC1) just to have battery save.

by slobu on 2012-02-27 (#90637)

As usual, I am humbled by the depth of knowledge you guys have!

It seems Battle of Olympus hits the sweet spot for usability and capacity. 64 characters also seems to be the limit as far as manageable input. Most of these password systems keep it near 26 chars.

I suppose the first character could be an unencrypted value that doubles as a key for the rest of the encrypted chars to save the expense of a separate checksum value. So, it'd take 64 tries to get a valid password and that's when value range validation kicks in..

by Zack S on 2012-02-27 (#90639)

Have you considered leaving out the encryption/checksum?

Considering how easy it is to defeat any nes password system with the tools we have available these days. It may not be worth the effort and rom space to bother.

by Bisqwit on 2012-02-27 (#90640)

Zack S wrote:
Have you considered leaving out the encryption/checksum?
Considering how easy it is to defeat any nes password system with the tools we have available these days. It may not be worth the effort and rom space to bother.

In my opinion, while it is encouraging for hacker spirit for the password system to yield to hacking, it should not be too easy. An accidental typo in the password entry should really give an error message rather than a different game state.

by Bisqwit on 2012-02-27 (#90641)

For the record, here's the Japanese Maniac Mansion password entry screen:

66 symbols, filled into (6+8+7)*5-1 = 104 slots, as indicated by Lidnariq earlier. That's almost twice the amount of information carried in an SMS, considering that the Japanese symbols correspond to syllables.

One may wonder, did they not even try optimizing the storage? For example eliminating irrelevant data or impossible combinations...

by slobu on 2012-02-27 (#90649)

Ya, I'd say encryption that doesn't cost an additional character is the way to go. The user positive feature (as Bisqwit mentioned) is user entry validation.

It looks like 64 character table renders 6-bit values. That means I'd need 8 characters to produce 6 8-bit variables. So, to get 12 8-bit values the end-user would need to enter 16 characters. That seems within the acceptable range no?

by Dwedit on 2012-02-27 (#90650)

If you're really crazy, you can do what Magic of Scheherazade does. If they get a password wrong 3 times, let them start at that level anyway, with reasonable default stuff for that starting location.

by slobu on 2012-02-27 (#90652)

Allowing failed passwords is an interesting idea. One that I didn't know developers even used!

I think, though, I'll keep it generic. I'm trying to develop a framework for any game. So, if SRAM is not an option it'll default to a password screen.

I'm thinking the vars could be divvied up as follows:

6 8-bit (0-255) variables
6 4-bit (0-15) variables
5 3-bit (0-7) variables
9 1-bit (true/false) variables

by Bisqwit on 2012-02-27 (#90653)

One more thing:
In my opinion, while the passwords should be readable, they should not have obvious patterns. If you record a password, and get e.g. "0000a0001",
and you then change one thing in the game and get another password, which is "0000b0001", it all too easily tempts the player to test what happens if they input "0000c0001" or "0a00b0001" or any other minor variation. And trust me, when you invoke your player's hacker-oriented mind tackling the game's internals rather than the game itself, the game has lost its appeal for all the wrong reasons.* It's like giving the player an exp button in an RPG. Any serious hacker cannot resist the temptation. And if you really want to cater to hackers, then at least make it a challenge worth of their attention.

The crypting mechanisms present in most of those games that I showcased are a good way to combat the low password entropy: Two successive passwords are not likely to look nearly identical. (They still can, because there is only a limited number of the crypting setups.)

*) This happened to me with Solar Jetman and some other game I cannot remember right now. Though as Brelagad writes in the next post, the horrible UI in password entry screen somewhat deterred me.

by Bregalad on 2012-02-27 (#90654)

I think 64 chars alphabet is really way too much.
In japanese, there is 50 or so kanas, so it makes sense Japanese games (which is the majority of the NES/FC library) use kanas, combined with latin letters and/or numbers it was easy to reach 64. Since everyone in japan knowns hiragana and lattin letters it is pretty normal. However in other countries, people only know 26 letters so it's a good idea to stick to a 32 symbol alphabet.
Passwords like Kid Icarus' or Metroid's are really annoying, as you need two different pencils of different colours to write them down, to avoid confusion between uppercase and lowercase.

Honnestly, who can see the difference between their written k and K ?

I think 32 chars is the way to go. With alphabet you already get 26 letters, there needs to be 6 additional symbols to get to 32 (because you want characters to be a 2^n value).
I'd say avoid 0 (confusion with O), 1 (with I), 2 (with Z), 5 (with S), and 9 (with G). In short I'd avoid numbers completely, and use other symbols like ?, ! and things like that to get up to 32 chars.

Obscene words should be no problem as long as they are not common, in fact I think it's rather fun these can lead to a password. If this is really a problem then get rid of the vowels and use numbers instead is probably a great approach.

I think wasting bits for passwords checking should be avoided as much as possible, these bits should be the bare minimum, in order to keep the password as short as possible.
Simon's Quest system is pretty, but it's such a waste they have a few bits just for a random value, the game selects a passwords among 16 or so randomly every time. Why ? There is no use for something like that, it's just a waste of precious password characters. It could have saved the town instead, and choose the same password every time you are in a state (which makes the most sense to me).

In order to have the possibility to have a number of symbol that is not in a 2^n form, it's possible to treat the password as a big number written in base N, where N is the number of characters. For example, use plain alphabet and the password is a number written in base 26.
Encoding and decoding it is just a matter of a lot of divisions and multiplications which can be done without too much trouble. This base conversion also probably act like a solid cryptography, it should be hard to read your game state in base 26, so few cryptography work will have to be done.

I think this is one of the best approach to passwords as there is almost no waste of letters. I haven't tried to implement it though.

The longest passwords I've ever need are probably found in Golden Sun where they can reach 6 pages. You don't need them to save your game though

Last thing, I think the password input screen MUST be paractical and allow for 2-dimentional browse through the characters. The system in Solar Jetman which requires you to use up/down to go through the alphabet is just terrible.

by Zack S on 2012-02-27 (#90657)

One of the things that makes entering these passwords tedious is that you have to look back and forth from where you wrote down the password and the TV for every character. With the execption of when you're lucky enough to happen upon a word or two inside the password.

What if the password was comprised of 4 symbols, up, down, left and right? Then you could simply hit the d-pad as you read the password. No password entry screen would be required, it'd be just like entering the cheats for contra.

It should also greatly simplify the code required to make this work. Each byte of data will correspond to exactly 2 symbols. Not to mention the lack of entry screen.

by Bisqwit on 2012-02-27 (#90658)

Zack S wrote:
It should also greatly simplify the code required to make this work. Each byte of data will correspond to exactly 2 symbols. Not to mention the lack of entry screen.

With 4 symbols, you can convey 2 bits of information: 00, 01, 10, 11. You need four of those for eight bits of data, i.e. a byte.
To convey 10 bytes of data (80 bits), you need 40 of those arrows. It gets tedious, especially when writing them down.

by Zack S on 2012-02-27 (#90659)

Bisqwit wrote:
Zack S wrote:
It should also greatly simplify the code required to make this work. Each byte of data will correspond to exactly 2 symbols. Not to mention the lack of entry screen.

With 4 symbols, you can convey 2 bits of information: 00, 01, 10, 11. You need four of those for eight bits of data, i.e. a byte.
To convey 10 bytes of data (80 bits), you need 40 of those arrows. It gets tedious, especially when writing them down.

Yeah, I didn't really think that through completely...

Anyway, it could be usefull for games that don't need to store much data. Perhaps something trying to stay in 4k or less.

As far as having to write down too many arrows, that's what cameras and screenshots are for

by Kasumi on 2012-02-27 (#90662)

The arrow thing is actually not a bad idea for what I would use "passwords" for.

I think my game will just use battery saving. But it (may) have a lot of control options. I'm also planning co-op and multiplayer modes. What if I go over to a friend's house, but want to use my own control settings without going through a menu with a bunch of text? I was going to handle it kind of like how the Smash Bros. Melee/Brawl handles name entry. On the mode screen, put the cursor over your character, and a menu pops up. From there you enter the "password" for your controls. That's what I came up with my every other character must be a vowel thing (You could play RI mode or RU or MO or whatever. Easy to remember.), but your arrow idea makes it even easier to enter. I also probably wouldn't need more than 6 bits, or error checking.

Edit: In fact, this could be used for things like quick options setting too. Imagine smash bros again. You can turn off items, set damage ratio, put different levels on random, select time mode, stock mode, set the time and the number of stocks... etc. It'd actually be super cool to be able to just enter a quick code that you have memorized for your favorite way of play rather than jump through menus. (Which of course would also be an option for people who don't want to remember stuff)

I definitely appreciate this idea, even if I don't end up using it. It's so simple, but useful for all kinds of things.

by slobu on 2012-02-27 (#90679)

I'd argue that with 4 symbols the amount of time inputting would be quite close to just entering your custom control scheme via a prefs screen.

Limiting the amount of options the end user wades through IS a noble goal though.

What about a cross shaped control that rests at 35 in the middle. Vertical movement is in the tens place and horizontal is in the ones place:

65
55
45
|35| <- Middle
25
15
5

and starts at 35 horizontally:

30-31-32-33-34 |35| <-Middle 36-37-38-39-40

Worst case scenario it takes 8 key presses to reach 0 (3 down + 5 left)

I know this is virtually the same as a symbol chart but maybe snapping back to the middle value would save some input time?

Re: Best Password System
by Memblers on 2012-02-27 (#90684)

slobu wrote:
So, I'd like to come up with a password system that stores 8-bit values. It should involve the least writing/inputting by the end user.

Why not use something more modern, like FlashROM, and ditch the annoying password entry altogether? Seriously, if your game is under 128kB, then the chip is like $1.07, and under 512kB would be $1.70. That's about the same cost, if not cheaper, than using EPROM. So it basically adds no cost at all.

Only downside is without extra SRAM, you need some room in RAM to hold the code that actually erases/writing of the FlashROM. It's not very much code though, shouldn't be a problem. And you would leave 4kB or 8kB free in your ROM (8kB would be recommended because you could keep a backup save to revert to if the other is corrupt upon loading).

I've been advising various people to do this for years, I've yet to see anyone do it though. So what if it's not emulated, obviously if someone wants to save in an emulator they're just going to use a save state.

I could supply the code and boards to do this, if it helps. Though the board I have now that supports this has "the works" (good mapper, WRAM, etc), I could easily make a simpler board that allows saving.

Re: Best Password System
by slobu on 2012-02-28 (#90696)

Memblers wrote:
slobu wrote:
So, I'd like to come up with a password system that stores 8-bit values. It should involve the least writing/inputting by the end user.

Why not use something more modern, like FlashROM, and ditch the annoying password entry altogether? Seriously, if your game is under 128kB, then the chip is like $1.07, and under 512kB would be $1.70. That's about the same cost, if not cheaper, than using EPROM. So it basically adds no cost at all.

Only downside is without extra SRAM, you need some room in RAM to hold the code that actually erases/writing of the FlashROM. It's not very much code though, shouldn't be a problem. And you would leave 4kB or 8kB free in your ROM (8kB would be recommended because you could keep a backup save to revert to if the other is corrupt upon loading).

I've been advising various people to do this for years, I've yet to see anyone do it though. So what if it's not emulated, obviously if someone wants to save in an emulator they're just going to use a save state.

I could supply the code and boards to do this, if it helps. Though the board I have now that supports this has "the works" (good mapper, WRAM, etc), I could easily make a simpler board that allows saving.

I appreciate both the opinion and the offer Memblers! I hope the 8T-ROM becomes something like the Melody board from AtariAge. Normal humans without soldering skills can purchase such a board through a storefront. It levels the playing field quite a bit.

Cart making is still a black art nowadays. You either do it yourself (which requires much more knowledge than programming). Or rely on sometimes unreliable strangers on the 'net - who may not have the time or inclination to burn your ROM when the need arises.

Passwords have a place in classic gaming - good or bad. As I said in a previous post, this is a fallback option for a generic game framework. Not every target may support SRAM.

If you have to do a password Memblers I'd be very interested in what it'd look like. Again, you've got 10,000 times my experience and I'd love to hear your thoughts!

Re: Best Password System
by Shiru on 2012-02-28 (#90697)

Memblers wrote:
So what if it's not emulated,

It increases difficulty of debug. You can't test this functionality with neither emulators nor PowerPak, you would need to flash you special cartridge every time to test it. Beta testers also would need to have it to test a game with full functionality, to not miss a situation like 'saved on the last level, and the game erased itself'.

Re: Best Password System
by bunnyboy on 2012-02-28 (#90698)

Shiru wrote:
Memblers wrote:
So what if it's not emulated,

It increases difficulty of debug. You can't test this functionality with neither emulators nor PowerPak, you would need to flash you special cartridge every time to test it. Beta testers also would need to have it to test a game with full functionality, to not miss a situation like 'saved on the last level, and the game erased itself'.

I have a UNROM board with flash on it. For people targeting it they just use WRAM for testing instead. The read/write routines are pretty contained so it is easy to swap between sram and flash.

by Bregalad on 2012-02-28 (#90700)

Yes, I know it would be way better to reprogram flash ROMs to do saves, but this cant be (currently) emulated which is a BIG problem (at least to me).

Something even cooler would be a device that plugs in controller port #2 or the expansion port and have some EEPROM with a block system like Playstation Memory Cards. Then again this is useless if it's unemulated and if no games makes use of it.

by tokumaru on 2012-02-28 (#90701)

Bregalad wrote:
Yes, I know it would be way better to reprogram flash ROMs to do saves, but this cant be (currently) emulated which is a BIG problem (at least to me).

Maybe it's time we added a "PRG-ROM is Flash" to the iNES header? =)

Re: Best Password System
by tepples on 2012-02-28 (#90704)

Memblers wrote:
Only downside is without extra SRAM, you need some room in RAM to hold the code that actually erases/writing of the FlashROM.

That and without extra SRAM, you don't get the map destructibility or other space for working data that comes from having extra SRAM. There's a reason that a lot of Koei games had one SRAM chip for saving and one for working.

Quote:
I could supply the code and boards to do this, if it helps.

Once you make such boards available along with a solution that doesn't require a developer to learn to solder, I'm in.

Bregalad wrote:
Something even cooler would be a device that plugs in controller port #2 or the expansion port and have some EEPROM with a block system like Playstation Memory Cards.

Or like the N64 Controller Pak, which turned a lot of games supporting save into games not supporting save in the hands of tightwad parents who would cheap out on memory cards.

tokumaru wrote:
Maybe it's time we added a "PRG-ROM is Flash" to the iNES header?

I guess that's part of what the NES 2.0 submapper is for. Flash would need mapper support to direct writes to the mapper or to the flash chip.

by Karatorian on 2012-03-01 (#90762)

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.

by slobu on 2012-03-01 (#90767)

Quote:
..they actually provide the system with more bits of information than the system utilizes

I never noticed that! Perhaps the characters A-Z could be cycled through in four directions (up/down/left/right) adding 2 extra bits of information. This gives us 104 values. We could interpret each entered value as 2 entries with 0-9. The game developer could divvy up the individual 0-9 entries as they see fit for each game variable. Values past 99 will be regarded as invalid. A mask will be applied based off of a character in the password. If someone tries to make their own password they're bound to produce at least one invalid entry.

by Bisqwit on 2012-03-01 (#90768)

Human beings appreciate redundance and choice.
That you can navigate half a screen right and two rows up by going first right and then up, or by going first up and then right, or maybe go left and wrap through the screen edge and then up, or vice versa, or maybe you'll rather wrap vertically, or maybe do both as well. That the system won't care which way you do it.

On the other hand, if you're designing an input system to be used only by TAS folks... you've got a small audience. First of all, the TAS folks aren't going to be using passwords to begin with. :-)

EDIT: And this I know, because I went the same tangent in Rockman Basics, maybe even farther. http://bisqwit.iki.fi/kala/rmbasicsgeneric.zip