5 ms·

I think Jonathan Blow's take is right: > ECS only starts to make sense when you are big enough to have multiple teams, with one team building the engine and th

I think Jonathan Blow's take is right: > ECS only starts to make sense when you are big enough to have multiple teams, with one team building the engine and the other using the engine to make the game; or you are an engine company and your customer makes the game. If that is not your situation, do not rathole. https://twitter.com/Jonathan_Blow/status/1427358365357789199 https://twitter.com/Jonathan_Blow/status/1427358365357789199 Most of the arguments I've seen for ECS in Rust suggest it helps to work with memory management/borrowing. For example, here's Patrick Walton's take: > There's a reason why Rust game engines all use ECS and it's not just because the traditional Unity OO style is out of fashion. It's because mutable everywhere just doesn't work in Rust. Mutex and RefCell explosion. https://twitter.com/pcwalton/status/1440519425845723139 https://twitter.com/pcwalton/status/1440519425845723139. And here's Cora Sherratt's discussion of ECS options in Rust: > So why do you need one? Well all ECS developers will claim it’s largely about performance, and show you a mountain of numbers to back it up. The more honest answer probably comes down to the difficulty of making ownership work in Rust without some type of framework to manage the transfer of ownership for you. Rust punishes poor architecture, so ECS’ are here to help. https://csherratt.github.io/blog/posts/specs-and-legion/ https://csherratt.github.io/blog/posts/specs-and-legion/ (This post also has the best visualisation and explanation of an ECS I've read.) I've read Hands-On Rust and you could definitely implement the game without an ECS. But at the same time it was useful to play with that pattern because it's in common usage in the Rust community. (Bevy also makes heavy use of it, for example, where it feels pretty lightweight because they made some good design decisions: https://bevyengine.org/news/bevys-first-birthday/#bevy-ecs https://bevyengine.org/news/bevys-first-birthday/#bevy-ecs.)

kvark 5y ago
Rust has ways to deal with mutability. Three-rs [1] uses a classic scene graph tree, like ThreeJS. It's based on Froggy [2], which is a general low level primitive for building a "traditional" topology of the classes. [1] https://github.com/three-rs/three https://github.com/three-rs/three [2] https://github.com/kvark/froggy https://github.com/kvark/froggy
halvnykterist 5y ago
I think the idea that you need something like ECS to deal with mutability everywhere is a misconception. Traditional architectures you'd use in C or C++ are all going to more or less have a tree-based ownership graph, and these translate very well to Rust. Long-lived pointers to things that you don't own are a great way to get UAF errors or similar, and having a collection of entities you can look up by ID is a common pattern to use outside of ECS. > But at the same time it was useful to play with that pattern because it's in common usage in the Rust community. And in doing so it perpetuates it. ECS is a good solution for lots of problems (in particular I don't agree with jblow's take) but parading it as _the_ way to make games in Rust feels a lot like how OOP has been championed in the past. If you're going to teach someone how to make games in Rust, doing with extra patterns that don't add much other than complexity (in this case) doesn't seem like a good strategy for teaching or introducing people to the language.
dgb23 5y ago
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 5y ago
  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 5y ago
  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 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 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 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 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 https://twitter.com/Jonathan_Blow/status/1427376307453665280
moth-fuzz 5y ago
This is an interesting happenstance in the Rust community that I think is largely cultural rather than technical. Backlash against some figurative idea of OOP is popular. ECS is popular as the messianic retort to that OOP figure. But when you look at it from an architectural standpoint, ECS is quite possibly one of the hardest things to do in Rust compared to other designs. Let me get this straight - you want to avoid shared mutability but you have all your gamestate in centralized stores? That systems will necessarily have to have shared, mutable access to? Possibly concurrently? I think it's a good idea architecturally, but also I think it's a tough problem to solve, and I think the claims that Rust lends itself to that architecture are false. It's even tougher in Rust than in other languages, I'd say. And though I've read the source code to many Rust ECS libraries, they all do it in different ways, and all of them feel like hacks. I definitely feel like the most "rustic" way to do game design, just based on what's easy to do in the language itself without resorting to workarounds, is to have individual actors maintain their individual state, and then have a common interface via a trait that would call update() or render() virtually in a loop or whatever. Then have them message each other via mpsc channels. That's pretty much rust straight from the book, and, it's also a bog standard GameObject architecture straight outta the 2000s.
- deleted 5y ago
  [deleted]
- platz 5y ago
  are these message channels deterministic? Or would order of delivery and processing be resolved by chance?
  - nyanpasu64 5y ago
    Message channels are deterministic if they're only used on a single thread.

kvark 5y ago

Rust has ways to deal with mutability. Three-rs [1] uses a classic scene graph tree, like ThreeJS. It's based on Froggy [2], which is a general low level primitive for building a "traditional" topology of the classes. [1] https://github.com/three-rs/three https://github.com/three-rs/three [2] https://github.com/kvark/froggy https://github.com/kvark/froggy

halvnykterist 5y ago

I think the idea that you need something like ECS to deal with mutability everywhere is a misconception. Traditional architectures you'd use in C or C++ are all going to more or less have a tree-based ownership graph, and these translate very well to Rust. Long-lived pointers to things that you don't own are a great way to get UAF errors or similar, and having a collection of entities you can look up by ID is a common pattern to use outside of ECS. > But at the same time it was useful to play with that pattern because it's in common usage in the Rust community. And in doing so it perpetuates it. ECS is a good solution for lots of problems (in particular I don't agree with jblow's take) but parading it as _the_ way to make games in Rust feels a lot like how OOP has been championed in the past. If you're going to teach someone how to make games in Rust, doing with extra patterns that don't add much other than complexity (in this case) doesn't seem like a good strategy for teaching or introducing people to the language.

dgb23 5y ago

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 5y ago
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 5y ago
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 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 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 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 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 https://twitter.com/Jonathan_Blow/status/1427376307453665280

moth-fuzz 5y ago

This is an interesting happenstance in the Rust community that I think is largely cultural rather than technical. Backlash against some figurative idea of OOP is popular. ECS is popular as the messianic retort to that OOP figure. But when you look at it from an architectural standpoint, ECS is quite possibly one of the hardest things to do in Rust compared to other designs. Let me get this straight - you want to avoid shared mutability but you have all your gamestate in centralized stores? That systems will necessarily have to have shared, mutable access to? Possibly concurrently? I think it's a good idea architecturally, but also I think it's a tough problem to solve, and I think the claims that Rust lends itself to that architecture are false. It's even tougher in Rust than in other languages, I'd say. And though I've read the source code to many Rust ECS libraries, they all do it in different ways, and all of them feel like hacks. I definitely feel like the most "rustic" way to do game design, just based on what's easy to do in the language itself without resorting to workarounds, is to have individual actors maintain their individual state, and then have a common interface via a trait that would call update() or render() virtually in a loop or whatever. Then have them message each other via mpsc channels. That's pretty much rust straight from the book, and, it's also a bog standard GameObject architecture straight outta the 2000s.

deleted 5y ago
[deleted]
platz 5y ago
are these message channels deterministic? Or would order of delivery and processing be resolved by chance?
- nyanpasu64 5y ago
  Message channels are deterministic if they're only used on a single thread.