3 years ago you explained how object orientation is not ideal, to say the least. Now Unity has adopted data driven design (thanks to Mike Acton) to their engine. Well done proving doubters wrong =) keep up the good work and thanks for the video.
It's not ideal when performance is a requirement, but can be ideal in other scenarios. For example, OO maps very closely to how human visualize the world, and having the code structured in this fashion makes for easier learning, faster implementation times, and easier maintenance, all things being equal. The Data Oriented approach requires you to think in a way that is not second nature, therefore time is spent learning this approach, time is spent implementing it because we have to think in an unnatural way to achieve our goals, and maintenance becomes more expensive for the same reasons and also because if the developer leaves then there's the issue of finding someone with Data Oriented knowledge to replace them and most likely will have to hire and train someone, which costs time and money.
@@RagdollRocket No problemo! Not advocating any particular approach, just trying to add some color on why paradigms such as OO exists at all and how one might benefit from them even if they are not the most performant. Sometimes keeping human labor costs low is more important than achieving maximum computational efficiency, such as in most business organizations, while in other fields such as graphics and gaming the opposite is true. OO has its uses even in gaming where frames-per-second is not crucial, but if you're looking to squeeze every drop from your system then you need to practice Mechanical Sympathy in which knowing your system, knowing it well, and programming to it (of which DOTS is one aspect) is all important.
@@anthonyortiz7924 yeah, I think that's the right thing to do. Staying open minded for any aproach that could improve the development process is the way to go.
@@anthonyortiz7924 Well you wrote: "OO maps very closely to how human visualize the world" I understand but this is something I am struggling with as it is not my the way I visualize the world. I have a tree, it has certain components and nature is executing jobs on these components, multi-threaded mind - hehe. I guess it is how we are all individually "wired". I guess as well in order to have the needed workforce to write code, we had to come up with something that more people would "get". I personally love the ECS model. This is the way Computers were designed to do things, which made me fell in love with code.
Did you find the last slide about blobs inadequate, or are you talking about the component types? I didn't think there's much to visualize assuming you already understand the chunk structure: For an object component, a chunk stores indexes (one per entity) into a managed array outside the chunk, where the actual objects are stored. For a chunk component, a chunk directly stores just one value for all its entities. For a shared component, a chunk stores a single index into a managed array outside the chunk, where the actual shared component value is stored. Through hashing and equality tests, it's ensured that chunks with the same shared component value have the same index into the array. How many chunks reference each value in the array is tracked with reference counting, and when no chunks reference a shared component value anymore, it is automatically disposed. SystemState components are stored just like regular components. When an entity with system state components is "destroyed", the entity is moved to a chunk with just its shared state components but none of its regular ones (all non-system state components effectively get removed).
The usage of StateComponent is to guarentee entites are not moved to other chunk, and each of them has the same index as before during interation work, especially in ijobchunk case:)
Thx for great videos. It would be nice to have new series of videos - about multiplayer unity 3d (mmo) games if possible. How to : reduce lag as much as possible (which libraries to use, explaining tricks, patterns, how to do server/client predicts etc) , server structure, create server in C#,Rust(much easier - if possible) or C++, DOTS and networking etc
chunk component for culling - BUT... how would you ensure that entities which are close to each other would be grouped into a chunk? or is my understanding of culling based on bounding areas incorrect in its assumption that if i include in my bounding area two entities which are on the opposite sides of the world, the area now contains the whole world and will never get culled? ...oh. I could ensure that via a sharedcomponent storing something like an index into a quadtree... but at that moment, i don't really need the bounding area anymore, since the quadtree index itself might be enough as info whether to cull or not...?
So this is why you are constantly railing against OOP... You are a unity C# programmer that doesn't get to implement proper OOP because of unity's composition over inheritance principle. I had a feeling that was what was going on. A quick search of your channel confirms it. I would really suggest you take a look at Unreal Engine 5 (C++). You will quickly abandon these notions about OOP when you actually apply it in a game engine environment.
