I’m creating framework that will make my office job much easier.
i want to consult with you guys about the architecture of it.
My Project always contain a script called “Scene Manager” which use to control the entire scene, but it is a total nightmare to get in that script and change it, its scrambled and messed up - classic Spaghetti code.
My idea is to divide all the responsibility to multiple scripts: 1.Camera Manager- provides the ability to navigate in the scene in a very similar way to navigate in the view port. 2. Device- Script that run on the device i’m modeling (as a part of a complete model) will be managed by Device Manager, that will control all the devices in the scene. 3. GUI Manager - Handle all the GUI. 4. Shaders and Textures Manager - will contain arrays with shaders, materials and texture that i’m using. 5. Some generic scripts that i built or downloaded from the asset store such as:
-Smooth look at
-iTween 6.Lights Script- Manage the Connection between all the Directional Light and all spotlights in scene to every object or gui object that interact with them in some special way.
and some scripts i wrote that build to be on a game object and manipulate it or it’s behavior in the scene.
all those scripts will be managed by the Scene manager that will hold references to each script and contain very general methods.
my question is:
Is this the right way? maybe there’s a better way to control and manage my scene, i’ll certainly will love to hear your opinion guys!
This is not really a discussion which requires a voting poll. Learning to separate concerns is a known part of OOP and COP. You already made mention of a lack of structure being spaghetti code so its clear its a good choice.
You will find yourself creating many more kinds of managers and components with each different kind of game or project you write code for. For example your no. 6 “Light Script” and its description is just to generic.
I will give you a personal example , in my framework code for a pinball game , there are lots of things that blink. Some of those objects are actual lights but not all, some are mesh objects with special material/shader set ups to blink them ( as if they were a light )
So I have an interface or base class to wrap them up into a new object logic named : “TableLightEmittingItem”
These are then used by all sorts of different classes I have to do controlled timed overlapping sequences that can be grouped eg :
“LightSequence”
“LightSequenceGroup”
etc
and then a manager class for this “TableLightController”
So this is not a controller of all lights in the project - but a controller for lights that belong to a specific purpose. I mean this controller of mine is dealing with the concept of lights where not all objects are even lights as I pointed out. The Controller doesnt know this though … neither do the sequence or sequence groups because they deal with an interface of a “light emitting item”
So your idea is good , create your classes but dont be surprised when the time comes to separate those classes themselves into more individual groups of concerns.
thanks a lot!
i will share my status in the next few month here in this post… i hope to get to some conclusions that can help others in building their own framework!