I would like to see one on reverse engineering script formats because I have no idea how to do it, despite having succeeded several times.
When deciphering script, actually going in and looking at the disassembly in a log file or a debugger is the best way to go. However, at times many of the script instructions can end up involving a lot of code, making it impractical for somebody new to assembly to understand. Also, some systems still lack a decent debugging emulator. In this instance, a simpler approach often works. What I would recommend is a variation of the data-corruption technique, where you change a single byte and note the effects in game. If you are hacking a game for a system that is fortunate enough to have a good debugger and breakpoints, you have some other good options as well. Almost all scripting uses "indirect" addressing to load the data from the script. On the NES or SNES, the log file or disassembly for an indirect would look something like:
In the case of scripting, this indirect LDA command will appear frequently, and each time either y or the $0A will be increased, so the bytes should be read sequentially. Once you see where the indirect LDA occurs, you can set a breakpoint for the program counter here (or a read on the indirect variable itself, $0A in this case). Then you can hit "run" repeatedly on your debugger, each time noting the value of the byte that is loaded, and the code will run until the next time a new script instruction is loaded. For games with large, complicated script instructions, this technique often allows you to visually see the effects of the commands. Often times though, several instructions will execute before you actually see something happen on screen. In these cases, the last instruction that executes prior to seeing something is some type of "wait for X" or "delay" instruction.
Also, you might note that if you set a breakpoint for the indirect variable ($0A above) instead of the program counter, you will sometimes see a byte loaded from a different program counter. Often times a script instruction consists of multiple bytes, where the first is the primary instruction/command, and the other bytes are operands that make the instruction more specific. It might take some practice, but after looking at some log files for awhile you should be able to note which bytes are the main instructions and which are operands. What works most of the time to identify instructions is that the value of the byte is used at some point to determine the program counter, typically through an indirect JMP($XXXX) or JSR($XXXX) type opcode. Some other methods used involve another indirect LDA type command, followed by a push to the stack, and then a return function (RTS,RTL). There is a different (though rarer and more inefficient) way as well, where the value of the byte read determines the program counter through branch statements. Ninja Gaiden does this for the scripting involved in its cut-scenes, reading a byte, then checking it repeatedly for specific values before branching to the code for the instruction.
After you've started to understand which bytes are instructions and which are operands, you are well on your way to understanding the script. For instructions that have operands, often times slightly changing the value of the operand and observing the results is enough to help you determine what the instruction and operand do. Once you have started to idenfity a few, identifying the rest gets easier. In cases where you need to understand the instruction itself and changing an operand(if any) has no visible effect, try replacing the instruction with one or more instructions that you have already identified (make sure to match the length of the original instruction), and then observe the results. There is a lot of trial and error involved, so make sure that you keep good notes throughout the process. Keeping notes helps you as a hacker, and also allows you to pass your knowledge onto others.