i have a discussion running with a scripter about structuring and separating things in unity and I am posting this topic here to get the opinion of reasonable programmers with experience in structuring and planing things on projects. Btw i am not a programmer by myself but I think I am not that bad in structuring processes.
Anyhow, my suggestion was to split all necessities of a regular game in main categories/modules to have a logic script above using them properly. My goal is to avoid a mess of unlimited lines of code for a faster clean-up or other optimizations and the possibility to enhance new features in the future, instead of throwing everything into one script, like the scripter with whom i have this discussion wants to do. What would be a better way?
My conception would be:
LOGIC SCRIPT (contains all the game logic and connections to other scripts & events)
↳ PLAYER SETTINGS (movement, controls, behavior, spawn & death settings etc.)
↳ GAME MODE SETTINGS
↳ WEAPON SETTINGS
↳ etc.
Would my kind of approach make things complicated or is that the usual approach of a professional programmer?
He says my structure would be much more complicated than managing it in one single script. I just want to have more overview on each module. And I somehow can’t get used with the idea to throw every process of the game into one or two scripts! However, isn’t it possible to create classes out of each module i’d like to separate and use them in main script. Anyhow, he refuses to go with my idea, nor does he provide a different solution except to throw everything in one script.
Personally I would tend to approach it along the lines that you suggest. I generally like to separate different functionality into different scripts where it makes sense to do so.
For example when designing A character controller, I would have separate scripts for things such as movement/collision, input, movement parameters(max velocity, gravity etc.) and controller state.
Using this method allow me to re-use the character controller for both player controller objects and AI objects, by using a different input script for example. It also makes it easy to override the default movement parameters to do such things as simulating the transition from ground movement to water movement, by virtue of having two instances of the movement parameters class and simply swapping between them as necessary.
A single script would quickly become unwieldy as more features are added.
The judicious use of inheritance, interfaces and components is, in my opinion, often the best way to approach anything but the simplest of applications.
Thanks for your input! As you confirm the idea of separating things makes sense in term of having a better overview for after processes especially when the project starts growing. That confirms my assumption.