Bevy Engine – Addressing the elephant in the room

A few days ago I just posted this link internally. I, like everyone else, needed a few days to properly review Bevy and get a better feel for what it brings to the table.

To put it simply, Bevy is essentially a Amethyst Engine 2.0. That can sound intimidating since it’s a separate project under different leadership, but I’m convinced this will turn out to be a Good Thing for the entire Rust gamedev community, including the Amethyst project.


I’m having an ongoing conversation with Carter, the author of Bevy, about how our two projects can come closer together, and possibly even operate as one. There is actually very strong precedent for this:

There would be no Bevy without Amethyst Engine

Carter acknowledges this several times in his writing. Bevy is the result of Carter spending copious amounts of time learning about Amethyst Engine in any way possible, including the many design discussions we’ve had on this forum.

Bevy’s accomplishment is your accomplishment too. :clap:

Bevy’s strengths

Bevy is not yet at feature parity with Amethyst Engine, but due to its cohesive design it is on track to catch up before long. This cohesion comes not from Carter being a better designer (though he’s certainly a good one!); it mostly comes down to fortuitous timing & circumstance.

Full-time dev with vision

Bevy’s super power is the simple fact that Carter can afford to be working on it full-time at his own expense. This has enabled him to do the rewrites we always wanted to do as we learned valuable lessons from our experimentation, because he had the bandwidth and linear focus to implement major changes without disrupting the work of others.

Top-down design

Now that Bevy is public it will face a lot of the same organizational challenges we’ve tackled already, but Bevy has a fundamentally different approach to how all major architectural decisions are made: Carter makes the final call on all major architectural changes.

This is often called the BDFL model: “Benevolent Dictator For Life”. It’s common knowledge now that this model is best suited for early-stage development when the project’s vision can be most effectively defined by a single individual with a complete overview. Later on, once that vision has been absorbed by other major collaborators and the project is so big that no single person can know all parts better than everyone else, the time comes to transition into a more democratic governance model.

Had @ebkalderon been in a position to do the same thing, we would have probably followed this model as well.

Mature rendering pipeline

wgpu didn’t even exist when Amethyst first came into being. Now it is mature enough to build on top of, and that is exactly what Bevy has done. And it’s been done in a way that doesn’t exclude other renderers from being plugged in.

We do not currently have any active developer working on our rendering pipeline. Whatever plans we might have to improve upon what we’ve got is a mute point so long as there’s no one ready to do the work.

Amethyst’s strengths


We’ve accomplished something rather extraordinary with the community of game developers we have assembled around a common cause. We’ve all been pointing in roughly the same direction. All Bevy had to do was say “that specific mountain top :mountain: let’s all go together there first”.


We’re sitting on a lot of institutional knowledge about how to best govern a project of our size. We have both a formal (a registered non-profit) as well as cultural foundation that can be of great utility for the likes of Bevy.

And frankly it’s often easier to understand such organically grown structures once you’re offering them up for the benefit of others, rather than trying to make sense of them from within.


We’ve dealt more with CI challenges than any mortal should ever have to endure. The most recent iteration using GitHub Actions is a huge accomplishment. What we’ve learned and consequently put together here should be very applicable to other Rust gamedev projects.

Libraries, docs, games…

There’s a whole bunch of other things I could pull in here but I need to finish this post. I might edit in some more later. Feel free to make your own remarks!


Atelier Assets

@kabergstrom and @aclysma are investigating how atelier-assets could be incorporated into Bevy. That certainly does not mean abandoning the work that’s also happening with Legion on that end, which is much further along.

What’s exciting here is that if atelier-assets becomes a dependency of Bevy that gives us some major common ground that ties us closer together.


Bevy ECS is a fork of hecs which in turn is a trimmed down version of Legion. Bevy’s additions brings its ECS back full circle to something quite similar to the newest Legion v0.3. But there’s still enough divergence between the two that pursuing a merger at this time doesn’t really make sense.

I see it this way: Bevy ECS and Legion will explore the same fundamental ECS design (archetypes) from two different vantage points:

Bevy ECS = In-engine
Legion = Independent

Either they’ll gradually converge to a point where one is subsumed by the other…
They’ll keep diverging, because it turns out both approaches have equal merit thanks to the novelty inherited by their unique vantage points.

