This talk just demonstrates that Unity's ECS implementation is very sub-par for generalized use. It's definitely useful for certain niche tasks, but could be dramatically improved. This just goes to show how difficult implementing a fully featured and effective ECS is.
Props for the talk. There needs to be a how-to section in entities package documentation with examples like the trick about adding and removing tag component with lifetime of one frame using the same system with two command buffers. Documentation is really bare and its not obvious we have that kind of tool at our disposal.
The missing link I wanted for jobs, no longer needing entities.foreach on the main thread to run safe relationships checking between entities, or using chunk data passed into jobs and looping for existing entity match, thank you! So much more simple
39:00 I'm confused, this explanation seems to contradict use of tag components as advertised earlier in the talk. If there is not much door and button entities - then there is no advantage in implementing it as tags other than preference. The same interaction implemented as regular component data (read every tick) has low and constant overhead in this conditions too AND you wont necessarily have to rewrite it once number of entities grows by order of magnitude suddenly.
Every frame is a simulation of the game world at a particular time. Think of all the states(data) as a dependency chain. Every node of the chain is something like a "simulation pass" or a job. Then DOTS running the passes via job system. It is very like rendering pipeline: every pixel is a state, every pass is a job, main pass depends on the pre-pass(depth or something else), and post-processing pass depends on the main pass. And the final framebuffer is the simulation result of the current frame.
Hmm I don't know. Entity interaction is the one thing that really bothers me about ECS architectures and while this approach is probably good enough to be practical in a real scenario I don't think this is as good as it gets
I have also been stuck at that. the only solution i found was to use fooEntityPrefab = conversionSystem.GetPrimaryEntity(fooGameObjectPrefab) but that only works if the door and button are under the same parent with convert to entity component.
you don't. you are thinking the way of oop. which is not desirable. you have to have right components, systems will do the work. like dooropener system will open the door (ie change state of doorstate component) if buttonstate component has on state. button state and door state can be linked by having tag components. when you go data oriented way you have to 'unlearn' oop way, or there will be conflicts.
@@herohiralal3255 If you place your doors and buttons in prefabs/scenes, then use conversion workflow. You will end up having a normal reference between MonoBehaviors converted to Entity reference at conversion. Otherwise if you're generating those entities procedurally (or based on some kind of data like levels from custom level editor), then it should be trivial. Have your conversion create an Entity for every source object first while filling some kind of Dictionary, then just use that dictionary to fill the missing pieces. You can probably do some of this work in a ECS System as well.
such an important talk, I think unity should get this guy to do as much of this as possible to help people with the transition. Understanding syntax and nitty gritty is fine, but without zooming out like this it's worthless.
I hope this speaker does this for every aspect of DOTS. I hope this isn't a one time thing. Feeling a bit left out with all these programmers who started learning python while still in Nursery.
So let's say this talk is way too complicated for me still...... What would be a good place for me to learn the stuff necessary to make use of this talk?
"This is why OOP winds up in these tangled messes." Nah, this is what happens if know nothing about OOP. Powerful tools require knowledge to use properly.
For me the most important and insightful talk from Unite 2019 so far, thank you!
This was such an awesome and useful talk! This specifically addressed my questions and thoughts. I really appreciated it. Thank you.
Great talk. However, I'd like to see ECS talks that break away from position and velocity examples.
This talk just demonstrates that Unity's ECS implementation is very sub-par for generalized use. It's definitely useful for certain niche tasks, but could be dramatically improved. This just goes to show how difficult implementing a fully featured and effective ECS is.
This is my favorite kind of relationship advice ;)
What other kind of relationships are there?
Oh, like database table relationships. Lol. Yeah, I agree
@@omg_look_behind_you Hahaha forever alone... all of us. XD
Props for the talk. There needs to be a how-to section in entities package documentation with examples like the trick about adding and removing tag component with lifetime of one frame using the same system with two command buffers. Documentation is really bare and its not obvious we have that kind of tool at our disposal.
Just the talk I needed. Great job to the presenter!
The missing link I wanted for jobs, no longer needing entities.foreach on the main thread to run safe relationships checking between entities, or using chunk data passed into jobs and looping for existing entity match, thank you! So much more simple
I just spent eight hours reading documentation with trial and error to understand this concept. This guy explained it in an hour.
39:00 I'm confused, this explanation seems to contradict use of tag components as advertised earlier in the talk.
If there is not much door and button entities - then there is no advantage in implementing it as tags other than preference. The same interaction implemented as regular component data (read every tick) has low and constant overhead in this conditions too AND you wont necessarily have to rewrite it once number of entities grows by order of magnitude suddenly.
Please more talks like this one!
Every frame is a simulation of the game world at a particular time. Think of all the states(data) as a dependency chain. Every node of the chain is something like a "simulation pass" or a job. Then DOTS running the passes via job system. It is very like rendering pipeline: every pixel is a state, every pass is a job, main pass depends on the pre-pass(depth or something else), and post-processing pass depends on the main pass. And the final framebuffer is the simulation result of the current frame.
Excellent talk.
This talk is really well delivered, it's engaging.
Thanks for sharing. I loved the simple yet real-world example.
MUST SEE!😀
But how we can obtain the velocity of agent you hidden for us
Relationship is exists from the first meeting
This session really pulled me from OOP perspective. I was really didnt know how to approach ECS.
Hmm I don't know. Entity interaction is the one thing that really bothers me about ECS architectures and while this approach is probably good enough to be practical in a real scenario I don't think this is as good as it gets
So you notify the difference btween struct and class composition
If anyone can answer please, how would you get the reference to door entity from the button entity in the first place?
I have also been stuck at that. the only solution i found was to use
fooEntityPrefab = conversionSystem.GetPrimaryEntity(fooGameObjectPrefab)
but that only works if the door and button are under the same parent with convert to entity component.
you don't.
you are thinking the way of oop. which is not desirable. you have to have right components, systems will do the work. like dooropener system will open the door (ie change state of doorstate component) if buttonstate component has on state. button state and door state can be linked by having tag components.
when you go data oriented way you have to 'unlearn' oop way, or there will be conflicts.
@@asiseverything3404 alright, any tips on how to link the button state and door state?
@@herohiralal3255 If you place your doors and buttons in prefabs/scenes, then use conversion workflow. You will end up having a normal reference between MonoBehaviors converted to Entity reference at conversion. Otherwise if you're generating those entities procedurally (or based on some kind of data like levels from custom level editor), then it should be trivial. Have your conversion create an Entity for every source object first while filling some kind of Dictionary, then just use that dictionary to fill the missing pieces. You can probably do some of this work in a ECS System as well.
@@phobos2077_ i figured it out some time between posting this comment and today lol
I want courses or detail document for learning ECS in unity, pls ?
such an important talk, I think unity should get this guy to do as much of this as possible to help people with the transition. Understanding syntax and nitty gritty is fine, but without zooming out like this it's worthless.
This guy .... "Speaker: Luna Meier, Unity"
He's transgender
Excellent talk, very useful for beginner.
I hope this speaker does this for every aspect of DOTS. I hope this isn't a one time thing. Feeling a bit left out with all these programmers who started learning python while still in Nursery.
Command pattern with navmeshagent make me madness
Thank you, a neat and smart trick. If anyone stuck with this, please note the attribute in comment.
Great talk. Thank you!
The url of the slide is incorrect
22:52 I tried this but still getting the error at runtime :(
So let's say this talk is way too complicated for me still...... What would be a good place for me to learn the stuff necessary to make use of this talk?
Frequently
why are you using a nonconcurrent system concurrently? makes 0 sense, since unity themselves designed it
"This is why OOP winds up in these tangled messes." Nah, this is what happens if know nothing about OOP.
Powerful tools require knowledge to use properly.
How do you handle DI in OOP in Unity? Because the way I see it, it's singleton(breaks OOP), static class(breaks OOP), or tangled messes.
It's too obvious stuff