I wanted to clarify something about scripts on a gameobject, maybe some of you can answer or at least give me some hints about the reason why every tutorials / scripts examples works that way :
In my case, i’ll take as example the FPS controller of the player.
So, most of the examples even Unity’s one are made of several scripts. One for the movement control and one for the mouse look. Respectively attached to the main gameobject which is the player and the other to the camera which is a child of the player’s gameobject.
Is it design this way to be more efficient (performance wise) or more convenient ?
Because since in our project we know how the player is made in terms of components and children objects, i’m starting to merge each c# script into one main “Player” script controlling every aspect of the player functionnalities (movement, mouse look, inventory, status…)
The last part is : the update function deals with a lot of things since everything is merged, is there an issue about that ? Does this impact performances on the script ? Is it better to have multiple instance of multiple scripts dealing with less calculations in the update function, or merging everything into one update function will be the same result ?
Splitting things up into many different scripts is mainly for organization purposes. Most people will split them up into different categories, like movement and camera. Splitting them up also makes it easier to find things and is just overall more convenient and easier to manage with big teams. So if you’re working with other programmers it is best to keep everything in categories and organized, that way more people can be working on the player at once. If you have everything in one file then only one person can be editing it.
Performance wise, it makes little to no difference. If you had a class in one script, and one in another, then just copy pasted them together, nothing really changes. The variables used (stuff that is stored in memory) stay the same, so you won’t be at much loss.
So an overall thought would be that, if you’re working by yourself, do it however you like. But if you’re on a team, it is probably best to go with a more traditional and organized approach that is easier for everyone to participate in.
It’s a good idea NOT to do this behaviour if doing things for a large amount of things, for example loads of bullets, alien attack waves and 100 enemies. If all will need updating each frame it is better to have them as objects preallocated with a control loop as opposed to each having its own Update.
But in most cases the above posters’ advice is a far better way to work.
Kind of an old topic but wanted to share my observation and in case i’m wrong get another opinion. I agree with hippo so far. Reason being , that scripts work in a time slice from the main thread so when you have too many instances of the same behaviour you divide the time frame into even more slices. That frequent switch between instances getting a slice of the frame update loop is killing perf, or at least it depends on how heavy the behaviour is. Also if you can decouple gameobjects with their data and keep data in one place and reference them inside a control loop as hippo says, it’s far better in terms of cache as well and it only requires one time slice instead of n(instances).
It may have just been a bug in my unity client, but when I was working with scripts, I had a main character script that had just about everything on it for the character specifically. Unfortunately, it seemed to have too much stuff that it was trying to do at once and the client would freeze up. It also did it in the test build. So, what I learned, which it is pretty obvious, is that everything has to come in a specific order to work properly. If you have so much stuff on a single script that you continuously get errors or performance problems, then this may be your problem. How does this tie in? Well, I just think it would be best to have things separated because of ^ organization, and also the fact that Unity seems to run better when things are separated enough for it to easily find and process things, when they have to happen at the same time.
I did a little test where I spawned either 10k cubes with their own script telling them to randomly move left and right every Update(), or 10k regular cubes and a single manager class loops through and randomly tells them to move left or right every Update(). This isn’t super scientific, but my older slow desktop rig had about 12-13 FPS average when the objects had their own script controlling them, and about 16 FPS average when the manager did it instead. I figured doing FixedUpdate() made more sense, so I tried that instead and the self-controlled objects averaged 8 FPS, while the managed objects got about 12-13 FPS.
And from that I conclude… well not a whole lot. Unless you have tons and tons of objects calling their own scripts (like many thousands) then it won’t make really any meaningful impact. But if you do have a high amount of objects it seems it could potentially pay off to use a single script to manage the many.
I don’t think your experiment was realistic. The improvement was there to support Management over Instances, it wasn’t as visibly impactful as you thought it would be. For one, 10k objects is difficult to handle anyway,which is why JobSystem is being developed. I’ve got an i7 8700 and a 1060 nvidia and I get 20-25 FPS for your unmanaged example. 10k objects are way too many. The new job system tries to handle such numbers and such use cases where you need to improve perf over Unity API using parallel code. You could do instantiation and transformations with CommandBuffers using Graphics.DrawMesh or use instancing etc and it would be so much faster.In terms of profiling using my own machine’s results based on your experiment,the unmanaged example,using LateUpdate uses 6+ ms collectively. The managed example, shows an average of 4.5. That’s almost a 30% increase in perf. That kind of perf increase percentage would be very desirable in more complicated scenarios such as normal game code. And that’s without all the microoptimizations that can be done.
FixedUpdate is mostly used for physics stuff .In the Profiler you’ll see that the calls made for FixedUpdate are 20k to 30k while LateUpdate uses exactly 10k. So changing that improves results.
No game is going to have so many gameobjects with that level of simplicity in their code. In most tech videos I’ve seen, you get glimpses from inspectors where gameobjects have 6-7 scripts on them. Now imagine that those scripts do not just translate stuff around. They do a whole lot more. Now imagine scaling that in an adequate number of instances as well.
Your right, it wasn’t really meant to be much of a real world test, and I used the high number of objects to intentionally bring FPS pretty low to compare the perf.
Also, I used FixedUpdate because I wanted to keep calling the scripts at nearly the same interval (using Update would mean it would work slower because of the lag, throwing off results more).
I figure there could be much more “real world” type testing done, with a scenario like your describing, like multiple scripts piled on for several different update/lateupdate/fixedupdate behaviors on a single object vrs a manager to see how that would work together, but I just threw that together to be a quick dirty test for drawing some conclusions about overhead of many scripts updating vrs just one.
If you would like to create a better, more realistic example I’d be happy to check it out and learn from it!
I haven’t read much yet into the jobs system, but what little I’ve seen it sounds cool, and I will be waiting to see how that turns out (I assume it isn’t yet available).
Doing the work in Update makes just as much sense. Using update doesn’t mean it works slower, it simply allows it to move onto the next update as soon as it can. So either way, it’s still an indication of which option is performing faster, in a more real-world way than FixedUpdate would.
Also make sure to do the test’s in a built version, not editor, as there are extra editor-specific callbacks that can affect results.
Yes, it’s a similar data-oriented system to the Job/ECS system that is in the works for Unity.
There’s also a similar free version to that addon you can find here:
Check this out https://www.patreon.com/LotteMakesStuff/posts.
She has two or three posts about the Job System. You can also check the latest Unites for some heavier examples. One was a strategy game with something like 42.000+ agents. And they seem to be working with some game companies to showcase/research the feature itself. https://www.youtube.com/watch?v=0969LalB7vw
