This is only a very brief overview of the ECS and Data-Oriented-Design. There are lots of resources in the description by people much smarter than me who go into more detail. I can't recommend watching those enough.
This is literally the best video on ECS ever made. Thank you so much! Can't wait to see (and use) your ECS library for UE4. (dude, make it open-source, there are plenty of potential contributors out there!!!!)
I've watched probably every single other ECS and Data Oriented Programming video on youtube up until this point, but if I'd have found yours earlier I wouldn't even have needed to watch the others. This is by far the best breakdown I've seen. Great examples, and thank you for showing the code and breaking it down to chunks and explaining those. I'm so lucky I started learning programing and discovered this concept early... I honestly always just assumed that programming systems and components were how games worked. Not with those words, but in my mind, having a whole chunk set aside that tells everything how to move or whatnot just makes so much sense. It seems insanely convoluted to need to "teach" every single thing in a game how it works. I only recently learned about the idea of inheritance, and that just makes everything even crazier to me! How has this been the norm for as long as it has? It blows my mind. lol
Thank you so much for this video. I actually never even considered optimising for cache until now. I hope we'll see more videos like this from you in the future.
Great Video! Your speed of talk and voice is slightly sleep inducing but i really enjoyed that only important information and examples are shown, no unecessary intro to waste time or unrelated info. Great Job, thumb up.
Data oriented design is just so logical. It's almost like when we've programmed in OOP the whole time, we tried to ignore the actual problem of transmuting data and instead focused on structuring the code with inheritance patterns, no matter if this would actually help to solve the problem. Just because someone once said that software should be written using OOP.
This is a fantastic explanation of ECS and an implementation of it inside an existing codebase that isn't built for it, thank you! I did have a few questions that the code explanation didn't really cover in detail that I think would have helped with explaining it more. 1) This is just to confirm it incase I'm misunderstanding, when your implementing into the actor in this case your getting a template of specific components(I'm assuming if the template doesn't already exist and if it does then just gets it from the existing list of archetypes that were created at runtime) and then creating a generic entity class that is intended to work with that archetype, then you setup the components in that entity(that part I understood) and then once its ready, tell the archetype that this entity is part of that list of entities and that it should be updated and such? 2) Where did the system's part of the ECS actually get updated? The code example didn't show where that stuff actually gets used outside of what the systems would be doing inside it. Again a fantastic video, I know asking to see the source code would be a bit much(assuming the project is probably super messy or whatever) but if its possible that would definitely go a long way as well because ECS definitely sounds like a great new tool to use...
GetArchetype gets or creates a new "database table" for the specific components. The Entity is just a unique ID and not a class. The CreateEntity function just returns the first free entity id in the pool, and AddEntity is to add a new row into the archetype database with new data for that entity id. Systems are updated through a Scheduler, it basically has a single FTickFunction for each ETickingGroup. A system class is registered to one of those tick functions and when executed it just loops over all registered systems and calls Update on them. A bit hard to release the source ATM, this is only a MVP and there are lots of features I want implemented before I can consider releasing it (Multithreading, networking, blueprints etc.)
@@dennisaaa_ Ah ok thank you, so that answers my question regarding the entity. But for the Systems, like are you registering them to the Scheduler inside the Scheduler, or using some sort of data asset to list them out and have the Scheduler read from it initially and setup the System to their corresponding tick function or something? I guess the basic version of what I'm asking is, I have a System I've made and now what's the process of hooking it up to the Scheduler so it can update? I really appreciate you answering my questions, if you ever do release the source code(no rush btw) probably having this Boids example as a "Simplified Version(or Branch)" without all the other bells and whistles would probably help others with understanding it easier as a learning resource...
@@YawLighthouse As of now systems are manually registered in a custom derived scheduler class unique for each project. I am not happy with this current setup and would like to automate it in the future which is why I didn't go into much detail about it
@@dennisaaa_ Ah gotcha, again I appreciate you answering my questions. Everytime I looked into a simple implementation of EQS in C++ to learn from I would always be pointed to use Flecs instead of just something to learn from(so if I need to make my own implementation I have the knowledge to do so sort of thing) so you answering questions and providing a barebones explanation helped alot! :)
Much appreciated! One question I struggle with is how entities bunch their components together, now I understand that to get each Move+Location component you have to iterate over several lists as they're grouped by archetype.
How would you integrate something like an oct-tree or bsp-tree into your example to speed up the n^2 operation of finding the nearby boids. How would that fit into ECS?
In this example I just used a grid to solve this which is very friendly to ECS. I have never had to implement an Oct-Tree or BVH etc. with ECS before so I can't comment on it. But different problems require different solutions so it's possible ECS is not a good fit for this
What type of games will benefit from ECS? How does it work in networked games? I have so many questions. But a 3x performance increase on a boid system seems like only scratching the surface. I’ve just been using OOP for so long I can’t think of places to use this!
You can use ECS is all types of projects, even outside of games. Though it's a tool and not a magic wand, you have to know when using it will help you or if it'll just make things more complex. For example, if you have lots and lots of players or AI that use the character movement then it might be worth exploring an ECS way of handling capsule movement. But if you don't have lots of entities that are using capsule movement then using OO might be the best way of solving that problem
"performance boost" = you can easily have 100 to 10000 as many simulated assets/agents, actng independently, fulfilling indepentend "scedules/jobs" , with ecs. The upper bound is mostly set by the ammount if cpu cache, and the slow ram+mainboard is less bottlenecking. This is very useful for simulation games (with large populations like Tropico that are composites of lists of traits/states, following basic needs and scedules), citybuilders (anything adjacent to dwarf fortress), anything adjacent to factorio, and the general RTS genre will easily lose its [200 units per faction limit] just by using ecs. You likely want to simplify pathfinding by precomputing and storing distance-fields to common/central rooms/doors/signposts on the gpu, and doing a* pathfinding only on the gpu, or by doing the timberborn-district-constrain, even only in a soft-version by using doors and gareways like pseudo-district-borders, and buffering distanceFields to all the doors/gates, so that any agent can easily triangulate its position in a maze, by just loading 3 (or more) relevant distance-field maps, that instantly tell the direction to 3 doors (gpus are super fast at estimating the first derivative for a general direction for a shortest path), and that gives a VERY good a* hint to where anything may be, within segments of 1024x1024 pixels. All this is the reason, I bought a ryzen9 with a gtx 3080, that underclocks even the slowest avalable 32 gb ram to run at only 2900ish ghz. I bought a pc, optimized for ECS, and it almost looks like the slow and small mainboard is an insult to all the things connected to it.
How does caching work when it comes to systems that operate on multiple components? 6:25 // movement system example foreach eid in entities: LocationComponent[eid].x += MovementComponent[eid].x; LocationComponent[eid].y += MovementComponent[eid].y; ... Do you get a cache miss in this case? How does the cpu have both LocationComponents and MovementComponents in the cache line? I hope its not a stupid question, i just can't wrap my head around this.
It depends. Firstly how the ECS is designed, is it using large mega component arrays for the program, does it group single components as tuples or does it use an archetype system as in unity? But in general though, you probably have components in L2 or L3 cache which still helps iteration time with multiple components
Hi, awesome video, was also thinking about this and am curios where we can find your library, also consider open sourcing it as it can benefit it's development greatly.
8:54 I feel attacked. This sums up my situation completly. When i noticed many instances of an object were running at the same time, i turnt to Multithreading, and now my code looks totally unrecognisable to the begining with iterations of code that still arent anywhere close to working consistently! Ive stuck on this same issue for months.
Have you 4k unreal actors that are updated in your last system? If so that's likely going to be a huge bottleneck. AActor is 800 bytes without any user data, and they'll be scattered all over memory. Have a look at perhaps having one actor with the instanced static mesh (or hierarchical variant) component. Good overview. Nice work.
Actually the component data can be better allocated to reduce this scattering. It is one of the requirements for having thousands of actors active in a scene.
This is interesting, 3 times faster, I must admit it's alot faster using unitys ecs systems, maybe its burst as well, or the way they store stuff, not sure. But good to know there are ways to implement similar approaches in other engines.
Fast compared to what? Are you saying that you wrote the whole program exactly in Unity again and it's fast? Forget the comparisons now. I am using both of them. Unity is smaller than Unreal. I'm not talking about speed. Unity still growing as a package. They take the things that Unreal has for years, from those the individuals and companies who have been on the market for years, and include them in the system. The important thing is which package is more suitable for style and production conditions? This is how product selection is made.
The two problems that I see with ECS are: - If you have, for example, 100 entities (minecraft skeletons, for example), where each entity has 10 components, and you have 10 systems to process these components, you would have to iterate 1000 (or 10 * 100) times, or, in other words, iterate over each entity 10 times instead of just 1 time with basic update() OOP design. So, you trade cache misses for 10 times the iteration? Doesn't seem fast to me. - If you have systems that target multiple (or even 2) components, this defeats all benefits from cache locality, making it as slow as OOP, maybe even slower (arguably).
Your conclusion just seems wrong. This was already tested many times in different frameworks and the ECS is inherintly faster than OOP. You literally take only data you need and process it all in one system one time per frame, instead of taking objects scattered in heap and call object.UpdateYourOwnData().
@@lekretka There are several problems with that logic: 1 - ECS is not cache-friendly by default. You can allocate your components in heap wherever you want and it will be as bad as "OOP". 2 - OOP is not that bad, big classes are bad. You can allocate your "small" objects (or components in component based system) using a pool or something similar, and it can be as cache-friendly as you want. Yes, there's a thought that systems in ECS allow processing the only data you need (since components of same type are allocated as big blocks), but that also requires more iteration, which require more cycles to process (I know, computer performance is not all about cycles, but still), but that also a dellusion, since most ECS systems actually work with more than one, or even multiple component types (practical example - Overwatch presentation about netcode and ecs), in which case, CPU will struggle, since components most likely will be in different heap locations, and it will be a much better option to just process blocks of OOP objects. I'm not against ECS, just watned to make that clear.
I'm also wondering why we could get performance benefit from ECS because of reduced cache miss. IMHO I think one system only touch one component sounds too perfect to me. Even though one type of the components can be put together and reduce cache miss, while cross referencing different types of components is still causing cache miss. However I do think ECS, meaning composition over inheritance (making data structure reusable) and separation between system (logic) and components (data), is making my head more clearer while implementing game. And it seems that it is very easy to run multi-threaded, which ultilizes the full power of a multi-core CPU.
Soooo ECS is very inconvinent, but can boost your perfomance if you have a lot of actors/objects? That sounds like something for extreme rare cases. I mean it's a great thing, but in 95% you don't need that. If you have 10 characters in your level, you don't need to hurt your brain trying to make ECS - instead just use nomal human OOP and voila!
It is currently inconvenient, but Unity is trying to popularize ECS as part of their "Performance by default" stance. Everyone can benefit from performance increases. And open possibilities to really help genres like MOBAS, strategy games and simulation games. As soon as Unity ECS tools come out of preview I will recommend all pathfinding in unity to be done utilizing ECS as the performance increase is incredible.
OOP is often what people say is normal cause that's what they know. Working in large games there is an underlying benefit to ECS which is the tenets of data oriented design. Even if performance isn't an issue it's good to know about different approaches to managing sets of data at a system level, because normal human OOP can often become very circular and gross, and even under the best conditions from a (usually never senior) programmer who swears they'll only ever write perfect code, there can still get to be an abstract level of bloat to deal with. The very fact we have games running in loops lends some credence as to why ECS and data driven design can be useful. Remember that these are just tools, and the more tools you know and understand, the better you'll be at solving problems. Framing everything in the context of "this or that" is the only way means you're generally choosing to stay ignorant to some degree.
I'm creating a mobile project in Unity using DOTS (ECS), and performance isn't the only reason I'm doing it, everything is easier to do when the data is ready! (networking, gameplay, Rendering ... )
once you understand, learn it, get used to it ecs is cleaner, more understandable easy to use and modify. it's not just good for performance, it's good for the code structure.
This is only a very brief overview of the ECS and Data-Oriented-Design. There are lots of resources in the description by people much smarter than me who go into more detail. I can't recommend watching those enough.
This is literally the best video on ECS ever made. Thank you so much! Can't wait to see (and use) your ECS library for UE4.
(dude, make it open-source, there are plenty of potential contributors out there!!!!)
I've watched probably every single other ECS and Data Oriented Programming video on youtube up until this point, but if I'd have found yours earlier I wouldn't even have needed to watch the others. This is by far the best breakdown I've seen. Great examples, and thank you for showing the code and breaking it down to chunks and explaining those.
I'm so lucky I started learning programing and discovered this concept early... I honestly always just assumed that programming systems and components were how games worked. Not with those words, but in my mind, having a whole chunk set aside that tells everything how to move or whatnot just makes so much sense. It seems insanely convoluted to need to "teach" every single thing in a game how it works. I only recently learned about the idea of inheritance, and that just makes everything even crazier to me! How has this been the norm for as long as it has? It blows my mind. lol
One of the best game dev videos on the internet right now. Well done, lad
Thank you so much for this video. I actually never even considered optimising for cache until now. I hope we'll see more videos like this from you in the future.
Just found your channel today and all of the content I've seen so far has been incredibly informative. Thank you for inspiring me to keep on learning!
Great Video! Your speed of talk and voice is slightly sleep inducing but i really enjoyed that only important information and examples are shown, no unecessary intro to waste time or unrelated info. Great Job, thumb up.
Atleast it wasn't a 2 hour long video.
Pro tip: This is exactly what the youtube playback speed is for.
And now we got MassEntity! Thanks for this video!
Data oriented design is just so logical. It's almost like when we've programmed in OOP the whole time, we tried to ignore the actual problem of transmuting data and instead focused on structuring the code with inheritance patterns, no matter if this would actually help to solve the problem. Just because someone once said that software should be written using OOP.
This is a fantastic explanation of ECS and an implementation of it inside an existing codebase that isn't built for it, thank you! I did have a few questions that the code explanation didn't really cover in detail that I think would have helped with explaining it more.
1) This is just to confirm it incase I'm misunderstanding, when your implementing into the actor in this case your getting a template of specific components(I'm assuming if the template doesn't already exist and if it does then just gets it from the existing list of archetypes that were created at runtime) and then creating a generic entity class that is intended to work with that archetype, then you setup the components in that entity(that part I understood) and then once its ready, tell the archetype that this entity is part of that list of entities and that it should be updated and such?
2) Where did the system's part of the ECS actually get updated? The code example didn't show where that stuff actually gets used outside of what the systems would be doing inside it.
Again a fantastic video, I know asking to see the source code would be a bit much(assuming the project is probably super messy or whatever) but if its possible that would definitely go a long way as well because ECS definitely sounds like a great new tool to use...
GetArchetype gets or creates a new "database table" for the specific components. The Entity is just a unique ID and not a class. The CreateEntity function just returns the first free entity id in the pool, and AddEntity is to add a new row into the archetype database with new data for that entity id.
Systems are updated through a Scheduler, it basically has a single FTickFunction for each ETickingGroup. A system class is registered to one of those tick functions and when executed it just loops over all registered systems and calls Update on them.
A bit hard to release the source ATM, this is only a MVP and there are lots of features I want implemented before I can consider releasing it (Multithreading, networking, blueprints etc.)
@@dennisaaa_ Ah ok thank you, so that answers my question regarding the entity. But for the Systems, like are you registering them to the Scheduler inside the Scheduler, or using some sort of data asset to list them out and have the Scheduler read from it initially and setup the System to their corresponding tick function or something?
I guess the basic version of what I'm asking is, I have a System I've made and now what's the process of hooking it up to the Scheduler so it can update?
I really appreciate you answering my questions, if you ever do release the source code(no rush btw) probably having this Boids example as a "Simplified Version(or Branch)" without all the other bells and whistles would probably help others with understanding it easier as a learning resource...
@@YawLighthouse As of now systems are manually registered in a custom derived scheduler class unique for each project. I am not happy with this current setup and would like to automate it in the future which is why I didn't go into much detail about it
@@dennisaaa_ Ah gotcha, again I appreciate you answering my questions. Everytime I looked into a simple implementation of EQS in C++ to learn from I would always be pointed to use Flecs instead of just something to learn from(so if I need to make my own implementation I have the knowledge to do so sort of thing) so you answering questions and providing a barebones explanation helped alot! :)
Much appreciated! One question I struggle with is how entities bunch their components together, now I understand that to get each Move+Location component you have to iterate over several lists as they're grouped by archetype.
thanks, this is really helpful
Nice. Very informative. Subscribed
great video, thanks
How would you integrate something like an oct-tree or bsp-tree into your example to speed up the n^2 operation of finding the nearby boids. How would that fit into ECS?
In this example I just used a grid to solve this which is very friendly to ECS.
I have never had to implement an Oct-Tree or BVH etc. with ECS before so I can't comment on it. But different problems require different solutions so it's possible ECS is not a good fit for this
anyobdy able to explain to me what the FQuery or Query in this code example is? Is it UE thing or something custom they made?
What type of games will benefit from ECS? How does it work in networked games? I have so many questions. But a 3x performance increase on a boid system seems like only scratching the surface. I’ve just been using OOP for so long I can’t think of places to use this!
You can use ECS is all types of projects, even outside of games. Though it's a tool and not a magic wand, you have to know when using it will help you or if it'll just make things more complex.
For example, if you have lots and lots of players or AI that use the character movement then it might be worth exploring an ECS way of handling capsule movement. But if you don't have lots of entities that are using capsule movement then using OO might be the best way of solving that problem
"performance boost" = you can easily have 100 to 10000 as many simulated assets/agents, actng independently, fulfilling indepentend "scedules/jobs" , with ecs. The upper bound is mostly set by the ammount if cpu cache, and the slow ram+mainboard is less bottlenecking.
This is very useful for simulation games (with large populations like Tropico that are composites of lists of traits/states, following basic needs and scedules), citybuilders (anything adjacent to dwarf fortress), anything adjacent to factorio, and the general RTS genre will easily lose its [200 units per faction limit] just by using ecs.
You likely want to simplify pathfinding by precomputing and storing distance-fields to common/central rooms/doors/signposts on the gpu, and doing a* pathfinding only on the gpu, or by doing the timberborn-district-constrain, even only in a soft-version by using doors and gareways like pseudo-district-borders, and buffering distanceFields to all the doors/gates, so that any agent can easily triangulate its position in a maze, by just loading 3 (or more) relevant distance-field maps, that instantly tell the direction to 3 doors (gpus are super fast at estimating the first derivative for a general direction for a shortest path), and that gives a VERY good a* hint to where anything may be, within segments of 1024x1024 pixels.
All this is the reason, I bought a ryzen9 with a gtx 3080, that underclocks even the slowest avalable 32 gb ram to run at only 2900ish ghz. I bought a pc, optimized for ECS, and it almost looks like the slow and small mainboard is an insult to all the things connected to it.
How does caching work when it comes to systems that operate on multiple components?
6:25
// movement system example
foreach eid in entities:
LocationComponent[eid].x += MovementComponent[eid].x;
LocationComponent[eid].y += MovementComponent[eid].y;
...
Do you get a cache miss in this case?
How does the cpu have both LocationComponents and MovementComponents in the cache line?
I hope its not a stupid question, i just can't wrap my head around this.
It depends. Firstly how the ECS is designed, is it using large mega component arrays for the program, does it group single components as tuples or does it use an archetype system as in unity? But in general though, you probably have components in L2 or L3 cache which still helps iteration time with multiple components
Hi, awesome video, was also thinking about this and am curios where we can find your library, also consider open sourcing it as it can benefit it's development greatly.
you can find the ecs plugin apparatus in marketplace
I feel my brain growing
8:54 I feel attacked. This sums up my situation completly. When i noticed many instances of an object were running at the same time, i turnt to Multithreading, and now my code looks totally unrecognisable to the begining with iterations of code that still arent anywhere close to working consistently! Ive stuck on this same issue for months.
Have you 4k unreal actors that are updated in your last system? If so that's likely going to be a huge bottleneck. AActor is 800 bytes without any user data, and they'll be scattered all over memory. Have a look at perhaps having one actor with the instanced static mesh (or hierarchical variant) component.
Good overview. Nice work.
Actually the component data can be better allocated to reduce this scattering. It is one of the requirements for having thousands of actors active in a scene.
Instant subscribe
What esc may require the most, is probably, the docs.
This is interesting, 3 times faster, I must admit it's alot faster using unitys ecs systems, maybe its burst as well, or the way they store stuff, not sure. But good to know there are ways to implement similar approaches in other engines.
Fast compared to what? Are you saying that you wrote the whole program exactly in Unity again and it's fast? Forget the comparisons now. I am using both of them. Unity is smaller than Unreal. I'm not talking about speed. Unity still growing as a package. They take the things that Unreal has for years, from those the individuals and companies who have been on the market for years, and include them in the system. The important thing is which package is more suitable for style and production conditions? This is how product selection is made.
Is this basically the same as the MassEntity system in UE5?
Yes
Is it possible to do and ECS like system with actor components in bp?
That would require a complete rework of blueprints.
You can do it in Apparatus ECS.
What do you think of MASS (ECS) in UE5 :) ?
Video coming soon
@@dennisaaa_ define soon Now hehehe
@@dennisaaa_ Can't wait
The two problems that I see with ECS are:
- If you have, for example, 100 entities (minecraft skeletons, for example), where each entity has 10 components, and you have 10 systems to process these components, you would have to iterate 1000 (or 10 * 100) times, or, in other words, iterate over each entity 10 times instead of just 1 time with basic update() OOP design. So, you trade cache misses for 10 times the iteration? Doesn't seem fast to me.
- If you have systems that target multiple (or even 2) components, this defeats all benefits from cache locality, making it as slow as OOP, maybe even slower (arguably).
Your conclusion just seems wrong.
This was already tested many times in different frameworks and the ECS is inherintly faster than OOP.
You literally take only data you need and process it all in one system one time per frame, instead of taking objects scattered in heap and call object.UpdateYourOwnData().
@@lekretka There are several problems with that logic:
1 - ECS is not cache-friendly by default. You can allocate your components in heap wherever you want and it will be as bad as "OOP".
2 - OOP is not that bad, big classes are bad. You can allocate your "small" objects (or components in component based system) using a pool or something similar, and it can be as cache-friendly as you want.
Yes, there's a thought that systems in ECS allow processing the only data you need (since components of same type are allocated as big blocks), but that also requires more iteration, which require more cycles to process (I know, computer performance is not all about cycles, but still), but that also a dellusion, since most ECS systems actually work with more than one, or even multiple component types (practical example - Overwatch presentation about netcode and ecs), in which case, CPU will struggle, since components most likely will be in different heap locations, and it will be a much better option to just process blocks of OOP objects.
I'm not against ECS, just watned to make that clear.
I'm also wondering why we could get performance benefit from ECS because of reduced cache miss. IMHO I think one system only touch one component sounds too perfect to me. Even though one type of the components can be put together and reduce cache miss, while cross referencing different types of components is still causing cache miss.
However I do think ECS, meaning composition over inheritance (making data structure reusable) and separation between system (logic) and components (data), is making my head more clearer while implementing game. And it seems that it is very easy to run multi-threaded, which ultilizes the full power of a multi-core CPU.
Soooo ECS is very inconvinent, but can boost your perfomance if you have a lot of actors/objects? That sounds like something for extreme rare cases. I mean it's a great thing, but in 95% you don't need that. If you have 10 characters in your level, you don't need to hurt your brain trying to make ECS - instead just use nomal human OOP and voila!
It is currently inconvenient, but Unity is trying to popularize ECS as part of their "Performance by default" stance.
Everyone can benefit from performance increases. And open possibilities to really help genres like MOBAS, strategy games and simulation games.
As soon as Unity ECS tools come out of preview I will recommend all pathfinding in unity to be done utilizing ECS as the performance increase is incredible.
ECS is bot inherently more complex, clean code is one of its benefits.It is time consuming and expensive to retrain developers.
OOP is often what people say is normal cause that's what they know. Working in large games there is an underlying benefit to ECS which is the tenets of data oriented design. Even if performance isn't an issue it's good to know about different approaches to managing sets of data at a system level, because normal human OOP can often become very circular and gross, and even under the best conditions from a (usually never senior) programmer who swears they'll only ever write perfect code, there can still get to be an abstract level of bloat to deal with. The very fact we have games running in loops lends some credence as to why ECS and data driven design can be useful. Remember that these are just tools, and the more tools you know and understand, the better you'll be at solving problems. Framing everything in the context of "this or that" is the only way means you're generally choosing to stay ignorant to some degree.
I'm creating a mobile project in Unity using DOTS (ECS), and performance isn't the only reason I'm doing it,
everything is easier to do when the data is ready! (networking, gameplay, Rendering ... )
once you understand, learn it, get used to it
ecs is cleaner, more understandable easy to use and modify. it's not just good for performance, it's good for the code structure.