Re Lua as it pertains to emulators.
Lua is a programming language. Fairly high level scripting but never the less full quite Turing complete programming language able to manipulate binary data quite happily.
https://www.tutorialspoint.com/lua/index.htm
https://www.lua.org/
It got popular to add to emulators, today most commonly seen in the tool assisted speedrunning community but has roots elsewhere.
https://fceux.com/web/help/LuaFunctionsList.html is probably the main reference grade implementation by which all other things are measured, though some emulators like
https://tasvideos.org/LuaScripting use subtly different names for things which you get to convert between.
Interpreters are also made for things, the DS for instance having a couple each with a quite appreciable homebrew scene within it.
It is run outside of the baseline system (the GBA is a 16 megahertz ARM7 with less than 512K of RAM all in, most of which will be used by the baseline game.
http://problemkaputt.de/gbatek.htm#gbatechnicaldata ) but largely aware or at least capable of peering into the memory, CPU and whatnot of the emulated device (without many of the same restrictions either).
This means you can then use a high level language with the power of your PC to effect changes within a game you are emulating. Changes within a game alone is a fairly impressive trick as to do it inside the game you are probably going to be learning ARM assembly, or whatever assembly your console of question needs (it varies between CPU types, and the associated hardware also changes how things play out), assembly being a very old and consequently having quite the barrier to entry for many. The power of your PC means you can do things that would take a seriously capable coder a great deal of effort, or indeed blow anything they can do with it out of the water -- your GBA is never going to be able to play a 1080p H265 video, your Lua script could detect a cutscene being played, disable the emulator and flash up your media player with fan remade scene, PC rerelease, console version, whole film..., soundtrack the base console would never be able to handle or so forth. It goes further still and being a program it can reach out and touch another emulator and now you have a 2 player mode in a game by whatever means you care to have (shared inventory, money, AI partner/player subversion, whatever the equivalent of tetris garbage blocks might be for your game).
The downside is it will need an emulator supporting it to run. Not so bad in days of old when everybody expected the PC to be the platform, since consoles, phones/tablets, raspberry pis all gained nice emulators then that is a rather more tricky proposition, to say nothing of people running things on hardware with mod chips and flash carts that you are pretty much excluding**.
**technically some of the modern debug over network, USB or whatever options mean timing issues aside you could probably get something going on with a remote host doing logic but eh, likewise some of the background OS running and providing options for hackers (if your control remap hacks are easy to employ for any game as opposed to luck or a slog then this is probably that) might be able to squeak in a Lua interpreter if nothing else.
https://www.dropbox.com/s/b2kuma6zs89di8n/Metroid.lua is an example of something done. Most probably start by making Lua scripts for cheats, which have the added bonus of being able to be made more complicated than "always be writing" or minor check and then write to instead be rather more complicated loops
https://www.tutorialspoint.com/lua/lua_loops.htm which means things that see the game crash, or want to be fine tuned (I don't want infinite health but I do want minimum, except in this scene/level... you are pretty much done at this point even for a complicated engine like the DS and newer, GBA is not a slouch (
https://doc.kodewerx.org/hacking_gba.html ) compared to older systems where "always be writing" or "write when the button on the cheat device is pressed" or "game genie is basically assembly coding" is in play.
Can also get it to load savestates, combine that with a check on score (or take damage, or death, or run out of bullets...) and maybe some simple memory writes to carry data over or set things up. Congratulations you have a nice challenge mode implemented, switch between games (they will include options to load games in the functions.
https://gbatemp.net/threads/possibility-of-game-changes-when-i-x-with-ds-emulators.577526/ ) and now you have a nice evening entertainment where people swap between games (possibly even on a screen by screen basis) without possibly even knowing what an opcode is.
https://textexpander.com/blog/the-7-most-common-types-of-errors-in-programming-and-how-to-avoid-them is also worth knowing at this point.
It does not make you a ROM hacker overnight -- you will still benefit massively from understanding the concepts that ROM hackers know and employ but it does both remove the barrier to entry of having to insert your changes into hardware (want to do a sprite edit, great inject it directly into VRAM when you see something in there, no need to figure out compression, injection, dodge a variety of animation limitations/memory write speed limitations...
.... I think I have another for the list of articles I should write. Really wanted to finish the finding hidden menus/cheats/easter eggs first.
Source
