I don't think there was a good advice how to split a class where everything seems to be connected anyway.
I'll address this for the sake of others who find this thread while genuinely looking for answers -- but I'm under no illusions about what you will think of me or my reply.
One of the reasons you haven't been getting more concrete answers is because you're asking a very abstract question. I can't know whether or how to break up your level class, because I have no idea what it contains.
But the general answer to the general question of how to break up a huge class "when everything seems to be connected anyway": you need to take a step back and look at it from an architectural perspective. What is coupled due to a genuine need for coupling, and what just sort of ended up that way? Obviously, everything IS connected to everything else in some fashion, or it wouldn't be a single program. But there is flexibility in how tightly things are connected, and in what is connected to what, and where those connection points are.
As an example, I have a separate class for generating the "blueprint" of a level. It handles all the procedural level level generation code, and creates an array with the results. That array is then passed to a different class which uses the array as a blueprint for actually building the level. This second class then keeps track of the locations of things during gameplay.
It would be easy to say that "deciding what to put where" and "putting it there" are too tightly coupled to separate without causing even more complexity, but I have found that not to be the case.
One technique that I've found is helpful for finding hidden/unnecessary couplings is writing unit tests, because this helps you think about smaller more isolated pieces of code.
Like everything else, design patterns and refactoring can be used badly, and make more of a mess out of code than it was before. But that's true of any programming technique, and doesn't happen when the technique is used properly & when appropriate. What makes structuring large bodies of code difficult is the need to simultaneously look at the big picture of the whole, and also the smallest decomposable parts at the same time.
Another thing is that should you split classes when they become "too" big. If so, why? What is the "limit" of lines of source code per class?
It's not the number of lines that's significant, it's the amount of work the class is doing, and what responsibilities it has.