Legion is definitely not going anywhere. It is guaranteed a following of its own due to its adoption in projects like the PragProg book spin-off of Roguelike Tutorial which comes out at the end of this year.


Bevy is pursuing a Godot-style approach to its Editor UI, which is to develop its in-game UI and Editor UI as one unified project. There are pros and cons to this approach which we will not discuss here.

What’s important to notice here is that the approach @mralve and the Amethyst Editor team is taking with their web-tech approach is in no way incompatible with what Bevy is doing. It’s a novel enough alternative path that is well worth exploring on its own merits. The stacks of the two editors are so different that they are very unlikely to be competing for oxygen.

One thing they might have in common is the overall UI/UX design. Pursuing a collaborative effort here definitely seems worthwhile.

Path forward for Amethyst

I am proposing that we double down on our core strengths, and find ways to collaborate with Bevy wherever possible. Our two projects have a whole lot to offer each other. And it would already be false to speak of Amethyst and Bevy as two entirely separate entities since we already have a lot of people, code & goals in common.

Coming up next

We’ve got a v0.15.1 release very close to being done.

The transition to Legion and a v0.16 release continues as planned for now.

What comes after that is less certain. I think the roadmap that’s being drafted will need to pivot from “What’s next for Amethyst” to “What will Amethyst and Bevy collaborate on”.

Got something to say? Reply below, or send me a DM on this forum or on Discord: @erlend_sh#4477

Be sure to read @cart’s reply below:


Hey @erlend_sh, thanks for the breakdown! :slight_smile:

I think you’ve hit it about right. :+1: I 'm really excited to see where this goes and how these communities will collaborate and improve each-other. :tada:


Hey :wave:

So first off, I’m new here. I have zero experience building things with Amethyst, very little experience making games, and very little experience using Rust. My words hold very little weight in this context.

I was wondering about what Carter wrote in this blog post:

None of the engines on the market quite line up with what I’m looking for. And the changes required to make them meet my requirements are either massive in scope, impossible (closed source), or unwelcome (the things I want aren’t what the developers or customers want). On top of that, making new game engines is fun!

When I read this, I made the assumption – perhaps incorrectly – that “the things I want aren’t what the developers or customers want” was referring to Amethyst (although not exclusively). If that is the case, bearing in mind I can’t speak on behalf of anyone else, it might be helpful to discuss what are perhaps some of the differences in philosophy between the two projects (the UNIX philosophy comes to mind as one example).

1 Like

Re governance, I think the most blocking component is at the project level. We don’t have anyone who is taking the role of managing direction, and I’m realizing this is a fundamental problem with my governance/organization models proposed recently.

I don’t mean to suggest this haphazardly, but given the disarray we’re trying to climb out of…a benevolent dictator would hasten the process. Maybe someone could, until our rhythm is more steady, take that role? We could have a fixed term, perhaps 6-12 months.


@erlend_sh Wow, what a fantastic post! Thank you for this. This kind of inspiring and informative post is extremely valuable for holding the community together and getting us on the same page. I feel more confident in Amethyst as a community and a project after reading this. I recommend turning this into a blog post for the web page.

I am curious to see where we go with Amethyst and Bevy. I am pleased that we are taking a collaborative approach to Bevy rather than an adversarial one.

:heart: I’m a huge believer in optimizing the development cycle. A huge thank you to everyone who has pitched in and helped me with CI, especially @Blisto.

As soon as I’m done assisting @mralve with the 0.15.1 release, I’m going to work on another round of CI improvements. I would love to collaborate with anyone who is interested (and not involved in the Legion port–because that is more urgent)!


Could there be an area of opportunity where Bevy and Amethyst could both standardize on? For example, perhaps there are engine features that both Amethyst and Bevy could streamline to a single standard that would make the transition for using either engine easier on game developers?

I have no doubt this could be a huge technical undertaking and would require a lot of patience on both ends, but it could give Amethyst and Bevy the opportunity to influence each other’s projects in a way that is beneficial for their users (i.e: game developers).

Yeah, I’m looking forward to having Carter chime in on this within a day or two. I don’t actually know what is being referred to here, as to my knowledge there was never any communication between us (Amethyst leadership) and Carter about this until 5 days ago when Bevy went public.

