I hear Rust being slow to compile is their biggest gripe, but really - look at what you’re gaining for the slowdown!
Bevy gives you a very nice ECS to model your app but compilation can be slower than hand crafted code, while not using it gives you tonnes more code and the complexities that come with it, just to compile faster?
I don’t know what you mean by, “just to compile faster.” Compiling fast is critical to game development. There’s no formula for fun so you have to iterate extensively.
I also don’t think that other solutions are “tonnes more code.” Any code will explode in size if poorly written. The same is true for bevy.
OK, even though it does not seem like that game was very notable, will give you that one game. Rust has at least ~5-6 game engines though, so you will have to come up with 4-5 more.
It's a single data structure that contains your entire game though? The whole point of the ECS is that literally everything uses the same data; it's like if you modeled every object in the world with one struct that has an optional field for every piece of data that could exist. I'm not saying that necessarily makes the tradeoff worthwhile, but calling it a "single data structure" is a bit reductive.
It's a single data structure that contains your entire game though?
Are you asking?
but calling it a "single data structure" is a bit reductive.
No it isn't. It's like a tiny database. Depending on how someone implements it, it could use arrays, hash maps and b-trees. There is no universe where this means a binary that does nothing should be 50 megabytes.
I would say yes it’s like a tiny database but as well as all the other things your added. And I think that’s a good thing, because it does this at the type level!
I’m actually seeing if I can build a parser using bevy_ecs just because the way their state machine works, it looks like it would be fun
In this case systems are the S of ECS and contain all your game logic, acting upon the entities and components (E and C).
By system management I assume they mean the APIs bevy offers for scheduling and sequencing systems and events so your game logic remains modularized while still running in the correct order.
It seems like you're calling an entire game engine "ECS". I'm not sure what the point is here, the whole question was what justifies having a 50 MB hello world binary. It doesn't matter what you put into a data structure, the data structure itself shouldn't make 50 MB binaries.
No, they aren't calling the entire game engine "ECS". Entity-Component-System is an architecture that Bevy is structured around.
As I have previously stated, I wouldn't blame the data structures used behind Bevy just yet, given Rust's tendency for making bloated binaries. What is taking the most space in this 50MB binary? How does it scale with the complexity of the application?
I don't know where you are trying to go with this logic. You still haven't assured that the 50MB is actually related to data structures used behind by bevy, lest you are insunating that the data structures used by bevy are solely responsible for that size, which is not what the post claims.
How small is a hello world in C on Linux? The last time I checked a few years ago, it was either 9Mb or 13Mb (memory is fuzzy on this one but one of them was right).
Edit: wow I’m way off… it must have been the 90s when I checked this lol
Yeah, testing here with GCC 13.3.0 led to 16K. Perhaps, when you made your test, the compiler was statically linking some libs, which would explain the massive increase in size.
I know the thread. Your point is about whether Bevy's "data structure" is worth 50MB. I pressing on the fact that you haven't shown what this 50MB actually are.
But, out of curiosity, do you also consider the Linux Kernel also a data structure?
> To be clear you think an ECS implementation is 50MB?
No.
> Do you think a spreadsheet the[sic] holds a function pointer is a kernel?
Do you think an entire engine, including its system scheduler, is a spreadsheet? If so, shouldn't be hard to apply the same argument to any kernel. Of course, it all relies on your definitions and sense of reductionism.
I think you're conflating other big features of a game engine with a way to store data. If you look at other ecs implementations they are data structures, they don't do "system scheduling" (is that different from regular scheduling?)
First of, Bevy isn't just an ECS implementation. It's a game engine designed around ECS. While the ECS part is its core, Bevy also provides rendering, resource management, physics, etc. One of its other tasks, a rather important one too, is system scheduling: once you register systems, Bevy is responsible for dispatching them each frame, at the appropriate time, while also avoid data races over global resources and components.
No one thought that or said that so I don't know what point you're trying to make.
If you go to the comments I replied it was someone saying bevy compiles slow and has excessive bloated binaries. Someone else replied that you get so much, like ecs. Then I said that ecs specifically is just a data structure and has no reason to bloat binaries to be 50MB for an empty program that does nothing.
You're replying about things no one was discussing.
Your whole thread is about nitpicking the phrase "Bevy gives you a nice ECS". You are the one who asserted that "ecs specifically is just a data structure" (it isn't, by most definitions [1] [2], except yours). I supposed you were referring exclusively to a simple and basic component storage implementation (which is a data storage), where as OP was probably referring to the whole ergonomics of writing programs in it, alongside all the other features. It seems to me that you're the one who missed the point.
Then, you used this reductionism to question whether the 50MB binary is worth it. And that's ignoring the fact that there are ways to cut it if you wish, as mentioned in the reddit thread. And then there's the issue of whether it will actually matter for a full game.
I will need citation on which link, and how it defines ECS as a data structure.
From [1]:
> Entity component system (ECS) is a software architectural pattern. An ECS consists of entities composed of data components, along with systems that operate on those components.
From [2]:
> ECS ("Entity Component System") describes a design approach which promotes code reusability by separating data from behavior. Data is often stored in cache-friendly ways which benefits performance.
What you just described is a data structure that gets used. If the user brings the behavior what is the ecs? It's the data structure.
Of course it will be used somehow. I don't call a std::vector a "vector system" because someone uses it, but I guess people think using this data structure makes it a "system".
It's a data structure, except it doesn't describe how data is actually stored, only how its elements interact, so it's a data structure that doesn't actually structure data. If you are the kind of person that considers stuff like MVVM and Clean Architecture to be data structures, then I suppose it would be consistent. Most people don't.
Other ECS implementations might not, but Bevy does come with a system scheduler. You register systems (functions that operate over the components) and, through their parameters, Bevy's scheduler decides how to parallelize the registered systems while avoid data races.
Other ECS implementations might not, but Bevy does come with a system scheduler.
That's an ecs data structure and a system scheduler. If I make a vector and a system scheduler, vectors don't suddenly have system schedulers, they are two different things.
You register systems (functions that operate over the components)
ECS isn't a data structure tho, it's a pattern. You must be referring to the component storage. That's, at best, half the equation. You do realize the discussion is about the 50MB program, which uses both the component storage, the system scheduler and other features, right?
> That's just adding a function pointer to field
Just as much as creating a new process, through the IP/PC field in the TCB. Don't know why you focused on that particular point, but sure.
Every implementation out there is a data structure. You keep talking about things that use it and then lump them together. That's just you.
You do realize the discussion is about the 50MB program, which uses both the component storage, the system scheduler and other features, right?
No, the first person I replied to said that justified a 50MB program. A few other software components don't make any sense either. 50MB is not something you get to with 4 or 5 parts of a game engine. That's the stripped binary too, it was originally 700MB.
Don't know why you focused on that particular point, but sure.
You brought it up, I'm not even sure what point you are trying to make.
> Every implementation out there is a data structure.
Examples?
> 50MB is not something you get to with 4 or 5 parts of a game engine.
Depends on the engine's architecture, runtime, etc. Again, don't know if you are blaming the bloat on those components alone (it seems like you are), but you haven't established a direct link between said components and the bloat, thus, it's hard to properly reason about the tradeoffs given that we don't know how said bloat scales.
> That's the stripped binary too, it was originally 700MB.
Actually, no. Rust doesn't strip binaries on release by default. There's a reason there's a guide about minimizing Rust program sizes.
> You brought it up, I'm not even sure what point you were trying to make.
You are the one who nitpicked over "You register functions", ignoring the rest of the sentence.
> No, it depends on excessive dependencies that themselves have dependencies.
Not necessarily. Not every dependency will generate code. Furthermore, those dependencies of dependencies are rather small. If you're so certain that's the case, then provide an actual analysis over a case. Would be an interesting read.
> And that 50MB was the stripped version. What is not sinking in?
From the reddit post you linked:
> paholg: Rust debug binaries tend to be large. What's the size of you compile in release mode?
> talentedBlue: 49M. looks more reasonable
> CleanCut9: You can strip the release binary to get it even smaller if you want
What didn't sink in is the fact that you don't seem to have read the linked thread appropriately.
Compile times are my biggest struggle, too. I'm vibecoding Bevy with parallel agents, and the bottleneck is often compiling the changes on my 7950X, not getting Codex to write them.
As far as file sizes go, I'd be really interested in how a Rust compiler that didn't monomorphize so much would perform. Right now you have to modify the source code to write polymorphic generic functions, but it doesn't strictly have to be that way (at least as far as I can see).
I wouldn't use Bevy for a web only game either, especially while it's still single threaded on WASM.
Those of us unfamiliar with Bevy can deduce what it might be, but it would be really nice if your introduction included at least a link titled "Bevy game engine" which links to bevy.org.
Then your unfamiliar readers can first hop to bevy.org to see what it's all about.
> These guides are up to date with Bevy version 0.18
This is huge, thanks. Unfortunately many Bevy resources became stale (the Bevy cookbook was even abandoned, there was little interest in keeping it up to date and so there were many sections for, say, Bevy 0.12)
As someone who is actively working on the Bevy Book, the next engine release should include the first public release of the Bevy Book. And once it's out, then we'll be doing our best to keep it updated and expand it alongside the Bevy engine.
Great news, thanks. I have to say that several times I tried to invent something from scratch only to eventually find, reading the documentation/examples, that Bevy already has that part covered.
I now default to the examples, but a book would greatly help.
This site is excellent. I emailed the author to thank them after reading it cover to cover, and they replied and asked if anything was unclear or if there was anything I wanted to see explored more.
My problem with bevy isn't the basics, but the architecture. I always feel like I'm making wrong decisions on if something should be a component or a field, and how it interacts with other stuff in systems. I just feel like I'm making an unmaintainable mess, but I'm not sure how it could be improved.
I think ECS is a new enough architecture that the patterns are still very much folk lore.
I think a lot of the way I try and structure my Bevy apps comes down to trying to separate the rendering from my game logic. Its very easy to confuse the two responsibilities.
Coming from the web and Ruby I find the lack of automated testing and TDD to be foreign to me. So I've been trying to figure out patterns that make my games easier to test. Hoping to write about it soon.
> I think ECS is a new enough architecture that the patterns are still very much folk lore.
ECS is a pretty old idea, built on concepts that are even older. I was playing around with an ECS-like engine of my own in C over 10 years ago, based on blog posts and talks that are now 20-25 years old. Even the Wikipedia article for ECS can trace the origins back to the 1960s. (Though obviously it hasn't been applied to video games for quite that long.)
Nowadays I'd probably reach for Godot and Kotlin if I just wanted to build a game in an ergonomic language on a solid foundation. You could still apply ECS concepts there, as well.
Rust has testing in the standard library -- IMHO Bevy is far easier to test than most game engines because it's "just rust". You can test game logic by starting headless apps, proding the ECS, and making assertions on the results.
For acceptance tests I've dusted off cucumber (after ten years of not thinking about BDD), as I it works great with Bevy
> I always feel like I'm making wrong decisions on if something should be a component or a field... I just feel like I'm making an unmaintainable mess,
That is true for all game platforms, experience takes care of it, don't give up.
About compilation time concerns, it doesn't seem to be a problem with Bevy, there's a fast compile mode with very reasonable performance.
However, I didn't see any scripting, there are scripting options for rust, it would be good to have bindings for some rust-like scripting.
This has been on my list to kick off for a while. From previous times I looked at it, these tutorials are the only text based tutorials that are really kept up to date. Love it
Thank you. Not many free and in-depth resource for Bevy engine. Mostly are paid ones. I am surprised that you switch from Ruby to Rust.
Seems a different beast to me.
As a long time ruby enjoyer and now also rust enjoyer, the core syntax and systems of rust are very rubyesque in a lot of ways, you can tell that some of the core contributors liked the language.
yeah ruby API ideas and the _why poignant guide specifically, they were very influential in programming in general. a number of early rust devs came from ruby as well. all original authors of cargo worked on ruby's bundler earlier. etc
The claim is that Rust took espression-orientation from Ruby. That's unlikely - it is much more inspired by FP languages which are also expression oriented.
Ah, you're right, I definitely misread that the first time. I think the only thing that Rust probably was directly inspired by Ruby on was the syntax for closures (which is not exactly the same, but when the closure uses a block rather than returning an expression directly it's similar, and I vaguely recall seeing something about that being intentional).
I really want to like bevy but compile times are slow and the output binaries are huge.
I built a few games in WASM and was shocked to see many of the bevy variants larger than the Unity versions.
There’s definitely a market for rust game engines but it seems that no one’s hit the sweet spot yet.
I hear Rust being slow to compile is their biggest gripe, but really - look at what you’re gaining for the slowdown!
Bevy gives you a very nice ECS to model your app but compilation can be slower than hand crafted code, while not using it gives you tonnes more code and the complexities that come with it, just to compile faster?
I don’t know what you mean by, “just to compile faster.” Compiling fast is critical to game development. There’s no formula for fun so you have to iterate extensively.
I also don’t think that other solutions are “tonnes more code.” Any code will explode in size if poorly written. The same is true for bevy.
I swear I have only heard about ECS and people trying to show off how good the ECS is when it comes to Bevy, never about an actual game.
"There are more rust game engines than rust games" - Confucius
"The claim which is made without proof can be dismissed without proof" - Big Brain
What are some notable rust games?
https://en.wikipedia.org/wiki/Tiny_Glade
OK, even though it does not seem like that game was very notable, will give you that one game. Rust has at least ~5-6 game engines though, so you will have to come up with 4-5 more.
Here is ten games in bevy engine
https://youtu.be/50g3eSrSM6Q
Rust has like 2-3 game engines and a bunch of bindings.
OK, so I didn't say random games, though. I said notable ones. None of those are notable, and half of them aren't even released yet.
Bevy gives you a very nice ECS
That's a single data structure. People say binaries start at 50 MB for a hello world program and 700 MB for the debug binaries.
https://old.reddit.com/r/bevy/comments/16wcixk/cant_figure_o...
It's a single data structure that contains your entire game though? The whole point of the ECS is that literally everything uses the same data; it's like if you modeled every object in the world with one struct that has an optional field for every piece of data that could exist. I'm not saying that necessarily makes the tradeoff worthwhile, but calling it a "single data structure" is a bit reductive.
It's a single data structure that contains your entire game though?
Are you asking?
but calling it a "single data structure" is a bit reductive.
No it isn't. It's like a tiny database. Depending on how someone implements it, it could use arrays, hash maps and b-trees. There is no universe where this means a binary that does nothing should be 50 megabytes.
> It's like a tiny database.
No it isn't. It also handles system management and concurrency, basically the main loop of your application.
I also would be cautious of assigning the blame of the binary size onto the data structure on its own.
I would say yes it’s like a tiny database but as well as all the other things your added. And I think that’s a good thing, because it does this at the type level!
I’m actually seeing if I can build a parser using bevy_ecs just because the way their state machine works, it looks like it would be fun
system management
What does that mean?
concurrency
Some data structures and databases deal with concurrency.
In this case systems are the S of ECS and contain all your game logic, acting upon the entities and components (E and C).
By system management I assume they mean the APIs bevy offers for scheduling and sequencing systems and events so your game logic remains modularized while still running in the correct order.
It seems like you're calling an entire game engine "ECS". I'm not sure what the point is here, the whole question was what justifies having a 50 MB hello world binary. It doesn't matter what you put into a data structure, the data structure itself shouldn't make 50 MB binaries.
No, they aren't calling the entire game engine "ECS". Entity-Component-System is an architecture that Bevy is structured around.
As I have previously stated, I wouldn't blame the data structures used behind Bevy just yet, given Rust's tendency for making bloated binaries. What is taking the most space in this 50MB binary? How does it scale with the complexity of the application?
Even if you can put a function pointer into a data structure, that's still just a data structure.
I don't know where you are trying to go with this logic. You still haven't assured that the 50MB is actually related to data structures used behind by bevy, lest you are insunating that the data structures used by bevy are solely responsible for that size, which is not what the post claims.
How small is a hello world in C on Linux? The last time I checked a few years ago, it was either 9Mb or 13Mb (memory is fuzzy on this one but one of them was right).
Edit: wow I’m way off… it must have been the 90s when I checked this lol
C statically linked hello world binaries have never been 9MB or 13MB, they definitely weren't in the 90s. Also these are rust binaries.
https://github.com/MichalStrehovsky/sizegame
Yeah, testing here with GCC 13.3.0 led to 16K. Perhaps, when you made your test, the compiler was statically linking some libs, which would explain the massive increase in size.
You should probably read the whole thread. You jumped in half way through and got all mixed up.
I know the thread. Your point is about whether Bevy's "data structure" is worth 50MB. I pressing on the fact that you haven't shown what this 50MB actually are.
But, out of curiosity, do you also consider the Linux Kernel also a data structure?
I pressing on the fact that you haven't shown what this 50MB actually are.
To be clear you think an ECS implementation is 50 MB?
But, out of curiosity, do you also consider the Linux Kernel also a data structure?
Do you think a spreadsheet the holds function pointers is a kernel?
> To be clear you think an ECS implementation is 50MB?
No.
> Do you think a spreadsheet the[sic] holds a function pointer is a kernel?
Do you think an entire engine, including its system scheduler, is a spreadsheet? If so, shouldn't be hard to apply the same argument to any kernel. Of course, it all relies on your definitions and sense of reductionism.
I think you're conflating other big features of a game engine with a way to store data. If you look at other ecs implementations they are data structures, they don't do "system scheduling" (is that different from regular scheduling?)
First of, Bevy isn't just an ECS implementation. It's a game engine designed around ECS. While the ECS part is its core, Bevy also provides rendering, resource management, physics, etc. One of its other tasks, a rather important one too, is system scheduling: once you register systems, Bevy is responsible for dispatching them each frame, at the appropriate time, while also avoid data races over global resources and components.
First of, Bevy isn't just an ECS implementation.
No one thought that or said that so I don't know what point you're trying to make.
If you go to the comments I replied it was someone saying bevy compiles slow and has excessive bloated binaries. Someone else replied that you get so much, like ecs. Then I said that ecs specifically is just a data structure and has no reason to bloat binaries to be 50MB for an empty program that does nothing.
You're replying about things no one was discussing.
Your whole thread is about nitpicking the phrase "Bevy gives you a nice ECS". You are the one who asserted that "ecs specifically is just a data structure" (it isn't, by most definitions [1] [2], except yours). I supposed you were referring exclusively to a simple and basic component storage implementation (which is a data storage), where as OP was probably referring to the whole ergonomics of writing programs in it, alongside all the other features. It seems to me that you're the one who missed the point.
Then, you used this reductionism to question whether the 50MB binary is worth it. And that's ignoring the fact that there are ways to cut it if you wish, as mentioned in the reddit thread. And then there's the issue of whether it will actually matter for a full game.
[1] https://en.wikipedia.org/wiki/Entity_component_system
[2] https://github.com/SanderMertens/ecs-faq#what-is-ecs
Your link describes a data structure and then just says "systems that use it" which is implied. Of course it gets used. Seems tautological.
I will need citation on which link, and how it defines ECS as a data structure.
From [1]:
> Entity component system (ECS) is a software architectural pattern. An ECS consists of entities composed of data components, along with systems that operate on those components.
From [2]: > ECS ("Entity Component System") describes a design approach which promotes code reusability by separating data from behavior. Data is often stored in cache-friendly ways which benefits performance.
What you just described is a data structure that gets used. If the user brings the behavior what is the ecs? It's the data structure.
Of course it will be used somehow. I don't call a std::vector a "vector system" because someone uses it, but I guess people think using this data structure makes it a "system".
It's a data structure, except it doesn't describe how data is actually stored, only how its elements interact, so it's a data structure that doesn't actually structure data. If you are the kind of person that considers stuff like MVVM and Clean Architecture to be data structures, then I suppose it would be consistent. Most people don't.
Other ECS implementations might not, but Bevy does come with a system scheduler. You register systems (functions that operate over the components) and, through their parameters, Bevy's scheduler decides how to parallelize the registered systems while avoid data races.
Other ECS implementations might not, but Bevy does come with a system scheduler.
That's an ecs data structure and a system scheduler. If I make a vector and a system scheduler, vectors don't suddenly have system schedulers, they are two different things.
You register systems (functions that operate over the components)
That's just adding a function pointer to a field.
> That's an ecs data structure [...]
ECS isn't a data structure tho, it's a pattern. You must be referring to the component storage. That's, at best, half the equation. You do realize the discussion is about the 50MB program, which uses both the component storage, the system scheduler and other features, right?
> That's just adding a function pointer to field
Just as much as creating a new process, through the IP/PC field in the TCB. Don't know why you focused on that particular point, but sure.
ECS isn't a data structure tho, it's a pattern.
Every implementation out there is a data structure. You keep talking about things that use it and then lump them together. That's just you.
You do realize the discussion is about the 50MB program, which uses both the component storage, the system scheduler and other features, right?
No, the first person I replied to said that justified a 50MB program. A few other software components don't make any sense either. 50MB is not something you get to with 4 or 5 parts of a game engine. That's the stripped binary too, it was originally 700MB.
Don't know why you focused on that particular point, but sure.
You brought it up, I'm not even sure what point you are trying to make.
> Every implementation out there is a data structure.
Examples?
> 50MB is not something you get to with 4 or 5 parts of a game engine.
Depends on the engine's architecture, runtime, etc. Again, don't know if you are blaming the bloat on those components alone (it seems like you are), but you haven't established a direct link between said components and the bloat, thus, it's hard to properly reason about the tradeoffs given that we don't know how said bloat scales.
> That's the stripped binary too, it was originally 700MB.
Actually, no. Rust doesn't strip binaries on release by default. There's a reason there's a guide about minimizing Rust program sizes.
> You brought it up, I'm not even sure what point you were trying to make.
You are the one who nitpicked over "You register functions", ignoring the rest of the sentence.
Depends on the engine's architecture,
No, it depends on excessive dependencies that themselves have dependencies.
There's a reason there's a guide about minimizing Rust program sizes.
And 50 MB was the stripped version, what is not sinking in?
> No, it depends on excessive dependencies that themselves have dependencies.
Not necessarily. Not every dependency will generate code. Furthermore, those dependencies of dependencies are rather small. If you're so certain that's the case, then provide an actual analysis over a case. Would be an interesting read.
> And that 50MB was the stripped version. What is not sinking in?
From the reddit post you linked:
> paholg: Rust debug binaries tend to be large. What's the size of you compile in release mode? > talentedBlue: 49M. looks more reasonable > CleanCut9: You can strip the release binary to get it even smaller if you want
What didn't sink in is the fact that you don't seem to have read the linked thread appropriately.
Exactly this.
Compile times are my biggest struggle, too. I'm vibecoding Bevy with parallel agents, and the bottleneck is often compiling the changes on my 7950X, not getting Codex to write them.
As far as file sizes go, I'd be really interested in how a Rust compiler that didn't monomorphize so much would perform. Right now you have to modify the source code to write polymorphic generic functions, but it doesn't strictly have to be that way (at least as far as I can see).
I wouldn't use Bevy for a web only game either, especially while it's still single threaded on WASM.
Bevy website has some tips for improving compile times, have you tried them out?
Yes, absolutely. I did that before vibecoding too, as rapidly editing and testing is so crucial.
The way Bevy's internal state is so easily saved and loaded is convenient for this.
- since we are on the topic, i wanted to ask people here
- could someone kindly share some resources on c++ game development
- here is what i have
- https://gamedev.net/tutorials/
- https://shader-learning.com/
- https://learnopengl.com/
- https://shaderacademy.com/
- https://www.gabrielgambetta.com/client-server-game-architect...
- https://github.com/0xFA11/MultiplayerNetworkingResources
- just a headsup, i am looking for 3D game development without unreal, unity , godot or any of those engines
https://lazyfoo.net/
Here's a great one: https://pikuma.com/courses/cpp-2d-game-engine-development
Handmade Hero
Those of us unfamiliar with Bevy can deduce what it might be, but it would be really nice if your introduction included at least a link titled "Bevy game engine" which links to bevy.org.
Then your unfamiliar readers can first hop to bevy.org to see what it's all about.
Very much agreed and appreciated. I've added an explanation to the top of the homepage.
> These guides are up to date with Bevy version 0.18
This is huge, thanks. Unfortunately many Bevy resources became stale (the Bevy cookbook was even abandoned, there was little interest in keeping it up to date and so there were many sections for, say, Bevy 0.12)
There's also ongoing work on the (for now hidden) Bevy Book https://bevy.org/learn/book/intro/
Already seems like a great resource to me but it's still WIP.
As someone who is actively working on the Bevy Book, the next engine release should include the first public release of the Bevy Book. And once it's out, then we'll be doing our best to keep it updated and expand it alongside the Bevy engine.
This is great news and thank you for work.
Great news, thanks. I have to say that several times I tried to invent something from scratch only to eventually find, reading the documentation/examples, that Bevy already has that part covered.
I now default to the examples, but a book would greatly help.
This site is excellent. I emailed the author to thank them after reading it cover to cover, and they replied and asked if anything was unclear or if there was anything I wanted to see explored more.
Quite the dedication to a free resource!
My problem with bevy isn't the basics, but the architecture. I always feel like I'm making wrong decisions on if something should be a component or a field, and how it interacts with other stuff in systems. I just feel like I'm making an unmaintainable mess, but I'm not sure how it could be improved.
I think ECS is a new enough architecture that the patterns are still very much folk lore.
I think a lot of the way I try and structure my Bevy apps comes down to trying to separate the rendering from my game logic. Its very easy to confuse the two responsibilities.
Coming from the web and Ruby I find the lack of automated testing and TDD to be foreign to me. So I've been trying to figure out patterns that make my games easier to test. Hoping to write about it soon.
> I think ECS is a new enough architecture that the patterns are still very much folk lore.
ECS is a pretty old idea, built on concepts that are even older. I was playing around with an ECS-like engine of my own in C over 10 years ago, based on blog posts and talks that are now 20-25 years old. Even the Wikipedia article for ECS can trace the origins back to the 1960s. (Though obviously it hasn't been applied to video games for quite that long.)
Nowadays I'd probably reach for Godot and Kotlin if I just wanted to build a game in an ergonomic language on a solid foundation. You could still apply ECS concepts there, as well.
> lack of automated testing and TDD
Rust has testing in the standard library -- IMHO Bevy is far easier to test than most game engines because it's "just rust". You can test game logic by starting headless apps, proding the ECS, and making assertions on the results.
For acceptance tests I've dusted off cucumber (after ten years of not thinking about BDD), as I it works great with Bevy
> I always feel like I'm making wrong decisions on if something should be a component or a field... I just feel like I'm making an unmaintainable mess,
That is true for all game platforms, experience takes care of it, don't give up.
About compilation time concerns, it doesn't seem to be a problem with Bevy, there's a fast compile mode with very reasonable performance.
However, I didn't see any scripting, there are scripting options for rust, it would be good to have bindings for some rust-like scripting.
This has been on my list to kick off for a while. From previous times I looked at it, these tutorials are the only text based tutorials that are really kept up to date. Love it
Thank you. Not many free and in-depth resource for Bevy engine. Mostly are paid ones. I am surprised that you switch from Ruby to Rust. Seems a different beast to me.
As a long time ruby enjoyer and now also rust enjoyer, the core syntax and systems of rust are very rubyesque in a lot of ways, you can tell that some of the core contributors liked the language.
yeah ruby API ideas and the _why poignant guide specifically, they were very influential in programming in general. a number of early rust devs came from ruby as well. all original authors of cargo worked on ruby's bundler earlier. etc
Really? What do you think comes from Ruby? Rust mostly seems to be inspired by ML and C++.
Actually I just checked the "official" list and they only list the closure syntax which seems pretty minor:
https://doc.rust-lang.org/reference/influences.html
A significant portion of the prominent community members come from Ruby so I guess there must be something …
Iterator style, chaining, traits, blocks all feel very rubyesque, and expression syntax as well, plus the cargo toolchain is very bundler-informed.
Expression orientation
That's from functional programming.
I don't think anyone claimed that Ruby and Rust were the only two languages with those features, just that they're something they both have in common.
The claim is that Rust took espression-orientation from Ruby. That's unlikely - it is much more inspired by FP languages which are also expression oriented.
Ah, you're right, I definitely misread that the first time. I think the only thing that Rust probably was directly inspired by Ruby on was the syntax for closures (which is not exactly the same, but when the closure uses a block rather than returning an expression directly it's similar, and I vaguely recall seeing something about that being intentional).
> Mostly are paid ones.
can someone link to some of those paid resources?
I think Chris Biscardi has some paid resources that involve Bevy at https://www.rustadventure.dev/pricing they might be referring to.
He's also got plenty of free resources which I love to watch: https://www.youtube.com/@chrisbiscardi
To be fair, Chris is the guy for bevy. He's been making videos long enough to know how to use it properly
can you tell me what those paid ones are?
Thank you :)