I made a Famicom Hangman game. The program is complete (although new things might still be added, but I think it is complete), but not all phrases are complete. If you have any, you can please suggest new words/phrases to add on. Also tell me any other question/comment/complaints you have. Even modify the program if you want to; it is public domain. If someone want to make label for 60-pins cartridge, I may also include that in the ZIP archive as well.
Wiki:
http://wiki.nesdev.com/w/index.php/Famicom_Hangman
Nesdev Wiki wrote:
Tested on official hardware: No (anyone who can do so, please do)
Any particular reason for it to fail in Nintendulator (bad opcode) and Nestopia (CPU jam)? If not, I wouldn't expect it to work on hardware.
Shiru wrote:
Keyboard only?
Yeah, I can't even emulate this thing... The only emulator I have that runs the ROM is FCEUX, and to enable the Famicom keyboard I have to use the "Scroll Lock" key, which my laptop doesn't have...
EDIT: OK, got the thing to work using the Scroll Lock key in Windows' on screen keyboard. Why the hell do you need 256KB of PRG-ROM for such a simple game? No graphics, no music, no options... did you just stuck a whole uncompressed dictionary in there?
Based on the project's page on NESdev Wiki, eventually the plan is to have several thousand possible phrases.
Nintendulator appears to be doing something weird with this... it's loading the incorrect bank into $C000-$FFFF, which obviously causes the game to crash (bad reset vector, etc.). Does anyone know what's up with that?
If I am doing something wrong, please tell me what I have done wrong. Is mapper 70 wrong?
The reason for 256K PRG ROM is to hold the texts in fifteen banks (I intend to have as much as possible), and the last bank is for the program. I may later on add support for standard controller as well, possibly add some more graphics, background musics, etc (if it fits in the last 16K PRG bank), or anyone else can modify it too if you want to since it is public domain.
I would like other people to help to add more words/phrases so if you have any suggestion, please post it.
How many thousands of words you are going to have? I know that with some compression you can put like 15000 in less than 40K.
Shiru wrote:
How many thousands of words you are going to have? I know that with some compression you can put like 15000 in less than 40K.
I intend to have 7680 phrases (this includes, but is not limited to, single words) exactly (but this is because of the amount of ROM available). Compression would be possible but I don't know how difficult that makes it to select them at random using indexing and those things. (Look at the source-codes if you are wondering)
Yes, it's possible to choose a random element from a list of pointers into Huffman encoded data. But practically, to choose one at random, you're going to need a random seed with at least 13 bits of
entropy. You can't get much of a seed from key press timing; each press yields only about four quality bits. (The upper bits are predictable and therefore don't count as entropy.) I think that's why Rare's version requires the players to enter their names on an on-screen keyboard before the puzzle appears on Vanna's board.
tepples wrote:
Yes, it's possible to choose a random element from a list of pointers into Huffman encoded data. But practically, to choose one at random, you're going to need a random seed with at least 13 bits of
entropy. You can't get much of a seed from key press timing; each press yields only about four quality bits. (The upper bits are predictable and therefore don't count as entropy.) I think that's why Rare's version requires the players to enter their names on an on-screen keyboard before the puzzle appears on Vanna's board.
Currently I use ARCFOUR loop running several times per frame on the title screen and when you win or lose, and once per frame otherwise, and uses the microphone for additional entropy, if it is available. I don't know how good quality it is but it seems to work OK as far as I can tell.
How much entropy do you get from measuring the length of time a button was held in CPU cycles? (remember to debounce)
I guess you can check the controller state about 30 times in a frame. It's actually rather difficult to press any button for less than one frame, so you'd have a fair bit of variety on just a "press start" timing on the title screen (especially since most people won't be trying to press it quickly anyway).
It might be a problem with emulators, though. Input polling might be abstracted and run on its own timer.
As for debounce, is that a problem with the NES? I've never tried polling the NES controller more than once per frame.
Dwedit wrote:
How much entropy do you get from measuring the length of time a button was held in CPU cycles? (remember to debounce)
I don't know, and I have no need to check the length of time a button is held or to debounce with what I currently have (although I would need to check those things for cursor movement (only) if I add support for the standard game controller).
I don't necessarily mean measuring it in actual time units, I'm just suggesting polling the joystick more than once per frame, and keep calling the RNG.
I couldn't sleep so I
made a test.
A poll loop on your start-game code seems pretty viable to me as a random seed generator. (Also there doesn't seem to be any need at all to debounce.)
With what I currently have, the time spent on the title screen, how long the space bar is held down, the initial contents of RAM at reset, and the microphone (if available), all affect the random number generator. You can look at the codes to see how it works. If you think it is good or no good then you can tell me your opinion, but you should look at it first before deciding if it is good or no good.
I was only trying the start button press thing to see how random it actually was; not a commentary on your game. (This is also why I put it in its own thread.)
Initial contents of ram and microphone are not good for randomness, especially because we mostly have to use emulators (very few of us have a keyboard and a famicom). I don't think there's any need for this.
tepples was suggesting you need enough bits of entropy to be able to jump to any of your phrases from the start. Your time spent waiting for space is good, I think, but only because you're not limiting it to one per NMI. In a short loop like that it's easy to rack up high numbers for your random seed. Since you go to the same wait-for-space routine after every round, that should be quite sufficient to keep the phrases from repeating in the same order, etc. There's really no need to do anything to the RNG anywhere else, like your microphone test.
rainwarrior wrote:
Initial contents of ram and microphone are not good for randomness, especially because we mostly have to use emulators (very few of us have a keyboard and a famicom). I don't think there's any need for this.
I know that; I am testing it only on emulator (the only hardware I have is a Famiclone with 60-pins and no cartridges) and I have no microphone on my computer, and it seems to work OK even if the initial contents of RAM and microphone are not used. What I use is
RC4 without a key ("S" is initialized to the identity permutation only), and the "i" and "j" are not initialized to zero or anything else (it just uses what happens to be in RAM, usually zero if an emulator is used, though), and the microphone sometimes causes it to add 2 to "i" instead of just 1, and the "K" output is ignored except when selecting the phrase to use at random.