When your game is compiled into bytecode, then all the script files disappear and are mixed into one giant mush of instructions (gross oversimplification, but it helps to get the idea). So it rarely matters how you organize your code across files for performance or memory consumptions. What matters is what that code actually does.
So when you wonder how to organize your sourcecode, then priority number one should always be readability or maintainability. See also the current hot network question "What are the benefits of multi-file programming?" on software engineering stack exchange
If you want to reduce the RAM footprint of your project, then you have to look at the actual content of your scripts and how you use them.
- Every component of every game object has a bit of management overhead. So having one large MonoBehaviour will often be slightly more memory efficient than lots and lots of small MonoBehaviours which do the exact same thing.
- This memory consumption is per instance of your script. If you put a MonoBehaviour on 1000 game objects, then it consumes 1000 times the amount of RAM if it's only on 1 game object (again a slight oversimplification, but it's a usable rule of thumb).
- But the actual memory footprint of each MonoBehaviour instance depends on how much data it actually stores in its public, private and protected member variables. A component which has just a single integer will consume a lot less RAM than a component which contains a large array of long strings. So if you have some MonoBehaviours which contain a lot of data but that data is only required by a small subset of objects in your game, then extracting that data into a separate component which you then add more selectively can save you memory.
But in most real-world Unity projects, the main contributors to memory consumptions are not C# scripts. They are the build-in Unity components and the assets they use. So before you start to look at the memory footprint of your own scripts, first consider if you really need all of your assets, which Unity components you put on your game objects and if you use those components in a memory-efficient way. For example, did you know that every single time you change a material.color
, Unity creates an entirely new Material asset in memory?
If you would like to know which parts of your game contribute for how much memory consumption, then you can use the Unity Profiler to find out.