Unity Job System - A Practical Code Example

[@InfallibleCode]

📦 Download the Example Project at www.patreon.com/posts/34702445

[@danielyu3010]

Great video! But I think you actually forgot to set the allocation to persistent.

[@isaacsurfraz3858]

Your presenting style and overall pace has gotten miles better since a year ago. Congrats on the great progress!

[@Rytech_Dev]

Is there a way to cancel a job system mid execute

[@hamzarylan7895]

i guess im asking the wrong place but does anybody know a method to get back into an instagram account..? I was dumb forgot my account password. I love any tips you can offer me.

[@jessekenzo8700]

@Hamza Rylan Instablaster =)

[@robelso5646]

Absolutely stunning tutorial! I'm so grateful there are developers like you that take the time to make such polished tutorials!!

[@happyfarang]

Great stuff. I need to watch this a few times but i can see a future where i can master this now - and yes, more on the issues that we will bump into is welcome in future videos

[@RussPainter8]

There was a live stream the next day which goes a lot slower and deeper into why things are happening.

[@magnusm4]

Next step will be mastering how to set linear code on the GPU rather than on the CPU.

[@Sarkahn]

Great video! A couple things though, at 7:55 when changing the data in the NativeArray, it's not really right to describe this as a "quirk of the job system". You're changing a value type inside an array, you would need to read the data, change it, and write it back to the array, regardless of whether or not you were inside of a job. Also typically with this setup you would want to schedule the jobs inside Update then call complete inside LateUpdate, this way your job actually has a chance to run in the background while other things are happening instead of just immediately blocking the main thread until the job completes.

[@RussPainter8]

Interesting. Could you complete them on the next update? Or is that just getting crazy?

[@Sarkahn]

@@RussPainter8 You could! You could even wait for the job to finish on it's own before completing it, but obviously in those cases the results of the job would be one or more frames behind what the player is seeing, but that might be fine depending on what you're doing.

[@OTadashi162]

It's great to have a real world usage example. I haven't tried JobSystem yet, but looks awesome how it's easy to improve the code.

[@ruslan_yefimov]

Just asking.. Have you tried it for the last 2 years?)

[@XZYSquare]

you overwhelmed me with the intro and I know what that stuff means.

[@dreamisover9813]

Nice video - by the way, the job system example video you did back in 2018 I believe was one of the most helpful videos I found to get my started with the job system back then :)

[@modernkennnern]

I tried using full-DOTS on my first ever game. It feels very nice and intuitive at the start ("This object can move straight forward, can rotate on the X-axis"), but if you're getting somewhat further than just a basic level then it starts getting very difficult to know how to proceed. I scrapped that entirely after about two days and tried a standard approach. I occasionally get that itch though, you know

[@carlosmspk]

You should try going full-DOTS for multiple projects, rather than working on a single project and trying to correct it. As you do things a particular (bad) way, the patterns will start becoming intuitive to you, and for each new project you'll find yourself coding things differently off the bat, simply because you know what you'll need later, what's useful in what layout, and how it should be structured. That, or, of course, follow tutorials...

[@wes5457]

Amasing video , your capacity for explane all simply is hight. Gracias.

[@Kolyasisan]

8:38 meow

[@InfallibleCode]

Lmao good ear 😹

[@JuniorDjjrMixMods]

Very nice and simple, I just think it should make the comparison a little fairer. A part of the performance didn't come from Jobs, but from the fact that you only have 1 Update method instead of many. I'm starting to learn System Jobs and I already optimize my codes precisely by avoiding several Updates, using a Manager for this and the performance improvement is very good. You could have shown Manager performance before Manager+Jobs.

[@zendsub8288]

Thank you so much! Very clear explanation of how these systems work and use in real cases.

[@stefans6557]

Yes, this looks very interesting, as it seems to be not too complicated. Will have to watch it over and try on a small example, before using it with a more complex project. But I am quite sure, I can get this running. Btw. if you schedule a job in Update() it is recommended to complete it in LateUpdate() (schedule early, complete late). PS: what I like about it: the real update code doesn't have to be in the Job itself, but can stay somewhere outside and be just called from the Job.

[@ashtwenty12]

Should have just had calcution for, number of Tennants * random number. Or randrange(12*tennentsCount, 24*tennetCount). Could also add some noise by adding randondom int, 1 to tennentCount

