Ok, disclaimer: I'm not really into this, just watched some videos, maybe I've some wrong assumptions. Have a look at this video: It shows a C++ beginner example from the early 90s that was made to get an idea how C++ works (as opposed to C). Then it shows how you can mess up your code by using shown design pattern in a hypothetical real world example, followed by performance considerations and finally ECS to the rescue. Some thoughts on the video: 1.) It's already in! Unity already has a powerful Entity-Component-System in it. The Entity is the GameObject, it's a container holding *Components* (hence the name), which give functionality to your objects. So you would *never* write an 'Animal' class and inherit different animals from that. This is early 90s C++ sample code. Not Unity. In Unity you would describe what an animal can do by adding a script for every specific functionality your specific animal (e.g. a bird) can do and save the GameObj as a prefab. So we want to have a bird in our game. We need a script describing how it flies. If we want the bird able to take damage and die, we add another script handling this. If we want it to make some crow noises, we add another script handling that. We would never assemble all of that in a single 'Bird : Animal'-class. 2.) No clue about real world game development. An actual bird in a actual game that needs hitpoints would most likely also have: - a behaviour state machine, maybe a behaviout tree. - a hitpoint/stats system, perhaps skill and/or weapon based. - an Animator - collision 3.) Dots is limited. Tell me if I'm wrong but what can it actually do? Calculate positions and rotations multithreaded? But that's all, right? So it's a niche solution for a niche problem. Wouldn't it be much more useful to have a special kind of restricted GameObject used for exactly this purpose? Say you want many birds flying around with no effect on gameplay. Or particles. At least as a first step into your brave new ECS world? Creation and update of this ECSGameObj would be different, Monobehaviours wouldn't work, and any code on it must be compatible to your ECSSystem. So people can use multithreading on systems when they actually need it, the moment they hit that performance border.