Happy Sunday! I hope you find this video useful! See additional notes about using UniTask in the video description. 👆 To get started in Unity, add GitHub package: github.com/Cysharp/UniTask.git?path=src/UniTask/Assets/Plugins/UniTask
This channel is an absolute gem! I got stuck in a loop of refactoring/reimplementing the baseline of my project because each time I figured something out that completely changed my view on how to design any given component. Having several years of experience as a professional dev in java/spring, each iteration felt unsatisfying because I knew that my implementation was still incredibly basic and I could do much, much better if I knew where to look for answers. Looks like I found the exact right place! Not even an hour into your channel and 75% of the questions I had written down in the past few weeks have been answered! Thank you so much for your incredible work!
Thank you so much for the kind words! I’m really glad the channel is hitting the mark and helping you tackle those design questions-especially coming from a solid dev background like yours. It’s awesome to know the content is resonating and giving you the insights you need. Happy coding, and I hope the channel continues to be a valuable resource!
@@SystemOfATool happens to me all the time, except i wouldn't say "exactly". i make a thing. the next weekend git amend makes a better version of it. awhile back i wrote a status system, the next morning i woke up to the status system video just posting. i think i actually posted in the discord a screenshot of my commit saying " Status system complete" with a timestamp of like 2am the morning the status system video released. ( git amend videos come out 8am my time).
Parallel thinking. Situations arise in certain orders that produce certain thoughts. Red hammer. Coupled with predictive analytics pivoting into prompting/steering some into directions (think recommended content meant to guide your decisions). Therefore, if you fall I'm a similar bubble/grouping, you are likely to respond to certain events that the other person in the same category did. (predictive) Therefore, with some suggestions, you will do the same, so you are prompted.
Yet another absolute gem. The clarity with which you present these complex topics is greatly appreciated. I found your channel as a beginner six months ago, and it has been a guiding light. Dare I say, your examples have inspired me to take leaps I wouldn't have thought possible six months ago. I have also been digging into your SWE Crash Course repository -- immensely valuable! Thank you for your hard work, and sharing it so freely. 🙏
Love your videos man, it’s a pleasure to see such advanced C# with Unity ! I mainly code networked games so I use a LOT of async code for lobbies, user authentication and all the services. I was always intimidated by UniTask but thanks to your video I will start using it. The guy that did UniTask (cysharp) has also released a reactive library R3, I always have been curious to how to use it in a game project. A video on R3 will be incredible !
Thank you! I can't express my appreciation through better words anymore, going from beginner to intermediate is not a hard progress, but to advanced level is just entirely different, you're like a shepherd that leads us forward with such amazing and incredible content, please please keep it up and we all here will support in return! Once again, thank you!
Awesome video, I’ll be watching it soon. Unitask is often mentioned in job descriptions alongside UniRX. It’s great that you’re covering these topics. Looking forward to seeing UniRX or Zenject in action soon! 😊
I use UniTask in every project, even if I can't say that I have understood it's capability in it's full extents yet. Thanks for your valuable addition in explaining it - the official documentation is at some points a little hard to grasp. Same goes for UniRX / R3, so I really would appreciate if you add a video on reactive programming to the series!
Randomly found your channel and really appreciate your job. You do not mainstream things. You do what you really like and want to share. I can feel it. I really inspired by such type of people like you. You are making huge job to show something new. Hope this comment will keep your motivation. I know how its important to hear that you are on the right way. Wish somebody will tell it to me somewhen))
One of my favorite subjects... I'm crying coroutine tears of joy right now. Although I will say I'm using DoTween -a lot- to replace coroutines. But maybe I can infer your opinion on that by listening carefully. Anyway thank you so much for the great content.
One of the neat features of UniTask is it's extension methods for DOTween, I think you'll like that - though I don't talk about it in this video. Check the readme on the UniTask GitHub for more info on that!
Very glad to see you've done a video about UniTask! It is so much closer to proper C# development vs coroutines, which are terrible in general. I replaced all my update loops with UniTasks, and I gain a lot of control over my flow like that. The UniRX is also pretty interesting but I never actually got to using it fully as I have other packages and systems for that kind of stuff. I didn't know about the UniTask ThrowIfCancel, I usually just use a cts and if it's inside a monobehaviour I link the Destroy token to it. Anyways, as usual I love your content as you actually make proper videos with proper architecture and not, heres a script that does get component every update loop etc.
Oh, a few important things about UniTask that you haven't covered: UniTask can switch to the theadpool/maintherad `Await UniTask.SwitchToMainThread' And UniTask.RunOnThreadPool, which are pretty powerful and useful, just need to remember to return to the Unity context when switching around.
Thanks for mentioning Awaitable! Were a bit confused why Unity had its own version when Task worked fine. But having it pooled make sense, and good enough for my limited use of async. UniTask sounds like a beast tho
Yeah, Awaitables might be enough for many projects. The nice thing is, the basic usage is the same so it's not a big learning curve to understand both.
I've been curious. I've been watching for a while now, and you're definitely starting to pile up on videos, and each and every one of them is something unique and challenging. How much of the information you've shared do you retain? Do you actively use most of these techniques in your own games? I ask because I'm starting to realize just how big the gap is between a true senior and even a mid-level developer like myself. I'm sure you hear it all the time, but truly, truly impressive stuff. I've grown immensely as a result and I appreciate it more than words can say.
Generally speaking I choose the topics based on subscriber request and not necessarily something I'm actively working on myself, though often they will intersect. Of course, I do not retain absolutely every bit of information - nobody can - but you will find that the longer you work to build up your skills, it all becomes more intuitive, and beyond that I use tools like Milanote, Eagle and Obsidian to keep track of information. Thanks for the comment.
@@git-amend Thank you for the video. I learned a lot. I have some question about UniTask and async workflow in Unity: 1) How far can we push UniTask for our games for example I have a Detection System with Physics.OverlapSphere and i fire this method every 10 frames of the update. If i hook this with UniTask, is it work correctly or does it have downsides? 2) We know that Unity uses 1 thread for their game logic and it's called Main Thread. Some operations must be on that thread. What should we careful for, What should we avoid?
@@kutanarcanakgul5533 Using UniTask with Physics.OverlapSphere is fine if you're looking to control when the method is executed (e.g., every 10 frames), but remember that physics operations still need to run on the main thread. The big thing to watch out for, and you are on the right track, is that you should keep Unity API calls on the main thread, use UniTask to manage asynchronous workflows, but avoid attempting to offload Unity-specific operations to background threads, as this will cause errors. Unity's game logic, including physics calculations, rendering, and most of its API, runs on the main thread, and some operations must stay on the main thread. For computationally intensive tasks that are safe to run on background threads (like non-Unity API computations), consider using UniTask.Run or Task.Run.
Great introduction! Would be nice if you could cover some more advanced UniTask scenarios in future videos. I've had some real headscratchers with cancellation and nested awaits over the months.
Thank you for making this video. It really cleared up all of my conceptions. Will you continue using UniTask in future videos, will you stay with Coroutines or use Awaitables?
You’re welcome! I think I will probably use a combination for videos, but in personal projects I will be using UniTask more frequently. When we get to talking about UniRx or R3, we’ll definitely focus more on this library and integration.
1:28 I'd like to add an important point I learned years ago about garbage collection. I use this a lot in the game I developing (vids under channel) Using 'New WaitForSeconds' generates garbage. If you know the duration you want to wait before hand you can set it one time like this: WaitForSeconds someDuration = new WaitForSeconds(0.015f); And in the Coroutine you can call it as such: yield return someDuration; This avoiding garbage collection and being mindful of memory allocation. I hope this helps someone. P.S. If you needed it to be different for each instance of the class you can set it from the inspector in the awake method: [SerializeField] private float duration; Private Void Awake() { WaitForSeconds someDuration = new WaitForSeconds(duration); }
What you are describing is a simpler version of the WaitFor.Seconds method mentioned in the video. You can see that here: github.com/adammyhre/Unity-Utils/blob/master/UnityUtils/Scripts/WaitFor.cs
Thank you. The only limitation I'm aware of is that you cannot use UniTask.RunOnThreadPool (which is a newer version of the now deprecated UniTask.Run method, similar to Task.Run). Otherwise all functionality is on the main thread and should work fine.
I was thinking about mentioning that actually, because MEC behaves a lot like the new Awaitable class. There's a big upfront allocation (which some users have reported stalls their initial start times if they try to run coroutines immediately) but after that you have almost zero allocations because of the pooling. Personally, I really like it, and for a long time I imported it into every project.
I love UniTask, it's problably one of the best frameworks you can use BUT, and this is very important, when calling a UniTask, this should be done through a async UniTaskVoid instead of a async void method, because otherwise it won't run through UniTask!
Yes, that's a very good point and an oversight on my part that I should have mentioned in the video. I'll add that to the video notes. Thanks for pointing that out.
Thank you for the video. It would be interesting to know how debugging process differs between UniTask and Awaitable, as well as more advanced use cases. A video about UniRx from you sounds too good to be true.
Great suggestion, maybe we can dig into that in a future video. Also, there does seem to be a lot of interest in UniRx or R3, so I'll be looking into that more.
Great video, very helpful. However, you forgot to mention one important detail - MonoBehaviour has a built-in CancellationToken called destroyCancellationToken.
@@git-amend One more thing - they've also added the ability to switch threads inline: // Execute something on the main thread await Awaitable.BackgroundThreadAsync(); // Now execute something on the background thread await Awaitable.MainThreadAsync(); // And back to the main thread
the information you provide is invaluable! i wonder why don't you make a fully structured course on Udemy it will be much better to show how to use patterns in a practical and complete course
Time is the answer to that question... I still have to maintain my day job! When the channel is a bit bigger I'll be able to do something like that for sure.
May I ask how do you pause a UniTask? Let's say you have an in-game async process running and you press to pause the game, how do you pause the UniTask and then resume after the game is unpaused? Is that possible? Loving the videos btw 🙂
To pause a UniTask, you can use `CancellationToken` and `await UniTask.WaitUntil` to check for a condition before resuming the task. For example, when the game is paused, set a `paused` flag, and have the task await `UniTask.WaitUntil(() => !paused);` to pause execution until the flag is reset. This lets the UniTask wait until the game is unpaused before it continues execution.
@23:45 you mention that "both UniTask and Awaitable have one restriction... that you cannot await a UniTask or Awaitable more than one time." What does that mean? Do you mean this won't work? { await myAwaitable; await myAwaitable; }
That is correct, you will likely get an exception thrown. If you absolutely must await a UniTask more than once, there is a mechanism to use continuations with the UniTask.Lazy method.
Not advocating for coroutine but you could have create the new WaitForSeconds once outside the forloop and re-use it each tick to rekove most of your allocation.
This was explained in the video, and there is an existing implementation in the Unity Utility library using the WaitFor.Seconds method. See github.com/adammyhre/Unity-Utils/blob/master/UnityUtils/Scripts/WaitFor.cs
Thanks for pointing that out! Using UniTask.Lazy() with AsyncLazy is a great way to avoid the limitation of not being able to await the same UniTask multiple times
When it comes to making a new Token (after the previous one was cancelled), I must recreate the CancellationTokenSource to issue a fresh/uncancelled CancellationToken, correct? And if so, are CancellationTokenSources pooled, or is it just a raw 'new' to get one?
Yes, you must recreate the CancellationTokenSource to issue a fresh, uncanceled CancellationToken after the previous one was canceled. CancellationTokenSources are not pooled; you create a new one each time using new.
I think it's a great Asset, along with all the other ones that publisher creates. I'm not sure that I'll ever make a video about it by itself, but if we do talk about Zenject or similar, maybe I'll use that as an opportunity to explain Init(args) a little bit as well.
So do I get this right that if I have some very memory heavy async tasks to implement (or veeeeery many tasks in general), UniTask is the way to go. If there are not too many of them, using Awaitable is fine. Right?
Yes, Awaitables is probably enough for many projects. Since the usage of Awaitables and UniTask, at least for the basics, is similar, it's easy to use one or the other.
I started using UniTask about 8mo ago. I find it much easier to understand normal C# async operations. I still use normal coroutines if I want it to always run on the main thread, and the UniTask when I want an operation to run async.
@@git-amend Yep. I find it very useful for things like scene transitions, loading in addressables, game initialization, etc. It is now one the standard packages I use in every project (along with Odin, a some editor tools).
You are mistaking async await | asynchronous and running something on other threads. Everything that this video showed runs on a main thread just like coroutines. You can explicitly ask UniTask to use different threads, yet it has to be explicit. It's written here "Runs completely on Unity's PlayerLoop so doesn't use threads and runs on WebGL, wasm, etc." in the documentation. It's important because otherwise, you would need to make some scheduler to ensure the UI thread updates the text on the screen. While you don't have to do that using unitask without explicitly calling other threads. This is another reason why UniTask is goated. So you can drop coroutines altogether.
UniTask hooks itself into the Unity player loop so it runs wholely on the main thread, unless you tell it to switch threads. Probably similar to git-amend's video on hooking Timers to the player loop. Edit: He actually mentions this at 21:26
Yes, if you use a CancellationToken with awaits, it's a good practice to wrap them in a try/catch block to handle the OperationCanceledException that is thrown when the token is canceled. This ensures that your code can gracefully handle cancellations and perform any necessary cleanup. It will still work if you don't, but the exception will continue to propagate and could cause some unexpected behaviour.
Unitask generally offers lower performance overhead than Coroutines, especially for frequent asynchronous operations or when running on performance-constrained environments like mobile.
Its cool no heap allocations and many features BUT is it really helpful in game dev , i mean unless you are making everything procedural you dont actually need it, what if i want to combine meshes at runtime , textures and interact with main thread
Be aware that .waitAll() works incorrectly, finishing instantly, when there is an exception/cancellation in least one of the sub-tasks. I spent a long time looking for the reason in my code, and eventually found a 2 year-old issue on GitHub.
th-cam.com/video/Nk49EUf7yyU/w-d-xo.html github.com/adammyhre/Unity-Utils/blob/master/UnityUtils/Scripts/WaitFor.cs The reason is we don't want to allocate memory every time we create a new WaitForSeconds object. Instead we make them one time and reuse.
![Unity async / await: Coroutine's Hot Sister [C# & Unity]](http://i.ytimg.com/vi/WY-mk-ZGAq8/mqdefault.jpg)
Happy Sunday! I hope you find this video useful! See additional notes about using UniTask in the video description. 👆
To get started in Unity, add GitHub package: github.com/Cysharp/UniTask.git?path=src/UniTask/Assets/Plugins/UniTask
Usefull? No. Awesome and usefull? YES SIR! Thank you! :D Sub and like!
This channel is an absolute gem!
I got stuck in a loop of refactoring/reimplementing the baseline of my project because each time I figured something out that completely changed my view on how to design any given component. Having several years of experience as a professional dev in java/spring, each iteration felt unsatisfying because I knew that my implementation was still incredibly basic and I could do much, much better if I knew where to look for answers.
Looks like I found the exact right place! Not even an hour into your channel and 75% of the questions I had written down in the past few weeks have been answered!
Thank you so much for your incredible work!
Thank you so much for the kind words! I’m really glad the channel is hitting the mark and helping you tackle those design questions-especially coming from a solid dev background like yours. It’s awesome to know the content is resonating and giving you the insights you need. Happy coding, and I hope the channel continues to be a valuable resource!
You are literally posting exactly what i'm doing, video after video, i'm starting to worry.
Hahah, well purely coincidence I can assure you, but I hope it's working out!
@@git-amend Coincidence? You're obviously spying on me :D
@@SystemOfATool happens to me all the time, except i wouldn't say "exactly". i make a thing. the next weekend git amend makes a better version of it. awhile back i wrote a status system, the next morning i woke up to the status system video just posting. i think i actually posted in the discord a screenshot of my commit saying " Status system complete" with a timestamp of like 2am the morning the status system video released. ( git amend videos come out 8am my time).
Parallel thinking. Situations arise in certain orders that produce certain thoughts. Red hammer.
Coupled with predictive analytics pivoting into prompting/steering some into directions (think recommended content meant to guide your decisions).
Therefore, if you fall I'm a similar bubble/grouping, you are likely to respond to certain events that the other person in the same category did. (predictive) Therefore, with some suggestions, you will do the same, so you are prompted.
People like yourself make the Internet a better place. Thank you, super helpful!
Wow, thank you!
Finally CySharp is getting some love. Haven't been able to use Unity without UniTask for a while
Nice! Yes, I think not enough people have been exposed to this awesome tool, or maybe it's a bit intimidating, but I hope this clears that up a bit.
Same, mostly because most of HadashiA's libraries have UniTask as a dependency (VContainer and VitalRouter).
Yet another absolute gem. The clarity with which you present these complex topics is greatly appreciated. I found your channel as a beginner six months ago, and it has been a guiding light. Dare I say, your examples have inspired me to take leaps I wouldn't have thought possible six months ago. I have also been digging into your SWE Crash Course repository -- immensely valuable! Thank you for your hard work, and sharing it so freely. 🙏
Glad to hear it!
unirx or cysharp/r3 next please, I love the way you explain complex topics with such ease.
Sounds good, 1 vote for Rx
1 vote for cysharp/r3
@@manofapocalypse r3 is much cooler since unirx is now archived and replaced by r3
r3 pls
+1 for r3
My company just introduced UniTask to our workflow, so this is some amazing timing 🎉
That's awesome!
Love your videos man, it’s a pleasure to see such advanced C# with Unity ! I mainly code networked games so I use a LOT of async code for lobbies, user authentication and all the services. I was always intimidated by UniTask but thanks to your video I will start using it. The guy that did UniTask (cysharp) has also released a reactive library R3, I always have been curious to how to use it in a game project. A video on R3 will be incredible !
Thanks! Yes, there seems to be a lot of interest in UniRx or rather the new R3 library. We will definitely do a video on that in the near future.
Thank you! I can't express my appreciation through better words anymore, going from beginner to intermediate is not a hard progress, but to advanced level is just entirely different, you're like a shepherd that leads us forward with such amazing and incredible content, please please keep it up and we all here will support in return! Once again, thank you!
Thank you, that is very kind to say. Lots more content planned, stay tuned!
been using UniTask in sharp projects for over 2 years now, it's really good for UI's and gameplay, also really good for restapi calls
You quite literally answer my prayers xD I’ve been struggling learning all of this for months… MONTHS.
Thank you so much!!
Glad to hear it! Hope the video helps you out.
Awesome video, I’ll be watching it soon. Unitask is often mentioned in job descriptions alongside UniRX. It’s great that you’re covering these topics. Looking forward to seeing UniRX or Zenject in action soon! 😊
Sounds good, will definitely be covering a few more libraries soon.
UniRX has been deprecated by its developer. The new thing is R3 (and R3.Unity) by the same dev.
@@ClayManLanDay cool, i will check it out
Found your channel 4 months ago, I have never had such a fast learning in the field of game dev before, thank you very much from Ukraine
Thank you! Very glad to hear that!
I use UniTask in every project, even if I can't say that I have understood it's capability in it's full extents yet. Thanks for your valuable addition in explaining it - the official documentation is at some points a little hard to grasp. Same goes for UniRX / R3, so I really would appreciate if you add a video on reactive programming to the series!
Thanks for the comment. There will definitely be a video on R3, there has been a lot of interest, so expect that in a few weeks!
Randomly found your channel and really appreciate your job. You do not mainstream things. You do what you really like and want to share. I can feel it. I really inspired by such type of people like you. You are making huge job to show something new. Hope this comment will keep your motivation. I know how its important to hear that you are on the right way. Wish somebody will tell it to me somewhen))
Awesome! Thank you!
One of my favorite subjects... I'm crying coroutine tears of joy right now. Although I will say I'm using DoTween -a lot- to replace coroutines. But maybe I can infer your opinion on that by listening carefully. Anyway thank you so much for the great content.
One of the neat features of UniTask is it's extension methods for DOTween, I think you'll like that - though I don't talk about it in this video. Check the readme on the UniTask GitHub for more info on that!
That's great to hear. Very exciting.
aaaaah how on earth have I not known about this... This is so awesome
Nice, glad you have discovered it!
Great video, I would like to see a video on UniRX.
Noted!
Very glad to see you've done a video about UniTask!
It is so much closer to proper C# development vs coroutines, which are terrible in general.
I replaced all my update loops with UniTasks, and I gain a lot of control over my flow like that.
The UniRX is also pretty interesting but I never actually got to using it fully as I have other packages and systems for that kind of stuff.
I didn't know about the UniTask ThrowIfCancel, I usually just use a cts and if it's inside a monobehaviour I link the Destroy token to it.
Anyways, as usual I love your content as you actually make proper videos with proper architecture and not, heres a script that does get component every update loop etc.
Oh, a few important things about UniTask that you haven't covered:
UniTask can switch to the theadpool/maintherad `Await UniTask.SwitchToMainThread'
And UniTask.RunOnThreadPool, which are pretty powerful and useful, just need to remember to return to the Unity context when switching around.
Thanks for the comment, glad to hear you're already using it!
Git-amend delivers again!
Thanks for watching!
Thanks for mentioning Awaitable! Were a bit confused why Unity had its own version when Task worked fine. But having it pooled make sense, and good enough for my limited use of async.
UniTask sounds like a beast tho
Yeah, Awaitables might be enough for many projects. The nice thing is, the basic usage is the same so it's not a big learning curve to understand both.
That's an incredibly useful video. Thank you so much for it.
You're very welcome!
I've been curious. I've been watching for a while now, and you're definitely starting to pile up on videos, and each and every one of them is something unique and challenging. How much of the information you've shared do you retain? Do you actively use most of these techniques in your own games? I ask because I'm starting to realize just how big the gap is between a true senior and even a mid-level developer like myself.
I'm sure you hear it all the time, but truly, truly impressive stuff. I've grown immensely as a result and I appreciate it more than words can say.
Generally speaking I choose the topics based on subscriber request and not necessarily something I'm actively working on myself, though often they will intersect. Of course, I do not retain absolutely every bit of information - nobody can - but you will find that the longer you work to build up your skills, it all becomes more intuitive, and beyond that I use tools like Milanote, Eagle and Obsidian to keep track of information. Thanks for the comment.
amazing video! i think unitask is the only library i import into every single project i work on. its a must for me (:
Nice, glad to hear that coming from someone who uses it all the time!
Another awesome video, unirx or cysharp/r3 next pls
Coming soon!
This guys created new Reactive Programming package called R3. They released R3 on March 2024. It's a replacer of UniRx. Did you see that package?
I have not, but I'm going to look into it now! Thanks!
@@git-amend Thank you for the video. I learned a lot.
I have some question about UniTask and async workflow in Unity:
1) How far can we push UniTask for our games for example I have a Detection System with Physics.OverlapSphere and i fire this method every 10 frames of the update. If i hook this with UniTask, is it work correctly or does it have downsides?
2) We know that Unity uses 1 thread for their game logic and it's called Main Thread. Some operations must be on that thread. What should we careful for, What should we avoid?
@@kutanarcanakgul5533 Using UniTask with Physics.OverlapSphere is fine if you're looking to control when the method is executed (e.g., every 10 frames), but remember that physics operations still need to run on the main thread. The big thing to watch out for, and you are on the right track, is that you should keep Unity API calls on the main thread, use UniTask to manage asynchronous workflows, but avoid attempting to offload Unity-specific operations to background threads, as this will cause errors. Unity's game logic, including physics calculations, rendering, and most of its API, runs on the main thread, and some operations must stay on the main thread.
For computationally intensive tasks that are safe to run on background threads (like non-Unity API computations), consider using UniTask.Run or Task.Run.
@@git-amend Oh I understand thank you very much for the long and detailed answer, it helped a lot.
Thanks for the nice video tutorial. I always learn new things from you!
My pleasure!
One of the best things that happened in my previous workplace was to start using UniTask everywhere instead of coroutines.
Nice! Seems like a common sentiment.
Finally! Always love this one
Right on, hope you find it useful!
Great introduction! Would be nice if you could cover some more advanced UniTask scenarios in future videos. I've had some real headscratchers with cancellation and nested awaits over the months.
Sound good, I'll try to do something like that in an upcoming vid.
Thank you for making this video. It really cleared up all of my conceptions. Will you continue using UniTask in future videos, will you stay with Coroutines or use Awaitables?
You’re welcome! I think I will probably use a combination for videos, but in personal projects I will be using UniTask more frequently. When we get to talking about UniRx or R3, we’ll definitely focus more on this library and integration.
1:28
I'd like to add an important point I learned years ago about garbage collection. I use this a lot in the game I developing (vids under channel)
Using 'New WaitForSeconds' generates garbage.
If you know the duration you want to wait before hand you can set it one time like this:
WaitForSeconds someDuration = new WaitForSeconds(0.015f);
And in the Coroutine you can call it as such:
yield return someDuration;
This avoiding garbage collection and being mindful of memory allocation.
I hope this helps someone.
P.S.
If you needed it to be different for each instance of the class you can set it from the inspector in the awake method:
[SerializeField] private float duration;
Private Void Awake()
{
WaitForSeconds someDuration = new WaitForSeconds(duration);
}
What you are describing is a simpler version of the WaitFor.Seconds method mentioned in the video. You can see that here:
github.com/adammyhre/Unity-Utils/blob/master/UnityUtils/Scripts/WaitFor.cs
@@git-amend I jumped the gun with my excitement. You are very thorough which is why I love your videos
Very clear and thorough explanation. Are there any limitations from using Unitask in a WebGL app?
Thank you. The only limitation I'm aware of is that you cannot use UniTask.RunOnThreadPool (which is a newer version of the now deprecated UniTask.Run method, similar to Task.Run). Otherwise all functionality is on the main thread and should work fine.
Love UniTask, literally Odin and Uni are first in every new project. I would also to see if MEC ( More Effective Coroutines ) compare to Uni. :)
I was thinking about mentioning that actually, because MEC behaves a lot like the new Awaitable class. There's a big upfront allocation (which some users have reported stalls their initial start times if they try to run coroutines immediately) but after that you have almost zero allocations because of the pooling. Personally, I really like it, and for a long time I imported it into every project.
I love UniTask, it's problably one of the best frameworks you can use
BUT, and this is very important, when calling a UniTask, this should be done through a async UniTaskVoid instead of a async void method, because otherwise it won't run through UniTask!
Yes, that's a very good point and an oversight on my part that I should have mentioned in the video. I'll add that to the video notes. Thanks for pointing that out.
I thought unitask was just another glorified task but it is impressive. I'll use it in my current projects.
Awesome
Thank you for the video. It would be interesting to know how debugging process differs between UniTask and Awaitable, as well as more advanced use cases. A video about UniRx from you sounds too good to be true.
Great suggestion, maybe we can dig into that in a future video. Also, there does seem to be a lot of interest in UniRx or R3, so I'll be looking into that more.
Great video, very helpful. However, you forgot to mention one important detail - MonoBehaviour has a built-in CancellationToken called destroyCancellationToken.
That a good point, starting from version 2022.2, the MonoBehaviour class includes a destroyCancellationToken. I'll add that to the video notes.
@@git-amend One more thing - they've also added the ability to switch threads inline:
// Execute something on the main thread
await Awaitable.BackgroundThreadAsync();
// Now execute something on the background thread
await Awaitable.MainThreadAsync();
// And back to the main thread
Great stuff! Thanks!
My pleasure!
i love your channel so much!
Thank you so much!!
the information you provide is invaluable! i wonder why don't you make a fully structured course on Udemy it will be much better to show how to use patterns in a practical and complete course
Time is the answer to that question... I still have to maintain my day job! When the channel is a bit bigger I'll be able to do something like that for sure.
May I ask how do you pause a UniTask? Let's say you have an in-game async process running and you press to pause the game, how do you pause the UniTask and then resume after the game is unpaused? Is that possible? Loving the videos btw 🙂
To pause a UniTask, you can use `CancellationToken` and `await UniTask.WaitUntil` to check for a condition before resuming the task. For example, when the game is paused, set a `paused` flag, and have the task await `UniTask.WaitUntil(() => !paused);` to pause execution until the flag is reset. This lets the UniTask wait until the game is unpaused before it continues execution.
Thanks for the video 🙏🏻
My pleasure!
@23:45 you mention that "both UniTask and Awaitable have one restriction... that you cannot await a UniTask or Awaitable more than one time." What does that mean? Do you mean this won't work?
{
await myAwaitable;
await myAwaitable;
}
That is correct, you will likely get an exception thrown. If you absolutely must await a UniTask more than once, there is a mechanism to use continuations with the UniTask.Lazy method.
Not advocating for coroutine but you could have create the new WaitForSeconds once outside the forloop and re-use it each tick to rekove most of your allocation.
This was explained in the video, and there is an existing implementation in the Unity Utility library using the WaitFor.Seconds method. See github.com/adammyhre/Unity-Utils/blob/master/UnityUtils/Scripts/WaitFor.cs
23:45 BTW, to avoid this limitation for UniTask you can use AsyncLazy, I mean UniTask.Lazy()
Thanks for pointing that out! Using UniTask.Lazy() with AsyncLazy is a great way to avoid the limitation of not being able to await the same UniTask multiple times
When it comes to making a new Token (after the previous one was cancelled), I must recreate the CancellationTokenSource to issue a fresh/uncancelled CancellationToken, correct?
And if so, are CancellationTokenSources pooled, or is it just a raw 'new' to get one?
Yes, you must recreate the CancellationTokenSource to issue a fresh, uncanceled CancellationToken after the previous one was canceled. CancellationTokenSources are not pooled; you create a new one each time using new.
what do you think anout asset Init(args)? would be interesting to watch your video about it - it is an alternative to VContainer and Zenject
I think it's a great Asset, along with all the other ones that publisher creates. I'm not sure that I'll ever make a video about it by itself, but if we do talk about Zenject or similar, maybe I'll use that as an opportunity to explain Init(args) a little bit as well.
@@git-amend thanks for the answer!
So do I get this right that if I have some very memory heavy async tasks to implement (or veeeeery many tasks in general), UniTask is the way to go. If there are not too many of them, using Awaitable is fine. Right?
Yes, Awaitables is probably enough for many projects. Since the usage of Awaitables and UniTask, at least for the basics, is similar, it's easy to use one or the other.
The most thing I've been commenting about in this channel 😂
I solve everything using unitask
Awesome! Yes, this video has been a long time coming!
I started using UniTask about 8mo ago. I find it much easier to understand normal C# async operations. I still use normal coroutines if I want it to always run on the main thread, and the UniTask when I want an operation to run async.
Sounds good. I think a lot of people are intimidated by the library, but once they get introduced to it they tend to use it all the time.
@@git-amend Yep. I find it very useful for things like scene transitions, loading in addressables, game initialization, etc. It is now one the standard packages I use in every project (along with Odin, a some editor tools).
You are mistaking async await | asynchronous and running something on other threads. Everything that this video showed runs on a main thread just like coroutines. You can explicitly ask UniTask to use different threads, yet it has to be explicit. It's written here "Runs completely on Unity's PlayerLoop so doesn't use threads and runs on WebGL, wasm, etc." in the documentation.
It's important because otherwise, you would need to make some scheduler to ensure the UI thread updates the text on the screen. While you don't have to do that using unitask without explicitly calling other threads.
This is another reason why UniTask is goated.
So you can drop coroutines altogether.
UniTask hooks itself into the Unity player loop so it runs wholely on the main thread, unless you tell it to switch threads. Probably similar to git-amend's video on hooking Timers to the player loop.
Edit: He actually mentions this at 21:26
@@lmao01 I'd still prefer coroutines if I want to associate a routine with a mono behavior. Messing with cancellation tokens is a PITA.
so, do I need to wrap awaits in try/catch if I suggest a cancelation token usage?
Yes, if you use a CancellationToken with awaits, it's a good practice to wrap them in a try/catch block to handle the OperationCanceledException that is thrown when the token is canceled. This ensures that your code can gracefully handle cancellations and perform any necessary cleanup. It will still work if you don't, but the exception will continue to propagate and could cause some unexpected behaviour.
What is the performance overhead of Unitask? Wondering if it is faster than Coroutines..
Unitask generally offers lower performance overhead than Coroutines, especially for frequent asynchronous operations or when running on performance-constrained environments like mobile.
Thank you!
You're welcome!
NICE!
Thanks!
Very cool brother
Thanks 👍
Nice 👌
Thanks 😊
Idea for content: Roslyn source generator
Not a bad idea, that one has been suggested before on Discord. I'll give it some thought.
Waiting for Unity Jobs tutorial from you🙄
Its cool no heap allocations and many features BUT is it really helpful in game dev , i mean unless you are making everything procedural you dont actually need it, what if i want to combine meshes at runtime , textures and interact with main thread
Unity has own destroy token in Monobehaviour
Be aware that .waitAll() works incorrectly, finishing instantly, when there is an exception/cancellation in least one of the sub-tasks. I spent a long time looking for the reason in my code, and eventually found a 2 year-old issue on GitHub.
I don't suppose you have a link to the issue?
@@git-amend github.com/Cysharp/UniTask/issues/514
@@PurpleDaemon_ Thank you, very good to know!
Hello, does anyone has a link to the earlier video that he mentions here? 3:17 I'm interested in why he made that change
Thank you!!!
th-cam.com/video/Nk49EUf7yyU/w-d-xo.html
github.com/adammyhre/Unity-Utils/blob/master/UnityUtils/Scripts/WaitFor.cs
The reason is we don't want to allocate memory every time we create a new WaitForSeconds object. Instead we make them one time and reuse.