❗❗ *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: th-cam.com/video/IO6_6Y_YUdE/w-d-xo.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
Thanks for the tutorials, I appreciate all the info especially on the new 0.5 version; I've watched a good dozen of your videos already and this one looks really helpful as well with all the state system stuff.
Glad you enjoyed and good to know you are interested in that topic! It is something on my radar, but I should just mention that there is no native audio solution in ECS - all audio must be triggered through GameObjects.
@@TurboMakesGames Thanks for the answer. The foundation of the upcoming DOTS audio system is the DSPGraph (now in Preview). I managed to create a DSPGraph audio system (thanks to the official Unity DSPGraph thread). But there are many problems with implementation in ECS, the solutions look very ugly)))
Thanks a lot for video! Do you think we could improve the logic to decrease the number of structural changes? I mean, changing state requires a lot of add/remove component. Or do you think it's acceptable regarding performance?
I believe the structural change is intentional essentially you'd want different systems updating the guard based on the guard state. I would only hesitate using this if the guard is changing state quite often then it might be better to just have some enum defining the guard state.
Good observation, the Readme file of this project talks a bit more about why they made the decision to use structural games over other ways. To summarize - they are optimizing for the most likely case - the most likely case is the guard is either moving to a target position (player or waypoint) or idling; state changes happen relatively infrequently. Because of this, it makes more sense to have separate systems to query for guards in a particular state, rather then having a larger system that potentially wastes processing power by constantly checking the state
@@crazyfox55 Thanks for your advice. I was indeed thinking about using enums. But I like the idea having separated systems handling each state. More "Single Responsability Principle" friendly
lmao @ the intro!! I'm a bit biased, but I must say that I prefer Infinite Axis Utility AI over state machines for controlling agents. The initial setup for utility AI is a little more time consuming, but handling transitions between states and setting up rules is easier and the resulting agent behavior is more fluid and adaptive. However, I could see state machines being useful in other game mechanics like in elevators and traffic lights. Thanks for the great info!
I had way too much fun making this intro 😆😆 Yeah this seems to work well for more or less simple implementations. Interested to check out the Infinite Axis Utility AI a bit more - good to hear you've been having a positive experience with it!
Looks extremely useful. However I would immediately like to change the idle timer code. With 1000 entities there are 1000 float values all incrementing by the same amount and checking if enough idle time has passed. Instead I would use a priority queue with the priority being the game time of when enough idle time has passed. To enter the queue a guard would add itself to a priority queue with priority being (current game total time + idle duration). A priority queue is just a queue that is sorted. For each frame check the queue if the current game time is >= the queue priority then remove that guard from the idle state and check the queue again to see if the next guard is also ready. This implementation means that only one float is checked per frame regardless of the number of guards. Also this is totally separate from ECS besides removing the idle component. What do you think?
That is a smart implementation but there is a couple of problems: Firstly, using a priority queue means we can't parallelize the code -- at least not without doing some work. Secondly, the fact that there are 1000 entities all incrementation by the same amount and checking if there is enough idle time means that we can really use the power of vectorization to run that code extremely fast. So, with all this, in the end I wouldn't be surprised if for 1000 entities, using a priority queue would actually be slower, if not more of a headache that doing the really simple approach. There is one place that in the example which is really the slow part and that is when you have to call ECB's to remove/add tags. If you are making a simulation where high, high entity counts are priority, these calls are not great for the vectorization of your calculations. But take this with a grain of salt if the target entity count is only 1000 entities.
That priority queue is an interesting thought to save on all the comparisons. One idea I had that would be like a half step to this would be to have one master game timer ticking up each frame, then when the entity begins idling, the timer component is set to the game time at which the guard exits the idle state. Each frame all entities in the idle state would need to compare their target value with the master game time. But with any optimization solution, you just need to consider what is the most likely case and optimize for that
@@TurboMakesGames another optimization if the idle times are more than just a few seconds is to have two stages of idle. The first stage would add a component "long idle time" this component would be checked in a system that runs only once per second. Then once the remaining time is below 2 seconds then switch to the regular idle component. Obviously play around with the different stages and rate of their systems to find an optimal solution.
That's a fair point, I could definitely see how you could run into lots of sync issues. Is this something you've had experience with, or just generally try to avoid?
Can I create a mixed game? My point is the game would only use ECS DOTS for a few mechanics, e.g. rendering and unit behavior. The rest of the mechanics would be done according to the old idea of creating games in Unity? Is it possible?/ Doesn't it make sense?
Yes definitely! In fact, because many features in regular Unity don't have a DOTS counterpart yet, you still need to use GameObjects to do things like animations and particle systems. But yeah it is definitely possible to make a game that is mostly traditional Unity, with select systems using ECS
Right now there isn't a good solution that is compatible with ECS right out of the box. If you wanted this you'd probably have to build something custom.
@@watercat1248 Royalty free simply means I don't need to pay royalty fees for using the song. In this particular case I didn't need to pay any money, just give credit in the description of the video. Different songs/artists have different restrictions on how you can use the music and what you need to do to use it
![Using Animation Curves in ECS - Unity DOTS Tutorial [ECS Ver. 0.50]](http://i.ytimg.com/vi/R7HGFVIQ-Tg/mqdefault.jpg)
![Using Animation Curves in ECS - Unity DOTS Tutorial [ECS Ver. 0.50]](/img/tr.png)
![How to Use the Entity Manager in Unity ECS - DOTS 2022 Tutorial [ECS Ver. 0.17]](/img/n.gif)
❗❗ *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: th-cam.com/video/IO6_6Y_YUdE/w-d-xo.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
Dayummmm. I love the opening!!!
Hahaha glad you liked it, I certainly had (way too much) fun making it 😀
Thanks for the tutorials, I appreciate all the info especially on the new 0.5 version; I've watched a good dozen of your videos already and this one looks really helpful as well with all the state system stuff.
Awesome, glad to hear this! Yeah the state machine setup is pretty cool 👍
Thanks, great content. The lack of DSPGraph documentation in ECS is very disappointing. Do you have any plans to make Audio ECS videos?
Glad you enjoyed and good to know you are interested in that topic! It is something on my radar, but I should just mention that there is no native audio solution in ECS - all audio must be triggered through GameObjects.
@@TurboMakesGames Thanks for the answer. The foundation of the upcoming DOTS audio system is the DSPGraph (now in Preview). I managed to create a DSPGraph audio system (thanks to the official Unity DSPGraph thread). But there are many problems with implementation in ECS, the solutions look very ugly)))
@@yuraYura-md2od I'm also interested in dspGraph, can I get acquainted with your implementation?
Thanks a lot for video! Do you think we could improve the logic to decrease the number of structural changes? I mean, changing state requires a lot of add/remove component. Or do you think it's acceptable regarding performance?
I believe the structural change is intentional essentially you'd want different systems updating the guard based on the guard state. I would only hesitate using this if the guard is changing state quite often then it might be better to just have some enum defining the guard state.
Good observation, the Readme file of this project talks a bit more about why they made the decision to use structural games over other ways. To summarize - they are optimizing for the most likely case - the most likely case is the guard is either moving to a target position (player or waypoint) or idling; state changes happen relatively infrequently. Because of this, it makes more sense to have separate systems to query for guards in a particular state, rather then having a larger system that potentially wastes processing power by constantly checking the state
@@crazyfox55 Thanks for your advice. I was indeed thinking about using enums. But I like the idea having separated systems handling each state. More "Single Responsability Principle" friendly
@@TurboMakesGames That makes sense. Thanks a lot
lmao @ the intro!! I'm a bit biased, but I must say that I prefer Infinite Axis Utility AI over state machines for controlling agents. The initial setup for utility AI is a little more time consuming, but handling transitions between states and setting up rules is easier and the resulting agent behavior is more fluid and adaptive. However, I could see state machines being useful in other game mechanics like in elevators and traffic lights. Thanks for the great info!
I had way too much fun making this intro 😆😆
Yeah this seems to work well for more or less simple implementations. Interested to check out the Infinite Axis Utility AI a bit more - good to hear you've been having a positive experience with it!
Looks extremely useful. However I would immediately like to change the idle timer code. With 1000 entities there are 1000 float values all incrementing by the same amount and checking if enough idle time has passed. Instead I would use a priority queue with the priority being the game time of when enough idle time has passed.
To enter the queue a guard would add itself to a priority queue with priority being (current game total time + idle duration). A priority queue is just a queue that is sorted. For each frame check the queue if the current game time is >= the queue priority then remove that guard from the idle state and check the queue again to see if the next guard is also ready. This implementation means that only one float is checked per frame regardless of the number of guards. Also this is totally separate from ECS besides removing the idle component.
What do you think?
That is a smart implementation but there is a couple of problems:
Firstly, using a priority queue means we can't parallelize the code -- at least not without doing some work. Secondly, the fact that there are 1000 entities all incrementation by the same amount and checking if there is enough idle time means that we can really use the power of vectorization to run that code extremely fast. So, with all this, in the end I wouldn't be surprised if for 1000 entities, using a priority queue would actually be slower, if not more of a headache that doing the really simple approach.
There is one place that in the example which is really the slow part and that is when you have to call ECB's to remove/add tags. If you are making a simulation where high, high entity counts are priority, these calls are not great for the vectorization of your calculations. But take this with a grain of salt if the target entity count is only 1000 entities.
That priority queue is an interesting thought to save on all the comparisons. One idea I had that would be like a half step to this would be to have one master game timer ticking up each frame, then when the entity begins idling, the timer component is set to the game time at which the guard exits the idle state. Each frame all entities in the idle state would need to compare their target value with the master game time. But with any optimization solution, you just need to consider what is the most likely case and optimize for that
@@TurboMakesGames another optimization if the idle times are more than just a few seconds is to have two stages of idle. The first stage would add a component "long idle time" this component would be checked in a system that runs only once per second. Then once the remaining time is below 2 seconds then switch to the regular idle component. Obviously play around with the different stages and rate of their systems to find an optimal solution.
it pretty cool, but remove and add component in networking is bad idea
That's a fair point, I could definitely see how you could run into lots of sync issues. Is this something you've had experience with, or just generally try to avoid?
@@TurboMakesGames i tried doing that in my personal project, and it is not good in predicting player actions
Can I create a mixed game? My point is the game would only use ECS DOTS for a few mechanics, e.g. rendering and unit behavior. The rest of the mechanics would be done according to the old idea of creating games in Unity? Is it possible?/ Doesn't it make sense?
Yes definitely! In fact, because many features in regular Unity don't have a DOTS counterpart yet, you still need to use GameObjects to do things like animations and particle systems. But yeah it is definitely possible to make a game that is mostly traditional Unity, with select systems using ECS
how i can use visual interface for creating state machine?
Right now there isn't a good solution that is compatible with ECS right out of the box. If you wanted this you'd probably have to build something custom.
UT 2004 music in the start lech hope this video i will not tern down by TH-cam
It's royalty free music, thanks for looking out though!
@@TurboMakesGames royalty free thats mean you pay in the and you able to use this music wherever you wish you wise right ?
@@watercat1248 Royalty free simply means I don't need to pay royalty fees for using the song. In this particular case I didn't need to pay any money, just give credit in the description of the video. Different songs/artists have different restrictions on how you can use the music and what you need to do to use it
@@TurboMakesGames ok
Unity deleted this
Yes, but they have some better sample projects up that I'd like to go over soon