Performance question: put everything in one component?

We are just starting to work on our new game, and we are still figuring out how to set up some standards.

We definitely concluded that we need our custom basic component for all objects in our game even if we do, or do not use functionalities of that component. So... how can this affect the performance of our game? Does excess components on objects can make the game more laggy?

Also, what if we put all of our custom functionalities in that one custom component, even if objects actually use only some of those functionalities. Will that be to overwhelming for game performace?

What is more laggy: lots of stuff in one component, or lots of components on objects?
(of course, i suppose that it is better to put only those components that we actually need, but... just a question)

 

The worst performance is when a game is broken. Putting all your code in one monster script makes it difficult to design, test, maintain, and modify, all of which increase the chance of bugs -- not to mention the extra weight of code on an object that doesn't need that code (assuming that code is being run). Don't do this.

Keep your scripts as small and simple as possible. Each script should do one specific thing and no more.

The performance difference between a single script and multiple scripts is negligible. What you do in those scripts is much more significant. For example, say you have 100 scripts with this Update method:

Code (csharp):

1. void Update() {
2.     counter++;
3. }

It'll still be faster than a single script with this Update method:

Code (csharp):

1. void Update() {
2.     var allObjects = FindObjectsOfType<Transform>();
3.     foreach (var t in allObjects) {
4.         var counterScript = t.GetComponent<MyCounterScript>();
5.         if (counterScript != null) counterScript.counter++;
6.     }
7. }

This is a contrived example, but it should illustrate the point.

 

Code that doesn't run has no effect on performance. Write good code first, and use the profiler to determine where bottlenecks are later.

--Eric

 

Ok, thnx, we are still figuring out this, how to organize our project code and structure, since we are all new in Unity.

 

I guess this still depends on personal preference. At least part of.
I would probably prefer a single component with 200 lines of code and 100 functions instead of having 100 components with two lines of code in one functioneach - even, if all those components are doing only one specific thing.

 

You're looking at it from a much too atomic scale. The general idea is that for a car, a script should handle shifting(the transmition), suspension, steering, and an engine. Not a script to raise suspension or lower suspension for each wheel.

 

I don't know if there is THE method for what you are asking for.
I guess creating classes and gruping them by some kind of relation / functionality could be the best approach.

Make some useful code and then try to make it clean... I guess you will find the disaggregation that meets your requirements when performing that last step.

If whatever solution you find, makes you comfortable, then it is okay.

 

Splitting components up some helps dramatically with reusability and readability. Split components up too much and you loose it again. The optimum balance will vary between projects and systems.

Performance wise their is no appreciable difference.