Bevy 0.5: data oriented game engine built in Rust
bevyengine.org
bevyengine.org
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!)
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.
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" :)
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 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 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.
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.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)
Same goes for PR descriptions like for the ECS v2 PR [1]. That's more text than half of open source libraries have documentation.
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 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.
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.
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 ;)
With archetypes alone, I believe this would have been highly undesirable (causing the entity moving back and forth between archetype tables)
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.
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?
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.
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.
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.
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.
https://github.com/bevyengine/bevy-website/blob/master/conte...
For people (like me) who want to see what can be made with bevy, have a look here: https://github.com/bevyengine/awesome-bevy
Have there been serious attempts to use ECS outside of gamedev? The concepts are pretty interesting.
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...
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".
I'm sure somebody else can give a more precise definition
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.