[@ristopaasivirta9770]

Love your presentation and examples. Just the right amount of theory and practice. Keep rocking hard, dude!

[@crazyfox55]

I also think you should point out that taking a summation over a set of uniform random variables is the same as the Irwin-Hall distribution. From what I've read any summation above 12 tenets would be equivalent to a normal distribution. Therefore you could easily simplify this code. Even if this is just a side example.

[@alexandrebrownAI]

I'm a little bit on the fence about this new job system. It looks like it would require all the layers of the application to depend on Unity. It also requires a very strict and prominent structure. It's not very intuitive compared to modern asynchronous solutions. Something built-in to the language like async await looks more interesting to me even though it might not be as performant. This Job System seem like a lot to digest and forces you into marrying it... We shouldn't have to make these comprises in 2020 as Kotlin, Go, C# all have a way to write async code in a synchronous flow where you just write code like you would in a synchronous manner.

[@IAmRyunis]

Keep in mind that the job system and async/await solve different problems; asyncrounous != multithreading. The job system is designed to compile to highly optimized, parallelizable native code. Of course that's not always necessary, so using async/await in other cases is completely legitimate. UniTask is a great plugin for async/await support. Be careful though, async functions in Unity always run on the main thread by default.

[@lorencebuzon5023]

async Task; however, already handles the Thread Assignment for you. Use a for loop or a for each loop on a Task

[@Wobling]

Another great video, short and sweet. Thanks!

[@MQNGameDev]

Thanks for explaining this so well. You rock Charles.

[@diplodocus3]

Great explainer! thanks. Clearly you're set to be the best channel in the segment on YT! Some off-topic questions though, what's your desktop resolution and why do you prefer intelliJ over others (I can already see some reasons)? And would it be a good idea to use this functionality for certain things on my production ready app for the Android platform?

[@InfallibleCode]

Thanks for you comment! I have 4K monitors and I run them at the highest resolution, but I typically increase the font size and zoom of all my applications by 125% - 150%. I come from a Java background and have been using IntelliJ for years. Rider has so many great features and Unity integrations that I don’t think I could possibly go back to VS lol And I wouldn’t suggest using the Job System in production until it’s been verified. You never know what could go wrong.

[@diplodocus3]

@@InfallibleCode that's a clear answer, thanks!

[@diplodocus3]

@@InfallibleCode Just tried Rider and mind has been BLOWN. VS looks ancient. But it's paid and I don't earn yet lol *sad face*

[@syriuszb8611]

Yeah, the jobs system with burst is a very powerful tool. The description under the burst is a huge understatement. It can increase performance even on order of magnitude, for free*. I'm wondering, why it is not accessible outside of jobs, maybe some day. It's easy enough for me to write jobs, but until it goes out of preview it's hard to use outside of "just testing stuff out". Also, I know it was a year, but you showed that you moved the code, but basically- it could not work at all, and we would have no clue. It would be nice, if you for example have power displayed and we saw that the total power before and after changes are same. I know, it's just example code, but still, until I have read the code few times and scratched my head I was not sure. Just because you added the power and did not reset it at new frame- that's no longer power, but energy! So yeah, I was wondering about that for a little too long. *the only cost is that some functions are not available.

[@noodle-eater]

Awesome dude, love all your videos. I start to understand the ECS by watching this video of yours.

[@RecOgMission]

Thank you so much - this exactly what I was looking for!

[@CreeperSlayer365]

This probably could do wonders for big AI battles

[@johnwarner5588]

Man, these are great! You've got a good sense for brevity. You cut to the heart of an issue and explain it simply and quickly. I have to rewind a few times to catch up with what you did, but.... I can do that, because... ya know... it's a video. This might be one of the best video tutorials I've ever seen.

[@Spherous]

It would be safe and more proper to wrap the code and the dispose in a try finally or a using statement.. That way if something throws, you can guarantee that you don't get a memory leak. 😊

[@InfallibleCode]

Thanks for the tip! I’ll mention that in tomorrow’s stream 😃

[@AaronStatic]

Just fyi... the Burst compiler doesn't support try..finally and using

[@EnriquePage91]

This would be better said on a video rather than on a stream though! Maybe add some annotations to this video about it? Although we also have to consider the last reply here stating this isn’t supported by the Burst Compiler.

