6 ms·

I think this is because of Rust. In my opinion the Rust game dev community is overly fixated on ECS. On the bright side, Rust has some damn good ECS libraries.

by bfrydl 6y ago

meheleventyone 6y ago
I’d agree to a point but it really crosses the whole gamut of hobby game engine development. It’s weirdly self reinforcing even in the face of more interesting architectural choices like DOOM Eternal’s.
- carteloupe 6y ago
  Interested what the architecture of DOOM Eternal is like, was there some talk / blog post about it?
  - meheleventyone 6y ago
    I believe it’s only been mentioned in passing and likely will be talked about at conferences soonish. Here’s a HN thread from when it was first talked about: https://news.ycombinator.com/item?id=22700563 https://news.ycombinator.com/item?id=22700563 There was an early talk about using a job system to run the Destiny renderer and then this one for the whole engine which is a very similar premise to the way DOOM(2016) and then DOOM Eternal evolved. https://www.gdcvault.com/play/1022164/Multithreading-the-Entire-Destiny https://www.gdcvault.com/play/1022164/Multithreading-the-Ent... The renderer talk is here: https://youtu.be/0nTDFLMLX9k https://youtu.be/0nTDFLMLX9k
- runevault 6y ago
  The way Eternal's engine is described it could simply be an ECS with a more advanced job system for farming out work because it can parse how the various objects are updated and only do reads after all writes to the objects happen.
swsieber 6y ago
Rust lends itself to ECS a lot more than it lends itself to behavior hierarchies using inheritance. That's an over simplification, but a useful one.
- bfrydl 6y ago
  I agree that Rust is more suited to ECS than hierarchies. However, the choice is not between ECS or inheritance. The reason I say that the community is overly fixated on it is that many of the benefits attributed to ECS aren't unique to ECS.
munificent 6y ago
> the Rust game dev community is overly fixated on ECS. Not just Rust. The game dev community everywhere is infatuated with ECS. It's basically cargo culting. There is a large base of amateur or indie game developers who want to feel like they are doing game development the "right" way. One big aspect of that is performance. ECS has a reputation for efficiency (which is true, when used well in a context where your performance problems are related to caching), so you see a lot of game devs slavishly applying it to their code in hopes that the "go as fast as a AAA game" Gods will land on their runway and deliver the goods. Every time I see a new ECS framework in JavaScript, I die a little on the inside.
- barrkel 6y ago
  I wouldn't dismiss the JS ECS frameworks without measurement. Polymorphism has costs, and while dynamic languages work hard to remove them, they still work best when they're able to monomorphize the call site, because that enables inlining without combinatoric explosion from chained polymorphic calls. Having a single type in your array means field accesses, method calls etc. have the potential to be monomorphized. There are performance wins to laying out your data in ways that avoid the need for polymorphism.
  - meheleventyone 6y ago
    I don’t believe any JS engines do any “shape” or “hidden class” caching other than for call site polymorphism?
  - munificent 6y ago
    > I wouldn't dismiss the JS ECS frameworks without measurement. I think the burden of proof is on the part of JS ECS frameworks to show they do have better performance by virtue of DoD and, if so, why. JS engine programmers have been optimizing object-oriented code for literally forty years, all the way back to when they were making Smalltalk VMs. If somehow a couple of folks hacking on ECS frameworks have managed to write code that runs faster on those JS engines than the kind of code they were designed for, I'd like to see it. > Having a single type in your array means field accesses, method calls etc. have the potential to be monomorphized. Sure, but object-oriented code does not require any more polymorphism than DoD does. Consider: * Iterate over an array of monomorphic components and call a method on each one. * Iterate over an array of monomorphic entities, access a monomorphic property, and call a method on the latter. There's an extra property access in the latter (which can easily be inlined), but no polymorphic dispatch. In practice, yes, it is possible to reorganize your JavaScript code in ways that play nicer with inline and possibly even code caching. But I have never seen any evidence that JS ECS frameworks actually do that. Instead, the few I've poked around in seem like typical slow imperative dynamically-typed JS. If someone is going to take a pattern that was invented specifically for a language like C++ that gives you precise control over memory layout and then apply it to a language that not doesn't give you that control but often uses hash tables to store an object's state, I think the burden of proof is on the framework to show that the pattern actually applies.

