I assume you are operating within the emulator. If you are using an external cheat program then actually what I am about to describe applies as well but it has a slightly different solution (assuming it also does not apply again in the wii u game).
Two main choices
1) Dynamic allocation
2) Pointer codes, related to 1) but typically considered differently by hackers.
Such things were not so common on older systems which were more direct and stable across boots but it is what it is.
Theory then.
1) I have a program. It does things but will need memory to do it with. As I would soon run out of memory programming languages give you the option to reserve and then release an area of code (if you fail to release areas it also is why some programs creep up and up and up in memory usage). If the game reserves an area but has not released it by the time the game lands and starts doing calculations on HP and whatnot then said HP and whatnot will be in a different location.
2) Pointers. Pointers... point the way to parts of memory/files. There is a classic exam question in programming courses (at least the low level ones) where you put together a list of pointers so you have a pointer to a pointer.... to a pointer to a value and you get to decode it for the exam to show you understand the concept (it is one new coders seem to struggle with for some reason). Game devs, sometimes for technical reasons but sometimes also for anti cheat reasons, use something similar from time to time, though it tends to just be the one . Here the pointer will be set and the game will then use that location. It costs the game basically nothing to figure out where the relevant code is so no worries there and programming is not really any harder either.
Eventually you end up with a fixed location that the game starts the chain of pointers from (though hopefully it is just one). For most systems with such things you typically get a tool that you tell the location of a cheat in for that boot, and another for another boot (different of course), a third helps a lot and sometimes a fourth is not bad.
It will then search for a value that looks like it could be a pointer (it will change and hopefully then look like a pointer). By comparing the various boots then the pointer location will be revealed. Should it be a pointer to a pointer to a pointer... then you get to repeat the process a few more times but using the pointer location)
You could do it with a generic program and your brains but it is easier if you have a search tool that is somewhat aware of the wii u pointer/address formats and memory layout. I don't know if there is one for the wii u at this point though. Once you have the pointer location you then get to alter your cheat codes accordingly, on the DS this is the reason for all this offset business you see in the listings of code types (
http://doc.kodewerx.org/hacking_nds.html#arcodetypes ).
This is probably a bit abstract so I will go a simpler example. I usually describe pointers as like a contents page in a book. Here though you have a magic book or something where the pages of something you wanted to see would change every read (say you find something at page 400, 275, 665 and 100 in four different sessions), however when you took a copy of the whole book (aka dumped the memory) there was a thing that also changed to 400, 275, 665 and 100 for each of those respective readings. You then note the location of this changing number and try reading again. It says 199 and as you turn to 199 you find the info you wanted. This is just like that.
Alternatively you can step through the program and any handler for it to find out what goes but don't go there right away if you don't have to.
Also if you found a bunch of locations of different aspects of gameplay (hp, mana, money, stats...) then do note where they are relative to each other -- if one always follows the other at a set distance then that can be helpful information, especially if you have fixed attributes (if your stats only go up every 2 hours or so then while HP and stuff might change in moments your stats can be a simple search string to find the new location every boot while you are doing this rather than having to do the search, lose HP, search, lose HP... routine, to say nothing of making it easier in the final cheat making session. It could be that you still have to do 10 different pointer codes for 10 different things but nobody sensible said hacking was always easy.
There are further things that frustrate cheats (the floating point stuff potentially being one as the hex does not behave like many other numbers), proper anti cheat pointer swapping variables (think every time it is altered it goes to a new location rather than just every boot/level/new game session) or values existing in registers/the stack but those show themselves in different ways, there is also ASLR but I don't think that applies to the Wii U.
