So I watched half of your video but I don't really understand. How does one create a custom component ? When I think of an component I think of Rigidbody, what is the difference between your custom components and a rigidbody component?
That’s a really good Question in this system each component only has data, unlike the Unity components which have both data and methods (logic). In our system we are building, the methods are located in systems. If we want to make a ridged body component we would not do it like in unity where a method on the ridged body is called whenever an entity is hit. Instead we would likely just make a tag “rigidbody” and a component “massVolume” to indicate we want it to be processed by the Collision System of the Physics which would watch all the things that have positions and massVolumes then if they collide it would add a component “collision” to the entity that would contain the information about what collided into it and forces involved or what ever you want your physics system to have and there would be another system maybe “rigidbody system” that would watch for any entities that have both a rigidbody and a collision object on it. That system would then loop through all of them doing whatever you wanted. With all of this setup you could have an entirely different system that maybe is “Paddle Hit System” that system watches for any entities that are tagged with “Paddle” and have a “collision” component and which loop over any that are available and then check the entities collision components to see if the thing that hit it is tagged as a “ball” at which point you just grab the handle that you placed inside your collision’s data and flip the velocity’s x or y component. You have just made a simple pong or breakout clone.
Unity uses the word "component" to mean something different than what it usually means on an ECS. So when you hear Entity, Component, or System, don't try to compare it with unity terminology. Simply think of 3 plain c# classes. In a very simple ECS, an Entity is a simple class with an array of Components, a Component is a simple class with a few properties (hp, position, etc), and a System is a simple class that contains 1 method "update" which takes a list of Entities and updates the entities that contain a very specific set of components while ignoring the ones that do not. That's an ECS at its core, of course building it like that would be really slow and difficult to work with lol.
This is far and above one of the best breakdowns of an ECS, and it is the only one I've seen (so far, but still, been at this research ecs thing for the whole year I've been trying to be a gamedev) that doesn't just talk about what it is, but the architecture itself. Thank you. I wish your channel had taken off, because you have a fantastic way of simplifying the complicated. Ah well, at least I have the rest of your playlist to dig through
16:14 maybe the best merchants are themself boss power NPCs that are hard to actually kill. Depending on the genre they also might be able to flee from you so fast you can't find them or kill them.
31:00 No, you don't have to go through every entity in the system (that would be extremally stupid). You just go through parents of specific components and check if they also have this second or third component you are checking.
This is really a great introduction to ECS for those like me who totally know nothing about it and plan to write a small game. OOP is really not suited to game development if we treat entities as classes.
But this is mindboggling. Unity does not endorse OOP for gamedev. The whole paradigm of MonoBehaviour is called component-object model and it's more or less the same thing as ECS. Whoever is making an OO game in Unity is terribly wrong right off the bat, and even though C# itself supports it and inheritance is mandatory for clever structuring and non-redundant codebase, Unity has never endorsed it for game development since day 1. I'll repeat, this is why it has COMPONENTS, a TAG SYSTEM, and you typically write managers (which are called systems in ECS). So I don't get what's the big fuss about this?
Care to elaborate on what you meant by that? The way I see it, ECS pretty much is OOP. All the entities and components are objects with their own methods and properties.
Its more the inheritance system that sucks for game development rather than object oriented programming itself, i think. There are many useful features of object oriented programming even without using the giant entity tree of inheritance
So basically, the message is "multiple inheritance is bad for entities/components" vs "OOP is bad for game development". I see "OOP is bad in games" (or even more surprisingly, "OOP is bad in general") a lot, but it seems like approaching many aspects of engine (or just game) design *without* OOP would be an exercise in unnecessary masochism with minimal (if any) performance gains, since most of the heavy lifting in a game is the real-time rendering which executes on the GPU rather than the CPU anyways. I totally get how multiple inheritance is bad for entity/component architecture, I just feel like it's a pretty big leap from that to "OOP is bad for game development", and I see similar statements disturbingly often.
Thank you I am glad. I was worried that it would be too long and drawn out. I am glad it was easy to understand. Have you watched any of the other content? If so how was the other content does it all make sense?
c++ can handle multi-inheritance. Great video. I hope you'll make, in a C# context, Unity's ESC since it seems that you know the implications on video games.
How about some info on handling complex state and flows etc. this seems to work well for really general systems, but not for stateful / sequential tasks, anything other than basic entity relationships.
That's a way to look at it yes but UUIDs take up more data then this and can't be targeted for example I will be using Index:Phase in the following example. If I have an array of 2 components and then I might have handles like this 1:1 2:1 but say I use the 1st element and then "delete" it. I would not want to actually delete the data because that would impact preformance but I also don't want anyone using the handle 1:1 to access the data because it's now invalid and may be being used by a new entity in a new way. So I would advance the phase of the entity thus invalidating the handle and now 1:1 would return null and 1:2 would return the component that is index 1. Does this make more sense now?
@@eforencreates548 I don't think the ESC system actually needs to de-allocate the component(s), the array is kept as-is (allocation wise). It's just that the UUID is cleared (or reused) on the component and when you try to access the component with the old entity UUID, the UUID's no longer match and you get a null. Note that the UUID can be a simple counter as long as you do not have independent threads/machines creating entities that need to be shared. Edit: Again, it is very very similar(if not the same) to your 'phase' in that respect, but I think you don't need that extra concept if you define entities in terms of just their ID. In that case the entity's ID == your 'phase'.
@@erwinmulder1338 you are not talking about a UUID an Universally Unique ID is different even if 2 separate computers make them. What your describing sounds like you have GUID and UUID mixed up a Globally Unique ID has a limited context of safety like a simple counter would. As for why we can't just use an ID it's slower your lookups become atleast 2n instead of just 1n because you have to look up what component index your looking for and then you have to look up that component where as with the phase we are using here all you do is you jump directly to the exact position of the array in the phases array then you check that if it's right your all good and you jump to the actual component you wanted in the component arrays. This is much faster because you don't have to search every element in the array of id's to see if it matches the ID you passed in. Just think how brutal that would be on your timing if you were to do an array for each lookup every time you wanted to access any data because no direct reference to the data should be used because then that ref may nolonger contain the correct data how ever with the phase handles you can pass around the Handle which is effectively a direct reference to the data because it contains direct references to the data but it also contains a reference to the phase that it checks before it let's you use the ref
Shablo5 I am just calling it Uber ECS to give it a name so that the Github repo can be found for example it is an ECS. I do feel that I have made some important changes that some other libs have not implemented like for example no precompile steps and having handles. Those are 2 huge quality of life changes over some other implementations
Your entities will be data only thus no logic. All the logic goes in Systems that scan the data for the conditions they want to change. For example a Velocity system might scan for any entities with both a position and a velocity and if an entity has both change the position by the velocity you may also have a drag system that runs after the velocity system that takes any entities that have a drag and a velocity and modifies the velocity by the drag. This allows the 2 systems to not care at all about the other and to function totally independently but effect the same entities the velocity system does not care about drag and the drag system does not care about position
So I watched half of your video but I don't really understand. How does one create a custom component ? When I think of an component I think of Rigidbody, what is the difference between your custom components and a rigidbody component?
That’s a really good Question in this system each component only has data, unlike the Unity components which have both data and methods (logic).
In our system we are building, the methods are located in systems. If we want to make a ridged body component we would not do it like in unity where a method on the ridged body is called whenever an entity is hit.
Instead we would likely just make a tag “rigidbody” and a component “massVolume” to indicate we want it to be processed by the Collision System of the Physics which would watch all the things that have positions and massVolumes then if they collide it would add a component “collision” to the entity that would contain the information about what collided into it and forces involved or what ever you want your physics system to have and there would be another system maybe “rigidbody system” that would watch for any entities that have both a rigidbody and a collision object on it. That system would then loop through all of them doing whatever you wanted.
With all of this setup you could have an entirely different system that maybe is “Paddle Hit System” that system watches for any entities that are tagged with “Paddle” and have a “collision” component and which loop over any that are available and then check the entities collision components to see if the thing that hit it is tagged as a “ball” at which point you just grab the handle that you placed inside your collision’s data and flip the velocity’s x or y component. You have just made a simple pong or breakout clone.
Unity uses the word "component" to mean something different than what it usually means on an ECS. So when you hear Entity, Component, or System, don't try to compare it with unity terminology. Simply think of 3 plain c# classes. In a very simple ECS, an Entity is a simple class with an array of Components, a Component is a simple class with a few properties (hp, position, etc), and a System is a simple class that contains 1 method "update" which takes a list of Entities and updates the entities that contain a very specific set of components while ignoring the ones that do not. That's an ECS at its core, of course building it like that would be really slow and difficult to work with lol.
That was really well put thank you :)
I believe for collisions specifically I would rather go with an event than with the ecs.
This is far and above one of the best breakdowns of an ECS, and it is the only one I've seen (so far, but still, been at this research ecs thing for the whole year I've been trying to be a gamedev) that doesn't just talk about what it is, but the architecture itself. Thank you. I wish your channel had taken off, because you have a fantastic way of simplifying the complicated. Ah well, at least I have the rest of your playlist to dig through
Thanks man, I'm glad I found this, you really helped me grasp ECS so I can better understand Unity's ECS implimentation. Wish I'd find this sooner!
In my opinion the best video to introduce ecs.
16:14 maybe the best merchants are themself boss power NPCs that are hard to actually kill. Depending on the genre they also might be able to flee from you so fast you can't find them or kill them.
Awesome intoduction to ECS ! I subscribed ! Thanks a lot Eforen Creates !
31:00
No, you don't have to go through every entity in the system (that would be extremally stupid). You just go through parents of specific components and check if they also have this second or third component you are checking.
This is really a great introduction to ECS for those like me who totally know nothing about it and plan to write a small game. OOP is really not suited to game development if we treat entities as classes.
But this is mindboggling. Unity does not endorse OOP for gamedev. The whole paradigm of MonoBehaviour is called component-object model and it's more or less the same thing as ECS. Whoever is making an OO game in Unity is terribly wrong right off the bat, and even though C# itself supports it and inheritance is mandatory for clever structuring and non-redundant codebase, Unity has never endorsed it for game development since day 1.
I'll repeat, this is why it has COMPONENTS, a TAG SYSTEM, and you typically write managers (which are called systems in ECS). So I don't get what's the big fuss about this?
Care to elaborate on what you meant by that? The way I see it, ECS pretty much is OOP. All the entities and components are objects with their own methods and properties.
Its more the inheritance system that sucks for game development rather than object oriented programming itself, i think. There are many useful features of object oriented programming even without using the giant entity tree of inheritance
So basically, the message is "multiple inheritance is bad for entities/components" vs "OOP is bad for game development".
I see "OOP is bad in games" (or even more surprisingly, "OOP is bad in general") a lot, but it seems like approaching many aspects of engine (or just game) design *without* OOP would be an exercise in unnecessary masochism with minimal (if any) performance gains, since most of the heavy lifting in a game is the real-time rendering which executes on the GPU rather than the CPU anyways.
I totally get how multiple inheritance is bad for entity/component architecture, I just feel like it's a pretty big leap from that to "OOP is bad for game development", and I see similar statements disturbingly often.
This was a great video. I'm interested to hear more about events :)
Thank you for the nice content, really insightful and easy to understand
Thank you I am glad. I was worried that it would be too long and drawn out. I am glad it was easy to understand. Have you watched any of the other content? If so how was the other content does it all make sense?
Play it on 1.25 speed
23:22 so I guess bevy being written in Rust is a plus there too
Examples of a language with multiple inheritance:
- C++
- Python
- Common Lisp
You've mentioned at least one of these in your video.
Thank you for mentioning the rest for curious viewers
Ruby is not a multiple inheritance language. stackoverflow.com/questions/10254689/multiple-inheritance-in-ruby
@@I3UCKWHEAT fixed
Great video dude. Very useful, thanks!
c++ can handle multi-inheritance. Great video. I hope you'll make, in a C# context, Unity's ESC since it seems that you know the implications on video games.
Can Do and Should Do are very different things.
How about some info on handling complex state and flows etc. this seems to work well for really general systems, but not for stateful / sequential tasks, anything other than basic entity relationships.
Can you give me some examples of things your having trouble with?
I feel that where you use 'phase', you have reinvented the UUID, except it's used on the handle instead of the entity.
That's a way to look at it yes but UUIDs take up more data then this and can't be targeted for example I will be using Index:Phase in the following example. If I have an array of 2 components and then I might have handles like this 1:1 2:1 but say I use the 1st element and then "delete" it. I would not want to actually delete the data because that would impact preformance but I also don't want anyone using the handle 1:1 to access the data because it's now invalid and may be being used by a new entity in a new way. So I would advance the phase of the entity thus invalidating the handle and now 1:1 would return null and 1:2 would return the component that is index 1. Does this make more sense now?
@@eforencreates548 I don't think the ESC system actually needs to de-allocate the component(s), the array is kept as-is (allocation wise). It's just that the UUID is cleared (or reused) on the component and when you try to access the component with the old entity UUID, the UUID's no longer match and you get a null. Note that the UUID can be a simple counter as long as you do not have independent threads/machines creating entities that need to be shared. Edit: Again, it is very very similar(if not the same) to your 'phase' in that respect, but I think you don't need that extra concept if you define entities in terms of just their ID. In that case the entity's ID == your 'phase'.
@@erwinmulder1338 you are not talking about a UUID an Universally Unique ID is different even if 2 separate computers make them. What your describing sounds like you have GUID and UUID mixed up a Globally Unique ID has a limited context of safety like a simple counter would.
As for why we can't just use an ID it's slower your lookups become atleast 2n instead of just 1n because you have to look up what component index your looking for and then you have to look up that component where as with the phase we are using here all you do is you jump directly to the exact position of the array in the phases array then you check that if it's right your all good and you jump to the actual component you wanted in the component arrays. This is much faster because you don't have to search every element in the array of id's to see if it matches the ID you passed in. Just think how brutal that would be on your timing if you were to do an array for each lookup every time you wanted to access any data because no direct reference to the data should be used because then that ref may nolonger contain the correct data how ever with the phase handles you can pass around the Handle which is effectively a direct reference to the data because it contains direct references to the data but it also contains a reference to the phase that it checks before it let's you use the ref
Holy smokes thanks so much!!!!!
What does Uber ECS do differently than ECS? Also, do you have any recommended readings on this topic?
Shablo5 I am just calling it Uber ECS to give it a name so that the Github repo can be found for example it is an ECS. I do feel that I have made some important changes that some other libs have not implemented like for example no precompile steps and having handles. Those are 2 huge quality of life changes over some other implementations
Bless you
So this approach is more EC than ECS, right?
What makes you think that? I would say that it is very solidly ECS
Oh, hmm, I thought it didn't actually use the "Systems" part of it, just Entities and Components?
How would it do anything without the systems part of it? How ever I did not talk about the systems in as much detail as I did the entities.
Sorry, you're right! Just rewatched it. I've been looking at so many varying ECS patterns/ideas/implementations that my head's spinning. :)
17:50 "Generally speaking you shouldn't have to ever put any logic in your data structures." What?
Your entities will be data only thus no logic. All the logic goes in Systems that scan the data for the conditions they want to change. For example a Velocity system might scan for any entities with both a position and a velocity and if an entity has both change the position by the velocity you may also have a drag system that runs after the velocity system that takes any entities that have a drag and a velocity and modifies the velocity by the drag. This allows the 2 systems to not care at all about the other and to function totally independently but effect the same entities the velocity system does not care about drag and the drag system does not care about position
I shouldn't even hear the phrase "garbage collector" in an engine/game development video.