Cheats are one of the entry level (at times) assembly type hacks. I assume we are observing the gamegenie= rom altering, gameshark/codebreaker=memory manipulation distinction. Game genie is little more than patching method so I will ignore any formatting there. I should note that the DS and many modern systems will have their binary (as in the code that touches the processor) in memory so memory cheats on such systems can be very far reaching as you can edit them like you would any other section of memory.
Realistically I could argue that assembly of any form requires every type of computing knowledge and cheats do not escape that (I could easily make an example requiring database and network knowledge and there is also the "glitching" side of things but we will avoid that one for now). In practice I think we can find a middle ground.
Basic gameshark to assembly (and so game genie) takes one of two routes in my experience
1) You build a proto memory manipulation cheat engine- these devices will hook the code every vblank or some such and write the value that needs writing. You replicate this in the code but altering the game binary (otherwise known as hooking the binary) to add this memory manipulation.
2) You edit the game. Say for losing health there is probably a routine in the game that in higher level coding would read something like
IF [character hit]
THEN [do damage calculation+knockback+whatever]
ELSE [carry on with life]
Rather nicely if you already have a memory cheat for this then you can get a debugging emulator to halt the game when it sees something tickle this memory area.
Anyway many are your options at this point- the basic method would be to find the eventual "sub" instruction* for the health and turn it into an add, turn it into a NOP (no operation- it does it and skips to the next one) or do something else entirely.
The better method would possibly be to find the "if character hit" and make that a NOP or change the branch to always follow the "not hit" route.
This also brings you onto the walk through walls cheats which are somewhat similar. This is also where the "you must learn it all" things come into play- some games will run a parallel "track" (quite literally in a racing game) to adjust abilities accordingly, other games will have collision detection (I am sure we have all seen 3d games use paper thin things and call it an object, also I am sure we have all fallen through the level at some point). Still negating or modifying such things should be but a thought exercise once you have figured out what methods it uses.
Moon jump.... similar and not. If the game has double jump you are laughing as you just have to find the "check when air/double jump is done" section and patch it out- you can do this with basic cheats if you are good (it is likely just a little flag in the memory) but I would agree it helps if you have assembly skill to get there. Otherwise.... two main schools in you either modify movement (if jump pressed then move character 3m in the air becomes 6m in the air or a nice accumulator function if you are better) or kill gravity.
Spectator/ghost modes are a different matter- some might choose to use variations of the above two methods, some might have to code something properly and some might choose to find a spectator/ghost mode already in the game and force movement controls onto that.
One hit kill have various methods. The obvious one would be to crank the damage up to 11, another could be to use a variation on the "if hit" back in infinite health but apply it to an enemy and trigger their death routine, another would be to weave between the two and drop the enemy health to zero leaving the game to take care of the rest.
No encounter... much like moon jump if the game has an encounter manipulating spell/item you are laughing (if it completely avoids "all but boss" you can probably even do it in a memory cheat and even do it without so much as contemplating assembly if you are fast on the memory dump/scan commands- normal and scan it, immediately use encounter item and scan it- you probably now have infinite encounter items and infinite no encounter or a small enough pool to do it well). If it is a drops by 75% option it gets harder as you have to figure out what it does and how it works- if it is just a storage value and can be cranked to 100% you are laughing once more but if it is a hardcoded 75% then other things might have to happen. Should you be doing it "properly" or not have items then it might be best to figure out how random is random- is it a timer of sorts, is it number of movements..... and hose that up (again you might be in memory manipulation country). You could also do the actual routine governing it. Games with touch this enemy on the world map to encounter (my favourite sort of method here) probably want to go back to the hit detection side of things. My favourite anecdote here is skies of arcadia on the dreamcast would spin up the disc shortly before a random battle but I am not sure where I want to go with that right now.
I know your little list was examples of things you aspire to pull off rather than actual examples needed so I will stop here for the time being.
I took pains above to cover just how many options there are available to you for as you are changing how the game works you may have broken the game in some form- how many RPG games have the "must lose this to further story" fight? How you work around this is up to you- you can make it selectable, you can force it, you can instead make a button combo to refill health..... so you hopefully you can see why you need to think almost in circles. Trouble is such thought patterns are often the antithesis of modern programming languages (Python makes an effort to contrast itself with Perl and other languages that do have many ways to skin a cat) so you might face a measure of unlearning. Of course the games you play on (especially older consoles) had programmers with similar decisions when they were programming the thing in the first place (and as anybody that has done this at length will tell you- these programmers are not always functioning at "masters of the art on their very best day" level).
For an example on the point above there is nothing stopping the game from having many methods to do the same thing, the example I was given and will now give is think how many ways there are to die (and lose a life) on the original mario for the NES
Fall down a pit
Hit an enemy
Hit an obstacle
Run out of time
Later games also had false mushrooms, you could be trapped by movement....
In each case it might have a sub instruction to lose a life for each of them as branching is a pain and though memory is tight it would usually stretch to two instructions.
There is nothing stopping you from combining the two schools, indeed some of the "selectable option" type trainers do exactly this.
Another anecdote- 007 mode on Goldeneye on the N64. You could choose damage, accuracy, health and more for your enemies. Such functions also played into any allies you had (negated somewhat by a magnum being Natalya having a magnum) and are a nice example of programmer shortcuts and the "break the game" logic.
*Assembly uses mnemonics which are short letter combos and sometimes phrases that indicate what they do- some processors will have hundreds and some only a handful, in almost all cases there are only about 20 core ones (arithmetic, boolean logic, memory manipulation and branching) used for almost everything and the others are variations on those themes (straight branch, branch if conditions met, branch if other conditions met....). More complex processors like the modern X86/X64 (what your PC most likely runs on) do have very complex instructions for very specific tasks, most consoles up to the likes of the original xbox (which was basically X86) will be relatively simple though.
To answer your question in a far shorter manner you are going to have to learn data representation, this is true of all ROM hacking though but here you can probably afford to/will want to spend more time learning about how arrays, how things can be stored in memory (computers do like their 8 and 16 bit sections but there is nothing stopping the upper 4 bits, or some other arbitrary amount, from being something entirely unrelated to the other section, it usually is related in some way but if you are looking for a simple number flipping the top bit of it changes the number entirely) and probably pointers (not sure how common memory pointers are as far as cheats go on the earlier consoles, the DS and GBA use them all the time though) where most would be ROM hackers will spend most of their initial time contemplating how to find tables for a game and other such things. The actual manipulation is seldom more than basic arithmetic and boolean logic (primarily as processors seldom do more than basic arithmetic and boolean logic) and for most cheats (including the complex stuff) you will probably not have to write any more than a basic subroutine at best.
Links
I did prattle on a bit in my GBA/DS guide but for now I think PC style assembly (
http://www.plantation-productions.com/Webster/www.artofasm.com/Windows/HTML/AoATOC.html ,
http://www.coranac.com/tonc/text/asm.htm and
http://stuff.pypt.lt/ggt80x86a/asm1.htm on top of your existing code making will be better. If you have not already read it then
http://doc.kodewerx.org/ for pretty much every console is also on your reading list.
Topic: 6502/65816 Assembler (Read 4657 times)