I would have preferred to start this conversation a lot earlier, but I totally understand Carter’s need to operate completely under the radar in order to stay focused for all this time.

Yep! The atelier-assets case is an example of that.


As Erlend said, Atelier Assets is such an example, but for anything core, that would be very limiting on both teams. Critical peripherals could certainly be discussed, like using mint. Maybe we could have a cross-engine translation abstraction, but it might end up with completely separate code per engine to account for ECS-specific optimizations.

Overall, it’s something that can’t be committed to in general, but there’s certainly room for investigating individual dependencies.


First I want to express in my own words how much the Amethyst project has contributed to Bevy’s success. I’ve been a passive member of the Amethyst community for years, basically since its inception. I’m very familiar with the code (and how it evolved), I’ve read the forum posts, I’ve read the docs, I’ve built apps, and I’ve championed Amethyst to my dev circle for years. I actually built a Rust game engine in the pre-Amethyst world and I can (maybe uniquely) attest to the fact that it was an entirely different experience.

I think its only natural for you all to then ask: If you knew the Amethyst codebase so well, and you loved the Amethyst project, why did you build Bevy instead of helping shape Amethyst into what you want it to be?

I’m going to answer this question, but please note that I’m not writing this to be combative and I would honestly prefer not to answer it at all. I have in fact worked very hard to not directly compare Bevy to Amethyst in any public forums up until this point (despite having been asked countless times) because I think this situation is steeped in nuance and I don’t really think its my place to represent other people’s projects.

However if we’re going to have honest technical collaboration, I think you all deserve honest technical answers so you understand my motivation and goals.

Compile Times

As you may have noticed in the Bevy blog post, productivity comes first for me. I spend a significant portion of my life making games and it’s a very iterative process. Amethyst’s compile times did not meet my bar for productivity. I make hundreds of changes a day and I can’t afford to wait 30 seconds for each one. I put in some work to improve this in Amethyst and did get some decent results. You may recognize me from the Better Compile Times Amethyst forum post. But it became clear to me that compile times were a problem that ran deep: a large number of dependencies, render code is generic all the way up to app setup, prefabs are expensive. Scripting was the proposed solution, but progress has been slow on that front and I still see that as a bit of a band-aid fix to a larger underlying issue. Especially if you want to script with rust code that calls in to Amethyst libs, which I would personally want.


Rendy is an extremely capable library, but I personally found it complicated. Combine that with a lack of active maintenance and the compile time issue above and I’m already biased toward alternative solutions. But wgpu surfaced, provided a simple standardized api, nice compile times, and had direct support from Kvark and a community of people. Adopting wgpu seemed like the right call to me.

Ergonomics / Clarity

There are a number of Amethyst apis that have more generics, macros, abstraction, lifetimes, and general cognitive load than I would prefer. Specs systems and components, shred, render logic, UI widget declarations, states, and prefabs come to mind.

I think the recent Legion port, atelier-assets, and the experimental scene/editor work will improve ergonomics in a lot of these areas, but when I started Bevy the future and timelines of these projects were very unclear to me.

Additionally, the simplification and improved ergonomics of Legion are relatively new occurrences that weren’t there when I started Bevy. I also like to think I did my part to encourage a simplified system syntax for legion. For most of its lifetime, Bevy actually used a legion fork (with system functions) instead of a hecs fork!


Projects like Godot and webrender have shown that game engines and UI frameworks can have a lot in common. There have been a number of successful Godot UI projects: the Godot editor, Rpg in a Box, 3d paint programs, and sprite tools, just to name a few. Webrender uses game-like rendering techniques to draw websites. Additionally there is a UI framework gap in the rust ecosystem right now. Given these things, the potential for code sharing, a full rust stack, and the additional value that dogfooding has for a project, I think it makes a lot of sense for a Rust game engine to build its editor in the engine.

In 2018 when Amethyst’s editor stack was being selected, I voiced these opinions in the Amethyst discord. But for other perfectly valid reasons a web stack was chosen. This is totally fine, it just isn’t my preference.


