Aras Pranckevicius (@aras_p) on twitter shared his talk on Entity Component Systems and Data Oriented Design for junior/future engineers at Unity. The talk is not Unity specific and is applicable to more general cases.

You can find the slides at http://aras-p.info/texts/files/2018Academy - ECS-DoD.pdf.

Sample code is available on Github: https://github.com/aras-p/dod-playground.

View full story

Thanks for sharing. I actually got hit into the exact problem of "what does what" issue (which I think is common in this case) typically the game object-component design and when everything is a game object like the current Unity. When object A and object B correlate, it gets confusing sometimes on where to put the logic. Is it A? Is it B? There's no defining answer cause I can only assume it's fine (because they are, as they are equally dependent on each other) until it's probably not. All I could do to make it clearer was to create a game object that is conceptually not a game object, that correlates them both and run things on that game object's update. It's not A and B, but a system that correlates both. Of course this didn't solve much in performance, just readability and separation concerns. I'm glad it's also is addressed in the slide.

8 hours ago, mychii said:

Thanks for sharing. I actually got hit into the exact problem of "what does what" issue (which I think is common in this case) typically the game object-component design and when everything is a game object like the current Unity. When object A and object B correlate, it gets confusing sometimes on where to put the logic. Is it A? Is it B? There's no defining answer cause I can only assume it's fine (because they are, as they are equally dependent on each other) until it's probably not. All I could do to make it clearer was to create a game object that is conceptually not a game object, that correlates them both and run things on that game object's update. It's not A and B, but a system that correlates both. Of course this didn't solve much in performance, just readability and separation concerns. I'm glad it's also is addressed in the slide.

It was one of my greatest frustrations when I moved from the wider Tech Startup world and Corporate Systems into Game Development with Unity that it was actually a step backwards in terms of the Framework helping with good Object Oriented Designed compared to things like J2EE frameworks in Java or even the Google Android API. ?

It is possible to push some good OO practices onto it mostly by means of delegation, but not easy as the core structure on top of which your code sits is one massive Flat Injection Of Concerns Engine were exposed data is either a public variable (thus breaking containment) or ends up serialized and deserialized when it's not supposed to.

I can only imagine how bad it must be for a Junior Developer still learning OO who is doing it in this anti-OO structure.

So it's pretty interesting that they've finally introduced something closer to the Model-View-Controller Design model and separated Data from Visualization.

Now if they created the proper slots (rather than we having to hack it) were we can hang the data in the natural hierarchy of game-wide-data, player-data, and game-level-data, in addition to the current visual-object-data, that would be great.

Soz if I sound a bit frustrated!

I have a similar frustration that terrible code that abuses OOP language features to make a flawed framework that actually violates countless OOD rules, is referred to in the talk as "traditional OOP". 

That's an extremely terrible thing to teach beginners. Terrible code is not "traditional" or normal. 

Also, every single ECS blog/presentation does this same thing - comparing their solution with a terrible design that breaks OO rules. I'm sure it's possible to show that a mixture of Relational data modelling, procedural programming and a pinch of DOD introspection is a good idea, without having to compare it against embarrassingly wrong OO code... And in the process, telling beginners not to bother learning any of the rules that the terrible straw man example code is violating. Bleh. 

And I'd gladly hear about the "right way" to do this, because if ECS is bad, bad OO is bad, then what's good? Links, blog posts, articles, code samples please. I'm a bit tired of hearing one side advertising some ultimate solution to everything and more (which looks kinda ugly and is probably just as unmaintainable as anything else as soon as it grew to something bigger than some bazzilion of sprintes rotating at once on the screen), and another side bashing this, and mentioning some proper OO code which I obviously had never an honour to see.

1 hour ago, noizex said:

And I'd gladly hear about the "right way" to do this, because if ECS is bad, bad OO is bad, then what's good?

Whatever is good for your particular project. There are no silver bullets. Software development is not a math exam where every question has a correct answer. There is no "this is the one and only right way to do the thing" in software development. There is no template you can follow that will guarantee success. There are a lot of what I would consider "usually wrong" answers, but what is "right" is entirely situational. There are times when even singletons are the least-worst idea one can use. There are even advocates for the use of the 'goto' keyword.

Take ideas from OO and relational modelling and functional programming as they are useful and code to principles rather than patterns. Think about what you're doing. Don't blindly apply other people's solutions to your problems.

4 hours ago, Hodgman said:

I have a similar frustration that terrible code that abuses OOP language features to make a flawed framework that actually violates countless OOD rules, is referred to in the talk as "traditional OOP". 

It's probably thought of as traditional because that's what a huge amount of learning material for OO teaches. OOP = "inheritance, polymorphism, encapsulation" is etched on the minds of many a student and judging by the code I've seen in the wild, many a practicing game developer, too.

