❗❗ *Caution:* This video was made using an older version of Unity ECS. While the core concepts remain the same, some of the API and workflows have changed as of ECS version 1.0. I would recommend checking out my ECS 1.0 tutorial video for a good overview of the latest standards for Unity’s DOTS: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-IO6_6Y_YUdE.html Once again, the theory behind the concepts of this video are still relevant, however the API has changed. Stay tuned for further updated videos on this subject. Please let me know if you have any questions either here or in our Discord community: tmg.dev/Discord
Hey all, thanks for watching this video! I know this video is probably a bit longer than it “could have been” if I just wanted to explain to you how job dependencies work. But with this video I really wanted to give you a practical example of how to use them rather than just “oh hey ‘job A’ depends on ‘job B’!” Again I know it’s not the way you would actually make a project like this, but I hope it helped you understand the quirks of job dependencies in ECS 😊
@@TurboMakesGames Not a problem! Would love a good tutorial or overview on Animation with ECS. There doesn't seem to be a lot on the topic and the best examples I have found have been from Philippe St-Amand with his Rival library (anything with Inverse Kinematics would be amazing).
Maybe Im thinking wrong about the whole job system, but one thing I don't understand is that all code examples schedule the jobs in every Update loop, can't you make a job that takes multiple frames and you want to access the data only after the job is "done"? For example let's say I click somewhere and then want to start a job that does some heavy work, for example a heavy pathfinding, that runs in the '"background" and can take a while and then once the pathfinding job is done I want to start the actual walking. But all job examples that I saw so far call schedule in Update, so every frame. Wouldn't that start a new pathfinding job every frame, even if the previous pathfinding isn't done yet? In traditonal C# code I would run the pathfinding in an Task and await it until the results are done, maybe my thinking is wrong, because I see jobs as tasks?
Yeah, that's a great point to bring up - in jobs scheduled in SystemBase Updates yes, the job will need to be completed within the frame they were scheduled. This does allow for parallel processing and reducing context switching, but it's not like asynchronous programming like you brought up. When scheduling jobs from MonoBehaviours, the jobs can take longer than a frame, so long as you don't force completion later in the frame. But this is definitely a topic I'd like to explore further on the channel, to give people some options for running code in the background over a longer period of time.
It's definitely something I'd like to explore at some point. Probably won't do anything with the official DOTS Netcode until we hear more from them, though I'd be more likely to do something with DOTSNET