[@marksmithcollins]

try statement is so much performance heavy.

[@r6scrubs126]

@@AaronStatic which part of this is using the burst compiler though? I would assume if anything its only the code inside the jobs that is using it, so using a Try/Finally or Using statement in the part that is just scheduling the job might be ok? Can't seem to find much documentation on this

[@daviddesvaux9786]

You don't want to dispose at the end of a method that is likely to throw exceptions, you should use a "using" block.

[@erz3030]

Marvelous video and topic Charles! Very well thought out and crafted as usual :) Keep up the fantastic content, cheers!

[@JimJakubJames]

Great example!

[@pudgystump]

This is pretty awesome.

[@entertainmentoverloaded5700]

the only video i understood from this channel... most other videos are un-understandable

[@scififan698]

that simply means you're not the target audience and you need to read more before coming here. What he explains is usually pretty basic stuff really.

[@entertainmentoverloaded5700]

@@scififan698 Fan dog spotted!

[@Gildar76]

Great video. I tried something similar a while back, and used a dictionary to map things back to game objects. It fellt like a few extra steps to take and a few extra collections to fill, but it was still faster :)

[@noptanakhon6650]

Very good example Thank you

[@wazatojanai6333]

Please continue doing DOTS stuff.

[@mastermati773]

12:25 Why did you use TempJob instead of Persistent allocation even though you disposed the array on destroy?

[@IdeaToGame]

He said that we'd need to change it to persistent, so I guess he just forgot to change it during the recording

[@mastermati773]

@@IdeaToGame Yes, but as I remember lifetime of TempJob native collections are 4 frames. After that time you got an error that you haven't disposed them. Btw I stopped caring. I pre-allocate everything in my projects, even managed objects, so... I don't care anymore xD

[@scififan698]

@@mastermati773 this is the right reflex indeed (assuming you can spare the memory): keeping a stable memory footprint and minimizing the usage of the garbage collector is the way to go for optimal speed. Re-use and pooling of objects is the way, instead of creating and destroying objects, etc. Even readonly List and such, with sensible capacity pre-allocation is a good idea, because it's way faster to .Clear() a list which is already in use (internally, it is just resetting the Count and keeping the Capacity anyway, so the memory will be re-used next time without re-allocation), than it is to allocate memory and stress the Garbage Collector. These old-school techniques are still relevant, also in managed languages, especially in games but also in industry high-speed algorithms. Also, the data cache benefits from contiguous memory usage, so keeping a tight memory footprint helps your application to keep good performance, instead of fragmenting memory by numerous different-size re-allocations. Only in low memory conditions and embedded systems, or on systems where memory is precious because of many concurrent processes or threads you don't want to starve out of memory, it is not a good idea.. but hey, in a game, you don't really care what other processes are doing anyway. Many mediocre programmers don't realize this until late in their project, and then they have to refactor their project for more stable memory footprint and linear memory access, which brings them great pain, so it is worth the attention to realize this from the start of a project!

[@regulargamer1991]

thanks for sharing! this ain't pretty but could get someone out of a tight spot.

[@petrosgiannopoulos112]

Very nice, and clean demonstration! One issue i find with using Unity Job System is that you have to have inside the Data struct fields in the simplest forms (int, float), but what if I am using an object of another class that has different types in it as well. Is there a way to include those without the unmanaged issue?

[@snipe_irl]

Production quality is really good. Although I wish you'd explain new concepts for dummies. Sadly you didn't really explain in this tutorial, rather you read out loud what we have to type. I wasn't able to take away as much, as the concepts you used in the Jobification step weren't explained well.

[@presidentmariachi4287]

DOTS is not for dummies.

[@magnusm4]

@@presidentmariachi4287 NOTHING is for dummies, but it's not about being smart or good at it. You must always start everything from the basics. Just cause you're good with machines doesn't mean you can immediately start working on a nuclear power plant or space rocket. You need a base introduction to the mechanics and functions of everything so you know what everything does, how and why.

[@rocksfire4390]

@@magnusm4 i agree. isn't it weird that people just expect you to know everything? everyone starts from the basics and works their way up, that's the entire point of tutorials!

[@mistermotomax]

Yeah, that's why you have to learn the basics of Unity first. For me, he was too fast in explaining the problem, maybe this helps: the scene has 65 buildings which do their update functions, this is expensive (65x update functions *one after another* ). Job system means 65 update functions *at once* (under optimal conditions).