I think this is because of Rust. In my opinion the Rust game dev community is overly fixated on ECS. On the bright side, Rust has some damn good ECS libraries.

by bfrydl 6y ago

I think this is because of Rust. In my opinion the Rust game dev community is overly fixated on ECS. On the bright side, Rust has some damn good ECS libraries.

meheleventyone 6y ago

I’d agree to a point but it really crosses the whole gamut of hobby game engine development. It’s weirdly self reinforcing even in the face of more interesting architectural choices like DOOM Eternal’s.

carteloupe 6y ago
Interested what the architecture of DOOM Eternal is like, was there some talk / blog post about it?
- meheleventyone 6y ago
  I believe it’s only been mentioned in passing and likely will be talked about at conferences soonish. Here’s a HN thread from when it was first talked about: https://news.ycombinator.com/item?id=22700563 https://news.ycombinator.com/item?id=22700563 There was an early talk about using a job system to run the Destiny renderer and then this one for the whole engine which is a very similar premise to the way DOOM(2016) and then DOOM Eternal evolved. https://www.gdcvault.com/play/1022164/Multithreading-the-Entire-Destiny https://www.gdcvault.com/play/1022164/Multithreading-the-Ent... The renderer talk is here: https://youtu.be/0nTDFLMLX9k https://youtu.be/0nTDFLMLX9k
runevault 6y ago
The way Eternal's engine is described it could simply be an ECS with a more advanced job system for farming out work because it can parse how the various objects are updated and only do reads after all writes to the objects happen.

swsieber 6y ago

Rust lends itself to ECS a lot more than it lends itself to behavior hierarchies using inheritance. That's an over simplification, but a useful one.

bfrydl 6y ago
I agree that Rust is more suited to ECS than hierarchies. However, the choice is not between ECS or inheritance. The reason I say that the community is overly fixated on it is that many of the benefits attributed to ECS aren't unique to ECS.

munificent 6y ago

> the Rust game dev community is overly fixated on ECS. Not just Rust. The game dev community everywhere is infatuated with ECS. It's basically cargo culting. There is a large base of amateur or indie game developers who want to feel like they are doing game development the "right" way. One big aspect of that is performance. ECS has a reputation for efficiency (which is true, when used well in a context where your performance problems are related to caching), so you see a lot of game devs slavishly applying it to their code in hopes that the "go as fast as a AAA game" Gods will land on their runway and deliver the goods. Every time I see a new ECS framework in JavaScript, I die a little on the inside.

barrkel 6y ago
I wouldn't dismiss the JS ECS frameworks without measurement. Polymorphism has costs, and while dynamic languages work hard to remove them, they still work best when they're able to monomorphize the call site, because that enables inlining without combinatoric explosion from chained polymorphic calls. Having a single type in your array means field accesses, method calls etc. have the potential to be monomorphized. There are performance wins to laying out your data in ways that avoid the need for polymorphism.
- meheleventyone 6y ago
  I don’t believe any JS engines do any “shape” or “hidden class” caching other than for call site polymorphism?
- munificent 6y ago
  > I wouldn't dismiss the JS ECS frameworks without measurement. I think the burden of proof is on the part of JS ECS frameworks to show they do have better performance by virtue of DoD and, if so, why. JS engine programmers have been optimizing object-oriented code for literally forty years, all the way back to when they were making Smalltalk VMs. If somehow a couple of folks hacking on ECS frameworks have managed to write code that runs faster on those JS engines than the kind of code they were designed for, I'd like to see it. > Having a single type in your array means field accesses, method calls etc. have the potential to be monomorphized. Sure, but object-oriented code does not require any more polymorphism than DoD does. Consider: * Iterate over an array of monomorphic components and call a method on each one. * Iterate over an array of monomorphic entities, access a monomorphic property, and call a method on the latter. There's an extra property access in the latter (which can easily be inlined), but no polymorphic dispatch. In practice, yes, it is possible to reorganize your JavaScript code in ways that play nicer with inline and possibly even code caching. But I have never seen any evidence that JS ECS frameworks actually do that. Instead, the few I've poked around in seem like typical slow imperative dynamically-typed JS. If someone is going to take a pattern that was invented specifically for a language like C++ that gives you precise control over memory layout and then apply it to a language that not doesn't give you that control but often uses hash tables to store an object's state, I think the burden of proof is on the framework to show that the pattern actually applies.