i am very impressed by this from what i have seen so far. this looks like a really good step forward. and seeing 100k + different things doing their own things and still having a stable Fps is insane. i am proud of being a developer in Unity and this is just going to further my will to work with Unity
I think I might be in love with this man. I have been trying to achieve this type of system in C# for a bit and don't have the years experience and knowledge to get it done. This is like software architecture gold. Jesus. This is awesome.
Spool What is a dev. You mean programmer? Since when did programmers become downgraded to just dev? No you need to integrate all this directly into the il2cpp compiler no one outside of unity could have done this without source to engine.
Nutter oligist A dev in my use of the word is any person developing a game or piece of software. Regardless of what type of work they are doing to said game or software. I am not downgrading anyone or any profession. I am simply grouping a set of tasks into a single title. I also did not mean adding this functionality into Unity itself. I do not use Unity. I meant adding this functionally into any C# code base that can appropriately use it's benefits.
Nutter oligist The code shown in the slides is specific to the Unity code base and it's custom compiler. But the over all design and structure is not. Which if you actually read my original comment and don't make assumptions, is what I am talking about. "I have been trying to achieve this type of system in > C# < (not Unity) for a bit"
As a self-taught programmer I've always thought my dislike of oop was due to inexperience. The convoluted efforts I've seen people go to with inheritance always seemed far too unreadable, and error prone. I try to use scriptable objects for settings and a ton of specific classes I throw on as components. Inadvertently I think I'm partway using ecs so I'm all for this new approach. Makes a lot of sense.
Nothing against you, but I've heard this time and time again and the only sensible response to "I've seen all these convoluted designs with inheritance" is: You can do terrible things with every tool you choose. OOP is not inherently bad, it's just that many people tend to overcomplicate things, especially when trying to be way more general than they need to be. Same goes for the data-oriented design shown here, btw: Imagine the examples here weren't very specific and well designed for their purpose, but were some weird over-bearing system trying to basically cover everything. That would be an absolute mess. You _can_ screw up with this, too, and if you do, it will be just as bad.
@@Clairvoyant81Sure. For instance, I heard that Java doesn't has a "C++'s friend-keyword-like", because of a huge misconcept that it is unsafe. The result: getters and setters uncapsulating everything, and all related classes put together, in an inheritancing monstruosity, because there's no way they can "set" variables that they could, if they were "friend"s.
@@atilafernandes217 Same is true for C#, a language I mainly use at work... there's been several occasions where I would have really liked to do a friend class. Multiple inheritance is another feature missing from many OOP languages because it's "unsafe", while most of them allow for interfaces and implementation of multiple of those... which often leads to a bit of interface insanity.
@@Clairvoyant81 Whle the gist of what you're saying is true, the details are wrong. OOP is not a tool, but rather a technique, which is the very reason WHY data oriented programming is being advocated usually within the context of how OOP adds to the complexity in many cases. Notice however that this does not render the concepts/constructs we typically associate with OOP, such as classes/inheritance/etc. as trash, they just end up getting used a little differently.
Im on the 30 minute mark, after 2 days of stopping, starting, reversing, and referecncing. Just going into Hash maps. I dont know what hash maps are, but now I havea reason to find out. Finding these videos is like finding the architecht in the Matrix, only, the architecht is a good guy.
The Boid System walkthrough is great. It helps to see a non-trivial architecture where multiple jobs are combining to build temporary natives and update components.
Working in the industry for many years now as a Java/Spring engineer for a big company, I have to say when I started seeing talk about how horrible OOP is I rolled my eyes. But after working on a video game using OOP, I found out how awful the approach was after almost a year deep with a sizeable codebase... It let me finally come to terms with how flawed OOP is and open my ears to such a great talk. In big companies you can overcome these obstacles by throwing more $$ and CPU at it. But when you are developing for a single computer (i.e video game) the problems are obvious. Thanks for sharing the truth to people.
I moved from array of characters to hash table of them. The binary searched array of characters equals in performance to the hash table sequentially searched. I also coded a "bits version" of the hash table, using shortened arrays, with big variables, instead of long arrays of bytes. The whole app lost 40% of speed, with this new version.
I love the results I see with data oriented programming and ECS and stuff but I have yet to see a talk that has made me think "Oh, THIS is how you use it." Even after watching this video I still feel that data oriented programming is ethereal... :( I want to be able to set things up in my projects so that I can as much as possible make changes, get things to do things and touch as little code as possible while I do it. When your client asks you to "just" change this entire menu screen and make whole new buttons that react differently 2 days before launch (which has happened a surprising amount of times to me), I don't want to be messing around with code. If possible, I'd rather just have the designers or artists fix the issues. Can I still do this with data oriented programming?
SuilSolas A you're basically just grouping data in their corresponding boxes. shoes go in this box, shirts go in this one. in object oriented programming you basically have a box in a box with two boxes in it that each stores 3 more boxes. imagine how much simpler it is for the hardware to fetch that data if it knows you store all your shirts in a single box, not one shirt each in a 1000 different boxes.
@@Antowam3 I see differently: in OOP your character has a head that is inherited by the body, that is inherited by the shoes. In DOP, the character is quartered: the heads of all them go here, the legs there, the shoes beyond...
Well, if I was a meat packaging machine, and you were supplying me with bodies, I'd MUCH rather you give me the parts in separate boxes, rather than whole bodies. That way I don't have to chop them up to put them on the shelves. And I think your CPU would also appreciate not having to run around fetching data that you could have easily pre-packaged for it.
@@zygocact5947 I can see the performance benefits, however, some intuition is doomed to be lost in the process. Plus, hash table is technically harder to handle than a simple array of characters (in their whole bodies).
I think it's because we've been brainwashed by OOP. "Put all data here. It's part of a Foo. Foo data goes in Foo object and it should be private and we should build functions to talk to Foo." The ECS is not that complicated if you can get past the separation of data and logic. I see beginners asking, "How do I do this with an ECS, how do I do that? Should I build an event system?" That's not necessarily in the scope of the ECS to answer, and it's not so hard to transcribe data and operations on data if you got the fundamentals down from whatever we conceive of as "objects" without encapsulating and bundling them together in an object. The problem I think for most people is that they haven't learned to organize their software and codebase by data rather than functions, or worse, by data rather than objects. If you have experience with procedural or functional programming that is object-lite and data-function heavy, then the ECS will be straightforward, you can take liberties with it, and not feel the need to hesitate all the time. I tend to think if people struggle with the ideas of ECS and how to design software with it that it might help to go back to C, or Lisp, or Haskell. Languages like C++ and C# and Java and Python and so forth do not promote the proper type of mentality to design and utilize an ECS to its fullest potential.
Let me see if I got it. If someone has a base class with the x,y location of a 2D character, a derived class with other data, and other class with an array of all characters, are you saying that it should has instead an array with all x positions, another array with all y coordinates, and so on? So, the array of all characters would be a "hash table", mounting the entire current/required character, builted from all its data, gathered together from all arrays, in a temporarily structure?
If you use random access patterns though, xyxyxyxy in interleaved AoS format will generally perform better, since you'll halve the cache misses that way. The one thing that *always* helps is to avoid loading irrelevant data into cache lines in your critical loops. If it's like xy[junk]xy[junk], then that's wasting a big chunk of your fastest memory.
@@atilafernandes217 The baseline usually is sequential access though (looping through arrays). There you can get the best performance with SoA layouts. They also do reduce cache misses if you're able to do hot/cold field/branch splitting as a result. At the end of the day, our engine stores a bunch of stuff (ideally in arrays). We might then build linked structures on top such as trees or hash tables or whatnot for spatial indexing, but even to build those data structures efficiently, we have to linearly (sequentially) traverse whatever is in our game scene/world/map. So usually for the most performance-critical types of games (ex: open-world 3D games), we have to get that sequential linear-time memory access as fast as possible before we even proceed further. For that, the ECS is about the easiest thing to maintain possible (it's not necessarily easy to maintain, but the easiest -- if you need very fast sequential access as it offers a very generalized way to associate data in parallel to an entity without interleaving the data with the entity's own data -- as object-oriented programming tends to want to do).
He should just show the complete code with execution times. Jumping from place to place with very little code, with a lot of hash maps and array hacks, new collection types, classes and function calls makes this very hard to follow. Good stuff otherwise, it's creepy how I have independently reached a lot of the same conclusions about architectural design. Essentially it seems like that class structures are built of arrays and hash maps and individual transformation operations wrapped as Jobs are run to increase performance. Would also be nice to know how you handle cross cutting concerns such as analytics and logging. Is it easy to write compiling code with run time errors because you lack some attribute or function call? The way components dependecies were set didn't seem too good on first glance.
You put more systems into the ECS to deal with specific cross-cutting concerns, and remove them as needed. Since entities are just "data" and dependencies are tracked, you can tack logging systems before or after other specific systems run, or in response to some state changes / transient events (I believe they're going to add reactive systems as in Entitas and a few other ECS frameworks, but you can do this now with event entity patterns, it's just less convenient).
To be honest, i always dismissed unity as a "One-size-must-fit-all" tool, that will due to this to large set of problems would fail to be tailored to the very different specific demands of different games. A RTS has a different physics frame-rate then a jump-and run and way more simulation work to shovel. So the engine has to be optimized for one of these, and the other one will suffer - as in needs to re-tweak and rewrite the engine for his program. Then i found this video. Would love to hear , how they abstract, what essentially are different engines into one huge bundle.
RTS with large armies is only skewed because rendering isn't necessarily the only bottleneck. Things like AI and pathfinding start to rival hotspots spend in rendering there. But optimal data locality still demands splitting cold fields away from hot fields regardless of the type of game, and that's where a heavily-optimized ECS shines in all cases. The one-size-fits-all tool that really doesn't fit all sizes is object-oriented programming, at least of a sort that wants to encapsulate and interleave all data together with an entity. That offers poor relative performance regardless of the type of game. Our hardware and its characteristics are constant. The first thing an ECS does to improve performance regardless of use case/game type is to break encapsulation in favor of a separation of data and logic, and to allow organizing data for optimal access patterns rather than just interleaving all, say, particle fields and bundle them inside a `Particle` object in the most inefficient way possible as OOP tends to want to do.
@@darkengine5931 This is a missunderstanding, i was refering to Unity, not to Data Orientated Design. The problem is that you need Object Orientation to find your way in the code, to read and understand. It is a purely human mental crutch. Still it should be what i see in a IDE. But then there should be a different perspective. One were i reassign members to entirely different data-structures optimized for hot-loops in the algos that chew on it. One can not exist without the other, for in a purely data-orientated world, project discover ability would sink to near zero. And that is a value in and of itself.
@@Canonfudder Cheers! My bad for confusing a Unity-specific thing with a more general concept. On OOP though, The problem I've found at least in my industry (computer graphics) and experience (into my third decade now) is that the layers of abstractions imposed by objects over data often makes things more difficult for me to find my way around other people's code than easing it. For example, I've been working with images/rasters since the beginning all the way back to Amiga and DOS days. I know them from a data standpoint. They're all 2-dimensional arrays of some fixed-point or floating-point number or an integer index into a color palette which is fixed/floating-point. Gimme the raw 2D image data and I can do cool stuff: draw very nice-looking antialiased lines, curves, rotate and scale large sprites, super-fast convolution filters, path trace a 3D input, you name it... on hardware both ancient and super new -- with the new stuff I can use SIMD and multithreading. On the ancient hardware, I got endless outside-the-box old school tricks up my sleeve to rival the new stuff. But impose a lot of objects and interfaces over the data like image factories and pixel format converters and paint brushes and antialiasing policies and curve drawing functions and whatnot and now you've not only skyrocketed my learning curve to do my magic, but my best efforts will probably perform at a fraction of the frame rates if you just gave me direct pixel access. I can't make jaws drop and show off my skills if I'm given all these obstacles over the data. And I've found that more and more true the longer I've programmed with OOP and even in areas much more high-level than image processing. The illusion that layers upon layers of interfaces and abstractions make code easier to navigate starts to fade as I gain more and more domain expertise and realize the hardest thing to learn as we wade through dozens of libraries to do the same thing is all the human-imposed ideas and constructs people put on top of the data. The older I get, the more and more I find this to be the case. I just want the data -- the common denominator behind a gazillion reinvented wheels of how to work with it -- not all the nonsense hurdles on top of it. I want to leverage my expertise, and my expertise doesn't include the gazillion possible ways of hiding and abstracting data that the world wants to impose over it or the endless programming languages people want to invent to basically handle the same underlying data. What I've gained expertise in is manipulating data, not working with Joe/Jane's super high-level object-oriented framework (those tend to come and go like fashion trends). I can't gain expertise in a consistent way working with a Tower of Babel. I need to learn one uniform language to write poetry with it, and that's always been the data. The data behind the endless image libraries out there is consistent even if the ways people invent of hiding the data and imposing interfaces over it are hardly consistent. When safety and maintaining invariants is a strong concern, I have found a functional programming style favoring immutables and pure functions much more productive than OOP. It doesn't attempt to hide the data, only impose invariants by preventing mutations to it. We just input something and output something new, and in the process of outputting, we can check and maintain invariants.
@@Canonfudder Might depend on the domain a lot. Well, some of the easiest code I've found to work with and debug of my colleagues (not my own since I could have a personal bias) was not heavily object-oriented. It got straight to the data and domain. It's like I had two separate colleagues before who both worked on rayracers. One was more data-oriented so he used a BVH and his code was tight, minimalist, and maybe it wasn't the easiest to read for beginners. But I immediately recognized the BVH there, why he used SIMD for the triangle intersections, etc. I immediately resonated with the code because it's the sort of code anyone with expertise here would write since the data, provided we don't try to hide it or decorate too much, puts us on the same page. Then I had another who was very object-oriented, and he used a KD-tree and also wrote like 10 times more code to do the same thing with lots of abstract interfaces, virtual dispatch, and class/function templates (C++), and it was terribly inefficient computationally but that's not even my point. It also took so much longer to learn since he imposed so many personal ideas over the raytracer in ways that no one who has been working in the industry for a long time except him could understand. At least in domains as complex as computer graphics, I think people's personal ideas of how to work with data if they're going to hide it and force us to work with their layered interfaces is actually far, far more complex than the data itself... and also far more unstable (I find such people changing their minds all the time about the interfaces they want to put on top of the data, but not the data.... the data is more constant/stable). Might also depend on how long we've been programming in a particular domain. It's like a car person who has been tinkering with engines and tuning them all their life might find a modern car with computers and automatic transmissions and stuff far more complicated to do what they want, while a beginner might think the opposite. The beginner might just want like, "This is how you make the car go forward. You put your foot here on this thing we call an 'accelerator'. Then if you want to make it slow down, you put your foot on this other thing. Then there is a wheel here and you can 'turn' it, and it is the same for other cars." And I think OOP is good for beginners like that. But it starts to get in the way for the advanced types because that style of hand-holding makes people only experts at learning the specific API, or car, or whatever it is -- when experience forces us to work with a bunch of them. And what we start to gain expertise over at that point is not a specific API, or language, or car model, but what they all have in common... and that's usually data and their formats in programming.
Most ECS architectures are still procedural and focused on mutating data in-place including Unity and DOTS, but they're extremely explicit about what systems mutate and access what data. So that makes it about as easy as possible to reason about thread safety outside of a functional context to the point where, with a minimalist language, the compiler can even do the multithreading for you, given that explicitness.
I should probably say this before people get ahead of themselves. ECS has a complication that makes it terrible for complexity. ECS is better suited for when you have a lot of simple behaving objects. But not objects of complex behaviors. It is entirely possible to make it so that you can have an ECS with Scripting. But the setup is more complex than normal object oriented design with minimal performance gain.
I don't know how I feel about this one. Don't get me wrong, Mike Acton is one of the smartest guy I've seen (and it really shows in these kinds of conference). However, I feel like he lost the passion(see cpp con 2014) and his talent might be lost at Unity. I'm sure Unity benefits a lot from him there, but I always envisioned he would be taking part in other (more interesting) projects, and stop trying to rescue Unity which is, in my opinion, not a great piece of software (that's a whole other topic). I don't know, It just felt like he was trying to apply something he believes in(Data Oriented Design), on a project he doesn't.
Hey BlueRain, I get where you're coming from, but isn't the comment section supposed to be a place to discuss? How did you feel about this talk compared to previous ones? Did you feel the same passion? What's your opinion? etc. Of course, you're going to infer some things and try to think for yourself if you want to bring anything worth while to the conversation. Again, not picking on the guy. Just trying to compare previous talks and the work he's now doing at Unity.
You're absolutely right, Francis, Mike is truly knowledgeable // yet given the task of turning a subpar piece of garbage like C# into a high performance gaming platform is a bit much to ask, so basically he tries to reengineer the stupid platform to generate real(native) code so any lamer can produce a reasonably playable game. SO a quick tip for all would-be game devs here: Don't use C#, it's crap, use the real thing, C/C++ with arrays, pointers and plain old datatypes.
Unity is already conquered the world. It's not ideal, but it's better for most of us snd it keeps improving. It already shows similar to native code performance, with simple code and clean architecture.
![ROSÉ(로제) - APT. (Band VER.) (With. 이영지) [더 시즌즈-이영지의 레인보우] | KBS 241129 방송](http://i.ytimg.com/vi/IW8qaemx74g/mqdefault.jpg)
I was fast forwarding to the Mike Acton part until I noticed he *is* Mike Acton.
Orange *is* my favorite color. But I also love leather jackets. So, I'm torn.
6 years already, and it has 75k views ONLY?. Most of the data is already out of date, but the general info is still relevant. This guy made this.
What's the new data?
i am very impressed by this from what i have seen so far. this looks like a really good step forward. and seeing 100k + different things doing their own things and still having a stable Fps is insane. i am proud of being a developer in Unity and this is just going to further my will to work with Unity
I think I might be in love with this man. I have been trying to achieve this type of system in C# for a bit and don't have the years experience and knowledge to get it done. This is like software architecture gold. Jesus. This is awesome.
You also dont have the engineering team and unity's blessing to do it.
True, but a smaller scale system with this general architecture is something a single dev can accomplish.
Spool What is a dev. You mean programmer? Since when did programmers become downgraded to just dev? No you need to integrate all this directly into the il2cpp compiler no one outside of unity could have done this without source to engine.
Nutter oligist A dev in my use of the word is any person developing a game or piece of software. Regardless of what type of work they are doing to said game or software. I am not downgrading anyone or any profession. I am simply grouping a set of tasks into a single title. I also did not mean adding this functionality into Unity itself. I do not use Unity. I meant adding this functionally into any C# code base that can appropriately use it's benefits.
Nutter oligist The code shown in the slides is specific to the Unity code base and it's custom compiler. But the over all design and structure is not. Which if you actually read my original comment and don't make assumptions, is what I am talking about. "I have been trying to achieve this type of system in > C# < (not Unity) for a bit"
IJobNativeMultiHasMapMergedSharedKeyIndices has the same number of syllables as supercalifragilisticexpealidocious.
As a self-taught programmer I've always thought my dislike of oop was due to inexperience. The convoluted efforts I've seen people go to with inheritance always seemed far too unreadable, and error prone. I try to use scriptable objects for settings and a ton of specific classes I throw on as components. Inadvertently I think I'm partway using ecs so I'm all for this new approach. Makes a lot of sense.
Same here :)
Nothing against you, but I've heard this time and time again and the only sensible response to "I've seen all these convoluted designs with inheritance" is: You can do terrible things with every tool you choose. OOP is not inherently bad, it's just that many people tend to overcomplicate things, especially when trying to be way more general than they need to be.
Same goes for the data-oriented design shown here, btw: Imagine the examples here weren't very specific and well designed for their purpose, but were some weird over-bearing system trying to basically cover everything. That would be an absolute mess. You _can_ screw up with this, too, and if you do, it will be just as bad.
@@Clairvoyant81Sure. For instance, I heard that Java doesn't has a "C++'s friend-keyword-like", because of a huge misconcept that it is unsafe. The result: getters and setters uncapsulating everything, and all related classes put together, in an inheritancing monstruosity, because there's no way they can "set" variables that they could, if they were "friend"s.
@@atilafernandes217 Same is true for C#, a language I mainly use at work... there's been several occasions where I would have really liked to do a friend class.
Multiple inheritance is another feature missing from many OOP languages because it's "unsafe", while most of them allow for interfaces and implementation of multiple of those... which often leads to a bit of interface insanity.
@@Clairvoyant81 Whle the gist of what you're saying is true, the details are wrong. OOP is not a tool, but rather a technique, which is the very reason WHY data oriented programming is being advocated usually within the context of how OOP adds to the complexity in many cases. Notice however that this does not render the concepts/constructs we typically associate with OOP, such as classes/inheritance/etc. as trash, they just end up getting used a little differently.
Im on the 30 minute mark, after 2 days of stopping, starting, reversing, and referecncing. Just going into Hash maps. I dont know what hash maps are, but now I havea reason to find out. Finding these videos is like finding the architecht in the Matrix, only, the architecht is a good guy.
The Boid System walkthrough is great.
It helps to see a non-trivial architecture where multiple jobs are combining to build temporary natives and update components.
Thanks for the talk, Mike Acton. Great!
Working in the industry for many years now as a Java/Spring engineer for a big company, I have to say when I started seeing talk about how horrible OOP is I rolled my eyes.
But after working on a video game using OOP, I found out how awful the approach was after almost a year deep with a sizeable codebase...
It let me finally come to terms with how flawed OOP is and open my ears to such a great talk.
In big companies you can overcome these obstacles by throwing more $$ and CPU at it. But when you are developing for a single computer (i.e video game) the problems are obvious.
Thanks for sharing the truth to people.
Mike Acton looks cooler here than it that CPP video :P
People don't exist for the benefit of you being able to categorize them as either looking cool or not looking cool.
Hear hear. As a programmer I am so sick of being treated as a sex object.
+Marnielle Lloyd Estrada
He lost weight. And he has less breathing difficulty.
Maybe he had to get really drunk to work up the courage to go in there and thrash them like that.
Dude, how can you even survive when being so dense? LMAO
Great presentation on Component Systems - Thanks Mike
Could you please put up the links for all of these projects in the description?
Unlike EVERY OTHER DOD PRESENTATION from Unity... I like this guy..
This guy is so damn cool. I mean, seriously.
I moved from array of characters to hash table of them. The binary searched array of characters equals in performance to the hash table sequentially searched.
I also coded a "bits version" of the hash table, using shortened arrays, with big variables, instead of long arrays of bytes. The whole app lost 40% of speed, with this new version.
wait wait Mike Acton works at unity?
he does now
Yeah but he probably had to move his 401k and all that shit.
Aaaand he's gone. :shrug:
@@darksidegirl Why did he leave?
This is great , i have to adopt it .
it will be interesting to see how the asset store publishers will update thier assets
Is there a link to the example code?
I love the results I see with data oriented programming and ECS and stuff but I have yet to see a talk that has made me think "Oh, THIS is how you use it." Even after watching this video I still feel that data oriented programming is ethereal... :(
I want to be able to set things up in my projects so that I can as much as possible make changes, get things to do things and touch as little code as possible while I do it. When your client asks you to "just" change this entire menu screen and make whole new buttons that react differently 2 days before launch (which has happened a surprising amount of times to me), I don't want to be messing around with code. If possible, I'd rather just have the designers or artists fix the issues. Can I still do this with data oriented programming?
SuilSolas A you're basically just grouping data in their corresponding boxes. shoes go in this box, shirts go in this one. in object oriented programming you basically have a box in a box with two boxes in it that each stores 3 more boxes. imagine how much simpler it is for the hardware to fetch that data if it knows you store all your shirts in a single box, not one shirt each in a 1000 different boxes.
@@Antowam3 I see differently: in OOP your character has a head that is inherited by the body, that is inherited by the shoes. In DOP, the character is quartered: the heads of all them go here, the legs there, the shoes beyond...
Well, if I was a meat packaging machine, and you were supplying me with bodies, I'd MUCH rather you give me the parts in separate boxes, rather than whole bodies. That way I don't have to chop them up to put them on the shelves. And I think your CPU would also appreciate not having to run around fetching data that you could have easily pre-packaged for it.
@@zygocact5947 I can see the performance benefits, however, some intuition is doomed to be lost in the process. Plus, hash table is technically harder to handle than a simple array of characters (in their whole bodies).
I think it's because we've been brainwashed by OOP. "Put all data here. It's part of a Foo. Foo data goes in Foo object and it should be private and we should build functions to talk to Foo." The ECS is not that complicated if you can get past the separation of data and logic. I see beginners asking, "How do I do this with an ECS, how do I do that? Should I build an event system?" That's not necessarily in the scope of the ECS to answer, and it's not so hard to transcribe data and operations on data if you got the fundamentals down from whatever we conceive of as "objects" without encapsulating and bundling them together in an object. The problem I think for most people is that they haven't learned to organize their software and codebase by data rather than functions, or worse, by data rather than objects. If you have experience with procedural or functional programming that is object-lite and data-function heavy, then the ECS will be straightforward, you can take liberties with it, and not feel the need to hesitate all the time. I tend to think if people struggle with the ideas of ECS and how to design software with it that it might help to go back to C, or Lisp, or Haskell. Languages like C++ and C# and Java and Python and so forth do not promote the proper type of mentality to design and utilize an ECS to its fullest potential.
Let me see if I got it. If someone has a base class with the x,y location of a 2D character, a derived class with other data, and other class with an array of all characters, are you saying that it should has instead an array with all x positions, another array with all y coordinates, and so on? So, the array of all characters would be a "hash table", mounting the entire current/required character, builted from all its data, gathered together from all arrays, in a temporarily structure?
If you use random access patterns though, xyxyxyxy in interleaved AoS format will generally perform better, since you'll halve the cache misses that way. The one thing that *always* helps is to avoid loading irrelevant data into cache lines in your critical loops. If it's like xy[junk]xy[junk], then that's wasting a big chunk of your fastest memory.
@@darkengine5931 I didn't get why it will has to has cache misses. Doesn't it is implementation-dependant?
@@atilafernandes217 The baseline usually is sequential access though (looping through arrays). There you can get the best performance with SoA layouts. They also do reduce cache misses if you're able to do hot/cold field/branch splitting as a result. At the end of the day, our engine stores a bunch of stuff (ideally in arrays). We might then build linked structures on top such as trees or hash tables or whatnot for spatial indexing, but even to build those data structures efficiently, we have to linearly (sequentially) traverse whatever is in our game scene/world/map. So usually for the most performance-critical types of games (ex: open-world 3D games), we have to get that sequential linear-time memory access as fast as possible before we even proceed further. For that, the ECS is about the easiest thing to maintain possible (it's not necessarily easy to maintain, but the easiest -- if you need very fast sequential access as it offers a very generalized way to associate data in parallel to an entity without interleaving the data with the entity's own data -- as object-oriented programming tends to want to do).
Great!!! Mike! thanks
I was hoping somebody would post this
anybody knows where can i get the project?
i was going through the ecs example on github by unity and a lot of the code shown here is not in the code in github
He should just show the complete code with execution times. Jumping from place to place with very little code, with a lot of hash maps and array hacks, new collection types, classes and function calls makes this very hard to follow. Good stuff otherwise, it's creepy how I have independently reached a lot of the same conclusions about architectural design. Essentially it seems like that class structures are built of arrays and hash maps and individual transformation operations wrapped as Jobs are run to increase performance.
Would also be nice to know how you handle cross cutting concerns such as analytics and logging. Is it easy to write compiling code with run time errors because you lack some attribute or function call? The way components dependecies were set didn't seem too good on first glance.
You put more systems into the ECS to deal with specific cross-cutting concerns, and remove them as needed. Since entities are just "data" and dependencies are tracked, you can tack logging systems before or after other specific systems run, or in response to some state changes / transient events (I believe they're going to add reactive systems as in Entitas and a few other ECS frameworks, but you can do this now with event entity patterns, it's just less convenient).
Thanks for the clarification!
Nice deep dive.
To be honest, i always dismissed unity as a "One-size-must-fit-all" tool, that will due to this to large set of problems would fail to be tailored to the very different specific demands of different games. A RTS has a different physics frame-rate then a jump-and run and way more simulation work to shovel. So the engine has to be optimized for one of these, and the other one will suffer - as in needs to re-tweak and rewrite the engine for his program. Then i found this video. Would love to hear , how they abstract, what essentially are different engines into one huge bundle.
Picasso CT... I didn't recognize you because you are talking normal instead of crazy.
RTS with large armies is only skewed because rendering isn't necessarily the only bottleneck. Things like AI and pathfinding start to rival hotspots spend in rendering there. But optimal data locality still demands splitting cold fields away from hot fields regardless of the type of game, and that's where a heavily-optimized ECS shines in all cases.
The one-size-fits-all tool that really doesn't fit all sizes is object-oriented programming, at least of a sort that wants to encapsulate and interleave all data together with an entity. That offers poor relative performance regardless of the type of game. Our hardware and its characteristics are constant. The first thing an ECS does to improve performance regardless of use case/game type is to break encapsulation in favor of a separation of data and logic, and to allow organizing data for optimal access patterns rather than just interleaving all, say, particle fields and bundle them inside a `Particle` object in the most inefficient way possible as OOP tends to want to do.
@@darkengine5931 This is a missunderstanding, i was refering to Unity, not to Data Orientated Design. The problem is that you need Object Orientation to find your way in the code, to read and understand. It is a purely human mental crutch. Still it should be what i see in a IDE.
But then there should be a different perspective. One were i reassign members to entirely different data-structures optimized for hot-loops in the algos that chew on it.
One can not exist without the other, for in a purely data-orientated world, project discover ability would sink to near zero. And that is a value in and of itself.
@@Canonfudder Cheers! My bad for confusing a Unity-specific thing with a more general concept. On OOP though, The problem I've found at least in my industry (computer graphics) and experience (into my third decade now) is that the layers of abstractions imposed by objects over data often makes things more difficult for me to find my way around other people's code than easing it.
For example, I've been working with images/rasters since the beginning all the way back to Amiga and DOS days. I know them from a data standpoint. They're all 2-dimensional arrays of some fixed-point or floating-point number or an integer index into a color palette which is fixed/floating-point. Gimme the raw 2D image data and I can do cool stuff: draw very nice-looking antialiased lines, curves, rotate and scale large sprites, super-fast convolution filters, path trace a 3D input, you name it... on hardware both ancient and super new -- with the new stuff I can use SIMD and multithreading. On the ancient hardware, I got endless outside-the-box old school tricks up my sleeve to rival the new stuff.
But impose a lot of objects and interfaces over the data like image factories and pixel format converters and paint brushes and antialiasing policies and curve drawing functions and whatnot and now you've not only skyrocketed my learning curve to do my magic, but my best efforts will probably perform at a fraction of the frame rates if you just gave me direct pixel access. I can't make jaws drop and show off my skills if I'm given all these obstacles over the data. And I've found that more and more true the longer I've programmed with OOP and even in areas much more high-level than image processing. The illusion that layers upon layers of interfaces and abstractions make code easier to navigate starts to fade as I gain more and more domain expertise and realize the hardest thing to learn as we wade through dozens of libraries to do the same thing is all the human-imposed ideas and constructs people put on top of the data. The older I get, the more and more I find this to be the case. I just want the data -- the common denominator behind a gazillion reinvented wheels of how to work with it -- not all the nonsense hurdles on top of it. I want to leverage my expertise, and my expertise doesn't include the gazillion possible ways of hiding and abstracting data that the world wants to impose over it or the endless programming languages people want to invent to basically handle the same underlying data.
What I've gained expertise in is manipulating data, not working with Joe/Jane's super high-level object-oriented framework (those tend to come and go like fashion trends). I can't gain expertise in a consistent way working with a Tower of Babel. I need to learn one uniform language to write poetry with it, and that's always been the data. The data behind the endless image libraries out there is consistent even if the ways people invent of hiding the data and imposing interfaces over it are hardly consistent.
When safety and maintaining invariants is a strong concern, I have found a functional programming style favoring immutables and pure functions much more productive than OOP. It doesn't attempt to hide the data, only impose invariants by preventing mutations to it. We just input something and output something new, and in the process of outputting, we can check and maintain invariants.
@@Canonfudder Might depend on the domain a lot. Well, some of the easiest code I've found to work with and debug of my colleagues (not my own since I could have a personal bias) was not heavily object-oriented. It got straight to the data and domain. It's like I had two separate colleagues before who both worked on rayracers. One was more data-oriented so he used a BVH and his code was tight, minimalist, and maybe it wasn't the easiest to read for beginners. But I immediately recognized the BVH there, why he used SIMD for the triangle intersections, etc. I immediately resonated with the code because it's the sort of code anyone with expertise here would write since the data, provided we don't try to hide it or decorate too much, puts us on the same page. Then I had another who was very object-oriented, and he used a KD-tree and also wrote like 10 times more code to do the same thing with lots of abstract interfaces, virtual dispatch, and class/function templates (C++), and it was terribly inefficient computationally but that's not even my point. It also took so much longer to learn since he imposed so many personal ideas over the raytracer in ways that no one who has been working in the industry for a long time except him could understand. At least in domains as complex as computer graphics, I think people's personal ideas of how to work with data if they're going to hide it and force us to work with their layered interfaces is actually far, far more complex than the data itself... and also far more unstable (I find such people changing their minds all the time about the interfaces they want to put on top of the data, but not the data.... the data is more constant/stable).
Might also depend on how long we've been programming in a particular domain. It's like a car person who has been tinkering with engines and tuning them all their life might find a modern car with computers and automatic transmissions and stuff far more complicated to do what they want, while a beginner might think the opposite. The beginner might just want like, "This is how you make the car go forward. You put your foot here on this thing we call an 'accelerator'. Then if you want to make it slow down, you put your foot on this other thing. Then there is a wheel here and you can 'turn' it, and it is the same for other cars." And I think OOP is good for beginners like that. But it starts to get in the way for the advanced types because that style of hand-holding makes people only experts at learning the specific API, or car, or whatever it is -- when experience forces us to work with a bunch of them. And what we start to gain expertise over at that point is not a specific API, or language, or car model, but what they all have in common... and that's usually data and their formats in programming.
unity needs to do a better job explaining the ecs system because its not becoming clear by videos like this
Because this isn't a tutorial? This is an in-depth analysis of ECS, why it exists, and how it performs?
The query here looks a bit like in functional programming, at least inspired. Is there any thing related to that?
Most ECS architectures are still procedural and focused on mutating data in-place including Unity and DOTS, but they're extremely explicit about what systems mutate and access what data. So that makes it about as easy as possible to reason about thread safety outside of a functional context to the point where, with a minimalist language, the compiler can even do the multithreading for you, given that explicitness.
That's nice. When do I get to blow stuff up?
Unfortunately this goes well above my head. :P
it's a deep dive into the system, no worries keep this talk in mind and go back to it after
Democratizing, with RULES! God, I love buzzwords.
I should probably say this before people get ahead of themselves. ECS has a complication that makes it terrible for complexity. ECS is better suited for when you have a lot of simple behaving objects. But not objects of complex behaviors.
It is entirely possible to make it so that you can have an ECS with Scripting. But the setup is more complex than normal object oriented design with minimal performance gain.
Systematic Anomaly...
I don't know how I feel about this one. Don't get me wrong, Mike Acton is one of the smartest guy I've seen (and it really shows in these kinds of conference). However, I feel like he lost the passion(see cpp con 2014) and his talent might be lost at Unity. I'm sure Unity benefits a lot from him there, but I always envisioned he would be taking part in other (more interesting) projects, and stop trying to rescue Unity which is, in my opinion, not a great piece of software (that's a whole other topic). I don't know, It just felt like he was trying to apply something he believes in(Data Oriented Design), on a project he doesn't.
Francis can we stop with assumptions ?
Who knows what he's thinking ?
You saw him talking for 2 hours and now you know everything about his life ?
Hey BlueRain, I get where you're coming from, but isn't the comment section supposed to be a place to discuss? How did you feel about this talk compared to previous ones? Did you feel the same passion? What's your opinion? etc. Of course, you're going to infer some things and try to think for yourself if you want to bring anything worth while to the conversation.
Again, not picking on the guy. Just trying to compare previous talks and the work he's now doing at Unity.
You're absolutely right, Francis, Mike is truly knowledgeable // yet given the task of turning a subpar piece of garbage like C# into a high performance gaming platform is a bit much to ask, so basically he tries to reengineer the stupid platform to generate real(native) code so any lamer can produce a reasonably playable game. SO a quick tip for all would-be game devs here: Don't use C#, it's crap, use the real thing, C/C++ with arrays, pointers and plain old datatypes.
Unity is already conquered the world. It's not ideal, but it's better for most of us snd it keeps improving.
It already shows similar to native code performance, with simple code and clean architecture.