This has to be in the top 5 UA-cam videos on the subject. You should be a professor or run paid courses because that was the best explanation on the subject.
I've shattered up. The clean code that does the job better (100 times) than code of mine (about 10k lines of code I was proud of). Okay, the man of great mind, you beat me. I realized than my programming skills isn't that great as yours.
Hah, and then you go on to find a memory leak in my code :D I hope you learned something from this video, the system does have limitations which other commenters have pointed out
Thanks for this well explained video, this gonna help me a lot to implement ECS in my game that I am writing in c++. You made one of few videos that really implemented ECS and no just a bunch of components with logic implemented in.
Thanks. Very useful information. Even if the concept is not new, its sometimes hard to see through the jungle of buzzwords. Also liked you showing code in C, which makes it very easy to understand.
Cherno mentioned something really important. If you create entities that can have multiple components, store them as pointers or even worse, create them inside Entity, you will end up with high memory usage and in case of iterating through components and dealing with elements, it will become a huge mess with bad performance. Idea of having entity just as an ID or keep this connection to component but within systems, iterate over components, not entities itself is much more appealing and performant.
it would have been intresting to see how you'd add a new type of entity with it's own behaviour. I was thinking about adding a new flag array (or expand alive-array), that stores what is the type of the entity, and use that, but then if you'll have tons of entities, the system part can be overloaded with if statements. Anyway loved the video! :D
Generally with these types of systems "types" are just a combination of unique component sets. However, as you said, you may want more types of flags without making separate components, like IS_ON_FIRE, IS_FROZEN, etc. In that case you could end up with a bunch of if statements or you could use something like a state machine.
The Only Thing I Needed for "Entity-Component-System" is The Description The Thing That You Playing The Game and The NPC That Destroys You Player is Protagonist NPC as Enemy is Antagonist That's The Thing I Wanna Know
Nice video. I have a question though. Since you use a bitmask on the entities to store which components they have, that heavily depends on the order in which you register the components. If you suddenly change the order in which you register them, the system fails. Do you have any plans for handling that? I'm asking because I'm working on my own ECS as well, but can't figure out how to solve this problem.
I'm not actually using an ECS in the game I'm working on, but I see the issue. If one day you decide that component C is not necessary anymore, but you still register A, B, D, then they will be misaligned. You could just continue to register C until you need another kind of component later on. Not the most appealing solution, but should work okay. Is there another reason you may want to change the registration order?
@@DylanFalconer Thx for the reply. I understand that, if you know the internals of your own engine well, this is not really a big issue, as you can just take this small inconvenience into account. I was mostly thinking from the perspective of other people using your ECS. I actually found a pretty nice solution online, where you keep track inside your systems, which entities and components are relevant for that system, not the other way around, where the entity keeps track of that. This way, the order of the components or systems is not important anymore :) Again, great video, and thanks for the reply :)
does using a bit field to filter entities in this implementation mean the number of component types we can create is extremely limited? For example would using a 64 bit int as the bit field mean our application can only have 64 component types? If so then this really isn't going to be enough for many applications, what would you suggest as an alternative to using a bitfield here?
@@cipherpunk7409 i ended up using sparse sets after reading the article "ecs back and forth" by the creator of entt which solves this problem. But yes multiple bitfields could do however I'm not sure how nicely it would scale if you had, say 200 or more components which is not an unrealistic number especially if your game engine itself uses ecs internally as well as for gameplay programming.
@@phee3D Nice solution. I've definitely heard of people doing the multiple bit field solution for 200+ components without performance issues. But it definitely depends on what you're making. Glad you found your path forward!
How does your ecs_query handle many systems and many (MANY) entities? I really like the approach you've laid out here, it's helped me in developing my own, but this seems to be a possible bottleneck since this must be queried on every call of your system function. I guess since you don't have a concept of a 'system' in your framework (meaning you aren't keeping any internal state for systems), it's hard to get around this problem, though.
I haven't thought about this problem in a long time, but my first approach would be to benchmark and if it's actually an issue then look into caching results.
Are you sure you don't want to make your tiles entities. Seems like you could make the behaviour of your tiles more flexible by being able to swap in and out different components on the fly and have systems that work on those components.
Indeed you can do that, it really depends what kind of functionality you want for your tiles. If your tiles can perform actions then it's something to consider for sure. For pure aesthetics, probably not. Minecraft has a type of split system where most solid blocks are just Blocks but more complex things like pistons and furnaces are TileEntities.
The downside of mixing tiles with regular entities is that tile position components will be mixed with entity position components. This could be bad if you have a huge number of tiles and you want to for example do collision checking between the entities, because at least in this video's implementation you'd also loop over every tile while just looking for entity position components. A more efficient and complex implementation should totally sidestep this issue. And the other issue with this video's implementation is of course that adding more components makes things slightly slower. Look up enTT on The Cherno's channel for a showcase of such an efficient implementation.
ECS is mostly useful for engine makers rather than game-makers. If you know the types of entities you want to have in your game then you can design a straightforward system for your game with that information. If your game design is fluid and/or experimental then you may benefit from ECS's flexibility.
Crashes on first call to ecs_query if enough entities aren't registered to trigger the realloc bc state.query_result.list was never malloc'd within ecs_init
I am working on implementing my own basic ECS for the first time and this video is extremely helpful! Thank you!
I'm glad it helped!
Me to bro
This has to be in the top 5 UA-cam videos on the subject. You should be a professor or run paid courses because that was the best explanation on the subject.
Why thank you very much, I'm glad you found it useful :)
This really helped me to finally understand what the hell ECS actually is. Thank you, kind sir.
Glad I could help
I've shattered up. The clean code that does the job better (100 times) than code of mine (about 10k lines of code I was proud of). Okay, the man of great mind, you beat me. I realized than my programming skills isn't that great as yours.
Hah, and then you go on to find a memory leak in my code :D I hope you learned something from this video, the system does have limitations which other commenters have pointed out
In the case of bird subclasses, interfaces are used in OPP, example creating a CanFly interface
Thanks for this well explained video, this gonna help me a lot to implement ECS in my game that I am writing in c++. You made one of few videos that really implemented ECS and no just a bunch of components with logic implemented in.
I like topics discussed on this channel
Appreciate what you're doing!
Glad you enjoy it! More to come!
Thanks. Very useful information. Even if the concept is not new, its sometimes hard to see through the jungle of buzzwords. Also liked you showing code in C, which makes it very easy to understand.
Best video on ECS so far.
Cherno mentioned something really important. If you create entities that can have multiple components, store them as pointers or even worse, create them inside Entity, you will end up with high memory usage and in case of iterating through components and dealing with elements, it will become a huge mess with bad performance. Idea of having entity just as an ID or keep this connection to component but within systems, iterate over components, not entities itself is much more appealing and performant.
Damn I wish this was the first video I came across trying to learn this. Thanks for the very clear explanations and walkthrough dude
You're welcome 🤗
I found your channel just recently and I love your videos and the knowledge it provides.
Thank you!
Nice straight forward code. Maybe use an enum to help with the remembering part that makes you uneasy.
Good idea
I Love Default Cubes in Any Kinds of 3D Game Engines
Wow tht is amazingly helpful as i learn unity dots, getting understanding of it under the hood is priceless, thank you!
Glad it was helpful!
it would have been intresting to see how you'd add a new type of entity with it's own behaviour.
I was thinking about adding a new flag array (or expand alive-array), that stores what is the type of the entity, and use that, but then if you'll have tons of entities, the system part can be overloaded with if statements.
Anyway loved the video! :D
Generally with these types of systems "types" are just a combination of unique component sets. However, as you said, you may want more types of flags without making separate components, like IS_ON_FIRE, IS_FROZEN, etc. In that case you could end up with a bunch of if statements or you could use something like a state machine.
Thanks for the rundown!
Thanks for the clear explanation!
I Love Default Cubes in 3D Game Engines
I Love 3D Game Engines Entity Component System
The Only Thing I Needed for
"Entity-Component-System"
is The Description The Thing That You Playing The Game and The NPC That Destroys You
Player is Protagonist
NPC as Enemy is Antagonist
That's The Thing I Wanna Know
Wow nice video, Found this randomly, Will follow your channel
Nice explanation. What font are you using in your terminal?!
Powerful
Together with 3D Game Engines RGB-Colored Arrows 3D XYZ Axis
Nice video. I have a question though. Since you use a bitmask on the entities to store which components they have, that heavily depends on the order in which you register the components. If you suddenly change the order in which you register them, the system fails. Do you have any plans for handling that? I'm asking because I'm working on my own ECS as well, but can't figure out how to solve this problem.
I'm not actually using an ECS in the game I'm working on, but I see the issue. If one day you decide that component C is not necessary anymore, but you still register A, B, D, then they will be misaligned. You could just continue to register C until you need another kind of component later on. Not the most appealing solution, but should work okay.
Is there another reason you may want to change the registration order?
@@DylanFalconer Thx for the reply. I understand that, if you know the internals of your own engine well, this is not really a big issue, as you can just take this small inconvenience into account. I was mostly thinking from the perspective of other people using your ECS.
I actually found a pretty nice solution online, where you keep track inside your systems, which entities and components are relevant for that system, not the other way around, where the entity keeps track of that. This way, the order of the components or systems is not important anymore :)
Again, great video, and thanks for the reply :)
does using a bit field to filter entities in this implementation mean the number of component types we can create is extremely limited? For example would using a 64 bit int as the bit field mean our application can only have 64 component types? If so then this really isn't going to be enough for many applications, what would you suggest as an alternative to using a bitfield here?
No reason you couldn't have multiple bit fields to handle additional component types.
@@cipherpunk7409 i ended up using sparse sets after reading the article "ecs back and forth" by the creator of entt which solves this problem. But yes multiple bitfields could do however I'm not sure how nicely it would scale if you had, say 200 or more components which is not an unrealistic number especially if your game engine itself uses ecs internally as well as for gameplay programming.
@@phee3D Nice solution. I've definitely heard of people doing the multiple bit field solution for 200+ components without performance issues. But it definitely depends on what you're making. Glad you found your path forward!
How does your ecs_query handle many systems and many (MANY) entities? I really like the approach you've laid out here, it's helped me in developing my own, but this seems to be a possible bottleneck since this must be queried on every call of your system function. I guess since you don't have a concept of a 'system' in your framework (meaning you aren't keeping any internal state for systems), it's hard to get around this problem, though.
I haven't thought about this problem in a long time, but my first approach would be to benchmark and if it's actually an issue then look into caching results.
17:50 lol
Are you sure you don't want to make your tiles entities. Seems like you could make the behaviour of your tiles more flexible by being able to swap in and out different components on the fly and have systems that work on those components.
Indeed you can do that, it really depends what kind of functionality you want for your tiles. If your tiles can perform actions then it's something to consider for sure. For pure aesthetics, probably not. Minecraft has a type of split system where most solid blocks are just Blocks but more complex things like pistons and furnaces are TileEntities.
The downside of mixing tiles with regular entities is that tile position components will be mixed with entity position components. This could be bad if you have a huge number of tiles and you want to for example do collision checking between the entities, because at least in this video's implementation you'd also loop over every tile while just looking for entity position components. A more efficient and complex implementation should totally sidestep this issue. And the other issue with this video's implementation is of course that adding more components makes things slightly slower. Look up enTT on The Cherno's channel for a showcase of such an efficient implementation.
I missed u
This is a very clear explanation! Thank you! But you microphone or recording application is disaster! 😅❤
" not working on a game "
Unity : *ECS*
what is that pig generator project called? i rly wanna start making one but i might need some hints
Nice slides, might I ask which software?
Cheers! For this one I actually just used images and OBS's "image slide show" option.
@@DylanFalconer oh that's cool thanks
What did you use to create the ui at 10:13? Imgui?
Similar, github.com/Immediate-Mode-UI/Nuklear
Would a game like smash brothers ultimate benifit from an ECS structures?
ECS is mostly useful for engine makers rather than game-makers. If you know the types of entities you want to have in your game then you can design a straightforward system for your game with that information. If your game design is fluid and/or experimental then you may benefit from ECS's flexibility.
@@DylanFalconer alright thanks
Crashes on first call to ecs_query if enough entities aren't registered to trigger the realloc bc state.query_result.list was never malloc'd within ecs_init
This is a bad example of ECS, go look for a better implementation.
Can you explain why it's bad? I bet you can't
The video started off well but it lost me around the 10 min mark.
That's a shame, why is that?