[@presidentmariachi4287]

@@mistermotomax N0 NO NO NO... You have to explain everything cuz entitled!!! REEEEEEEEEEEEEEEEEEEE!!!!

[@zeejenkins]

You forgot to change the Allocator to persistent

[@ultimatesin3544]

Thanks a ton for showing how to minimize use of the new operator and reusing the same job struct, I've been looking all day and it seems like nobody else even considers doing this even though the whole idea behind jobs is to increase performance.. Thanks man.. Also just a question - OnDestroy isn't guaranteed to be called on mobile, and the doc for that method says to use OnApplicationFocus(bool hasFocus) for retaining data, etc... so should we be disposing (and then recreating) the NativeContainer there instead? Man you have no idea how hard it is finding basic stuff like this lol.. Thanks for the vid!

[@ultimatesin3544]

Oh btw - my question with mobile.. if we are disposing/recreating NativeContainer outside the scope of the running job.. doesn't that have the potential to break the job if it's still running when the app loses focus? I wish there was a simpler way of handling this stuff, thinking about just using the C# async/await...

[@RussPainter8]

At 12:14 you mention changing the allocator to Allocator.Persistent, but that doesn't happen in the code we see on line 17. I'm wondering why it's still working with this array that shouldn't live very long?

[@magnusm4]

I imagine this job system will give the ability to have large open worlds with lots of living entities such as colonies of a species that live together, far less games with lag or performance issues and can focus more on just making the game they want, more complex mobile games and the ability for more people to make large scale strategy games. And of course I predict NONE of this will happen and it's potential will be wasted, as usual. Looking forward to the threads of people's creations with it tough

[@irybas]

You are incredible! We wait for the next great video :D

[@ewwitsantonio]

I'm a bit of novice programmer, so bear with me: Could you use the Job System to make SQLite database calls? I'd love to have a simple way to query a local database in a game but not have the main thread hung up every time I make a search. Imagine there's an in game Encyclopedia (all set up locally w SQLite), and I want to give the user an ability to search in game, without killing the frame rate. I've done some multithreaded code but it feels rather complicated for my current skill level. Thanks for the great video! Really helpful and well produced content.

[@osten222312]

You can, but it will not prevent disk lookup locks, and is a bit overkill. Your example is better done in a worker thread as it is not a batch job of several instruction, just a main thread lock. It is easily solved with a coroutine, and does not require the job system.

[@marcolozano1348]

Hi @Infallible Code, im one of your new subs and i have a question. We should use Jobs for every class which repeats itself in the same scene right? For example an enemy script. I should then create an enemy manager and so on, right>?

[@gamedevmode]

This is great stuff...but this very issue can be solved by having one manager With Update method and that will Call the Update1 Method for Every Building instance. But it's always good to have multithreading 😀

[@crazyfox55]

This would take the same amount of time as the original implementation because each update would run one after the other.

[@scififan698]

@@crazyfox55 not really, it would actually be pretty fast, as there is less calling overhead in a simple for loop over consecutive memory than there is over framework code calling methods of objects spread all over the managed heap. A for-looped single threaded implementation over a consecutive array or contiguous list would probably would end up somewhere in the middle between a typical MonoBehaviour implementation and a job implementation. unless the optimizer does a very good job, of course.. then all bets are off and it becomes case-dependent. lol

[@rubyrails2329]

Very helpful !

[@sandsoftimer]

Awesome but if i have thousands of joint (For example: Fixed Joint) which is using physics update then how can i tell to calculate physics using Job System. Is there any possibility to calculate Fixed Joint through Job System. Sorry for my English.

[@andriy_z]

Nice!

[@ashfid8987]

I enjoyed this really. Very simple and effective. But, what about raycasting? Maybe 1000 enemies raycasting? Do we use ECS’s raycast or we can use normal raycast?

[@SchalaArchives2023ish]

Is there anything in the code preventing the use of Burst? Enabling Burst will optimise this even further.

[@chronowalker1889]

am i the only one finds keystroke sound very soothing xD

[@rani600]

I'm not completely sold about the job system, it seems like it complicate things code-wise, and only good to use in specific scenarios, such as rougelite games and such. anyways, great video as always.

[@TheAndrejP]

