For anyone interested in learning / trying out Bevy, have a look at The Unofficial Bevy Cheatbook (i'm the author): https://bevy-cheatbook.github.io.
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!)
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.
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.
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" :)
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.
> 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.
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.
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.
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.
I couldn't quite figure out from the description how the edges are actually stored and I was curious why having the ComponentIds densely packed helps. I'd love to hear more about how the graph is represented. :)
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
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.
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 ;)
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.
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.
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)
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.
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?
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.
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.
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.
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.
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.
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]).
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".
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 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).
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.
As a Bevy contributor, I can say that rg3d is much more mature and feature-complete than we are right now. They're substantially ahead on animations, UI, sound and rendering.
That said, the engine isn't ECS-based (they use a scene graph instead), the community is much smaller, and the engine as a whole seem to be much more narrowly focused on a specific type of 3D game, exemplified by the shooter example.
Alright, well if you ever release ngrid I'm sure you won't mind if I post about alternatives right?
Maybe include some links to some competitors, and an invitation to their discords. Also I'll be sure to not mention your project at all in my post. Hope that's ok.
I’ll release it soon. I can tell you can’t wait for it.
Also the scenario you describe is a different thing since one is commercial and one is open source. But I wouldn’t be particularly upset about you mentioning your product.
Also I’m not going to mention alternatives but I wouldn’t be butthurt if they post it themselves. Is that a hard concept?
The name-dropping/link-dropping with an extra discord link that will likely expire long before everything else is tasteless.
A tasteful mention would look like this:
> If you're looking for a scene graph based engine instead of an ECS based engine, checkout $PROJECT_NAME at $PROJECT_LINK and here's an example $EXAMPLE_LINK
I can't vouch for the accuracy of the statement, but it clearly lays out the primary difference in value proposition, and 2-3 distinctions in value proposition would be good.
The goal should be to help people find what they are looking for, not spam.
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!)