Bevy 0.5: data oriented game engine built in Rust(bevyengine.org)
bevyengine.org
Bevy 0.5: data oriented game engine built in Rust
https://bevyengine.org/news/bevy-0-5/
67 comments
Contributor here: there's so much cool stuff in this release.
I was personally most involved in improving the docs, the reliable change detection work (you can now detect changes no matter when your system runs, even skipping arbitrary numbers of frames), and a great deal of the other ECS work. AMA if you have any questions or requests ;) I'm particularly curious about "I'd like to use Bevy but..." stories.
I was personally most involved in improving the docs, the reliable change detection work (you can now detect changes no matter when your system runs, even skipping arbitrary numbers of frames), and a great deal of the other ECS work. AMA if you have any questions or requests ;) I'm particularly curious about "I'd like to use Bevy but..." stories.
I really liked your (now abandonned) understanding-bevy book.
So I'm so glad you are involved in improving the docs!
Thank you for your contributions! I'm most excited about labeled run criteria and the other ECS improvements. For those not following along, the goal is to eventually implement statecharts [0], which are kind of a generalization of finite state machines that are more practical for specifying the behavior of complex systems. I think that's going to really put Bevy's ECS above most of the competition and push the field forward.
[0]: https://statecharts.github.io/
[0]: https://statecharts.github.io/
> I'm particularly curious about "I'd like to use Bevy but..." stories.
I am a game dev novice, but the concept I am wanting to develop requires mesh loading (fbx/dae), animation/skeleton/bone loading, and custom bone manipulation. Granted Bevy does seem to have the physics I need via the rapier plugin. I have been working with Godot to achieve my PoC, but would love to use Bevy instead. I admit to not keeping up with the current state of these features.
I am a game dev novice, but the concept I am wanting to develop requires mesh loading (fbx/dae), animation/skeleton/bone loading, and custom bone manipulation. Granted Bevy does seem to have the physics I need via the rapier plugin. I have been working with Godot to achieve my PoC, but would love to use Bevy instead. I admit to not keeping up with the current state of these features.
Thanks for chiming in :) Animation is a common request, and definitely still not-very-usable.
Thanks to the work of lassade, our resident animation expert, I expect we should have basic animation in place for 0.6. For skeletal animation in particular, they've been prototyping with a crate of their own [0] to hook into Bevy that seems like an excellent proof-of-concept.
0: https://github.com/lassade/bevy_spine
Thanks to the work of lassade, our resident animation expert, I expect we should have basic animation in place for 0.6. For skeletal animation in particular, they've been prototyping with a crate of their own [0] to hook into Bevy that seems like an excellent proof-of-concept.
0: https://github.com/lassade/bevy_spine
I've been using Godot for some small gamedev projects, but have been interested in Bevy because Rust is my primary language. The Bevy Book stil says that Godot should be picked for any big projects; is there a rough estimate of when Bevy would be at a point where you'd be confident recommending it for a Next Big Project™? I know timelines can be tough to nail down, but even something like "a very long time" or "a couple of years" would be helpful. Thanks for your work btw :)
Depends on your iteration speed, exact needs, and willingness to work on engine development.
Personally, I'm building my turn-based tactical RPG in it, which is absolutely a Big Project, but I'm not planning to release for a year or two, don't need complex 3D features and am devoting half of my effort to engine dev.
For single-player games that aren't very asset-heavy, I would say 3 months or so for UI to stabilize is a safe point to start work.
For games that have complex animation or sound needs, require networking or want to use a ready-to-use physics library, I'd estimate about 2 years from now.
If you're trying to build a game with very-little coding (and want something comparable to Unity or Godot), "a very long time" :)
Personally, I'm building my turn-based tactical RPG in it, which is absolutely a Big Project, but I'm not planning to release for a year or two, don't need complex 3D features and am devoting half of my effort to engine dev.
For single-player games that aren't very asset-heavy, I would say 3 months or so for UI to stabilize is a safe point to start work.
For games that have complex animation or sound needs, require networking or want to use a ready-to-use physics library, I'd estimate about 2 years from now.
If you're trying to build a game with very-little coding (and want something comparable to Unity or Godot), "a very long time" :)
Thank you for your clarification, this helps a lot, I think for now better to learn a engine like Godot, and waiting the Bevy-ish engines to mature!
Off-topic, but is your game open source? I'd love to see more examples of Bevy being used in the wild.
Source-available for now, we're still sorting out the exact licensing strategy.
The Bevy code itself isn't very impressive at all yet; most of the work at the moment is on improving the engine and solving some of the remaining design challenges.
We're currently blocked on "clone-able entities" (and ideally "indexes"), and I'm working on an RFC for each of those.
Source: https://github.com/leafwing-studios/fop-game Rules / design doc: https://rules.fontsofpower.com/#/
The Bevy code itself isn't very impressive at all yet; most of the work at the moment is on improving the engine and solving some of the remaining design challenges.
We're currently blocked on "clone-able entities" (and ideally "indexes"), and I'm working on an RFC for each of those.
Source: https://github.com/leafwing-studios/fop-game Rules / design doc: https://rules.fontsofpower.com/#/
I'm a novice game dev and I'm currently using Godot so i'd like to use Bevy but i'm waiting for an editor UI. What's the roadmap looking like for that?
Great question; it's hotly awaited by a lot of the community. Rough (and very unofficial) road-map is looking like:
1. 0.6 (June 2021): First-class ECS-integrated UI solution is architected and released. Asset management, animation and scenes are improved. Plugin architecture and data-driven workflows get a closer look.
2. 0.7 (August 2021): Editor MVP launches as a separate application built in Bevy, focusing on supplementing code-first Bevy workflows with things like property inspectors, scene management, system visualization and so on.
Once that's launched, I expect that we'll be working on making Bevy more usable through the editor for low-code users, although the goal is to ensure that pure-code (and pure Rust) Bevy games have feature parity with anything you can do in the editor.
Once that's launched, I expect that we'll be working on making Bevy more usable through the editor for low-code users, although the goal is to ensure that pure-code (and pure Rust) Bevy games have feature parity with anything you can do in the editor.
Bevy 0.4: data oriented game engine built in Rust - https://news.ycombinator.com/item?id=25480321 - Dec 2020 (23 comments)
Bevy 0.3: game engine built in Rust - https://news.ycombinator.com/item?id=24983956 - Nov 2020 (55 comments)
Bevy 0.2 - https://news.ycombinator.com/item?id=24530698 - Sept 2020 (43 comments)
Bevy: A Game Engine in Rust - https://news.ycombinator.com/item?id=24334307 - Aug 2020 (42 comments)
Bevy: A data-driven game engine and app framework built in Rust - https://news.ycombinator.com/item?id=24123283 - Aug 2020 (103 comments)
Bevy 0.3: game engine built in Rust - https://news.ycombinator.com/item?id=24983956 - Nov 2020 (55 comments)
Bevy 0.2 - https://news.ycombinator.com/item?id=24530698 - Sept 2020 (43 comments)
Bevy: A Game Engine in Rust - https://news.ycombinator.com/item?id=24334307 - Aug 2020 (42 comments)
Bevy: A data-driven game engine and app framework built in Rust - https://news.ycombinator.com/item?id=24123283 - Aug 2020 (103 comments)
Bevy: A Game engine built in Rust - https://news.ycombinator.com/item?id=26131350 - February 2021 (117 comments)
The activity on this story seems to have triggered the flamewar protection mechanism - any chance of vouching for it to get it back on the front page?
Lead Bevy developer here. Feel free to ask me anything!
What have the biggest challenges been?
Kudos! What an impressive collection of features and display of substantial development in almost all areas of the framework!
What's the current status of OpenGl Support? Any progress there? It would be really "cool" and inspiring to be able to develop on older yet otherwise good-enough hardware... thinking about all those very young future devs stuck with all that otherwise good-enough hardware here ;)
What's the current status of OpenGl Support? Any progress there? It would be really "cool" and inspiring to be able to develop on older yet otherwise good-enough hardware... thinking about all those very young future devs stuck with all that otherwise good-enough hardware here ;)
Please share what that hardware is. On Linux, Vulkan support starts at Intel IvyBridge, which is 8 years old now. Do people develop games on older computers these days? On other OSes, we have D3D12/D3D11 and Metal support.
We let wgpu https://github.com/gfx-rs/wgpu-rs handle our graphics backend abstraction, so our OpenGL support will come whenever they implement and release it. Currently, it seems to be a WIP.
Has basic 2D drawing (lines, rectangle, bezier curve etc) added yet? I remember it was in the plans in the very beginning.
No, but the https://github.com/Nilirad/bevy_prototype_lyon crate does a very nice job here :)
Officially, not yet, but there is a good community-maintained plugin: `bevy_prototype_lyon`.
Is it currently possible to use Bevy with given MTKView on iOS?
We have already an app with thousands lines of code and we need to render a game like experience on a just single page. We can achieve this with SpriteKit or SceneKit but we need something on android as well. So we are investigating a cross-platform tool.
The given iOS example on Github repository creates the window itself but it not possible for us.
edit: It looks like bevy uses winit for windowing and it doesn't support this. So winit is the blocker here.
We have already an app with thousands lines of code and we need to render a game like experience on a just single page. We can achieve this with SpriteKit or SceneKit but we need something on android as well. So we are investigating a cross-platform tool.
The given iOS example on Github repository creates the window itself but it not possible for us.
edit: It looks like bevy uses winit for windowing and it doesn't support this. So winit is the blocker here.
Bevy is modular, in the sense that you can remove higher-level parts/layers if you don't want to use them.
For example, you could use only the Bevy ECS if you didn't care about the rest.
You could replace `bevy_winit` (window creation using the winit library) with your own alternative.
For example, you could use only the Bevy ECS if you didn't care about the rest.
You could replace `bevy_winit` (window creation using the winit library) with your own alternative.
I'd just like to mention that the release notes are one of the best I've read.
Same goes for PR descriptions like for the ECS v2 PR [1]. That's more text than half of open source libraries have documentation.
[1] https://github.com/bevyengine/bevy/pull/1525
Same goes for PR descriptions like for the ECS v2 PR [1]. That's more text than half of open source libraries have documentation.
[1] https://github.com/bevyengine/bevy/pull/1525
Is it a good idea do you think to use Bevy for a game yet?
I don't expect a concrete promise, but is to reasonably bug free, and is it likely to be "not too hard" to upgrade to new versions in future? Or should I wait?
I don't expect a concrete promise, but is to reasonably bug free, and is it likely to be "not too hard" to upgrade to new versions in future? Or should I wait?
Bevy has no stability guarantees. APIs will be broken.
However, that said, many of us are already building "real games" with Bevy. I've been using bevy almost since day-1, and none of the updates have been particularly difficult/painful. The changes have always been easy to adapt to, especially with the Rust compiler helpfully pointing out everything you need to fix ;).
In terms of features for building "real games", bevy is still lacking in many areas:
- UI is very primitive (this is the next focus area to be worked on)
- animation (already in progress)
- audio (community-made plugins are available)
- advanced rendering features and performance optimizations (also already being worked on)
- there is no editor yet
Given the super active development pace of Bevy, many of these areas will greatly improve soon.
If you want to make a content-focused game with lots of assets and requiring a level/scene editor, Bevy is not ready yet. However, if your game is more code/programming/logic heavy, I definitely recommend that you try Bevy already now. The programming experience is awesome, the ECS ergonomics are really good. It's really easy to code game logic.
However, that said, many of us are already building "real games" with Bevy. I've been using bevy almost since day-1, and none of the updates have been particularly difficult/painful. The changes have always been easy to adapt to, especially with the Rust compiler helpfully pointing out everything you need to fix ;).
In terms of features for building "real games", bevy is still lacking in many areas:
- UI is very primitive (this is the next focus area to be worked on)
- animation (already in progress)
- audio (community-made plugins are available)
- advanced rendering features and performance optimizations (also already being worked on)
- there is no editor yet
Given the super active development pace of Bevy, many of these areas will greatly improve soon.
If you want to make a content-focused game with lots of assets and requiring a level/scene editor, Bevy is not ready yet. However, if your game is more code/programming/logic heavy, I definitely recommend that you try Bevy already now. The programming experience is awesome, the ECS ergonomics are really good. It's really easy to code game logic.
Depends on how quickly you're moving and how much polish you want :) Great for game jams and prototypes, not there yet for published games.
Reasonably bug free, yes. Not too hard to upgrade, yes. Are critical features missing or inadequate (audio, animations, networking, UI...), also yes ;)
But, just like making a game engine, there are a huge number of parts to making your game. If it's a weekend project, you can patch it up with 3rd party integrations and focus on the parts that are currently great.
Reasonably bug free, yes. Not too hard to upgrade, yes. Are critical features missing or inadequate (audio, animations, networking, UI...), also yes ;)
But, just like making a game engine, there are a huge number of parts to making your game. If it's a weekend project, you can patch it up with 3rd party integrations and focus on the parts that are currently great.
With the implementation of Change Detection + Sparse sets, does that mean that using components to handle entity state (e.g. flags like is_hungry) is recommended? And then a system querying for Changed<is_hungry>
With archetypes alone, I believe this would have been highly undesirable (causing the entity moving back and forth between archetype tables)
With archetypes alone, I believe this would have been highly undesirable (causing the entity moving back and forth between archetype tables)
Yep, marker components is a much more feasible pattern now, and I tend to prefer tiny, granular components when writing Bevy apps as a result.
The only drawback to this design is that you can't add / remove components instantly[0], and instead need to wait for the next "hard sync point" at the end of the stage.
0: https://github.com/bevyengine/bevy/issues/1613
The only drawback to this design is that you can't add / remove components instantly[0], and instead need to wait for the next "hard sync point" at the end of the stage.
0: https://github.com/bevyengine/bevy/issues/1613
Yes! Marker components, as we like to call them are a common and encouraged pattern :)
You mention:
The solution is to build a "graph" of archetypes to cache these results... If ComponentIds are densely packed, you can use sparse sets to cheaply jump between archetypes.
We ended up cutting some of the technical ECS details from the blog post to make it more easily-digestible. The description in this pull request is effectively a stand-alone blog post describing things like the Archetype Graph: https://github.com/bevyengine/bevy/pull/1525
I've been anticipating this, glad it's released! I started using Bevy a few months ago on version 0.4 and have had a really great experience learning the tool and getting help from the community. The documentation isn't as full as I'd like, but there's lots of examples and people available to answer questions. This post is just to encourage anyone interested to go ahead and try it out.
Check out https://bevy-cheatbook.github.io/ ! It's a WIP, but it covers all the basics very well.
It's easy to market what Bevy is when it's called a 'Game Engine' but I hope this platform can really become the next Omniverse-type collaborative 3D environment for the Architecture/Engineering/Construction market. Right now, there isn't a great place to park BIM files.
Yeah, there's been a ton of interest in using Bevy for non-game applications.
We have at least two projects doing CAD with it, several trying to use it for machine learning, exotic high-performance database-like applications, and some interest in using it as an ergonomic fully cross-platform GUI builder once our UI solution is built out.
We have at least two projects doing CAD with it, several trying to use it for machine learning, exotic high-performance database-like applications, and some interest in using it as an ergonomic fully cross-platform GUI builder once our UI solution is built out.
Can you link the CAD projects?
One of them is closed-source, with a paid dev team. CAD for mining I believe :)
The other is aevyrie's[0] pet project, with an eye towards eventual open-source commercialization. Right now, he's been working on building out the fundamentals needed, with a fantastic set of plugins for frustum culling, picking, bounding boxes and so on that will be needed.
He's @aevyrie on the Discord[1] if you'd like to ask him more questions.
0: https://github.com/aevyrie 1: https://discord.gg/bevy
The other is aevyrie's[0] pet project, with an eye towards eventual open-source commercialization. Right now, he's been working on building out the fundamentals needed, with a fantastic set of plugins for frustum culling, picking, bounding boxes and so on that will be needed.
He's @aevyrie on the Discord[1] if you'd like to ask him more questions.
0: https://github.com/aevyrie 1: https://discord.gg/bevy
If you can't get to the bevyengine.org web site, you can view the release announcement in the Bevy projects' web site Github repo:
https://github.com/bevyengine/bevy-website/blob/master/conte...
https://github.com/bevyengine/bevy-website/blob/master/conte...
[deleted]
Congrats!
For people (like me) who want to see what can be made with bevy, have a look here: https://github.com/bevyengine/awesome-bevy
For people (like me) who want to see what can be made with bevy, have a look here: https://github.com/bevyengine/awesome-bevy
Huge release. Glad to see this engine is still making progress.
Their ECS implementation sounds like a full-fledged in-memory DB.
Have there been serious attempts to use ECS outside of gamedev? The concepts are pretty interesting.
Have there been serious attempts to use ECS outside of gamedev? The concepts are pretty interesting.
That was the eye opener to me to understanding ECS and how to apply it, that Entities are just Primary Keys and Components are Tables in a database, just in-memory and with native types. Systems are just processing stages in attaching a feedback loop to the database
You're not alone: the Bevy community's been exploring this too, both on the application side and the ECS-innovation side. The query caching is a neat trick that learns directly from DB's.
Some of our most anticipated planned ECS features include secondary indexes (for things like looking up all entities in a particular cell) and relations (components that also point to another entity, inspired by FLECS[0]).
0: https://ajmmertens.medium.com/flecs-v2-3-and-v2-2-is-out-893...
Some of our most anticipated planned ECS features include secondary indexes (for things like looking up all entities in a particular cell) and relations (components that also point to another entity, inspired by FLECS[0]).
0: https://ajmmertens.medium.com/flecs-v2-3-and-v2-2-is-out-893...
What does it mean for a game engine to be data oriented or data-driven?
It's in contrast to Object-Oriented Programming. In OOP, you define classes of objects, with behaviors/functionality attached to them.
In Bevy, the focus is on the data. The ECS is like a big table (if you are not familiar, you can think of it by analogy with a database or spreadsheet). It stores all your data. Components are like the columns of the table, and entities are like rows.
You then write functionality separately. You can query the ECS to get the data you need. Your logic is not attached to any particular "object instance" or "object type".
In Bevy, the focus is on the data. The ECS is like a big table (if you are not familiar, you can think of it by analogy with a database or spreadsheet). It stores all your data. Components are like the columns of the table, and entities are like rows.
You then write functionality separately. You can query the ECS to get the data you need. Your logic is not attached to any particular "object instance" or "object type".
Broadly it means there's an emphasis on creating your content declaratively, often in a config file format (i.e., not in code). Saying "there's an entity X, it has these behaviors, it has these properties" in XML or JSON or whatever else. And then actual code is written separately, to handle specific logic that uses those declarative properties.
I'm sure somebody else can give a more precise definition
I'm sure somebody else can give a more precise definition
I think what you describe is "data-driven". This engine is "data-oriented", which is a different thing.
I personally consider us to be "both" (and we've ping-ponged back and forth on the right term to use in our taglines). Our app model is "data driven" in that we encourage users to drive logic off of raw data whenever possible and provide tools to respond to data changes. We are also "data oriented". We spend a lot of time optimizing our ECS data structures to maximize cache efficiency. We are _also_ "data driven" in that we try to use hard numbers to motivate design decisions whenever possible (although i consider that to be a secondary descriptor of the project).
Are there any benchmarks of Bevy ECS v2?
There are some in the blog post, with more details in the corresponding PR: https://github.com/bevyengine/bevy/pull/1525
Ctrl+F for "Benchmarks" to find the right section :) Eventually it would be nice to update the cross-engine ecs_bench_suite fully to reflect the changes.
Ctrl+F for "Benchmarks" to find the right section :) Eventually it would be nice to update the cross-engine ecs_bench_suite fully to reflect the changes.
adamnemecek(2)
I did a major overhaul of the book for the new 0.5 release, and it's better than ever! Many pages were expanded or rewritten, new content added, and community feedback addressed. This is now one of the most detailed learning resources for Bevy.
Enjoy, and have fun making things with Bevy!
(the book is a continuous work in progress, even more content and improvements coming soon!)