Arcade games are much the same as anything else. Arcades might have had slightly more CPU, RAM and graphics ability compared to contemporary consoles or PC but still operate in much the same way.
If it is one of the things MAME supports then a lot of the source code (which also the documentation of the hardware) will detail where things are found within the ROMs so you do also have that perk.
Otherwise it is standard level hacking approach.
There are two main ways to describe a 2d game level
1) You have a bitmap of sorts detailing every square (think drawing it on graph paper). More popular with single screen games that don't move the camera but not all such games will use this, and some that do move the camera (unrelated in most cases but cool so I link it https://docs.google.com/document/d/1iNSQIyNpVGHeak6isbP6AHdHD50gs8MNXF1GCf08efg/pub?embedded=true
) will also use this approach.
This ends up a long list of
2) You have a coordinate system. X, Y, type and any initial condition or maybe held items being a good start, direction being the next big one to include (older games might just have a different type for left facing and right facing) as well as maybe an item number/designator. You get to figure out the ordering of this, though it is usually not so bad. Theoretically it could be split up and have all one type together, then another (think how a game might group all the attack stats for a party, then do def, rather than doing atk, def, special, magic.... for each individual character) but I don't think I have ever seen it for a level, and it is not that hard to work with should it be the case.
With both approaches then layering aspects are popular here and levels may be split into several aspects (backgrounds, player accessible platforms, enemies, hazards...). Some may even mix and match coordinates with bitmap setups on different layers.
Some games might auto populate a segment (put two end blocks down and it will fill in the middle automatically) but nothing too drastic there.
If a game has a countdown timer on it then it can be in the header/footer/description section but it can also be hardcoded elsewhere in a game. Find two levels with different timers and swap them around to see if the timer changes. Likewise if this is a run to the right game doing a no going back level where others in the same game will allow it then that might be encoded somewhere in it too.
Newer games might have more advanced aspects -- if you ever see pokemon hacking forums discussing scripting they are likely talking about the paths that NPCs might take or levels might use to change rather than the game's text/speech.
True 3d games follow similar concepts, except the whole world might be a giant model and everything else plays in it. Racing games might then have a track defined too (The KCL format seen in various Mario Karts tending to be a good start if you want some baseline reading). Main exception being side on/2.5D stuff (New Super Mario Brothers on the DS being an example) which might well use a more 2d approach.
Pseudo 3d like isometric and the race to the horizon might be more a list of premade blocks (this is left turn, this is right, this is hard right, this is straight...).
Mode7 type deals is usually 2d but mode7 is more of a camera trick anyway, similar thing for many pinball type games if they are not just defined in the code itself.
After I find the level data (tracing, corruption, someone before me found it and made a note somewhere, elimination... it really does not matter) I usually start by making a minor tweak, or if I know where two are then swap them around to see what changes. For the bitmap type then your hex may resemble the level if you get it into the right length of window and start location in the editor.