Afraid I am not that familiar with the day to day use of lua in desmume (this is not really my thing, and if I do a challenge run it is usually within the game's own framework) but I reckon I can do an overview and otherwise point you in the right direction.
Finding memory location is basically just finding cheats
For the GBA but works the same on just about everything
https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial
https://gamehacking.org/wiki/Hacking_NDS (if that is down do a search for enhacklopedia as that is the base document that various places mirror)
The more advanced ROM hackers and cheat makers will have a mental library of things devs have done in the past and things dev could do as a possibility (if I want stats then I tend to expect them to all be like stats, say every characters attack stat one after the other, or every character/weapon/spell/item having their own individual list one after the other or at set locations), possibly some tricks (if you want the super rare only available after a 40 hour side quest/grind sword then you can do that, however if item 1 is the rusty kitchen knife you start with, 2 is the first sword in the shop, 3 is the big sword, 4 is magic sword... then keep ticking up numbers for things in your inventory and eventually you will find the rare stuff, or alternatively you can probably buy 50 potions to learn where it is in memory, the only picked up once or twice in dungeons thing is most likely a few bytes away from that), how games tend to be put together (if I am looking for something in memory I will have a good idea of when it will be put into it, or at least of a list of good starting locations, which can help with certain things, and also can do tracing
https://www.romhacking.net/documents/361/ ) but that just makes my life easier by virtue of it rather than strictly being necessary for most things.
Lua
http://wiki.desmume.org/index.php?title=Faq#What_is_this_Lua_stuff_I_see.3F
Lua is a general purpose programming language (some circles in game hacking have their own specific things, not my favourite thing to see but is what it is), seen in many things but game wise it is emulators that mostly we see it from (hacker and tool assisted speedrunner, though they can be different emulators).
https://www.lua.org/
The main reference most emulators will be built to mimic, which does include desmume, is the NES emulator FCEUX (it is also one of the best examples of a debugging emulator)
http://fceux.com/web/help/fceux.html?LuaScripting.html
Looking at
http://fceux.com/web/help/fceux.html?LuaFunctionsList.html
emu.loadrom(string filename)
Loads the ROM from the directory relative to the lua script or from the absolute path. Hence, the filename parameter can be absolute or relative path.
If the ROM can't be loaded, loads the most recent one.
savestate.load(object savestate)
Load the the given state. The argument is the result of savestate.create() and has been passed to savestate.save() at least once.
If this savestate is not persistent and not one of the predefined states, the state will be deleted after loading.
If it is matching in functions (or at least those ones) then to that end combine a basic memory read of the value you found with the cheat searching inside a basic IF ELSE (lua might use a different phrase but IF ELSE is what most will know it as in general programming) style loop* (
https://www.tutorialspoint.com/lua/lua_loops.htm seems like a reasonable start) and then those things for loading ROM and matching savestate (which you would make ahead of time to be on the right level with all the necessary preconditions). I don't know what you would have to flash up a message saying do this to proceed but there should be something somewhere in that, or at least something external you can call, or just have a list of things). Get the basics working and you can then start doing say random loads of things. Technically you don't need a savestate either as you could generate all the data necessary and inject it into memory (could even carry things, say lives, over from previous games if you want to make things follow through, though you can do that easily enough with cheats).
*I don't know how much programming you already know. We do have a general intro to such things
https://gbatemp.net/threads/so-you-want-to-learn-to-program.371255/ but a more applicable to this might be
Anyway more is better but something like described above can be done with some basics, and if you grasp it here then when it comes time to learn programming for real you will have a leg up. If nothing else then for the sake of others playing along at home
Computers/processors have maybe three main functions.
1) Maths. Adding things, subtracting (in some cases), multiplication, division (the GBA notably lacks it in the CPU and has to be an extra function)... for various different styles of number (signed, unsigned, floating point, higher precision floating point, fixed point, grids/matrices/arrays, larger values, smaller values...), plus boolean logic, plus certain types of shuffling data around (shifts, rotates, floor, ceiling, masks though masks might also be boolean
https://help.libreoffice.org/Calc/Mathematical_Functions https://www.osdata.com/topic/language/asm/shiftrot.htm ) or
sorting it and a few other related things. Everything mentioned thus far is very useful in a lot of different situations and likely what you will spend a good chunk of your initial learning programming getting drilled on. Here then... basic maths like you might do in a calculator will probably do, probably not even trigonometry is necessary for this sort of thing though the more you know the more creative you can be with some of the things you do.
2) Housekeeping. There is only a limited amount of space to do things with so things need to get shuffled in and out of registers (the size of these being what determines the "bit" of a machine/OS, and when it says 32 bits it means 32 1s or 0s in a row, possibly only about 20 of them, unless it is the NES and in that case technically 3 but practically 2 of them and they are 8 bit). Higher level languages handle more of this for you at the cost of speed, Lua is a very high level language so will spare you most things.
3) Program flow. Maths and fiddling with numbers is fun and housekeeping is necessary. The good stuff is when you can do maths and then depending upon the results of said maths choose a different path to go down. Branches and jumps,
https://xkcd.com/292/ , loops (you might want to do something over and over, or over and over until it is finished, or do something if something happens but something else if not) and various other words meaning much the same thing as all those then all being part of this.
This is also where a lot of code goes wrong and where a lot of exploits can happen.
To that end if you also want to learn the common errors in programming then it will help too (not least of all because you as the new to programming type will be making many of them yourself)
https://textexpander.com/blog/the-7...-errors-in-programming-and-how-to-avoid-them/
Also means you can have some fun but setting values beyond what the game might expect, quite good for challenges as well if you want to throw people's normal expectations/play styles off a bit)
A nice example of some of the fun that can be done here
https://www.romhacking.net/forum/index.php?topic=18717.0
A more basic example but for the DS
https://forums.desmume.org/viewtopic.php?id=10957
https://forums.desmume.org/viewtopic.php?id=11217
Beyond this everything is how creative you want to be.
Random game selection rather than set progression maybe, could even be a branching path depending upon performance.
Setting inventory
Setting a handicap (stats, maximum 3 ammo at any one time)
Maybe messing with controls (up is down, run jammed on, no shooting...)
Little randomiser maybe (might need to learn level editing basics for this one)
Jumping between one room in one game, another room in another game when you exist that first game's room, before jumping around some more... Or maybe just a quick and easy way to do different level order, repeat a level/segment, or maybe a boss rush. Can even do something silly like "beat your score from last time" which might be hard if they played to win last time and now have to beat that where a person that held back might have an easier time.
"Die 5 times", or maybe load savestate in choice locations and get them to die or do something special and die afterwards.
Finish exactly on/exactly with/...
Randomly load a savestate from a few seconds back just to mess with the player.
Combination of goals rather than simple score or whatever
If not a random savestate then random turbo mode, or random slowdown (messes with rhythm which in turn messes with players that play to it)
Force certain graphical layers off
... this could go on for a while. All relatively easy to do, give or take playing to the point in the game where you make the savestate (remember you have cheats and savestates of your own)
If you want to know how to do the hardware thing I speculated upon then that is a far greater project. The harder part would likely be merging games together and not having them interfere with each other, though the assembly is not likely to be anything other than tedious. If none of that or the previous thing makes sense or you can't ask sensible questions about what you might want to have to do from a general programming understanding of things (don't expect you to know specific header and file call methods of the DS, would expect you to speculate on their existence as a general thing and hurdle to overcome) then you have a long road ahead before you get anything there. Personally I could do it but would sooner grab a DS flash cart, reset option and savestates, and possibly just leave it as a manual thing.