I can't speak to the complexity of this project, but for ROM hacking in general, it's not all too complicated, but it does take some persisence. First you need

I can't speak to the complexity of this project, but for ROM hacking in general, it's not all too complicated, but it does take some persisence. First you need to find code relevant to what you want to do. You can take diffs of memory as you do things in the game to narrow down where the relevant addresses are, and then set breakpoints on read/write to those locations to find relevant code. After that, you can mostly just follow the assembly - you can even read backwards up the call stack by reading to what look like the beginning of a procedure, and searching for jumps to that address. Once you've found the code you want to modify, you just need to find some empty space in the ROM that you can branch out to to write your code. The trickier bit is if you're in a spot where you need to worry about timing. On older consoles, this included things like changing the HUD or wave effects, etc., since you need to make sure whatever work you do gets done in time for HBlank/VBlank. Some consoles also had some built in functions that would give you an idea of what code was for, like the lz77 compression on the GBA, which was mostly just used for graphics. Similarly, DMA was most often used for copying sprite data. On newer consoles where code was often compiled from C (rather than assembly with macros), I'm under the impression you can also do things like try to pattern match on the signature of standard library functions.