❗❗ *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
Sweet!! I always wondered what those blob assets were all about but never got around to figuring them out. Also I learned something new about C#'s "using" keyword.
Yeah definitely! I feel like blob assets are one of those topics that sound a lot scarier than they actually are - especially once you start to use them, they make a whole lot more sense.
This was definitely harder than other concepts and I will need to practice with them to completely wrap my head around the concept and all the steps needed to use them, but they do seem useful. Thanks for the tutorial.
Yeah this is definitely a tough one to wrap your head around at first, I think a lot of the boilerplate code makes it seem more confusing than it actually is. Once you use them to solve a practical problem, they make much more sense.
So glad to hear this! I always find it so valuable to watch tutorials on things I think I already know pretty well - a lot of times I find I end up filling in gaps in my knowledge I didn't even know I had
Hey all! I know this video is a bit more code-heavy than normal and you don't see a whole lot going on in the Unity editor, so I hope it is easy enough to follow along with. As always, please let me know if you have any questions on this! Happy Blobbing 👽
3 ปีที่แล้ว +1
I wonder why they didn't make an editor version where you create blob assets just like scriptable objects. It's as a replacement of SO I would like to use this anyway but it becomes very tedious when you need to convert SO with a million steps.
@ Exactly what Luke said, seems like a great idea for a custom editor tool 😊
3 ปีที่แล้ว +1
@@TurboMakesGames I think it should be doable with the same codegen method they used for authoring components, right? Or am I missing something? Seems strange they didn't just do it if it was that simple..?
Thanks for this video, I had to return to this topic after a years pause, and couldn't for the life of me remember how I had done it in my previous projects. Such a huge struggle to get the most simplest of tasks a programmer does in a matter of seconds, oh the things we do for that little bit of extra speed and efficiency
Keep it up. Love your videos :). I feel like this talk could have paraphrased the documentation rather than explaining each concept one after another, verbally. Overall, great video my guy.
What are the advantages of using a blob asset vs an ordinary singleton entity that you only ever read from? If you only ever read data from the singleton entity's components wouldn't it be equally as fast? I suppose a blob asset would guarantee that you don't accidentally write to it, but it seems like that's a pretty minor issue compared to all the extra code required for setting up blob assets. I think the would both use the same amount of memory. Thoughts?
Good question, performance-wise yeah, they're probably about the same. The thing you get with blob assets is "guaranteed" immutability, meaning the data is guaranteed to be able to be read from multiple systems/jobs/threads at once. I say guaranteed in quotes as you can do things like I did in my game of life where the blob asset pointed to entities, and while the entities stayed the same, the components on the entities didn't have the same guaranteed immutability. With a singleton you're only reading from, it's like a pseudo-guarantee, where you know that as the developer know that it will never change, but there are no built-in safety systems to prevent you from doing this. Only other thing I can think of right now would be blob arrays, but you could use something like dynamic buffers on your singleton
So this kind of data - immutable(like say spaceship max speeds, max turn speeds, max HPS etc) - can be stored 1. blob assets 2. components(singletons) - and i believe i read on forum but that was an old thread - in 3. static classes like readonly fields(i think it's possible to use static readonly data from jobs too) - it would be nice to see which method is the most performant especially if this kind of structs that hold the data contains a lot of fields(i bet on 2. but not sure 100%)...
Don't know for sure, but I'd say blob assets would be more performant over singleton components because of guaranteed immutability, meaning no safety checks need to happen. Static readonly fields could work but it seems like a bit of a code smell to me as it kinda breaks the ECS model. But great thoughtful comment though!
Hi, i've got a question, how would you do the construction of the blob asset in a baker, because whenever i'm trying to do this, when i'm allocating the reference to an entity in a baker i have a leak warning from unity
Depends on what exactly you are trying to do. So long as the data is unchanging, then yes, a blob asset could be used for something like that. Though often times in games items do have the ability to change over time, maybe they get weaker with use or you can add behavior to them by combining other items. So I could see blob assets being used as a way to store the "base" stats of all the items in your game, then when a player gets an item, those values are copied into something that is mutable like a dynamic buffer. Also I should point out that most people still use OOP for the front-end UI logic of inventory selection/crafting screens as it is easier to do and doesn't really benefit from the performance gains of ECS anyhow. Hope that helps!
They do at first, but once you use them and figure out how best to use them, they begin to make much more sense. It's really just a way to store and reference data that does not change.
![Demystifying Transforms in Unity ECS - Unity DOTS Tutorial [ECS Ver. 0.17]](http://i.ytimg.com/vi/NGLVVI2HAo4/mqdefault.jpg)
![Demystifying Transforms in Unity ECS - Unity DOTS Tutorial [ECS Ver. 0.17]](/img/tr.png)
![How to Use Dynamic Buffers in Unity ECS - DOTS Tutorial [ECS Ver. 0.17]](http://i.ytimg.com/vi/Ki0AwYZw2Ac/mqdefault.jpg)
![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
Sweet!! I always wondered what those blob assets were all about but never got around to figuring them out. Also I learned something new about C#'s "using" keyword.
Yeah definitely! I feel like blob assets are one of those topics that sound a lot scarier than they actually are - especially once you start to use them, they make a whole lot more sense.
This was definitely harder than other concepts and I will need to practice with them to completely wrap my head around the concept and all the steps needed to use them, but they do seem useful. Thanks for the tutorial.
Yeah this is definitely a tough one to wrap your head around at first, I think a lot of the boilerplate code makes it seem more confusing than it actually is. Once you use them to solve a practical problem, they make much more sense.
I am glad I watched this vid even though I thought I new how to use blob assets as they seem way easier to create and assign to now.
So glad to hear this! I always find it so valuable to watch tutorials on things I think I already know pretty well - a lot of times I find I end up filling in gaps in my knowledge I didn't even know I had
Hey all! I know this video is a bit more code-heavy than normal and you don't see a whole lot going on in the Unity editor, so I hope it is easy enough to follow along with. As always, please let me know if you have any questions on this! Happy Blobbing 👽
I wonder why they didn't make an editor version where you create blob assets just like scriptable objects. It's as a replacement of SO I would like to use this anyway but it becomes very tedious when you need to convert SO with a million steps.
@ Hmmm... that's a pretty cool idea. I wonder if anyone has tried to make a plugin/package for unity editor to do that.
@ Exactly what Luke said, seems like a great idea for a custom editor tool 😊
@@TurboMakesGames I think it should be doable with the same codegen method they used for authoring components, right? Or am I missing something? Seems strange they didn't just do it if it was that simple..?
Hey Turbo! I suggest doing some ECS/DOTS for UGUI. Would be super useful.
Thanks for this video, I had to return to this topic after a years pause, and couldn't for the life of me remember how I had done it in my previous projects.
Such a huge struggle to get the most simplest of tasks a programmer does in a matter of seconds, oh the things we do for that little bit of extra speed and efficiency
Hehe, glad you liked the video. Stay tuned for some time saving ways to reduce the amount of boilerplate code I write in ECS... 😉
Keep it up. Love your videos :). I feel like this talk could have paraphrased the documentation rather than explaining each concept one after another, verbally. Overall, great video my guy.
Appreciate the feedback, always looking for ways to improve these videos. Glad you enjoyed 😀
I know the lines get long, but don't be afraid to declare the type of variable. It makes it easier to understand instead of using 'var' everywhere
Appreciate the feedback, will take this into consideration, cheers!
What are the advantages of using a blob asset vs an ordinary singleton entity that you only ever read from? If you only ever read data from the singleton entity's components wouldn't it be equally as fast? I suppose a blob asset would guarantee that you don't accidentally write to it, but it seems like that's a pretty minor issue compared to all the extra code required for setting up blob assets. I think the would both use the same amount of memory. Thoughts?
Good question, performance-wise yeah, they're probably about the same. The thing you get with blob assets is "guaranteed" immutability, meaning the data is guaranteed to be able to be read from multiple systems/jobs/threads at once. I say guaranteed in quotes as you can do things like I did in my game of life where the blob asset pointed to entities, and while the entities stayed the same, the components on the entities didn't have the same guaranteed immutability. With a singleton you're only reading from, it's like a pseudo-guarantee, where you know that as the developer know that it will never change, but there are no built-in safety systems to prevent you from doing this. Only other thing I can think of right now would be blob arrays, but you could use something like dynamic buffers on your singleton
Thank you sooooooooooo much.
May someone think it isn't nessasery. But if you wanna change SphereCollider or else basic collider, you should use this.
Yes, DOTS colliders use blob asset references!
So this kind of data - immutable(like say spaceship max speeds, max turn speeds, max HPS etc) - can be stored 1. blob assets 2. components(singletons) - and i believe i read on forum but that was an old thread - in 3. static classes like readonly fields(i think it's possible to use static readonly data from jobs too) - it would be nice to see which method is the most performant especially if this kind of structs that hold the data contains a lot of fields(i bet on 2. but not sure 100%)...
Don't know for sure, but I'd say blob assets would be more performant over singleton components because of guaranteed immutability, meaning no safety checks need to happen. Static readonly fields could work but it seems like a bit of a code smell to me as it kinda breaks the ECS model. But great thoughtful comment though!
Hi, i've got a question, how would you do the construction of the blob asset in a baker, because whenever i'm trying to do this, when i'm allocating the reference to an entity in a baker i have a leak warning from unity
Can blob assets be used as lookup tables where a value is paired to a fixedstring key and can be retrieved using the key?
Would you use this for an item system where nothing changes? Or is there a better ECS system for this use case ?
Depends on what exactly you are trying to do. So long as the data is unchanging, then yes, a blob asset could be used for something like that. Though often times in games items do have the ability to change over time, maybe they get weaker with use or you can add behavior to them by combining other items. So I could see blob assets being used as a way to store the "base" stats of all the items in your game, then when a player gets an item, those values are copied into something that is mutable like a dynamic buffer. Also I should point out that most people still use OOP for the front-end UI logic of inventory selection/crafting screens as it is easier to do and doesn't really benefit from the performance gains of ECS anyhow. Hope that helps!
How to build apk file of Dots Project?
I'm planning on making some videos soon discussing making builds for DOTS games on different platforms.
Is Blob Asset a Scriptable Object for DOTS ? Seems very similar.
Kindof! There are a lot of similarities between the two. However just keep in mind that Blob Assets are for static data only
blob assets mentally hurt my brain a bit.
They do at first, but once you use them and figure out how best to use them, they begin to make much more sense. It's really just a way to store and reference data that does not change.