That's OK though. Other people will then be able to use Bevy for actually making a game.
And to be fair, not every great engineer is a great writer, artist, composer, or any other role one might like to have on board for making a game.
That's OK though. Other people will then be able to use Bevy for actually making a game.
And to be fair, not every great engineer is a great writer, artist, composer, or any other role one might like to have on board for making a game.
> Other people will then be able to use Bevy for actually making a game.
Nobody makes games in Bevy though, Bevy is just a very good, modern graphics tech demo, not something suitable for developing actual games. Even the biggest title out there, Tiny Glade, is just a level editor with precisely zero gameplay features. Bevy's "popularity" (on social media, not among game developers) is entirely hype-driven by people that do not actually make games at all.
> Bevy is just a very good, modern graphics tech demo, not something suitable for developing actual games.
I would agree with you that bevy is not fit for making a commercial game. but not because its not capable. Its just NEW. we are only now starting to see commercial games come out with godot and thats 11 years old. bevy came out what, late 2021? give it some time. It still needs more workflow tools, a level editor stable documentation and a bunch of other things.
It will get there. it just takes time.
> Nobody makes games in Bevy though
Obviously not true, latest Bevy Jam has ~100 submissions! They might not be the games you were thinking about, but they're games nonetheless.
Beyond the game jams there are definitively people making games with Bevy too, but I don't think anyone of them gone mainstream (yet?) but it's a bit harsh to say no one is making games with Bevy when that's clearly not true.
It takes a long time for a game engine to be ready to create the kind of experiences you're probably thinking about, and even if everything goes great with Bevy in the future, it's still probably years rather than months until any big studio will think of start using it for something important.
With that said, people are for sure making games in Bevy even if the experience is non-optimal. Search on GitHub for "bevy" and sort by latest update and you get a snapshot of the projects that are on GitHub, then imagine there is a magnitude more people working privately.
I judge the viability of a game engine/framework based on its commercial success. This may be a bit harsh but the truth is that hobby game jams and games with complex gameplay features are two different kinds of games and the viability of Bevy for one does not automatically make it viable for the other. Bevy may be fun to use for a simple 30 minute platformer for a game jam, but try re-creating any of the big indie hits released in this year and you will quickly realize how much friction Bevy/Rust create. In fact, of all the 619 successful (>500 reviews) games released in 2025 on Steam, can you point out at least one of them made in either Bevy or Fyrox?
https://steamdb.info/stats/gameratings/2025/?min_reviews=500...
> you will quickly realize how much friction Bevy/Rust create
For me the experience is completely the opposite. ECS as a pattern lets me build way larger games with more complicated and interesting gameplay than I could build before without ECS. It's something about about easy it makes to create de-coupled functions and being able to easily put things under automatic testing that makes the whole process so much smoother. Before moving to Bevy I mostly used Unreal Engine and on two projects Unity, FWIW.
> I judge the viability of a game engine/framework based on its commercial success. This may be a bit harsh
I don't think it's harsh at all, I'd do the same if I was trying to build mainstream games, and I think many other peoples do so to.
But that's also very different than "Nobody makes games in Bevy though" which is what you said at first, which is a lot less charitable than what you wrote in your comment now. I understand it's an exaggeration, but it reads as you're sour about it, rather than being interested in a conversation about it.
I'm not sure what exactly you're expecting from a game engine that is not even yet six years from its first commit, but nevertheless - while it came out in 2024, not 2025, Tiny Glade[0] is built with Bevy.
https://steamdb.info/app/2198150/
Only the ECS.
I fail to see how that's particularly relevant, considering that this discussion started with the implication that ECS specifically is a neat fad that Bevy users will eventually get bored of.
And again, I am not sure what exactly people are expecting of a game engine that started development in 2019. Development of Tiny Glade itself started less than three years after Bevy's first commit, which was an obvious factor in Pounce Light building a custom renderer.
It's relevant because the post I replied to is misleading on its own.
How is it misleading? Even Unity and Unreal games often have parts of the engine modified or replaced, e.g. swapping built-in audio for fmod/wwise or built-in physics for something in-house. Pounce Light has discussed the fact that it's primarily the renderer that they replaced[0], and they are not the first, nor will they be the last studio to use a custom renderer.
If your criteria for "made with Bevy" is "every single system in the game must be from Bevy", then sure, you won't find a single Bevy game in existence. But you will also find a lot fewer Unity and Unreal games than you think.
0. https://80.lv/articles/exclusive-tiny-glade-developers-discu...
Tiny Glade is a great sandbox that must not have been easy to implement, game or not.
However, it doesn't even use Bevy's renderer, but their own: the devs mostly just care about its ECS. So it definitely isn't the showcase Bevy is looking for.
Why? What does Bevy lack?
There are two primary issues. In game development, for developing game features, iteration speed is the most important factor, you usually want a higher level scripting language in your game engine, so that a developer's workflow looks like this: make a simple change, hit a reload button, issue a few inputs, go back to the editor, make a simple change, repeat. Other popular game engines, more or less, solve this problem by providing a way to make gameplay features in a higher level language (GDScript in Godot, C# in Unity, BluePrints in Unreal Engine, often Lua with custom game engines), with Bevy, you make a change, and you rebuild the code, and often times, making a simple gameplay logic change (for a spell, an item, or some NPC interaction), will also change the ownership rules in case of Rust, because you may want to now access the same item mutably in two places or other things, and that requires you to restructure your simple script to appease the borrow checker, which also brings us to the second issue, in game development, a lot of bad practices, become good practices, take cyclic references for example, which are a common pattern in video games, in other lower level languages, or languages that allow embedding a higher level language, it's not that big of a deal, in Rust you have to do some shenenigans with things like RefCell<Vec<Rc<RefCell<Item>>>> which is simply not very ergonomic and adds a lot of development friction. A lot of people don't realize that game engine and gameplay programming are two vastly different things that have different requirements, and Rust is a poor fit for the latter.
Have you tried using Bevy? I have used it for some pretty non-trivial use-cases (not open source), and I have found that I did not have to use the typical "RefCell<Vec<Rc<RefCell<Item>>>>" stuff you talk about. There are paradigms in place for safe mutable access to the game state without jumping through hoops.
Of course you no longer have to actually try anything and give it a good-faith evaluation before criticising it. If it's different, then it de facto sucks.
This stance is not necessarily wrong - life is short, after all, and not every cup of tea has to be drunk from - but it does make finding useful criticism in a haystack of generic talking points rather difficult.
> in Rust you have to do some shenenigans with things like RefCell<Vec<Rc<RefCell<Item>>>> which is simply not very ergonomic
The entire raison d'être of Bevy and the reason it is built how it is is that the ECS eliminates that. If your Bevy code contains something that looks like that, you are using it very wrong. You put the data in the ECS, and any gameplay code goes into some system that uses the queries to pull the data it needs out of it. If you need something like a backreference, you don't add one in an unholy tower of refcells, you just use a different query.
If you wanted to argue that a soup of mutually referencing objects is easier to deal with than having to use a query system, I'd disagree, but you'd have a valid argument. What you posted above just highlights that you don't know much about bevy.