That looks a bit more simplistic than the likes of GBAATM and Gabsharky on the GBA or DSATM on the DS, and the main components of it don't appear to have been updated much in a while.
You do however have the option of doing things like the more manual methods that came before the automated tools.
Here is an older guide for the DS
https://gbatemp.net/threads/crackers-ds-trainer-maker-tutorial.44410/
I have a related section in my GBA/DS hacking docs for a GBA game.
The simplistic version of those is there are two different approaches.
1) You do what the hardware gameshark will be doing. This is to say running a small section of its own code all the time (typically in a vblank -- vertical blank, an event that happens regularly as long as the machine is running and thus is really good for this sort of thing) aimed holding memory values and whatever else it has.
60 times a second might not quite be enough though, and if an action drops the health massively and is immediately followed by a "is the player dead?" check it is not going to do much. Goldeneye on the N64 is my main example of this -- big explosions will still kill you with a basic infinite health cheat but if you have the in game infinite health cheat then you can survive them all day long. It is usually easy enough to find the vblank routine and stick another few commands in there, though you can do anything that happens often enough to be useful.
2) You alter the game at a fundamental level. If the above might try to give you infinite health by forcing the health value to the max 60 times a second this comes the other way and will attack the part of the game code that deals with health. Kind of hard to die if nothing you do touches your health.
If you have the classic memory cheat from 1) you will know where the health is stored. You set your debugger to tell you when something touches that area. Next thing you know you have a list of things that happened just before that, one of which will be a subtract command or something. Turn it into an add or negate it and infinite health, or at least that action will not take health (my favoured example of the "failing" of this method is to contemplate original NES Mario -- you might die from time, pits, hazards, enemies and in later games poison mushrooms. All of those might mess with the lives counter so messing with just the one method might leave the others, however 1) would likely not be worried as it knows nothing and cares less of all the things that can touch it).
The automated tools are typically quite crude. They will do the job and most would not care, however if you went manually then you could well do something in an absolutely tiny snippet of code or change (if it is a sub to an add then it might even be a single solitary bit that is changed in some systems if their maths functions are encoded next to each other in the list).
Compared to automated tools these types of things are quite involved, however they are not necessarily the "10 years of learning and I might" stuff but actually pretty good projects to learn assembly with and if you plan to do much N64 work on games nobody knows you are going to have to help yourself out as there are not many people playing ROM hacker for the N64.
