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!

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.