I wouldn't quite call it a "strawman" when that kind of horrible code is exactly how a lot of people write "OO" code.

1 hour ago, noizex said:

And I'd gladly hear about the "right way" to do this, because if ECS is bad, bad OO is bad, then what's good? Links, blog posts, articles, code samples please. I'm a bit tired of hearing one side advertising some ultimate solution to everything and more (which looks kinda ugly and is probably just as unmaintainable as anything else as soon as it grew to something bigger than some bazzilion of sprintes rotating at once on the screen), and another side bashing this, and mentioning some proper OO code which I obviously had never an honour to see.

I understand that you're annoyed by this "ad", they're just probably happy that this could solve their engine's problem and try to go radical. They wanna push their Unity code to a smart watch, so they gotta do what got to do. As long as you know that there's no extreme end when it comes to architecture, this is nothing but a resourceful information. Mix and match anything you like.

It's even more fierce in web development if you know it. MVC? AMVC? MVW? MMVW? VW Beetle? List goes on... there's even an "evangelist" job, whose job is to convert people to one of their frameworks, constantly pushing their approach, to ensure they win the developers hearts to become the gold standard of the web (sounds like Unity right now in gamedev, eh?). One best example is Ruby on Rails. It was so popular that some may not even know it's written in Ruby. All they know is it's, well, Ruby on Rails. The other is jQuery. It solved cross-browser problem, until better JavaScript is introduced. So it works in the past, but not anymore today. Heck, even Facebook starts off with PHP with traditional page-based approach, until they can push browser standard to have JavaScript to be turned on by default in browser and the approach changes to become a hybrid real-time AJAX floor cleaner. When they got too big, they solve their scalability issue by making their own PHP to C++ transpiler. Whatever works for them, just like what Unity is doing now for their own, which they happen to share.

The ECS approach they proposed is still experimental anyway (in Unity), and if you want me to be skeptical, in my opinion it will still definitely be a mixed approach in the end. Just like Oberon_Command said, there are no silver bullets when it comes to software design and architecture.

2 hours ago, mychii said:

It's even more fierce in web development if you know it. MVC? AMVC? MVW? MMVW? VW Beetle? List goes on... there's even an "evangelist" job, whose job is to convert people to one of their frameworks, constantly pushing their approach, to ensure they win the developers hearts to become the gold standard of the web (sounds like Unity right now in gamedev, eh?). One best example is Ruby on Rails. It was so popular that some may not even know it's written in Ruby. All they know is it's, well, Ruby on Rails. The other is jQuery. It solved cross-browser problem, until better JavaScript is introduced. So it works in the past, but not anymore today. Heck, even Facebook starts off with PHP with traditional page-based approach, until they can push browser standard to have JavaScript to be turned on by default in browser and the approach changes to become a hybrid real-time AJAX floor cleaner. When they got too big, they solve their scalability issue by making their own PHP to C++ transpiler. Whatever works for them, just like what Unity is doing now for their own, which they happen to share.

The ECS approach they proposed is still experimental anyway (in Unity), and if you want me to be skeptical, in my opinion it will still definitely be a mixed approach in the end. Just like Oberon_Command said, there are no silver bullets when it comes to software design and architecture.

I'm well aware there are no silver bullets, I just don't know if bashing one solution because it skews OO without showing the actual solutions which work or show the OO as it should be helps much. Most of discussions about ECS turn into argument how bad one or another side is, so there must be some practices that are in "the middle" and that could form a good toolbox for engineering solutions for our needs - I'd love to hear what are these. 

And funny thing you mention Ruby on Rails, that's what my team is doing in my day job, but I think you kinda drifted with that analogy... And of course there are arguments over which framework or solution works better - I just suggest to make this more... productive? so we could share the good practices and solutions? Not expecting silver bullet here, what Oberon accused me for. "Take ideas from something and something and use it to your whatever" says nothing really. We have a real problem here - management of entities and their logic in a game world. Of course this will be different for RTS strategy vs. race game vs. open world RPG. But if that's not good, then what is? Most of 3D games nowdays require some kind of 3D world filled with objects that are processed by some logic - lets discuss this and ditch all racers, platformers etc. which may require something slightly different, and talk what is better than ECS, data-driven or badly-OO-based one...

2 hours ago, Oberon_Command said:

Whatever is good for your particular project. There are no silver bullets. Software development is not a math exam where every question has a correct answer. There is no "this is the one and only right way to do the thing" in software development. There is no template you can follow that will guarantee success. There are a lot of what I would consider "usually wrong" answers, but what is "right" is entirely situational. There are times when even singletons are the least-worst idea one can use. There are even advocates for the use of the 'goto' keyword.

Actually as far as I know we're talking about generic game engine support here, so it's not about my particular project, it's about generic enough solution to fit more uses than single one...