How to maintain a large Level class?

[Krice]

I have a Level class from which some special level types are derived, but most of the code is in Level class. It has also a member Level_Map class which is kind of strange, because it could have more low level generation code. Also, there are separate classes for most feature generation (corridors, rooms, rivers, etc.).

Since Level has roughly two main operations: generation and then actions that happen in level during the gameplay, my plan is divide the class to "base" class with generation and actual Level class with gameplay operations. In a way Level_Map is redundant so it could be a part of that base class.

The deriving style is probably not important, because I just want to split the class to those two main operations, because it's so huge. I may have to open the base class to public access I guess. I'm mostly thinking out loud, but if someone has more experience on OOP I'm happy to know your opinions.

[Krice]

I planning to split the base class to two types of classes. One for tile based "low level" class with only tile and object generation, then next level has routines which generate shapes (rooms, corridors, rivers, etc.) and finally the Level which has gameplay operations. I think there could be even three splits for shapes and then the main sequence of generation (which creates stuff in certain order). Yes, I think this starting to look better.

[Krice]

I think for me at least the big revelation was that you don't have to create a class structure which has "useful" classes for each level of inheritance. In this case only the last level of inheritance is ever used as an object. It doesn't even make any sense to create objects from lower level of classes. But the split to different "levels" of functionality is such a great way to make the source code cleaner and more manageable which is important in large projects.