[dgb23]

I really like Jonathan Blow, but I sometimes wish he would substantiate these kind of claims more so an outsider could learn what he is actually saying and why. I've watched a lengthy video of his on that topic but I didn't get out anything other than "you don't need it". No concrete implementation cases where it gets in the way or how a category of problems is better modeled in a different way.

[cardanome]

I am beginning to suspect people like him because he speaks slowly with lots of repetition and in a relatively accessible way.

Sure he might have lot's of valuable experience but every video I have watched of him was like a 1 hour rambling opinion piece which could be 3 minutes of actual content.

His video reaction to the rustconf ECS video had some good points but they were very nitpicky and not really justifying the length of the video at all.

[modernerd]

On why ECS gets in the way for him:

> Because it is far more complicated, thus takes far more work, than what you actually need to do. That work has a large opportunity cost. https://twitter.com/Jonathan_Blow/status/1427378984145154048

To me this has more nuance than, “you ain't gonna need it”. I don't think “concrete implementations” would do all that much to strengthen his argument that unnecessary complexity gets in the way of shipping for indie devs:

> Even 10% friction more than I ever had would have killed me. I wouldn't have been able to make the things I had. Even 5% more friction would have been really bad. https://youtu.be/4t1K66dMhWk?t=3635

And…

> I have, several times, built games where I barely managed to finish. … I've just experienced that too many times to increase friction. I need to decrease friction. https://youtu.be/4t1K66dMhWk?t=3072

And again, in relation to entities rather than Rust's borrow checker:

> If you are trying to focus on the way your entities are set up, you are mis-directing your effort and that's going to make it harder. Try to solve the problem that makes your game interesting. What is it about the gameplay that makes it interesting … that users can see? Focus on that, solve those problems. https://www.youtube.com/watch?v=w7W3xM2tzRA

On what he uses instead of ECS/components in his engines:

> One struct per entity type, with a base struct that is common to all of them. https://twitter.com/Jonathan_Blow/status/1427376307453665280

[meheleventyone]

Frictions a funny thing in this sense and what hurts one person helps another.

One example is that a concrete entity is much harder to change than one that is composed of concrete components. So for example an artist I work with took some components from an FPS game we made, some other random components we had and a couple of components made in people’s spare time, made a bunch of art and ended up with a pretty convincing prototype of a multiplayer shooter. He couldn’t have done that at all following a concrete entity approach.

Composition and in particular making composition data-driven and runtime malleable is very flexible even if you don’t care for the ECS approach.

But a large part of the problem is that we end up promulgating opinion divorced from context and often a lot of that context is not really more complex than the approach someone is used to. Like if you have no problems with the concrete entity approach which has been a successful pattern since forever then there isn’t that much compelling you to change. That doesn’t make it the one true way or that because someone famous and opinionated likes it that there isn’t an alternative that will better serve someone else’s needs.

Horses for courses.