nesdev.org

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.

... 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.

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..

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.

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.

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...

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?

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.

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

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.

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.

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.

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.

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

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.

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?