Here's an amazing artistic representation of what I'm talking about with the pathfinding. Every chunk is assigned an integer value that represents the 4 possible directions through which the chunk can be entered by X (represented here by the inwards-pointing arrows).
The pathfinding algorithm can take the chunk X is inside, and then the chunk that Sonic is inside (or, the chunk that X currently believes that Sonic is inside). The pathfinding algorithm reads every chunk as a simple grid, ignoring anything inside the chunks, but only looking at the entry/exit directions. If a neighboring chunk does not have the same entry/exit direction as the currently focused chunk, then that path is discarded. This is repeated for every chunk until all that's left is the path to Sonic's chunk.
Inside every chunk is a set of tiles (not depicted in this image) that X uses for lower-level pathfinding. This isn't much more complicated than his current behavior, except that these would have additional triggers based on which direction that X is planning to leave the chunk. So, in Green Hill Zone, if X needed to move upwards, and he's in a chunk with a slope, then there will be a tile that tells X to stop, spin-dash, and launch himself off of that slope. A complex behavior like this would be very hard and tedious to implement without splitting the pathfinding into chunks like this. X doesn't worry about any of the lower-level pathfinding tiles inside the chunks until he's inside a corresponding chunk, which is important for performance.
I've circled a few instances here where this approach would cause problems unless I added special exceptions for these specific levels. I would really like to abandon the Sonic 1 levels entirely and just make original levels that are designed with this system in mind, but I could make this work if I really had to
>>545046568
Sonic Overkill or something edgy like that