Same as everything else.
Games typically have text in them, graphics (which can be some text representations and also what you will likely be looking at when it comes to editing a font), audio, gameplay and some code linking it all. You can do a lot without going into the code world but the best hackers will be able to manipulate that. There are also things the devs can and did do that might make a game harder to hack than a simplistic ideal or some other games.
For text then most usually start with learning to make tables. If you have ever used a code like A=1, B=2, C=3.... then games often use their own rather custom setup here and the would be hacker tends to then have to figure out what a game (or indeed section of game) used. This data is collected into a file called a table file that various tools beyond that can use to view, extract, edit (or at least attempt to edit) and reinsert.
Relative search is what most start there with Roman alphabet games (Japanese, Chinese and other such languages can be harder here as relative search is of limited use)
http://www.romhacking.net/utilities/513/Games don't read text like modern text viewers, browsers and whatnot and thus need to have something tell it where everything is and by extension how long it is. For this you have values somewhere in a game that tell it, point the way if you will and thus we have pointers. I usually liken them to contents pages in books -- rip out a bunch of pages and count the number of pages it should be normally and you will be ahead in the book, stuff a bunch in and now behind. Various rip out and stuff in (no translation is ever likely to be the exact same number of characters after all) and you can see why pointers get broken and need to be fixed when editing text.
Graphics.
The basic tool of choice is a so called tile editor. Each system tends to have a few formats it mostly relies upon and these can different between systems, so much so that most tile editors will split things up by system.
I like
https://www.romhacking.net/utilities/112/ as an entry level option myself but there are plenty of others.
There are simple tricks like backwards searching (find the thing in an emulator memory/sprite viewer and search the ROM for that and you might find it) but a lot of people will simply open the ROM and press down/page down a lot until they find something useful.
Audio varies between systems. As megadrive audio creators were often highly regarded as coders in their own right then you tend to have to get down and dirty with the hardware unlike some later systems where you might have simple tools to convert to midi.
To that end grab some hardware documentation and a debugger, or hope someone came before you and blazed a trail.
Gameplay ranges from levels, to stats to all manner of things in the middle of that, and includes actually being able to design a game -- I am sure we have all played some boring hack, server setup or something made by someone that merely has a bunch of overpowered stuff and made it boring as a result.
This gets a bit involved for a simple forum reply so I will defer to my GBA/DS docs
http://www.romhacking.net/forum/index.php/topic,14708.0.html for level editing basics.
Stats. Usually numbers in the memory somewhere. Can be edited many times, though some games might calculate them or assign them by level.
Code then.
I usually encourage people to learn to make cheats as a first thing
https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorialGet good at that and much of what follows is made easier.
After this most would probably look at some tracing, though some might look at hardcoding a cheat
https://www.romhacking.net/documents/361/ is for the GBA but is much the same for all systems. Afraid I don't have a good suggestion for a megadrive debugging/debugger emulator these days but you should be able to find something (might start with the tool assisted speedrun set if you are struggling otherwise).
Anyway tracing will see you able to follow things back from memory to the location on the cartridge, as well as what was done to it if something changed along the way (compression, decryption, simple alteration of some form).
The hardcoding a cheat thing comes up as once you have found it the very same thing that allows you to break on a write to the memory location holding say a graphics you are interested in for tracing works just as well for the lives counter in a game. Find the instructions that fiddle with it and you can change a subtract to an add or simple set and thus now have infinite lives or go one further and find something like
https://www.dragonflycave.com/mechanics/gen-i-capturing for your game of choice.
Somewhere along the way you will also pick up a static disassembler -- the ones from emulators that run in game are useful for a lot but as not everything runs in a given period in a game you will want something to reference against and for that then static disassembly (as opposed to the dynamic/runtime ones from emulators) make a nice text file of instructions to pick through.
We had a discussion on SNES assembly a little while ago that might also provide some insight as again much of the underlying logic carries between any system be it a humble bbc micro or a modern PC game.
http://www.romhacking.net/forum/index.php?topic=32527You can do this to understand any aspect of the game. Further hackers will then see to add extra functionality in the game -- better fonts for translations, fix bugs, multiplayer maybe, add new in game actions that might have appeared in sequels...
One of the things that most commonly gets in the way is compression. The megadrive was old enough to avoid most of it compared to newer systems but it is still present in small amounts, and usually quite custom.
https://ece.uwaterloo.ca/~ece611/LempelZiv.pdf serves as a nice primer on the various types of compressions seen out in the wild. Being a rather lower power system as these things go mean you will mostly see simple forms like run length encoding (RLE), maybe some simple unpacking and utterly primitive LZ compared to the crazy stuff seen elsewhere so there is that.
Save games also feature in here, and usually when it comes to assembly as games will have a checksum to make sure the save did not get corrupted (or edited by a cheater). Or if you prefer back to the A=1 B=2... thing from before. Add up all the values in the message before this sentence and then imagine someone has changed some words, is it likely to be the same value? Welcome to the world of hashes and checksums. They can be anything, though again the megadrive is on the weaker side of computing power so tended not to delve into full blow cryptographic stuff that is trivial today.
Topic: how to modify sega genesis games ?? what tools should i use? (Read 4147 times)