nesdev.com

https://www.youtube.com/watch?v=A6UcHYZt9l0

This guy shows how to make a nes game genie code, by ram searching, debugging, and then experimenting.
From what I can tell, he was doing a great job showcasing how to make an actual gamegenie code.

Is there more videos just like this? Not those dumb/easy infinite life codes, but actual codes where you have to debug constantly.

(You guys make game genie codes all the time.. why not record it, and get some views )

PS. Found some sites with a good chunk of cool game genie codes, so I can take my time learning how to make them... just glad I found this video showcasing how you actually do it!

No, we really don't. It's a total pain, and only suitable for situations where the modification you want can be made with 1 to 3 carefully chosen bytes. That's really pretty rare, so in general larger and more comprehensive patching mechanisms are preferred.

I make them several times a year.

Usually start on level X codes in unpopular games that have few codes.

_________________
nesdoug.com -- blog/tutorial on programming for the NES

but this is how you do it right?

I'm guessing with harder codes you just do more debugging and write/execute more addresses to see when it breaks.

Short answer: yes. But if you're already making codes of this sort in emulators, you might as well just use other features that are less obtuse and annoying than GG codes.

Long answer: this is a form of reverse-engineering. YT is not particularly a good medium for learning how to reverse-engineer a specific game, but may be helpful for demonstrating how to use an emulator's debugger or understanding RE-related concepts in general. This general skill set is not limited to just "making GG codes".

I think given what you're looking at and doing, your desires and goals might be better-suited for the romhacking.net forum. No harm in asking here though, of course.

This video has the general idea, but the person doesn't know all of the features of FCEUX, which could have made the process quicker / less tedious.

First, he should have set a save state at the exact moment he is observing, and reloaded it over and over, as needed. Even better would be to slow emulation to 50% or 25%. Isolating variables is key, and the most important variable is time. The key event happens at one frame. If you can minimize the time frame, you have less code to look at.

Second, in the debug window, if you right click to the blank gray area to the left of the disassembly, it will open the hex editor in ROM view to that exact line of code. You can modify the binary directly, reload the save state, and see results immediately. If you don't like it, you can undo (ctrl z?) the changes.

That would be quicker than making temporary game genie codes.

Personally, I would have watched the RAM in the hex editor rather than the RAM search tool, but that is just my preference.

Third, other tools are available, depending on your needs. The code / data logger and the trace logger.

One fun thing to try is run the code / data logger, which color codes the hex editor in view=ROM, and then just randomly change some data, and see what happens.

Another thing you can do is search the ROM (hex editor, view = ROM, find) for strings of text, or color palettes, etc, and edit those. (maybe not good for game genie, though).

_________________
nesdoug.com -- blog/tutorial on programming for the NES

I'm not gonna watch a 20 minute video through just to tell you if the guy is good at demonstrating what he's doing. In general I consider videos a really terrible way of learning anything not directly related to a visual interface (which a debugger is, though, so I guess that redeems it partly).
However, judging by Dougeff's comments, this guy's approach isn't particularly good.
Also, I'd choose Mesen as my tool over FCEUX any day. Debugging, breakpoints, testing out changes etc. is all so much more intuitive and easy to pull off in Mesen's interface.


That's gotta be the most boring video ever.

You'd have to at least make sure you get a working code before even starting to record, and then pretend you go through the same process again, skipping over all the failed approaches.
I guess I could make a mildly interesting video about how I managed to replicate TGM's "invisible tetris" mode in NES tetris using only three Game Genie codes, but the actual complete process I went through would not be interesting for anyone to watch.

https://www.youtube.com/watch?v=tmrXakd_r6I

a person sits and smiles at the camera for 4 hours, got 3 million+ views.

Trust me, anything can be interesting to people.
Also, just skimming through parts of the video gets you the general idea.

lastly, for educational purposes, it would be interesting.. not 1 million view interesting, but some people would like this.

A lot of us here are probably a bit old-school, in that we don't equate number of YouTube views with quality. Probably many of us here (myself included) don't consider YouTube hits a reliable measuring statistic of anything, let alone personal qualities such as interest or worthiness.

If a 24-hour Andy Warhol movie is boring to someone, it really is boring, never mind that Andy got 1,000,000 of his sycophants to say that they watched all of it.

So, 1 million = interesting; please stop with this useless yardstick.

Conciseness, thoroughness, lack of rambling, step-by-step procedures; other nice and long adjectives like these are my criteria for the quality of an educational video.

_________________
http://www.chrismcovell.com