Question Coroutine or Job System for a additional Task ?

if you have to perform an additional task during the game, e.g. animating a loading bar or taking a screenshot without causing a lazy still image you certainly need something like a coroutine or an additional independent thread that does the additional work so that the game is not slowed down while the screenshot or the loading bar does not get stuck while loading. But what would be more suitable and correct if I am wrong with my assumption! The coroutine is there to process a task bit by bit during each frame. And Unity Job System can distribute a task in an additional thread that the main thread does not have to do. You couldn't always use the Unity Job System instead of a coroutine because in this case even the main thread remains unaffected and another thread / CPU core can take care of the additional task without the main core responsible for all processes in the game has to deal with it and can concentrate his full performance on the actual game?

 

Animating the UI will have to be done on a main thread anyways, so for something so simple, I'd just be using a coroutine myself. Which is what I've done.

 

Unity Engine is not multi threaded. So any things managed by the engine (GameObjects, Components etc.) cannot be manipulated from other threads. You could do some number crunching in another thread and then use those within the engine. But everithing else runs single threaded by default and by design.
The new DOTS-ECS paradigma is designed for efficiency and multithreading. So if you have performance concerns this is worth a look. But it's a whole new data oriented design principle and still in development. But the prospect is exciting.

 

I use Unity 2020.1.3f1 is this new enaught?
And why do the new CPUs get more and more cores when Unity can only address one of them? And what is the Unity Job System if it is supposedly not responsible for multi-threading?

 

You can use DOTS-ECS with this version if it is what you are asking. The process of getting the responsible packages is a bit "hidden", unfortunately. Look in the DOTS subforum for more information.

When Unity got first released in 2005 multithreading was not a thing. The core of the engine has not changed as it would be VERY difficult to implement it afterwards. It is way more difficult than just pressing the magic "make multithreaded" button. And since Unity strives for ease of use adding multithreading could make it more difficult for users too. ECS only achieves "easy" and reliable mutithreading by heavily restricting what devs can do. So it's forcing the developer to code in a certain way.
Also I'm not aware of any major engine which is multithreaded by default. So it is nothing "unusual" what Unity does here. And I'm not aware of many "normal" applications which are multithreaded (Firefox has threads for tabs). So when you "waste" your CPU-cores it is not Unity's fault.

It is responsible for using different cores. But as I said the things you can do with it are restricted. If you want/need a multithreading engine look into DOTS-ECS or elsewhere entirely. Things are as they are and you won't change them by nagging and bitching.

 

"If you want/need a multithreading engine look into DOTS-ECS or elsewhere entirely."
That sounds like you trying to turn me on a different engine like Unreal ...
Is "DOTS-ECS" so exotic compared to the usual monobehavior classes that you have to classify it as a different engine?

 

If it is a better choice for you why not? You should always pick the best tool available for your needs.
Is Unreal capable of multithreading out of the box? I don't know.

It's a completely different paradigm. Monobehaviors are based on OOP. ECS is based on DOD (Data Oriented Design). Have a read about it yourself. This book is about the concept, not Unity's implementation of it. Unity's implementation is still in the works and changes frequently and many things are not supported properly (Animations, Input, UI, Cameras, Sound). And it may still take some years until all of these have "catched up" to MB's so don't hold your breath.
This is an example of how it looks in practice in Unity. This is almost 2 years old so some things have changed in the meantime.

 

Does that mean you can't make a full-fledged game as a one-man developer by simply continuing to use classes with monobehaviors for things that are not yet supported like: "Animations, Input, UI, Cameras, Sound", those with OOP be made? Or would a mixture of the two be incompatible?

And for which platforms can DOTS-ECS currently be used? For me (PC, Mac, Linux standalone) and (Android) would be important for my activities...

And what exactly is the difference between the Unity Job System and Dots ECS?

 

The hybrid or "chimaera" approach is often necessary. As the video shows some performance relevant things are done in ECS whereas some things are done with MB's (sound, UI) as there is no direct ECS counterpart yet. I guess it would be VERY difficult to make a pure ECS game. So both worlds can be used together but cooperation can be a bit difficult. You must either have the Monobehaviors read the Entities state or let a system update the entities state into the Monobehaviors.

Job System is part of DOTS together with Burst compiler and ECS (and maybe new SIMD math lib).

I'm not too deep into ECS as it is too "immature" for my taste. Especially the documentation is lacking and you have to reverse engineer everything from "outdated" example projects. So I will wait another year or 2 before I invest more time in it. But I follow the DOTS forum to keep up to date with the general state of things.
AFAIK ECS can be used on all normal platforms as well (not sure about WebGL). But I suggest to spend some time in the forum and the (sparse) documentation if it suits your needs.

 

My goal is to build a lot of quality and performance into my game. Namely, in my past I have often been able to experience how games run with only 15fps because e.g. 50 NPCs are walking around while the CPU is at most only max. 20% loaded. In such scenarios I ask myself whether one e.g. something like this couldn’t have been prevented by executing the path finding over several threads on the NPCs, e.g. ?

 

Hi,

The new job system is able to dispatch into multiple threads unlike how Unity used to be, you can now use multiple threads! However Unity wanted their new multi-threading to be thread safe and as thus they created the new job system to work with ECS within DOTS..

But oh nooo, what does this mean that you should use a whole new design paradigm? Not necessarily - And here's why, in most cases the original Gameobject workflow works fine, especially seeing how well defined the area is and the amount of support you can get around the topic however!.. ECS, has gotten a lot more stable in recent years, and i personally use it in all my new projects, as i like the design paradigm more... It also scales better in terms of software architecture.. The basic gist of it is that you split you game up into data and behavior.. So you have entities which are comprised of a number of Components, the compenents only have one job - Storing data.. You now use systems which change that data, these systems work with both the new and old input system, and more importantly have an amazing performance benefit!.. But the problem is that there's not many resources on the topic yet.. however i found this amazing youtuber and he really knows what he's doing! So i will greatly recommend him
https://youtube.com/c/TurboMakesGames