It'd probably be interesting to take a look at how my game's engine works compared to SNES games that probably had a lot more planning put in before development started. Since I just figure things out as I go, I try to keep everything especially flexible while trying to keep it efficient too.

There's also some aspects of how the code works that's inspired pretty directly by how Super Mario World hacks work, especially interactions with the level, but I have no idea what most games even do.

I guess a lot of flexibility I have in my game's engine is in the form of hooks, which I think I was introduced to though TI-84+ calculator apps which use them pretty prominently to add features to the OS.

I have code that sets up all the graphics registers for gameplay, and it gets used when unpausing or starting a level, and at the end it can just call arbitrary code that can override any of the previous stuff however it wants. I have another specifically for adding code to override how layer positions should be calculated, in case a level wants to scroll some funky way.

Similar situation for block interaction: whenever the game wants to know if a block is solid on a particular side, it'll get a per-block default but it will also check for a hook for that specific kind of interaction on that specific block, which may decide that the block isn't solid after all (or have the block or player react in some arbitrary way). That's how blocks that have their solidity switch on/off work in my game.