During my early Unity years, I challenged myself to create modules without using "Update" except when you need to accept Inputs from the user. This is something that I still follow and have also taught this to many of the junior devs in my company. It's almost always part of my TODOs for writing any thing. Events are the best.
New unity input system is also even based, so you don't need to run input anymore in an update loop (of course not all input). And btw share this video to juniors in your company, would appreciate :D
I've always done GetComponent just once in Awake() or Start() and assigning it to a variable within the object. Never thought of just dragging the reference in the Inspector, but good to know.
Svaka cast! Ovakvi detaljni tutorijali su nam potrebni! Kada sam poceo game development, moja prva prosta android igrica "Falling blocks" je jedva radila na telefonu upravo zbog lose optimizacije! Ali godinu dana kasnije, sa zavrsenom IT akademijom i dobrim znanjem C# jezika, sada svaka igrica radi u 60+ fps
The only thing you should do each frame is listen for player input. Everything else should be event based. Send out an event (I like Action/Func), and whatever system interested in knowing can subscribe to that event.
Even player input can be much easier to have as event-based thanks to the new input system. Once you've figured it out, it's so much nicer than doing crappy and possibly expensive checks in Update using if statements. The code is cleaner too.
Thanks for the video man.. (The sound was a little off coz your voice came only from the left speaker, just a notice) Waiting for more informative videos ;)
You welcome! I did mistake during recording, but that is improved in my latest video. Hope you will enjoy my other videos, and feel free to join our discord :)
Around 6:30 you say that update loop can only be disabled when game object is disabled, which is not true at all. You can disable individual components using Behaviour.enabled property
@@tomiczdarko Well its much less risky to disable single component. You just gonna have to remember that GetComponent call will require "includeDisabled" set to true. I'd say its actually more powerful if combined with events. Say your component is disabled by default but it subscribes to some events. When events fire -> Component will enable itself -> Do the job -> Go back to disabled state. I'd rather do that than coroutines since coroutines are annoying to manage, can be especially annoying if you start multiple and then you're gonna deal with interruption nonsense
@@saniel2748 I do agree. I wanted to bring awareness about coroutine to beginners, they can use them instead of an Update loop, especially if they need to wait for something and then finish which is way harder to do with an update loop. There are countless ways to do certain things, every problem has it's own approach, I didn't have time in this video to go with every possible endge case, just wanted to bring awareness. Anyway, thanks for the comments, really appreciate :)
Great video, great tips. Good job. Here's something else I like to do, maybe worth a try sometime. Good for performance, code readability, portability and coder sanity. In a monobehavior sub-class definition that I know I will need to call many of, often, I'll create a static list of the class within its definition. then OnEnable, instances of that class call a static method to register themselves within that static list if they don't already exist within it, and the app is running. and OnDisable, they unregister themselves under same conditions. Then I have one static 'UpdateAll' function that iterates through the list and updates them en masse, and as much as possible, without calling specific functions within the class implementations. Then once - per -often, i call TheClassName.UpdateAll(), and if any are registered, they update. This seems to speed things up quite a bit, even though internally it's probably very similar to what Unity does under the hood, I suspect there's added expense with the standard way from context switching or something, thread allocation who knows.
Manually calling an Update function for a list of GameObjects is a known optimization tip and it is way faster (if you have A LOT of objects of course) than Unity's built in automatic Update calls, because Unity does the Update callbacks from the C++ side, which need to be routed to the C# side to be executed, and that adds a small overhead for each call. And that's (one of the many reasons) why DOTS/ECS is fast: it does process Entities by groups, not individually.
You have to be careful with OnTriggerEnter or OnCollisionEnter too. And don't forget about the collision filter. What can you say about UniTask? As an alternative to updates and coroutines? Suppose we run a UniTask loop with Delay Frame(120) or just Delay(seconds) So that the check does not take place every second, but only a certain number of times per minute?
Coroutine: be aware that this is not multi-threading. The coroutines still run on the main thread, just making it easier organize code that should run for a specific time. But its not optimizing CPU core usage.
i really dont like to put anything in update and i try avoiding the most but sometimes im just not sure how to update a value without a start point, but as you stated, events is good to go
When I really need to make check in update. I will always go for fixedUpdate and if I can go even lower I will create a slowUpdate I only call 4x per second for some AI check for example and when they are out of the camera bounds I disable them. No one notice the difference in game except the fps.
Coroutines are easy but you need to be aware how many times you are calling it, I often find myself in situations where my coroutine is getting called multiple times which results in erratic behavior and I spent hours figuring out what is wrong.
Umh, I think you really scratched the surface here. Okay, those 3000/frame checks will take some time, but its not the most important thing here. First of all, you need to learn habit to periodically check for stuff that is less important. For example, enemy can check for path to your player every 0.25 or every 0.5s or so. Promity check does not need to fire every frame, it can five every brief time, like 0.1s. But the most important is that every Update() call comes with a cost even if its empty, due to Unity costly marshalling operation. So instead of having 1000 entiteis with Update() loop, its actually much much better to have one object that iterates over list of 1000 enemies and manually calls method that updates logic (this pattern also makes easy to include levers how often you need to timeslice that particular entity type).
But try this Public class EnemyController : Monobehaviour { float health = 100; bool IsDead { get ; set { IsDead = value; if(IsDead) CheckDead(); }} } Void CheckDead() { Destroy(gameobject); }
During my early Unity years, I challenged myself to create modules without using "Update" except when you need to accept Inputs from the user.
This is something that I still follow and have also taught this to many of the junior devs in my company. It's almost always part of my TODOs for writing any thing.
Events are the best.
New unity input system is also even based, so you don't need to run input anymore in an update loop (of course not all input). And btw share this video to juniors in your company, would appreciate :D
"The reason why all those early access games on steam are always laggy is because their developers didn't subscribe to my channel" 😂 Subscribed!
Man, this video is just insane, thank you so much. I subscribed.
I've always done GetComponent just once in Awake() or Start() and assigning it to a variable within the object. Never thought of just dragging the reference in the Inspector, but good to know.
I like your presentation. The only one I truly understand. Please keep these coming. Subscribed, and liked all of your posts.
This was an awesome video! Can't wait for more, specifically on coroutines!
Coming soon :) I always wanted to give in depth tutorial on coroutines because I think other covered only surface :)
Just the kind of content I was looking for!
Man, please never leave youtube, my game fps gone from 15 fps to 144fps (monitor max fps), thanks 💯
Thank you ! your way of explaining is very soothing and easy ! THANKS
Svaka cast! Ovakvi detaljni tutorijali su nam potrebni!
Kada sam poceo game development, moja prva prosta android igrica "Falling blocks" je jedva radila na telefonu upravo zbog lose optimizacije! Ali godinu dana kasnije, sa zavrsenom IT akademijom i dobrim znanjem C# jezika, sada svaka igrica radi u 60+ fps
Great video, I have subscribed.
Thank you!
My friend, your audio only goes into my left ear.
Thanks for pointing out! Will fix in the next video.
My brother, he is standing on our left.
This is really great information.
This video feels like a marvel henchman is menacingly teaching me C# instead of interrogating me lol
😂😂
nice content, you got your 1000th subscriber 😁
Awesome thank you!
thanks for the advice, very useful!
The only thing you should do each frame is listen for player input. Everything else should be event based. Send out an event (I like Action/Func), and whatever system interested in knowing can subscribe to that event.
Even player input can be much easier to have as event-based thanks to the new input system. Once you've figured it out, it's so much nicer than doing crappy and possibly expensive checks in Update using if statements. The code is cleaner too.
That sounds like a nightmare to debug.😮
You are hilarious dude. Subscribed.
Thanks for the video man.. (The sound was a little off coz your voice came only from the left speaker, just a notice) Waiting for more informative videos ;)
You welcome! I did mistake during recording, but that is improved in my latest video. Hope you will enjoy my other videos, and feel free to join our discord :)
Around 6:30 you say that update loop can only be disabled when game object is disabled, which is not true at all. You can disable individual components using Behaviour.enabled property
I agree. Though the point is the same :)
@@tomiczdarko Well its much less risky to disable single component. You just gonna have to remember that GetComponent call will require "includeDisabled" set to true. I'd say its actually more powerful if combined with events. Say your component is disabled by default but it subscribes to some events. When events fire -> Component will enable itself -> Do the job -> Go back to disabled state.
I'd rather do that than coroutines since coroutines are annoying to manage, can be especially annoying if you start multiple and then you're gonna deal with interruption nonsense
@@saniel2748 I do agree. I wanted to bring awareness about coroutine to beginners, they can use them instead of an Update loop, especially if they need to wait for something and then finish which is way harder to do with an update loop. There are countless ways to do certain things, every problem has it's own approach, I didn't have time in this video to go with every possible endge case, just wanted to bring awareness. Anyway, thanks for the comments, really appreciate :)
very good content!
Thank you!
My left ear enjoyed the video
Ahah you made my day 😂
Science you explain you can also explain about FIXEDUPDATE
You are the first one I finally got to understand thank you
FixedUpdate is coming very soon :)
Great video again ❤
Thank you!
Great video, great tips. Good job. Here's something else I like to do, maybe worth a try sometime. Good for performance, code readability, portability and coder sanity.
In a monobehavior sub-class definition that I know I will need to call many of, often, I'll create a static list of the class within its definition. then OnEnable, instances of that class call a static method to register themselves within that static list if they don't already exist within it, and the app is running. and OnDisable, they unregister themselves under same conditions. Then I have one static 'UpdateAll' function that iterates through the list and updates them en masse, and as much as possible, without calling specific functions within the class implementations. Then once - per -often, i call TheClassName.UpdateAll(), and if any are registered, they update. This seems to speed things up quite a bit, even though internally it's probably very similar to what Unity does under the hood, I suspect there's added expense with the standard way from context switching or something, thread allocation who knows.
What you are taking about is called an observer pattern. I use it often in tasks where i need to observe and make changes on input.
@@tomiczdarko oh thanks for that clarification, I figured there was a formal title for it but didn't know it. Yes very helpful sometimes.
Manually calling an Update function for a list of GameObjects is a known optimization tip and it is way faster (if you have A LOT of objects of course) than Unity's built in automatic Update calls, because Unity does the Update callbacks from the C++ side, which need to be routed to the C# side to be executed, and that adds a small overhead for each call. And that's (one of the many reasons) why DOTS/ECS is fast: it does process Entities by groups, not individually.
Thanks a lot for such great content, mate! Sub!
Welcome!
You have to be careful with OnTriggerEnter or OnCollisionEnter too. And don't forget about the collision filter.
What can you say about UniTask? As an alternative to updates and coroutines?
Suppose we run a UniTask loop with Delay Frame(120) or just Delay(seconds) So that the check does not take place every second, but only a certain number of times per minute?
i luckly can change my Audio out to mono because only left is weird haha. Thanks for the video anyway
Coroutine: be aware that this is not multi-threading. The coroutines still run on the main thread, just making it easier organize code that should run for a specific time. But its not optimizing CPU core usage.
True!
That is a cool AR game.
i really dont like to put anything in update and i try avoiding the most but sometimes im just not sure how to update a value without a start point, but as you stated, events is good to go
When I really need to make check in update. I will always go for fixedUpdate and if I can go even lower I will create a slowUpdate I only call 4x per second for some AI check for example and when they are out of the camera bounds I disable them. No one notice the difference in game except the fps.
is doing some thing like decreasing the amount of times you want to call your function in your update with some cooldown using X-=time.deltatime bad?
It’s not. It’s a unity way to decrease or increase passed time.
Subbed
At the beginning u felt if i didnt hand over ten k i was going to my knee caps slapped. So i subed instead
your voice is entirely only on the left audio channel...
Coroutines are easy but you need to be aware how many times you are calling it, I often find myself in situations where my coroutine is getting called multiple times which results in erratic behavior and I spent hours figuring out what is wrong.
Join our discord community and get the best Unity tips discord.gg/4CqnGESuRn. And sorry for the audio.
Hey, what’s the AR game you showed a clip of here?
Skeletons AR 2022, it's only available on Android as an open beta.
good one..
Umh, I think you really scratched the surface here. Okay, those 3000/frame checks will take some time, but its not the most important thing here. First of all, you need to learn habit to periodically check for stuff that is less important. For example, enemy can check for path to your player every 0.25 or every 0.5s or so. Promity check does not need to fire every frame, it can five every brief time, like 0.1s. But the most important is that every Update() call comes with a cost even if its empty, due to Unity costly marshalling operation. So instead of having 1000 entiteis with Update() loop, its actually much much better to have one object that iterates over list of 1000 enemies and manually calls method that updates logic (this pattern also makes easy to include levers how often you need to timeslice that particular entity type).
Good comment! I recommend everyone to read this.
@@tomiczdarko Thank you!
cool... like
But try this
Public class EnemyController : Monobehaviour
{
float health = 100;
bool IsDead {
get ;
set {
IsDead = value;
if(IsDead) CheckDead(); }}
}
Void CheckDead()
{
Destroy(gameobject);
}
let me guess you will talk about fixed update
Yes, coming soon :)
You seriously need to check the audio using headphones when editing your video.
I do. I am new to editing and made a mistake, hope it is better in my newer videos :)
Mate you recorded your video mono, its pretty hard to listen to you. Still, the topic you talk about is a really nice one.
RIP my left ear
Bros been insulting everyone whos looking at the thumbnail
I cannot feel my right ear
Ähmm, even 100 000 checks per second is nothing. This is not where the bottleneck typically is for a Unity game. What is expensive are api calls.
Agree
Audio only in left ear, can't watch.
Will be fixed in the next video, sorry :)
I quit unity then i moved to defold engine 2d and 3d lua ggame engine.
Well, very bad video that will lead you to the wrong way.
I disliked in first milisecond.
Me too. Because of sound. But after a while I changed my mind because content is on point.
My left ear enjoyed this