I’ve been converting obj models to scripts for automatically creating and destroying levels that load into a scene.
The levels work with portal rendering, sectors and portals.
I call them visibility portals.
You can do impossible space with visibility portals.
The script creates game objects, portals and sectors.
There is only one list of all the vertices that make the level.
Each game object has a mesh renderer and triangle index list.
Portals find neighboring sectors by searching every sector triangle index list for the portal triangle index.
The portal finds two sectors that share the int index in the sector triangle index list.
The portal belongs to one sector then the other sector is the neighboring sector.
The neighboring sector is put in the portal script and portals are put in a list on the sector game object.
Portals vertices are put in a list in the portal script for portal rendering.
The idea I have is a game manager in the scene on a empty game object and it creates and destroys the levels.
I’m tired of importing a level from blender then connecting all the portals in editor.
40 levels is a bunch of materials and level data.
Is it okay to put all that info into one class?
Anything that works is “OK”!
Is it ideal? That is harder to determine, based on what you are saying.
The question of what should go in one class or another class is not always easy. But I start with the division of responsibility principle. It basically says that each class in an object-oriented program is responsible for one “thing”. But it is not always easy to define one “thing”, especially if you are designing objects that manage other objects (sometimes called “controllers”). Management is abstract.
Working code is king. If you find your code is hard to understand, refactor it. Use version control software like git, to give you the confidence to make changes, knowing you can revert to the last working version if something goes wrong. Make small changes. Write unit tests or other tests to help you to catch problems sooner.
A straightforward approach to architecting controller code is to start with one controller. Put everything in there. But as it grows, you will see that some members (functions, properties, fields) are tightly coupled, but that different sets of those members are loosely coupled, or have no interactions. Then you can break those members out into a new controller class. It could be a new component on the same game object, or a different game object, depending on the data (fields/properties). You want to put behaviour as close to its data as possible.
Sounds like you have a pretty sophisticated design, and you will probably end up with various controller classes, in the end: PortalController, SectorController, SpawnController, or things like that. Maybe there will be a MainController or a LevelController or some other top-level controller to manage the other controllers. Think about the work that needs to be done, with each controller playing a role, like a person on a team, and there is probably one team lead, or supervisor, or project manager, or coordinator.