5 ms·

jonathan blow is not a big fan of ECS https://www.youtube.com/watch?v=4t1K66dMhWk https://www.youtube.com/watch?v=4t1K66dMhWk

by platz 8y ago

gameswithgo 8y ago
It isn't appropriate for all games. Which is important to keep in mind. Sometimes people get crazy and do these really complex high performance ECS systems for a 2d game with 10 entities. Or a game with only 2 kinds of entities. Just unnecessary complexity in those cases.
- platz 8y ago
  I am not a game dev, but from watching some of his stuff, I have a feeling he would invert that claim, and say ECS is fine for smaller games but for really involved systems with time-to-market pressures the framework is too limiting.
  - mcphage 8y ago
    > but for really involved systems with time-to-market pressures the framework is too limiting It was specifically designed and developed for involved systems.
  - jungler 8y ago
    Jon is also known for being hugely opinionated with only his direct personal experience backing him up. His basic thought on ECS is that it's "obvious". And if you have worked on an involved game a few times and tried to examine the performance bottlenecks of the architecture, it really is. There are different flavors of "how to ECS" that make tradeoffs between static compile-time composition(theoretical fastest ECS: an entire scene is fed into a compiler and it emits a custom bespoke memory layout and an API for it) and runtime dynamism(most flexible ECS: dynamic types, reflection, some code to automatically maintain indexes). But the basic principles of working directly with compositions of plain old data are ingrained throughout, and emerge naturally from trying to extend a simple game with simple data structures and an imperative code style, without resorting to OO inheritance(which was tried and discarded because properties inevitably crept upwards into the parent class leading to a memory-hungry "God Object").
    - platz 8y ago
      I don't think I'm claiming that Jon would advocate for OO inheritance. I also think he thinks that SoA instead of AoS is a good thing - no qualms there. I guess he would probably have the most comments on how to deal/access/manipulate that SoA at a higher level
Impossible 8y ago
Jonathan Blow's commentary isn't anti-ECS. It's more skeptical of Rust's borrow checker, more specifically he's pointing out how the original talk ends with bypassing the borrow checker and copying a pattern that would have equal safety in C or C++.
- platz 8y ago
  That is true + there is an offhand quote he makes about ECS in general, but 99% is about the issue you mention
dfsdfsdfsdfs 8y ago
couldn't make it through as he says "right?" at the end of every sentence

jonathan blow is not a big fan of ECS https://www.youtube.com/watch?v=4t1K66dMhWk https://www.youtube.com/watch?v=4t1K66dMhWk

by platz 8y ago

jonathan blow is not a big fan of ECS https://www.youtube.com/watch?v=4t1K66dMhWk https://www.youtube.com/watch?v=4t1K66dMhWk

gameswithgo 8y ago

It isn't appropriate for all games. Which is important to keep in mind. Sometimes people get crazy and do these really complex high performance ECS systems for a 2d game with 10 entities. Or a game with only 2 kinds of entities. Just unnecessary complexity in those cases.

platz 8y ago
I am not a game dev, but from watching some of his stuff, I have a feeling he would invert that claim, and say ECS is fine for smaller games but for really involved systems with time-to-market pressures the framework is too limiting.
- mcphage 8y ago
  > but for really involved systems with time-to-market pressures the framework is too limiting It was specifically designed and developed for involved systems.
- jungler 8y ago
  Jon is also known for being hugely opinionated with only his direct personal experience backing him up. His basic thought on ECS is that it's "obvious". And if you have worked on an involved game a few times and tried to examine the performance bottlenecks of the architecture, it really is. There are different flavors of "how to ECS" that make tradeoffs between static compile-time composition(theoretical fastest ECS: an entire scene is fed into a compiler and it emits a custom bespoke memory layout and an API for it) and runtime dynamism(most flexible ECS: dynamic types, reflection, some code to automatically maintain indexes). But the basic principles of working directly with compositions of plain old data are ingrained throughout, and emerge naturally from trying to extend a simple game with simple data structures and an imperative code style, without resorting to OO inheritance(which was tried and discarded because properties inevitably crept upwards into the parent class leading to a memory-hungry "God Object").
  - platz 8y ago
    I don't think I'm claiming that Jon would advocate for OO inheritance. I also think he thinks that SoA instead of AoS is a good thing - no qualms there. I guess he would probably have the most comments on how to deal/access/manipulate that SoA at a higher level

Impossible 8y ago

Jonathan Blow's commentary isn't anti-ECS. It's more skeptical of Rust's borrow checker, more specifically he's pointing out how the original talk ends with bypassing the borrow checker and copying a pattern that would have equal safety in C or C++.

platz 8y ago
That is true + there is an offhand quote he makes about ECS in general, but 99% is about the issue you mention

dfsdfsdfsdfs 8y ago

couldn't make it through as he says "right?" at the end of every sentence