Some might deem that running before you can walk, especially if we also have to consider counter anti piracy*/anti cheat stuff. That said the basics are not that complicated and you will be able to do useful things in fairly short order using them.
*anti piracy often detects changes to the game binary. Even if your cheat patch does not touch anything there it can trip it anyway. Anti cheat also often does similar.
Anyway there are two main areas to consider in memory of any given program
1) The memory itself aka data section
2) The code that runs the game aka executable section
Save hacking is another thing but I will skip that in this. Note that savestate hacking is basically just a version of 1).
Most basic cheats you have dealt with on consoles before that are not save cheats will be 1). Here the data the game generates to store variables like how much health, ammo, mana, strength, item durability, items in inventory, possibly stuff like speed in game, how many steps before the next "random" battle and so on and so on. Find where a variable is located and you can alter it.
Various cheat devices will have more and more functionality beyond just hold this item at this value until either I turn off or the game turns off. You will also gain basic loop options as well so you can do things like check this value, if it is less than, equal to, greater than, between this range....
Finding variables can be hard. The basic stuff you can constantly change, manipulate or otherwise handle in very quick succession (it is easy to fire a bullet or stand there being hit by a weak enemy, if the game puts nice numbers on screen you can even search for them, or search for them once you convert it to hexadecimal number types) tends to be found quite easily by just constantly searching until the list gets small enough that you can watch it all at once, or try things out and see what happens. Things that are on or off, or take 10 minutes to reset to try for another search take more effort. Savestates can help here as you can load and test things, load and try something else, load and test until such a time as you find what you want.
Also worth noting is once you find one item the one next door to it might also be of interest, or the value up from it can be something rarer. This can be especially useful when doing infinite items. This is how people usually do things like have 99 end game weapons -- find a cheat for say iron daggers you can buy in the starting town and it is of the form that this value followed by this number means, note that 2 might be say a steel dagger, and the super gold obsidian fancy end game sword with a 30 hour game + 5 hour sidequest to get it is hopefully then just a matter of trying 3, 4, 5,... until you get there. Can also be useful if you are helping someone fill in a FAQ and want all the details.
Two main subjects to discuss now would be data types (you already met floats, and I mentioned in passing other number types, this would be expanded to include things like linked lists, and all the other stuff on things like
https://www.tutorialspoint.com/cprogramming/c_data_types.htm ) and cheat prevention methods, however I will put a pin in that for the moment.
2) You might have met in old school games as a game genie, though not all game genie codes deal with the executable. Likewise on the DS as the executable binary was in memory you could edit that, and people did.
Anyway here you change how the program works, or maybe data it brings along for the ride within the binary. The scope for changes available here is dramatically more but so does the difficulty.
The CPU is the beating heart of the system, or subsystem, in most cases. There are parts that might never be touched in a given game but everything usually comes back to the CPU.
They are at their heart actually quite simple devices, even the decades of stuff built on stuff built on stuff that is the modern X86/X64 Intel/AMD style processor (by comparison the ARM of just about everything else nowadays, along with the Z80, 68K, 6502, PowerPC, 8080, MIPS and other things you will have seen if you looked at specs sheets for game consoles and microcomputers are usually even more tame but also a bit more limited).
You might have looked at something like
https://www.felixcloutier.com/x86/ and seen the 1000+ instructions (never mind one of Intel's own datasheets covering timings, caches and multiple cores), some of which do very weird and wonderful things like smoosh arrays together and thought oh dear. Don't worry as nobody really memorises all of that in an effort to do useful things, and most of it is slightly more advanced or tweaked ways of doing basic things. Some might memorise all of say the 6502 processor (around here most would note its use in the NES) and they might have some odd ways of looking at things if you speak to them after you got this X86 stuff on lock but it should all be pretty familiar (learn one type of assembly and you can do two, learn two and they are start being reasonably familiar).
Anyway instructions can be categorised in various ways but I usually find it helpful to split the basic maths from the system/processor manipulation/housekeeping and the program flow stuff.
Maths is maths. Processors excel at doing very basic maths operations. Indeed they are so basic it can be hard for people to imagine how anything useful gets done. Some also like going to look at adding machines as everything is adding in the end (adding is adding, multiplication is adding, subtraction is just a type of adding and if you remember logarithms from school division is a type of subtraction which as just mentioned is also adding), and if you don't know Boolean logic (gates from electronics) then do that too. X86 can reach out and touch memory from instructions, some older systems might need dedicated instructions for that one (or use something called DMA, direct memory access, to do other things)
System manipulation and processor housekeeping is just that. Things that manipulate memory, other registers and the like. PUSH and POP are some of the most important here, and you met those already.
Program flow is when stuff starts getting useful. If you learn basic programming you will be introduced to loops (FOR, While, IF ELSE...). These are things that allow you to do things like add things up and only when something happens do something else. In the processor these will be things like compare (CMP), jump (JMP) and branch in some other systems (BRA) with most things just be variations on that (Jcc being jump if condition met and has a nice long list of things it can check and jump accordingly
https://www.felixcloutier.com/x86/jcc ). Programmers will also usually bunch up a group of instructions that perform a common task and then jump to it (this would be calling a function), and calling a function might first mean you do some housekeeping (the push and pop stuff) so it does not overwrite your useful data or trouble itself.
I should mention the NOP at this stage. Short for No-Operation. When playing cheat hacker this is going to be your friend where in normal assembly programming it has very limited uses (mostly just a means of making something wait if you have a complicated instruction you need to wait to complete). If you start pressing delete in code already compiled bad things start happening as something that jumps to somewhere else might encounter something it does not expect (or miss an important step). A NOP essentially causes no change in the state of things but a cycle to skip. Some systems will have a dedicated NOP, some programs you are viewing/editing assembly with will give you one it made up and other times you get to make your own (MOV EDX, EDX being a nice choice as it merely copies the data from one register to itself and does not change anything, indeed most programmers on most systems will copy a register to a register).
The main reason it is your friend is you can edit out instructions you don't want. Die in a game and lose a life, oh no the thing that reaches out, grabs the lives value, subs one and then returns it no longer subs one because the sub part is a NOP. Come to a shop and it wants all the gold to buy an item, oh no the the thing that checks your wallet balance suddenly does not care and will proceed to the allowing you to buy it (possibly sending you to negative money, though that will probably only be a few instructions later down the line) regardless of whether you have sufficient funds.
I should note that we normally use the die in a game part as an example where this gets tedious. Think basic mario. Time running out, hit enemies, hit hazards, fall in a pit, poison mushroom, possibly get crushed... all of these can lead to a sub from the lives value where a simple cheat holding the single lives value is a nice bit easier. At the same time holding a life value once every frame to max might not keep you invincible if the game keeps the life value in the CPU during all its calculations, or you get more than the max value/your current max during that frame, in which case the hack that does the compare life and checks if greater than 0 bit is far nicer to go and fiddle with.
So yeah 1000+ instructions, even more if you account for sub types, many doing weird and exotic things that few would be able to explain in depth. If however you can get an understanding of the flow of operations and what it is doing, and change critical parts of it, most of which will be fairly simple, you can do some wonderful cheats, and also write documents like
https://www.dragonflycave.com/mechanics/gen-i-capturing for everybody to read and design in game builds to handle. The
https://stuff.pypt.lt/ggt80x86a/asm1.htm link from earlier is quite old but in later chapters does a good job in building up instructions into something you might consider useful to do in programming, the art of assembly one (
https://www.plantation-productions.com/Webster/ ) will eventually get there as well but will teach you computer science first, which you can also learn from that
UNSW computing playlist if you want something a bit more passive.
Naturally it gets a lot lot lot more complicated (I barely mentioned timing for instance -- not all instructions take the same time to perform), program flow skipped out stacks, did not mention the program counter (the program will note where it is presently at), status flags (if you check if something is negative you might want to note that somewhere, it is but one thing a flag might handle), and the registers for X86 are weird compared to a lot of other ones in that they stack on top of each other for the smaller values (AH and AL both go next to each other to form AX which in turn is a chunk of EAX so be careful sticking something in AH if you have some good data you want to keep in EAX. This is not common in other systems where most registers are an island undo themselves).
Anyway pointers and data types.
As there are limited amounts of registers you have plain old memory to stash data in when it is not being operated upon. It pays then to note where you stored this data, something to point the way as it were. As mentioned though modern programming can dynamically allocate memory as it is needed rather than have one programmer attempt to account for everything in the game all at once (or two+ programmers work closely together to make sure they did not step on the toes of another, which gets about as annoying as you imagine). At some point will be a hardcoded value (give or take ASLR) for which the path to the value you want that run/that instant can be started at, you might have to go through a bunch of pointers to get there (and possibly do some maths on the values contained) but you will get there.
Data types.
Computers started off doing simple addition of positive whole numbers. Negatives are useful to have so you have those next (though there are a few variations -- the first obvious choice of use the top bit in the value to indicate negative works well until you get negative 0 and have to account for that when you are checking to see if something is less than or at 0), fractional values are also useful if you start dividing things so you have those as well (in PCs these days floating point numbers of various precisions are pretty much what is used, however there are others used in older systems or more specialised calculations where the inaccuracies of floating point become troublesome*).
*10 divided by 3 is 3.33333.... however say it only stores 3.33 then multiplying by 3 I have 9.99. Now imagine that is money and all of a sudden I have 0.01 left over, multiply that by a few million transactions and then all of a sudden the morally unscrupulous programmer gets to retire. If you have ever heard of a penny rounding scheme then this is that. There are other problems with floating point (beyond it being slower) but they are usually variations on that theme.
Stacks of related numbers became useful so now we have arrays**, and they also bring their own area of maths (I don't know if you have suffered matrix and vector maths at school yet but yeah it does have actual uses in the real world, even more so if you find yourself playing with 3d graphics and calculations for it)
**level up happens. + 5 to all stats. Easy to have an array add 5, more tedious (and longer) to add 5 to each and every aspect of it. Have to do something complicated on top of that like +10% to primary stats and +5% to others... even more tedious but less so with arrays as you can multiply by another array. This is why C family tutorials will spend hours going over arrays and getting their usage down.
https://www.tutorialspoint.com/cprogramming/c_unions.htm is another. Linked lists (and doubly linked lists and all the rest) more still.
Again this is all skipping over things that various computer education courses will spend months on but hopefully it is enough for you to start making sense of things.
Tools
Cheat searchers like you started this thread off wanted to use are little more than slightly specialised debugging tools for programs.
https://www.hex-rays.com/products/ida/ is paid for for the current version but older ones are available for free.
https://ghidra-sre.org/ is free and positioned as something of a competitor to IDA. It is good though (it is something of the NSA's baby and they know how to hack)
http://www.ollydbg.de/ is a bit old school but still used by a lot of people, and in some ways a bit more gentle on newcomers.
https://rada.re/n/ is the last of the big ones used by hackers on the PC. Before the rise of ghidra it was probably the big open source competitor to IDA. Still has some great stuff in it though.
There are a thousand other tools handling executable packing (EXE and DLL files are not always just plain and in the open -- compression, encryption, protection... can all feature and game devs are some of the biggest users of it), DLL export and plenty more besides.
