No Stupid Questions

Yes, that's a big part of it. Unity-based games generally follow most if not all of the framework that Unity defines, and since Unity itself is very well understood mechanically, that makes it very easy to find the right places to inject mods directly in between the game itself and the Unity DLLs that the game calls to act as a middleman or even completely replace the functionality that one side or the other would otherwise be implementing, and with that you can either create a mod on your own, or create a reusable modding API/framework for other mods to connect to. It's not quite as straightforward as modding a game that is intentionally designed to be moddable, but in general, it's pretty trivial once the basic setup work has been done and it's almost the same for almost any Unity-based game so it's not hard work to repeat on new Unity-based games either.

All software breaks down to assembly so you can reverse engineer it. What's lost is function names, variables etc. https://github.com/mytechnotalent/Reverse-Engineering

That's possible in some cases but pretty rare realistically. DLL mods are much more common. Windows (and most operating systems) have the concept of what they call dynamic link libraries (DLLs) which are basically modules of reusable code that a program (like a game) can use. Now these are not the same as game mods, but its their inherent modularity that makes them useful for game mods. It's also a big part of what triggers anti-viruses, as this is also a very virus-like behavior.

The trick is, anyone can trivially look at any DLL and see what functions are in it, and you can easily trick the game into calling a different version of any DLL file you provide, and the game won't realize there's anything different about it, it's just expecting the same function names to be there but it doesn't know if they'll do anything different than it expects (this is often how viruses work too). There are many common well-known DLLs like Unity or DirectX or SDL that a game will often be connected to and calling into constantly in a very deep and profound way and this provides a great starting point for a modder to gain access to the game logic. Once you have identified a DLL like this for a particular game, you can replace that with your own DLL that either has the same functions, or (more practically) simply stands in front of the real DLL and hands all the functions directly to the real DLL as soon as they are called while also providing a branching point where modding code can start to develop.

Once you have direct access into the code paths that the game is calling, you can run your own code instead of, or in addition to, the real code it is calling, and from there it's pretty much open season for modding. Once you're changing or replacing the running game code in any form, that's a mod. And usually the first layer that gets built at the DLL level is not a mod itself but rather a mod loader that instead of making any significant changes on its own, it's only job is to intercept as much of the game's logic as it can, then load other mods/DLLs to activate each one and pass control to them when needed or requested. This way, you don't need every individual modder to be able to figure out the exact places to do all this DLL interception which would almost certainly conflict with each other since everyone would do it in a slightly different way and in different places. Instead modders can just follow the documentation of the initial mod loader/framework and have access to everything in the game that the mod loader is already intercepting for them.

This is what's involved in making a game moddable. Sometimes developers do this work themselves, designing these access points into the game itself and provide their own mod loader and modding API. Obviously this saves a lot of work on the part of the modding community, but either option leads to pretty much the same place. These are what we sometimes call "code mods" or "core mods".

There are also games where some or most of the game logic and graphics functions are modularized into datafiles. In this case, you don't even necessarily need code mods for many things, depending on how much has been modularized into data, and how easy to acess that data is (often defined in text, XML, json, or other easily modified formats). You can also have mods that are just "data mods" where no game code is even changed at all, only the data files like swapping a 3d Model for a different model, or changing a texture to look different, changing the stats of an enemy or a weapon, or even adding content and whole new levels or areas purely with game data, and completely reusing and building on top of the existing code without modifying it.

Code mods and data mods like this are by far the most common modes of modding games today, but which methods exactly depends on the game and what is most suitable for it. Memory-access mods like you're describing are typically the most challenging to develop, the most fragile to maintain, and usually the hardest to detect, which makes them most suitable for cheating but rarely suitable for genuine modding. Trainers, cheat engines, aimbots, overlays and other automations often take advantage of memory access, and likewise tend to flag on anti-viruses and anti-cheats for obvious reasons. It's definitely possible to use them for legitimate modding but it is uncommon.

Basically yes, you find which values in memory are changing when you do actions ingame, and you can also figure out which functions run etc. Then you can for example replace the function call with your own function. I can't do this myself and it is very time consuming, you can watch tutorials on IDA or Ghidra to get a gist.

To be more exact, usually games additional dlls, and they will first try to load ones from the same folder as the exe, so you can modify or add a dll and whrn the game calls it make the modifications you need. So no need for a secondary process that monitors the game, but it is kind of hacking the game.

But often it is not that hard, c# or java dont get compiled into machine code and usually keep more metadata about the code, sometimes basically the original source code. Unity, Godot and UE all have some level of support (or reverse engined knowledge) for modding even if the game iteelf doesnt explicitly care about it. Of course it is much easier is the game is made with modding in mind though.