I want to write my engines and my games in Rust. I think Rust compiles fast enough, is expressive enough, and performs well enough to make it an extremely compelling gamedev language, even when compared with “high level” scripting languages. This will likely be an extremely divisive opinion, but I think adding official support for multiple languages to an engine is a mistake. Unity and Unreal succeed both because of their technical merits and because they have a rich ecosystem of tutorials, logic, and assets that everyone can use. I think making it easy for engine users to build content in whatever language they want is actually an anti feature, because it results in lowest-common-denominator apis (C ABI) and a fractured ecosystem.

(As an aside: I dont intend to stop people from making 3rd party scripting plugins or extending Bevy to make that possible, but I currently have no intention of endorsing those plugins officially. And I won’t compromise Bevy’s rust APIs or overall maintainability for scripting.)

Making a call

The work required to bring Amethyst in-line with my priorities would have been significant. I found myself with the inclination, ability, and perspective to build a proof of concept of my “ideal” engine in a relatively short period of time. Within a few months I had proven to myself that the path I was on worked for me. Within six months, I was ready to see what the world thought. The initial response has been overwhelmingly positive, but I think the jury is still out on many of the decisions I made. Only time and more eyes on the project will be able to tell us what is good and what needs rethinking.

And just to reiterate @erlend_sh’s points, the approach I used in Bevy is a direct result of the Rust gamedev ecosystem’s work up until this point. I didn’t build Bevy in a vacuum. I read your code and learned from it. I took dependencies on libraries that you built (or contributed to). It was an iterative improvement built on the shoulders of giants, and you all are the giants. The stack I chose and the techniques I used largely didn’t exist for most of Amethyst’s lifetime. I’m sure many of you would have made the same technical decisions I did if you were in my shoes.

To answer @stefee’s question, the only categories in my blog post that I personally felt Amethyst fell into were “large number of changes required” (see above points) and “things I want aren’t what the developers want” (and this really only applies to the Editor stack and official scripting support, which are admittedly “small” gripes in the grand scheme of things). The point in question was largely intended for other engines.

As @erlend_sh called out, I don’t think this post is the right place to debate any of the topics above. If you feel the need, just start a new discussion in any of the Amethyst or Bevy communities and pull me in.

Bevy’s Next Steps

Collaboration with Amethyst

Collaboration with the Amethyst team is a high priority for me, where collaboration makes sense. Here are some of my thoughts:

  • Atelier Assets: The atelier-assets project does almost everything I want from an asset system, so it probably doesn’t make sense to re-invent the wheel here. There were a few aspects (ex: the rpc system) that I wasn’t initially super sold on, but they probably arent blockers. Atelier assets in general looks very solid and is probably the clearest collaboration area. I do still need to do a hands-on review before committing to direct integration. And as my bandwidth is currently very limited, so I can’t promise it will happen immediately.
  • Legion: Legion is getting simpler and more ergonomic every day. I don’t want Bevy to get too distracted by a major ECS refactor, but there might also be a point where it no longer makes sense to maintain two ECS frameworks when our goals are so similar. However when it comes to ergonomics and compile times, I’m not willing to make many concessions.
  • Cross Pollination: The Amethyst team has a lot of brain power. Some of you have industry experience and many of you have been exploring the rust gamedev space for years. A number of Amethyst developers have already started great conversations on the Bevy side and have convinced me to take directions I wouldn’t have even considered without their help. I really hope this pattern continues. I’d love for the “cross pollination of talent” to continue across both projects.
  • Editor: We are on different paths from a stack perspective, but we should absolutely share whatever lessons we learn as we build the editors. At the end of the day, UX is the most important thing.
  • Compatibility: I don’t personally think an “Amethyst/Bevy engine compatibility layer” is worth the complexity cost. It’s an interesting thought, but it seems like a great way to get bogged down in complexity and design discussions. It would also introduce additional friction to trying out new designs, when there is already more than enough friction.
  • Scalability: Bevy had massive success the day I open sourced it. I did not anticipate to have a community of this size on day one and was wholly unprepared from a process perspective. The Amethyst organization has been operating at a large scale for years, so I would love to learn from their experiences here.

Collaboration Elsewhere

I want Bevy to be a good player in the Rust ecosystem. We should be building and using common, reusable foundations and not re-inventing the wheel or over-extending the Bevy project’s reach. Folks from a number of prominent Rust projects have reached out to me to discuss collaboration and I intend to take those talks very seriously. I will go into these discussions with a willingness to compromise in the interest of the larger ecosystem.

