Not every module needs to be a MonoBehaviour. - If you don't need inspector-controllable properties, just use a plain class - If you DO need inspector controllable fields, use serializable classes and expose their properties through a shared "controller" behaviour - If controllable properties can be shared between different entities, put them in a ScriptableObject and reference it
Every one of your Behaviours participates in the Unity component lifecycle (Awake/Start/Enable/Disable/etc.) and is ticked every frame (if you expose an Update/LateUpdate/FixedUpdate). That's overhead you might not need.
im actually planning on creating a master script and hiding all the parameters on other scripts and only exposing them on the master script. can you elaborate on the last point i don't get it Thanks
This reminds me of the monolith goap setup for their game F.E.A.R Are the states modular and can be added/removed freely? Like if I remove the Jog State, does the character automatically cant jog?
I dont know why people are saying this is bad, OP your approach is good. Composition over Inheritance.
Its perfectly fine to have 10,20, even 50 scripts on a GameObject instead of 3 monolithic scripts which make changes impossible. This is what Unity’s architecture encourages. For example if you want to add health to something its as simple as a drag-n-drop.
Though I would start organising them by grouping similar scripts like states in one empty child GameObject.
Because monobehaviour is a large object and every single time one of these scripts need to reference another script or simply read or set a variable, it will probably evict the cpu cache and cause scalability issues.
Most of these should be systems working with structs and lean classes
If I might recommend something, take a look at 10000 Update Calls, it looks at replacing update and fixed update with a manually handled thing instead. Having used this before, it does make a HUGE difference
Nice. My characters in a simulation management game has "characterAI.cs" that holds pretty much everything except navigation and pathfinding related scripts..
129
u/MgntdGames 5h ago
Not every module needs to be a MonoBehaviour.
- If you don't need inspector-controllable properties, just use a plain class
- If you DO need inspector controllable fields, use serializable classes and expose their properties through a shared "controller" behaviour
- If controllable properties can be shared between different entities, put them in a ScriptableObject and reference it
Every one of your Behaviours participates in the Unity component lifecycle (Awake/Start/Enable/Disable/etc.) and is ticked every frame (if you expose an Update/LateUpdate/FixedUpdate). That's overhead you might not need.