Well, yes and no. Is writing code using the job system and jobs harder than writing a MonoBehaviour and dropping it onto a prefab? Yeah, a bit. But keep in mind when you'd be using the jobs system in the first place - when you have to multi-thread your code, which is when you're hitting performance bottlenecks. So if we start under the assumption that the scene contains a large number of instances of the same prefab with a MonoBehaviour that does some non-trivial, but not insanely complex amount of tasks in Update, which due to the amount of the instances is causing performance issues you will have to optimize. This could be anything from flocking behaviour of animals to randomizing events in the environment, characters and cars moving through a city GTA-style,... it's certainly not limited to roguelikes. The first thing I'd try when optimizing something like this - presuming I'm not doing something stupid like performing unnecessary tasks within an update of an object with a large amount of instances in the scene - is multithreading. So if you've got to write multi-threading code and the alternatives are just writing your own system that spreads out the work among multiple threads and using the job system I can with a great deal of certainty claim that the job system code will be far less complicated than anything that even begins to resemble a sturdy multi-threaded solution.

[@milanstevic8424]

@@TheAndrejP In fact, without the job system, you wouldn't be able to do anything multithreaded and related to gameobjects, because unity wasn't thread-safe to begin with. this is the only way to actually use multithreading in the core unity functionalities.

[@EnriquePage91]

You know what would be killer? A video of the shortcuts you use the most for Visual Studio... you damned Keyboard Warrior 😂. (It’s for realz tho, pls)

[@TommyTheITGuy]

I think he's using Jetbrains Rider.

[@miguelangelgalindo3124]

will this way to return data from a job work with any object? I mean if tentants or PowerUsage were something different than an int. I need to return a Texture2d

[@JohnVanderbeck]

Sadly this design patter -- which seems simple enough -- doesn't appear to work anymore? You can't run IJobParrallelFor on a Native collection unless you mark it as ReadonOnly, at which point you can't modify the data like you do in this video :(EDIT: I stand corrected. This pattern does still work as long as you are using NativeArray to hold the items. It does not work with a NativeList)

[@greendino5868]

How dots system fare now in 2021, is it really okay to go to that direction completely??

[@DutchyChannel]

A part of me is struggling with the fact all of this has to be done with structs, even though it makes sense in the context of what jobs do. The struggle is with how when you make changes to a struct, the entire struct is copied; with structs with a bit more complexity (more properties) this seems like such an inefficient method. Are my concerns valid, or is there something I'm overlooking here? Or is this copying not actually as 'heavy' for the processor?

[@ibrahimAlbayrak0]

hello, I was going to use job system in my project, but I realized it didn't work. I used the example in your video and saw that the job system was working, but this time, when I deleted the math part you wrote, I saw that it didn't make any difference. So then why did you write the other codes? Does the job system only work for the math library?

[@peny1981]

Can I use this for Tcp connections, instead of c# threads/ tasks ?

[@kokizzu]

what if the number of items to be processed dynamic?

[@Jaqopx]

That was awesome.

[@Obyvvatel]

Don't you need to do something with the data after the job is completed? Like, wouldn't you need to pass every struct of BuildingData back to the building, since it's not by reference?

[@simonchen6698]

Sorry late reply, but I believe this is the exact point he was trying to make at the end of the video. Using a Dictionary would probably be the most performant, instead of having to do a nested loop iteration.

[@magnusm4]

The main issue I can think of is implementing the open and close principles and other techniques into a system so reliant on splitting everything up and be so specific about every little detail. This is something that is bad in game design as simplicity is the key to versatility such as calling the interface function OnFire for example.

[@Ayushmaan_Singh77]

Its just a doubt .....How can we instantiate GameObject using job , if its possible

[@98josemam]

at 8:43, why you change int for var? I though that if u specify the class it was more optimized

[@IAmRyunis]

He simply changed it for aesthetic reasons. In any case the "var" keyword is just syntactic sugar anyway, so you don't have to type out long type/class names. Since C# is a strongly typed language the compiler is aware of the underlying type at all times and result in exactly the same compiled code.

[@98josemam]

@@IAmRyunis Cool, thanks

[@bruninhohenrri]

How to do it when your "buildings array" is dynamic ? I have a list of chucks that are always generated when the player moves, i want to use a job to generate the mesh for each one of those :)

[@fernandodarci]