However I have no intention to compromise Bevy’s core principals during this process, so sometimes I might need to say no.

Bevy’s “Experimentation” Phase

Most of the good parts of Bevy’s design were the result of experimentation and the freedom to do so. In the immediate short term, I don’t want Bevy to get bogged down in RFC processes or org charts. Instead I will use the following process to scale:

  1. I plan on being a BDFALAICMI (Benevolent Dictator For As Long As I Can Manage It). I will personally review every PR that gets merged and every design decision made. Eventually (if we do this right) that will become impossible, but we aren’t there yet. As I build trust in contributors and the project expands I will eventually start delegating. But I will always bias toward “small and focused”.
  2. I will select a few key focus areas for the next few months of Bevy’s development. Anything outside of these focus areas will not receive priority for my attention. This will result in some people building cool stuff that doesn’t get merged for awhile, but thats what third party crates are for. Merging too many features too quickly will result in bloat, a sub-par user experience, and innovation friction. Rustc uses a similar mindset and I think it works pretty well for them.
  3. Within the chosen focus areas, I will encourage people to write as many “fast and loose” 3rd party plugins/crates as they can to test different designs for the given focus areas. I will do my best to give visibility to those projects to facilitate collaboration, testing, and code reviews. I will also do my best to communicate my thoughts on the focus areas ahead of time so developers understand the constraints they will be operating under.
  4. When these external crates identify clear paths forward, we will start the longer process of designing the final crate. It will be the job of the Bevy community to convince me that we should use a given approach. For the time being this will not be a democratic process, but I promise I am reasonable. And I will defer to experts when I am clearly out of my depth. If we land exactly where we started, either I was 100% right (unlikely) or we did something wrong (likely).

Closing Thoughts

Not much else to say at this point other than: I love you all, you helped make Bevy possible, and I can’t wait to build the future of Rust gamedev with you.


I appreciate this is a tangent and not relevant to the original post, but I wanted to speak to this.

I’ve worked on moderation for a large OSS project where there was a sudden influx of attention in a short period of time. I recommend being proactive when it comes to community standards and enforcement. Have a CoC in place as early as possible and be prepared to enforce it or have others enforce it for you. IMO, this is essential for the safety of existing contributors and for being inclusive to whoever might want to start contributing. Some people will not feel comfortable participating if there is no moderation in place.

If you don’t want to get distracted thinking about community management, maybe find someone to do that job for you, but I would be very wary of not having a moderation process.

Perhaps someone can speak to how Amethyst has approached this.


@stefee that is some much appreciated wisdom right there. I agree that we need to make the Bevy community a safe place for everyone. I’ll try to sort a CoC out as fast as possible.


Bevy is pursuing a Godot-style approach to its Editor UI, which is to develop its in-game UI and Editor UI as one unified project…

I love this so much, so cool :heart::heart::heart:
It’s one of the things I would love in Amethyst, and I’m happy Bevy will aproach the editor this way.

1 Like

I’m currently the one fronting the editor on the Amethyst side, I’m working on a large forum post about our details and plans, but I can say that a few months back we chose to test the web stack, but this did not prove fruitful for the editor as it would require extra manpower that we currently don’t have, so the Amethyst Editor is going to be in-engine, we just haven’t been public about it yet as we’ve been doing a countless amount of private tests.


I am not a gamedev, but I have experience with making games using unity and game maker in the past.
I am following Amethyst for a long time (waiting the right time to start a game :crossed_fingers: )
I have read the Introduction to bevy post first day it appeared. I enjoyed the read a lot and I agree with the author @cart in almost every motivation he listed there.
The thing that I loved the most is that the whole stack is written in the same language.
My motivation to like this idea is that I am currently working a big project written in react-native (engine one), and I have huge experience with making a great app using an engine written in C++, the main code in TS (Typescript), tooling in Ruby, native modules in Java/Brightscript/C++, and it becomes very complex project with time.
I would like to learn one language and do everything in it.

Huge respect for both Amethyst and Bevy communities, hope the collaboration would show success, and hope I will start creating games using the tools you are creating :100: :+1:


:tada: :raised_hands: