The best ECS/DOTS intro I have seen in 5 years.. and that components have gone a long way in the right direction, but it is still weird and confusing af. Build subscene in a scene to just get a "mapping" between Entities and GameObjects? And then we have animations and audio and that brings me to the conclusion: except I have a massive game with huge amount of objects in the scene on mobile or want to calculate for them A* path, I would go for the traditional GameObject oriented logic and mechanics, they are as intuitive as any other object oriented language (at least the most popular ones) and gets in 99% of non-RTS games the job done with 30-60fps! Please, never drop the support for the "old" GameObjects and MonoBehaviours!
@@leonidus101 thanks! And yeah there's currently no plans of getting rid of GameObjects, and MonoBehaviours, as they are the quicker way to iterate on most games. However ideally over time that gap closes and you can pick whatever suits the problem you're currently looking at at any given time in your game. Some features lend themselves well to quickly composing behaviour based on a set of components while other games/mechanics just want a quick way to create a component with some behaviour and quickly be able to add it to the object in the game. In the future when GameObjects are also Entities you'll be able to add componentdata directly to your GameObjects, skipping the need for baking entirely in most simple cases, by which point you might notice some features become easier to implement in ECS than normal GameObject land, and that way you don't have to sacrifice performance anymore either :)
You can even use ECS as a part of your traditional game object oriented ways. You were always doing it with ParticleSystem ^^ Ideally a packed set of systems where you can update them on your own when you need something that is very intensive to be executed fast and in parallel using Burst + jobs One example i can think of is if you wanted to simulate realistic clouds, you can just make a specific ECS world that simulates clouds very effectively by utilizing burst and jobs.
@piotrek7633 not quite, it's useful for performance but that's not all entities is about, it's about architecture, putting your data first and solving your problems as discrete, composeable tasks. There are plenty of games using an ECS for more reasons than just performance. Some games lend themselves more to this design than others, but that doesn't make it only about performance :)
Nope, however ECS is lightweight enough that you can make your own fairly easily, or as discussed in the last part of the presentation, you can interact between GameObject's and entities to do what you want. Say you wanted particles to spawn as the bug dies, you would simply spawn a GameObject with the particles at the time you delete the bug entity
@@DanielKierkegaardAndersen Thank you. I am doing something very similar but I am not using unityobjectref. What is the reason to use this? Thanks again
@@shotoutgames8823 correct, UnityObjectRef allows the use of struct IComponentData, and as a result as long as you're just querying for that component/changing the reference, but not accessing the reference (getting the managed data it point to) then you're allowed to use burst. Something you can't do if you were using class IComponentData (which we also name managed components)
Which error are you getting? GetDependency let's Bakers know to track any changes to an additional object. Since bakers are only run when you change your baked MonoBehaviour, it won't know to update after making changes to any other objects that the baker might be dependent on (like your spawning GO). To fix this, you use GetDependency to let the baker, "also update this baker, when you change anything on the passed in object"
Burst, Jobs, and Entities-Graphics are not supported in WebGL, but Entities, Native Collections and Mathematics are supported. Meaning if you want graphics you have to run your own solution or use GameObjects as the frontend, but you can still write a lot with the core Entities API (e.g. all the API showcased in this talk)
Haha, well a company is made out of many minds, the people making a web-based solution for UI Toolkit are quite unlikely to be the same people that made DOTS, after all they are fairly opposing ideas, so I'm a little uncertain how you got this idea ;)
@@daxodearchives9467 Sorry, my comment was on the horrible choice of solution, I'm happy they are doing a new GUI implementation but they should have stuck to two separate methods for Edit and in-game, immediate mode ui's are excellent for technical interfaces, take a look at Flutter but using a Web like solution where you have 2-3 files you need to maintain per logical page entity is just dumb, that is also why .NET WPF was and .NET MAUI is such disasters.
this is probably the best introduction video on DOTS I've seen!
The best ECS/DOTS intro I have seen in 5 years.. and that components have gone a long way in the right direction, but it is still weird and confusing af. Build subscene in a scene to just get a "mapping" between Entities and GameObjects? And then we have animations and audio and that brings me to the conclusion: except I have a massive game with huge amount of objects in the scene on mobile or want to calculate for them A* path, I would go for the traditional GameObject oriented logic and mechanics, they are as intuitive as any other object oriented language (at least the most popular ones) and gets in 99% of non-RTS games the job done with 30-60fps! Please, never drop the support for the "old" GameObjects and MonoBehaviours!
@@leonidus101 thanks! And yeah there's currently no plans of getting rid of GameObjects, and MonoBehaviours, as they are the quicker way to iterate on most games. However ideally over time that gap closes and you can pick whatever suits the problem you're currently looking at at any given time in your game. Some features lend themselves well to quickly composing behaviour based on a set of components while other games/mechanics just want a quick way to create a component with some behaviour and quickly be able to add it to the object in the game. In the future when GameObjects are also Entities you'll be able to add componentdata directly to your GameObjects, skipping the need for baking entirely in most simple cases, by which point you might notice some features become easier to implement in ECS than normal GameObject land, and that way you don't have to sacrifice performance anymore either :)
You can even use ECS as a part of your traditional game object oriented ways. You were always doing it with ParticleSystem ^^
Ideally a packed set of systems where you can update them on your own when you need something that is very intensive to be executed fast and in parallel using Burst + jobs
One example i can think of is if you wanted to simulate realistic clouds, you can just make a specific ECS world that simulates clouds very effectively by utilizing burst and jobs.
This is for games that require top performance, you need to figure out in your game needs it or not, most of the time you dont
@piotrek7633 not quite, it's useful for performance but that's not all entities is about, it's about architecture, putting your data first and solving your problems as discrete, composeable tasks. There are plenty of games using an ECS for more reasons than just performance. Some games lend themselves more to this design than others, but that doesn't make it only about performance :)
By far the best primer talk on ecs i ve seen it clears up so many questions i had starting out! Keep em coming please 🙏
This is AWESOME!! Good Job!!
These videos are very valuable to beginner devs like myself, thank you for sharing
This is much needed that how things are done ✅
Great talk Anne and Dani, excellent overview into all that Unity ECS has to offer!
That clicker on the other hand needs to go 🗑
Awesome!Please combine GameObject and Entity as soon as possible🤩.And it's improtant to teach me how ECS and OOP sharing data~😭
Animation and Audio aren't ecs compatible. what about VFX and particle systems??
Nope, however ECS is lightweight enough that you can make your own fairly easily, or as discussed in the last part of the presentation, you can interact between GameObject's and entities to do what you want. Say you wanted particles to spawn as the bug dies, you would simply spawn a GameObject with the particles at the time you delete the bug entity
@@DanielKierkegaardAndersen Thank you. I am doing something very similar but I am not using unityobjectref. What is the reason to use this? Thanks again
Is it because it can be in a struct as I am using a Class??
@@shotoutgames8823 correct, UnityObjectRef allows the use of struct IComponentData, and as a result as long as you're just querying for that component/changing the reference, but not accessing the reference (getting the managed data it point to) then you're allowed to use burst. Something you can't do if you were using class IComponentData (which we also name managed components)
The only problem is that it doesn't look fun to code with
Why is GetDependency (Spawning GO) give me an error in the code? What does it do anyway?
Which error are you getting?
GetDependency let's Bakers know to track any changes to an additional object. Since bakers are only run when you change your baked MonoBehaviour, it won't know to update after making changes to any other objects that the baker might be dependent on (like your spawning GO). To fix this, you use GetDependency to let the baker, "also update this baker, when you change anything on the passed in object"
So when will ECS for All be ready
DOTS support webgl？
Burst, Jobs, and Entities-Graphics are not supported in WebGL, but Entities, Native Collections and Mathematics are supported. Meaning if you want graphics you have to run your own solution or use GameObjects as the frontend, but you can still write a lot with the core Entities API (e.g. all the API showcased in this talk)
So the same people that thought that creating a 'Web-based' solution for UI Toolkit did this monstrosity... weird mind set.
Haha, well a company is made out of many minds, the people making a web-based solution for UI Toolkit are quite unlikely to be the same people that made DOTS, after all they are fairly opposing ideas, so I'm a little uncertain how you got this idea ;)
@@daxodearchives9467 Sorry, my comment was on the horrible choice of solution, I'm happy they are doing a new GUI implementation but they should have stuck to two separate methods for Edit and in-game, immediate mode ui's are excellent for technical interfaces, take a look at Flutter but using a Web like solution where you have 2-3 files you need to maintain per logical page entity is just dumb, that is also why .NET WPF was and .NET MAUI is such disasters.
*insert charlie day meme
Haha, well, we're trying to go through the entire API in less than an hour, so it has to be a bit speedy in some parts 😆
@@DanielKierkegaardAndersen I appreciate it though. Any resource for dots is a good one.
Williams Brian Davis Jose Williams Betty