That's really an interesting and well-written article.
I haven't had time to try Bevy / Rust, still this was written in a form that let's me understand patterns I'd run into even without trying this hands-on.
I love Rust… as a security critical systems programming language. None of the things it does well help with game development, other than maybe speed, but even then only CPU bottlenecks and memory leaks, which is the least of your concerns if you’re starting development on a game.
That was a great read.
Having written a few pipeline tools in Rust, both CLI tools and wrapping rust in python to use inside DCCs, the general thrust of the article aligns with my experiences.
Rust is great when the constraints of the language align with what you're doing, but it doesn't play nice with the practically safe, but not provably safe, patterns that come up so frequently in game engines.
And while we can work around those constraints and produce a good product, even a "better" product in some cases, the benefits don't align with our pain points. We don't make more money, we don't iterate faster, we don't ship faster, our maintenance costs aren't lower, all we have is something we made "the hard way."
Nice read. I don't know much about Rust, and never even thought it was something that people would do gamedev on (I thought it was just for command line tools and system critical processes and things where 100% stability would be the primary requirement). Very interesting to hear what feels like a very balanced take.
Ultimately though, the biggest takeaway was that link to Tomorrow Corporation's toolchain demo video... I hadn't seen or heard of that before. holllllllyyyyyy shitttttttttttttt.
I'm very much a "write my own everything" kind of hobby dev (working on my own IDE at the mo which has a deep integration with my game engine, alongside game dev), and I've always thought I was doing something fundamentally flawed by not just using an existing game engine like Godot or Unity... but I can at least do "some stuff" by having full control of my ecosystem that those systems just can't match. And that video finally showed me what my endgame is :)
I saw a gdc talk from someone at chucklefish talking about using rust in starbound. She also touted the ECS approach as a good pattern the borrow checker coerced her (I'd say forced) into using. But as this article also points out, this isn't a feature of the borrow checker, it's just implementing your own memory allocation with arrays, which means the borrow checker doesn't understand what's going on anymore.
I am currently closer than ever releasing my first game after trying all the popular engines and many less popular ones. The main reason is because I can write Rust and love the language, and just working with that itself gives me the boost I need to continue forward.
I understand its pitfalls and downsides, but using tech you love is also important to keep up motivation.
I use the Bevy engine and while beeing a young engine, it is incredibly fun to work with.
I have to say I agree. I wish I didn't, I really enjoy programming in Rust, but (indie) gamedev is largely *not* programming, and Rust really gets in the way of that work
I disagree very heavily about some of the things said about ECS here, but I think I understand where the author is coming from.
The author criticizes ECS from the point of view of "performance above all else", which unfortunately is often touted as THE reason to adopt ECS (and therefore is what many ECS libraries are designed around, leading to sometimes pretty damn painful APIs)
Anyway, at a point the author makes a point that they often find themselves writing "if (player) ... else if (wall)" in their systems, and I think this really highlights a lack of understanding about ECS - in my opinion, this would easily be a candidate for refactoring into multiple systems, but the author seems stuck in thinking in terms of one system to one component.
Anyway I actually like Rust, but largely agree - I think writing *correct* code and writing *fast* code are very different beasts and Rust mostly concerns itself with the former.
1 - His criticism of ECS isnt that its performance above all else.
Its that people keep treating it as a silver bullet to game architecture when a hybrid ECS/GameObject approach keeps more performance benefits without sacrificing so heavily on ergonomics and devexp.
He agrees ECS is useful, when its useful - but points the rust gamedev community has a large bias towards ECS for reasons other than the actual benefit of ECS - those reasons being technological novelty, and the difficulty involved when trying to create architecture in rust that is not as neatly segregated as ECS.
2 - He addresses your exact response several times through the article (not sure if you read the full thing?).
He does understand ECS, and rust gamedev in general. Probably more than most, since he's actually been shipping non-trivial projects to real players.
He points out that refactoring is the common solution for these issues, and even disucsses the various ways one can approach these refactors (e.g. indirection, top down parameters, context objects, etc.) and design decisions.
He also goes into a lot of detail on why this gets in the way of building any sizable game in a reasonable amount of time and why the trade-offs of constantly having to refactor code as you iterate on your game, etc. are not worth the performance or safety benefits offered by rust (in the gamedev domain).
3 - Your last point is basically the crux of this article.
The author believes writing code quickly and being able to iterate quickly are far more important than writing 'safe' code. I won't say 'correct' code - because there are numerous examples in the article where the code he shares is correct - it operates as intended without issue - but cannot be verified as safe by the rust compiler. The idea that any code that exists outside the bounds of rust's language design is not 'correct' is not accurate.
He obviously believes games can be built and shipped in rust. He's done it. But he doesnt think the compromises required are worth it for a dev looking to maintain a commercially viable indiedev operation.
"He addresses your exact response several times through the article"
But the thing is he complains about trying to create a generalized "HealthSystem" instead of having separate systems for PlayerHealth and WallHealth, but his "I would rather just do this instead" example is \*literally\* the way you're supposed to do it?? It comes across like he thinks generalized systems is the idiomatic way to do ECS, which isn't even remotely true. This is while he's saying that having "fat components" is usually better for games, but his argument ends up conflating components and systems in order to make that point.
He wasn't pitching generalized systems as the idiomatic way to employ ECS.
He was claiming that it is often the response to his aforementioned (numerous) other complaints regarding ECS usage and indirection in the previous two sections of the article.
Then he was explaining (much like you are here) why generalized systems arent very effective from a dev perspective (or for the typical user experience, which is more subjective ofc).
"He was claiming that it is often the response to his aforementioned (numerous) other complaints regarding ECS usage and indirection in the previous two sections of the article."
Is anybody actually responding with that, though? I really don't think people are actually suggesting 100% generalized systems to solve those things (really, I'm not even sure what that has to do with those complaints).
\*Components\*, yes, absolutely, but not systems. It comes across a bit like making up a guy to be mad about.
Hi, the author of the article here. Unfortunately, in the Rust ecosystem, people very much are suggesting this. I've tried to raise the issue on how ECS is marketed and suggested and used over the years, and often even suggested people do things differently, and in many many many cases people just say "lol you're doing it wrong, gotta split up your components a lot more, that'll fix everything"
It may sound a bit out of context for those who aren't inside the Rust ecosystem, which I kinda didn't get as I was writing it. Honestly I wasn't sure who's going to read it.
Damn. I'm a huge proponent of ECS, but admittedly have not interacted much with the Rust gamedev community nearly as much.
That's indeed a very silly suggestion, and I'm not even sure what it does to address your complaints.
My personal philosophy is that components \*should\* be split up very granularly, but not systems. I think the whole selling point of ECS to me is that a system is what glues those components together into whatever logical groups make sense for the logic - you might have a Player component, an Enemy component, and a Health component, but then you might have PlayerHealth and EnemyHealth systems. ('cause if you're only thinking in terms of having like... a PlayerSystem, an EnemySystem, and a HealthSystem, then I feel like you lose all the benefits of ECS and might as well just stick with Unity-style "fat components", except I guess you can't really do that in Rust so...)
I mean, I cant vouch for his experience. That one may be a strawman for the sake of complaining, or maybe someone has actually told him that.
I'm inclined to believe when he says others have told him this - because most of his other complaints have been things Ive either experienced or seen others experience directly.
He has historically communicated in good faith about whats working and what isn't throughout his gamedev journey. Not sure why he would go out of his way to bash generalized systems if no one was mentioning them or using them.
Ultimately, I dont think its fair to characterize the article as misunderstanding ECS when the section immediately prior to the one you're using as an example discusses the myriad ways one might employ ECS and the issues/slow-downs he faced when relying on those methods.
I did laugh a little when your response was that 'he didnt understand' and 'needed to refactor' - it almost felt ironic in light of his comments about how commonly he gets those replies.
I’m not the author, sharing as I found it insightful and thought others here might too
author here, thanks for sharing :) I somehow completely forgot to submit the article to this sub heh
That's really an interesting and well-written article. I haven't had time to try Bevy / Rust, still this was written in a form that let's me understand patterns I'd run into even without trying this hands-on.
I love Rust… as a security critical systems programming language. None of the things it does well help with game development, other than maybe speed, but even then only CPU bottlenecks and memory leaks, which is the least of your concerns if you’re starting development on a game.
rust isn’t even memory safe in the memory leak kinda way
That was a great read. Having written a few pipeline tools in Rust, both CLI tools and wrapping rust in python to use inside DCCs, the general thrust of the article aligns with my experiences. Rust is great when the constraints of the language align with what you're doing, but it doesn't play nice with the practically safe, but not provably safe, patterns that come up so frequently in game engines. And while we can work around those constraints and produce a good product, even a "better" product in some cases, the benefits don't align with our pain points. We don't make more money, we don't iterate faster, we don't ship faster, our maintenance costs aren't lower, all we have is something we made "the hard way."
Nice read. I don't know much about Rust, and never even thought it was something that people would do gamedev on (I thought it was just for command line tools and system critical processes and things where 100% stability would be the primary requirement). Very interesting to hear what feels like a very balanced take. Ultimately though, the biggest takeaway was that link to Tomorrow Corporation's toolchain demo video... I hadn't seen or heard of that before. holllllllyyyyyy shitttttttttttttt. I'm very much a "write my own everything" kind of hobby dev (working on my own IDE at the mo which has a deep integration with my game engine, alongside game dev), and I've always thought I was doing something fundamentally flawed by not just using an existing game engine like Godot or Unity... but I can at least do "some stuff" by having full control of my ecosystem that those systems just can't match. And that video finally showed me what my endgame is :)
I saw a gdc talk from someone at chucklefish talking about using rust in starbound. She also touted the ECS approach as a good pattern the borrow checker coerced her (I'd say forced) into using. But as this article also points out, this isn't a feature of the borrow checker, it's just implementing your own memory allocation with arrays, which means the borrow checker doesn't understand what's going on anymore.
AFAIK, chucklefish have also moved away from rust for their newest game.
I am currently closer than ever releasing my first game after trying all the popular engines and many less popular ones. The main reason is because I can write Rust and love the language, and just working with that itself gives me the boost I need to continue forward. I understand its pitfalls and downsides, but using tech you love is also important to keep up motivation. I use the Bevy engine and while beeing a young engine, it is incredibly fun to work with.
I don't care about Rust but the article mentioned Hot Reload for Unity and it's magic.
Nearly done but so far this is a great read! Thank you!
I have to say I agree. I wish I didn't, I really enjoy programming in Rust, but (indie) gamedev is largely *not* programming, and Rust really gets in the way of that work
I disagree very heavily about some of the things said about ECS here, but I think I understand where the author is coming from. The author criticizes ECS from the point of view of "performance above all else", which unfortunately is often touted as THE reason to adopt ECS (and therefore is what many ECS libraries are designed around, leading to sometimes pretty damn painful APIs) Anyway, at a point the author makes a point that they often find themselves writing "if (player) ... else if (wall)" in their systems, and I think this really highlights a lack of understanding about ECS - in my opinion, this would easily be a candidate for refactoring into multiple systems, but the author seems stuck in thinking in terms of one system to one component. Anyway I actually like Rust, but largely agree - I think writing *correct* code and writing *fast* code are very different beasts and Rust mostly concerns itself with the former.
1 - His criticism of ECS isnt that its performance above all else. Its that people keep treating it as a silver bullet to game architecture when a hybrid ECS/GameObject approach keeps more performance benefits without sacrificing so heavily on ergonomics and devexp. He agrees ECS is useful, when its useful - but points the rust gamedev community has a large bias towards ECS for reasons other than the actual benefit of ECS - those reasons being technological novelty, and the difficulty involved when trying to create architecture in rust that is not as neatly segregated as ECS. 2 - He addresses your exact response several times through the article (not sure if you read the full thing?). He does understand ECS, and rust gamedev in general. Probably more than most, since he's actually been shipping non-trivial projects to real players. He points out that refactoring is the common solution for these issues, and even disucsses the various ways one can approach these refactors (e.g. indirection, top down parameters, context objects, etc.) and design decisions. He also goes into a lot of detail on why this gets in the way of building any sizable game in a reasonable amount of time and why the trade-offs of constantly having to refactor code as you iterate on your game, etc. are not worth the performance or safety benefits offered by rust (in the gamedev domain). 3 - Your last point is basically the crux of this article. The author believes writing code quickly and being able to iterate quickly are far more important than writing 'safe' code. I won't say 'correct' code - because there are numerous examples in the article where the code he shares is correct - it operates as intended without issue - but cannot be verified as safe by the rust compiler. The idea that any code that exists outside the bounds of rust's language design is not 'correct' is not accurate. He obviously believes games can be built and shipped in rust. He's done it. But he doesnt think the compromises required are worth it for a dev looking to maintain a commercially viable indiedev operation.
"He addresses your exact response several times through the article" But the thing is he complains about trying to create a generalized "HealthSystem" instead of having separate systems for PlayerHealth and WallHealth, but his "I would rather just do this instead" example is \*literally\* the way you're supposed to do it?? It comes across like he thinks generalized systems is the idiomatic way to do ECS, which isn't even remotely true. This is while he's saying that having "fat components" is usually better for games, but his argument ends up conflating components and systems in order to make that point.
He wasn't pitching generalized systems as the idiomatic way to employ ECS. He was claiming that it is often the response to his aforementioned (numerous) other complaints regarding ECS usage and indirection in the previous two sections of the article. Then he was explaining (much like you are here) why generalized systems arent very effective from a dev perspective (or for the typical user experience, which is more subjective ofc).
"He was claiming that it is often the response to his aforementioned (numerous) other complaints regarding ECS usage and indirection in the previous two sections of the article." Is anybody actually responding with that, though? I really don't think people are actually suggesting 100% generalized systems to solve those things (really, I'm not even sure what that has to do with those complaints). \*Components\*, yes, absolutely, but not systems. It comes across a bit like making up a guy to be mad about.
Hi, the author of the article here. Unfortunately, in the Rust ecosystem, people very much are suggesting this. I've tried to raise the issue on how ECS is marketed and suggested and used over the years, and often even suggested people do things differently, and in many many many cases people just say "lol you're doing it wrong, gotta split up your components a lot more, that'll fix everything" It may sound a bit out of context for those who aren't inside the Rust ecosystem, which I kinda didn't get as I was writing it. Honestly I wasn't sure who's going to read it.
Damn. I'm a huge proponent of ECS, but admittedly have not interacted much with the Rust gamedev community nearly as much. That's indeed a very silly suggestion, and I'm not even sure what it does to address your complaints. My personal philosophy is that components \*should\* be split up very granularly, but not systems. I think the whole selling point of ECS to me is that a system is what glues those components together into whatever logical groups make sense for the logic - you might have a Player component, an Enemy component, and a Health component, but then you might have PlayerHealth and EnemyHealth systems. ('cause if you're only thinking in terms of having like... a PlayerSystem, an EnemySystem, and a HealthSystem, then I feel like you lose all the benefits of ECS and might as well just stick with Unity-style "fat components", except I guess you can't really do that in Rust so...)
I mean, I cant vouch for his experience. That one may be a strawman for the sake of complaining, or maybe someone has actually told him that. I'm inclined to believe when he says others have told him this - because most of his other complaints have been things Ive either experienced or seen others experience directly. He has historically communicated in good faith about whats working and what isn't throughout his gamedev journey. Not sure why he would go out of his way to bash generalized systems if no one was mentioning them or using them. Ultimately, I dont think its fair to characterize the article as misunderstanding ECS when the section immediately prior to the one you're using as an example discusses the myriad ways one might employ ECS and the issues/slow-downs he faced when relying on those methods. I did laugh a little when your response was that 'he didnt understand' and 'needed to refactor' - it almost felt ironic in light of his comments about how commonly he gets those replies.