Brute force like that is not going to get you anywhere very fast, the numbers you yourself provide illustrating why.
When it comes to changing core mechanics like this then even if it eventually ends up as just a number then to get there you will understand how the game actually does things, which is to say assembly. You can do any number of graphical, level, text and maybe even audio hacks without a knowledge of assembly (though it will help, and some games might actually need it) but this sort of thing requires it for essentially every game*. this is why most people learning hacking will start with graphics and text, or maybe cheats, and then build and build from there.
*some games on newer systems, and a select few older ones, will use scripting languages which are easier to modify but even today they are not so common.
The CPU runs instructions. It will add numbers, compare numbers, manipulate numbers, manage the system, manage its limited resources, move/jump to other areas of code... in various ways. Different CPUs do things differently, may have different capabilities, and said manipulations are very small and low level (no** nice IF [thisnicelynamedvariable] is less than [thisvalue] DO [blah] ELSE carry on with game that anybody with some general language comprehension could probably grasp the meaning of, even if they could never spot a syntax error). On top of that you also have any other chips involved likely being different, different memory layouts and more besides.
**such things may have actually never really existed for 16 bit era and older games as the games themselves were typically programmed in assembly, albeit when you are doing that you do have some things to make it nice for you.
For the the megadrive/genesis you are looking at a Motorola 68K or 68000 for the main CPU and a Z80 for the audio core. Both of those extremely popular chips in electronics/computing in general back in their day but today considerably more obscure. Fortunately this very site aims to collect documents and tools that help with this sort of thing. It is a lot of information but for the most part it is a selection of basic instructions and instruction types that are used most of the time and anything obscure you can look up.
In your case you already have some things to look at but in the general case you would have to do some work to get there first (either work back through graphics or work up through something in the game -- most of those things you mention probably correspond to changing weapons which is easy enough to do in most games).
You would then need a debugging emulator. Alas I am not so familiar with the current ones for the megadrive/genesis and what they can do so I don't know where to point you. By the way if general emulators are lacking (and megadrive/genesis debugging side of things was when I last went looking) then we tend to point people at the TAS aka tool assisted speedrun crowd as they usually develop debugging emulators for their uses and such things can be twisted to work here.
Again as you know the numbers you have a nice starting point. What you would do is set a breakpoint (probably a break on read, sometimes termed bpr but that might vary with emulator) on one of those locations (no point doing two at once if you are learning).
The emulator will pause when the game reads it.
From here you can advance one instruction at a time and figure out how the game manipulates and interprets the number. For something like this I don't imagine you will be more than about 40 instructions before you have a grasp of what is happening, and may be somewhat less than that (if it is something which happens often within a game the devs will try to keep the numbers down, indeed that it crashes for some things being an illustration of this as checking it is valid would take extra time it does not have).