For games, I find that it is much easier to dynamically anaylze them while they are running to get an idea where you should be looking. Use something like cheat engine to get the address of health and use the built in debugger to find what writes to that health address. Then you can get the address for the instructions that write to the health and go back to something like Ghidra and start reverse engineering from there. But for small indie games, the dissasmbler in Cheat Engine is actually quite good depending on what you are trying to do.
An understanding of how C/C++ memory mangement works and how things like arrays/pointers etc normally get compiled down by the compiler. Having a general idea of how indie games a typically made (a loop which reads input -> updates game state -> draws to the screne) helps as well. In the case of finding what writes to the HP, you'll end up in a function that most likely updates game state, so you can then just walk up the functions to get to the main loop.
I spent a lot of my youth reverse engineering a small indie game. It go to the point where as a community we reverse engineered most of the in game objects into C header files. Then with the help of those header files, we made custom AI possible. Used a DLL to detour the normal AI function to our function and in that function we loaded Angelscript files that had access to the original game objects so they could control the objects. Ghidra didn't exist back then, and IDA was too expensive and the Cheat Engine dissambler was bad, so we reverse engineered everything in Ollydbg.
This was of course for a tiny indie game with a custom engine. I imagine now days with everything being made in Unity/Unreal etc, it's much harder to reverse engineer. Also x86 calling conventions were nicer than x64 imo ;).