You are using List for vertices, List for uv mapping and List for triangles, right? Convert those lists to float3, float2 and int, fill the native array and do the calculations. After this, simply put the data into mesh (out of the job) and done.

[@thepeacekpr]

Thank you very much for explaining this concept. I have a question. I see you using var most of the time instead of just typing the class name. Why is that? Any coding reasons or you just like them that way?

[@milanstevic8424]

because it simplifies and improves readability of the code. var can be used thanks to compile-time type inference, otherwise you still need to explicitly declare a type, if the variable isn't locally defined, contains multiple declarations, or if the assignment is ambiguous due to inheritance. in all modern IDEs you can rollover the identifier and inspect its type, so you lose nothing, but might gain a lot. more often than not, compound variable declarations/definitions already contain everything there is to know on the right hand side, leading to redundant and annoying boilerplates here's a common example Dictionary processingDictionary = new Dictionary(); can be written as var processingDictionary = new Dictionary();

[@thepeacekpr]

@@milanstevic8424 Got it.

[@scififan698]

another good reason is that anything which is 'var' declared, will not have to be touched when refactoring types, since it will automatically (strongly typed, so you lose nothing) follow along with the type. If there would be an explicit type instead of 'var' in your declaration, a type refactoring would oblige you to also visit that line of code explicitly, manually or by tool, introducing needless risk of errors. That's just more work for nothing, so var is clearly a win. Most people who are against 'var' in C#, confuse it with habits in less strongly typed languages like javascript and believe it will be slower in C# and such nonsense. They simply don't understand the C# language very well. Nothing like that is true: 'var' in C# is as strongly typed as any other regular old-school declaration, but without the keyboard effort. It is indeed syntactic sugar of the good kind. And to those who still use Hungarian notation and such, I have only a middle-finger message: grow up already, Hungarian notation is an antipattern and you still don't realize that. lol

[@johgranger1304]

FEEDBACK: I downloaded the project and there are missing scripts on multiple game objects. Also had an issue with using declarations because you don't show it at the beginning of the video so I couldn't get the Jobs interface to work.

[@monkeyrobotsinc.9875]

i dont get what the buildings are calculating. are they being created procedurally every frame? or what. is there no LOD?

[@shintarouemiya]

Off topic question but... why is your Unity editor looks so smooth?

[@burakgok2909]

Hello, I would like to understand one thing clear when we use the job system its blocks the main thread ( main thread has to wait until the job gets done) right? It's similar to using thread.join( ). I want to know what is the reason for blocking the main thread since it will make the application unresponsive? why they don't work concurrently? Thank you for the tutorials.

[@qwendolyn5421]

You didn't change the allocator from tempjob to a permanent one

[@scififan698]

indeed.. he said it, but didn't do it. oh well, a slight sloppy blemish on an otherwise rather good tutorial.

[@daviddesvaux9786]

Is this executing on the GPU or CPU ? I thought the job system was all about the GPU. Is the job's code translated into some compute shader ? Because otherwise, if it runs on the CPU, then I don't see what thiss brings, cause this is almost as easily acheivable by handling threads manually.

[@scififan698]

if you really think what you wrote, you clearly did not understand any of it. you need to read more, and assume less. lol

[@sommmen]

Hi! so in my daily life i work with normal c# and just started to do a bit of Async programming now .net core is here. Is async not supported in unity - and why should i use this over asyn? i also read something about coroutines which i suppose could do the same? nice and clear tutorial btw!

[@MrCorrectify]

Coroutines run in the main thread, they aren't parallel. Unlike standard functions, coroutines can wait. This is just a convenience that allows you to do stuff like speed up your game by distributing heavy logic over multiple frames, as well as create otherwise complicated functions that require timing (wait 5 seconds, do X, wait 3 frames, do Y). Async is supported and has the same limitations as jobs. Jobs is basically an architecture built around async to make it more safe, simple, and design friendly (profiling stats, intelligent distribution and queuing, etc.)

[@sukhmandersingh4306]

@@MrCorrectify coroutines are for IO intensive tasks it cannot speed up computations

[@bilal12e]

Sir what Compiler are you using ?

[@scififan698]

the one built into Unity. lol

[@codingjammer6403]

The ECS seems to be already outdated: docs.unity3d.com/Packages/com.unity.entities@0.9/manual/ecs_creating_systems.html Its using SystemBase (less code needed) Or am I wrong?

