1. I presume that would include whatever coordinate systems are in play and might well change something in this, though if the speed is still a separate value and instead just an instant teleport at opponent position - some probably array (if going around a loop then - 20 to Y in one place might be behind, in others would be ahead).
3. I have no idea of the specifics of this console.
Usually there will be an emulator with a debugger inbuilt, or the means to farm it out into another program (GDB being the most popular of the open source options, leading to things like
https://wrongbaud.github.io/posts/ghidra-debugger/ , though others will use IDA). In some cases hardware debugging becomes an option, though this is usually reserved for debug hardware on older machines and machines with a real firmware/underlying OS running all the time (which the Vita should be, the PSP had such a thing so can't imagine this does not).
These will give you access to things that read and write memory (not much different to cheats but can be more convenient), registers and breakpoints which are keys to the kingdom, possibly also some graphics, network and audio viewers depending upon the emulator.
Anyway breakpoints and crash course therein.
In traditional computing your memory can be doing one of three things.
Reading data
Writing data
Executing code
Modern security makes the latter a bit more tricky on various levels (see rings on PCs or indeed discussion of Harvard architecture and alternatives if you are bored) but eh.
Break (related to the pause-break on your keyboard above the page up button) then stops all execution and says what you told me to wait for just happened. There are also watch/log options in some cases so you can review it a later (useful if an area is hammered constantly and you care more about exceptions to the norm).
There are then three main types
Break on Read aka BPR in most cases. It stops when the area(s) you told it to watch get read from.
Break on Write aka BPW in most cases. It stops when the area(s) you told it to watch get written to.
Break on Execute aka BOE in many things but also BPE in others.
Run to line is a popular option in emulators but in reality is a special case of break on execute. If you are already on the path you might then say come back when you get to this location, or just skip ahead a bunch of stuff that you know/does not concern you and don't want to have to press yes 40 times if "stepping" through instructions.
Break on access is a thing offered in some cases and combines various things (while an execute might technically have to read something in the first place to do it then it counts as separate in most cases).
You find something in the chain that does what you want, cheats being part of this puzzle but also graphics (in classic 2d games you will have something like an object area memory handling sprites aka objects, whatever changes this screen location after a jump or indeed changes sprite to jumping pose will take its cues), audio (if channel whatever reliably fires after you jump then whatever triggered that will have taken a cue or eventually end up dealing with something you actually care about) and controls (if something happens after you press start then it will have had to read the control state or its debounced location -- you tend to copy control states say once a frame to avoid issues with mechanical switches aka the buttons on any controller from messing you around by having to go through oxide layers, maybe wearing a bit and whatever else).
Anyway this all concerns instructions in code. It will be assembly which for many is the final boss of learning ROM hacking. It is harder than python but also not that bad when it comes down to it.
Instructions for my money get broken down into three camps
1) Maths. Addition, subtraction (at least in most modern machines), multiplication, division (again at least in most modern machines). With possible versions to handle various data types (adding an array being different to simple unsigned integer, which is different to signed, maybe longer values, maybe float values... this is how you end up with many instructions on modern CPUs but actually not that much underneath it all). Basically still the same as playing with spreadsheets in most regards
https://help.libreoffice.org/Calc/Mathematical_Functions
2) Housekeeping. mov in most instruction sets (don't know if the vita uses something odd but something similar will exist) is what copies data from one register to another, push and pop get data from registers to the the stack and vice versa (helpful when you only have a handful of registers measured in bits -- if a system is 32 bit it is because the general use registers are this)
3) Program flow. Maths is interesting and all but games are often literally defined as a series of decisions (no decisions, no game, so much for candyland and snakes and ladders I guess) which usually in normal programming gets expressed in discussions about loops (IF ELSE, FOR EACH, WHILE and such like) but here will probably be various flavours of compare and branch even if they do much the same thing. This is also where most hacks come in as here is where you change things like if hit then remove health to make it so the hit never happens, though the maths can also be changed (subtract from life count location soon becomes add or NOP aka no operation aka do nothing, in the case of the former then all of a sudden hitting something might not damage as much as heal you, or boost nitrous if you have found that in the meantime).
I doubt there is a guide worth reading to learn basic assembly for the vita. I usually then point people at the likes of
https://www.plantation-productions.com/Webster/ and
https://stuff.pypt.lt/ggt80x86a/asm1.htm and get them to read the first few chapters at the very least such that it starts to make more sense.
This can also help but does not go in as hard for assembly, though if you are more hazy on programming in general then is very good stuff
On assembly then unless you exclusively stick to the oldest of old then learn one and you can learn two, learn two and three will be simple enough, as will all the rest. The main differences then coming in the types of maths available, nature of jumps/branches and how you read/write normal memory (PC stuff allowing it in most instructions, most other things have dedicated read and write to memory). Oh and how you find data in the ROM/ISO. For most things GBA and older on cartridges then basic tracing is easy as the cartridge is in memory (know where something is in ROM because you say found it in a tile editor or via more conventional hacking means and you can literally read the command that is fetching it or vice versa.
https://www.romhacking.net/documents/361/ being for the GBA but a nice guide to it all), for newer stuff then it will tend to be abstracted behind a cartridge read command which in some ways actually makes life nicer as you know what the whole file is, and possibly how any compression or encryption works.
Some debuggers will have way more functionality than that. Logging is one of the more useful as this way you say want to learn about jumping in a game (maybe to make low gravity). Here you would do anything but jump. After starting logging then get to a quiet point in the game if you can but then you idle, move, punch, accelerate... anything you like but jump, now jump, everything else from background animations to music to general movement should have been seen before, jump however will then be the last new code executed and thus you have what you want to look at without having to fiddle watching button presses or work backwards from graphical or audible results. Do enough logging and you can also spot hidden functions and possible bonus content.
This is how many advanced cheats will be made -- basic infinite potions is the proverbial kiddy pool of this all, more advanced stuff might start looking into flags and inferring layout* and assembly approaches then sort the men from the boys -- while it is generally considered more in the realm of ROM hacking I can happily say some of the best applied assembly hackers out there I have ever seen/met move in cheat making circles.
*I usually use the example of inventory cheats. You could do the infinite potions search routine on an end game sword that takes you 40 hours to farm form. Don't do that though. Get infinite money, get to the first worthwhile shop, buy many starting daggers such that you have a code for infinite of those. Nobody cares though but inventories will tend to be one of two approaches, three in the modern world.
1) Each item will be a fixed location in an array/memory area (think cells on a spreadsheet) and the value there tells you how many you have.
2) Each item will have an identifier and number you have. You will see this more in games with limited inventory and inventories you can rearrange but not exclusively.
3) More modern things might have each say sword pickup as a unique set of encoded data not unlike a character's stats. Speaking of stats don't level up 500 times to improve the luck that only goes up every 10 levels. Find something more basic and then it will either be with the rest of the data of that character, or if each character's atk value is with the rest of the party followed by def followed by... then carry on with that and luck is probably after that somewhere even predictable locations away.
Anyway 1) and 2) will also be how people find hidden weapons that might only be unlocked by hidden conditions, or were dropped by the devs for being overpowered or something. Also how many play as hidden/boss character cheats are made (find whatever value corresponds to the chosen character, then the next... easy enough with menu select and savestates, bosses will still tend to be in there as other values usually immediately after playables or at the end of the range, though you might have to try all of them).