[@manishotaval8316]

Does the "Unity Job" work for mobile platforms especially Android?

[@excellNexcel]

Unity can't even get finalized documentation (or any for that matter) on DOTS for the developer. Each iteration of DOTS is different from the previous version. Yes, it is more performant by default, and when Unity has a finalized version in about 2 years, then I will make the greater concerted effort to learn it

[@eyezl3832]

very clean walk through of job system, but video editing is a bit distracting, almost feels like watching an indian soap drama

[@r6scrubs126]

Its a little worrying to me that you can't even generate a random number in one of these jobs using the normal method. Like yeah in this case there's a unity alternative, but are there other things you can't do inside a job and where there is no built in unity alternative?

[@scififan698]

when you think about it, that's actually pretty normal and expected, considering the regular Unity classes were never built with thread-safety in mind, and would be burdened by such measures like locking, lock-free collection classes etc. It's actually not a bad thing there are separate classes for this, from a performance point of view, although as a programmer-user experience this seriously sucks and looks messy and confusing, I agree. Maybe in a far future, Unity programmers will consolidate, but I wouldn't count on it, given their reputation to rather build new features than to fix their old issues. lol

[@anton.m.korshunov]

It's just a dream

[@TheUncutAngel]

your code editor is so packed full of random indicators that it makes it very very hard to follow along--and all I'm doing is watching. Consider yourinterface on this as something less frilly and easier to look at. Might look second nature to you, but you risk alienating the audience over something trivial. So far the hardest part of this tutorial is finding out where and what you're typing, and where exactly it gets copied and pasted. Everything else is very clear and helpful. edit: like at 11:50 you said you were going to create fields. And then you click some hotkeys and text is generated-and-cut-and it's like... where the hell do I look?

[@quanghong3922]

You missed Burst Compiler

[@yoyomario]

This isn't a correct example to show performance gain, since it's well known single Update() from "Manager" class is superior to multiple single objects calling Update() each for them selves respectively. So if you want to show a practical code example, and actual performance gain, first write code with good architecture and then translate into the Job system. You did a mistake here of updating the code architecture of executing and moving it to job system where we have 2 major changes for performance.

[@watercat1248]

That sounds great but is 1 big problem i have no idea haw to find jobs system code in unity

[@XZYSquare]

wait why does that 1:30 second intro sound like an ad? the way you accent every half a second is why i click skip on ads :p the rest of the video seems ok tho

[@RemusCroft]

Weird, non-intuitive, full of limitations. I don't like it. It feels like crutch. It feels much more complicated than actual C# mutithreading. Designing something like that whilst main competitor push visual scripting as much as possible is pretty questionable decision for Unity IMO. Anyway, great video. thanks!

[@milanstevic8424]

oh somehow visual scripting is comparable to multithreaded solutions. wow besides unity has its own visual scripting. as if that solves the world hunger.

[@PocopoKids]

Improve more easy to understand your video

[@RayHorn5128088056]

Your demo was flawed even though you did make your point during your video. The code you refactored to run in the background should have been run only once when the game initialized and surely not for every frame. I know you wanted to make your point and most people would not notice what I just said. There was no reason to have a bunch of static buildings update themselves in the manner shown on every frame. Also a state machine could have handled the background processing but only when the state of each building actually changed. In other words, the best approach would have been to perform the initialization of the building data when the game started and only once then if the building's state related to the computation changed while the game was being played the data would be updated but only when dependent variables changed and not otherwise. Under no circumstances should ALL of any object be updated for each rendered frame and this was the bug. What you demonstrated would also "seem" to "fix" the issue because your fix was no fix because the underlying issue was that of incorrectly updating a bunch of static buildings when nothing changed. It is always possible and desirable to avoid using background processing whenever possible. Video game developers have been using state machines for many years because state machines are very fast and very powerful. State machines do not require background processing. I think if you wish to make a point about programming you should stick to real world situations rather than building a broken game just to make a point. Kudos for the efforts. You got me hitting the subscribe button.

[@afrakes4510]

Thumbs down. unnecessarily confusing. I've watched it a dozen times and still am perplexed about all the back and forth, doing something, then declaring almost done, then changing , then saying , See, it works!! .. naah man.. redo this slop.