1. state/stages can't be used together; since plugins may use states (and even baisc funcionality, like the fixed frame step), you can't use stages
2. in order to flush commands, you need stages, but you can't use them due to 1.
The result is that with Bevy itself, writes (commands) become effective only at the end of each frame. There is a plugin written by a 3rd party, but the Bevy developers are treating this as very low priority (it's been open for a very long time, and it's not even scheduled for the next release). Paradoxically, it matters little because there's a lot of hype about Bevy, but there are little (or none) significant projects - only very small ones or demos, which don't require efficiency or precise timing.
Additionally: the Bevy team doesn't write documentation at all. The "cheat book" is written by a 3rd party, with the consequence that it's partial, superficial, and it may be halted at any time (note that I don't fault the book maintainer(s); their contribution is crucial!). This isn't great when one approaches the engine for the first time; it actually sucks because engines like Bevy are (relatively) large beasts.
Hi! I'm one of the four formal maintainers of Bevy. I'm not particularly interested in convincing you personally, but I think it's important to publicly address some misunderstandings.
The scheduling rework that you're complaining about is extremely high priority, and I have personally invested hundreds of hours into redesigning and refactoring this mess (which is now in its third serious iteration). It's a challenging problem, and the volunteer who has taken responsibility for the rewrite has needed to step back for a while as they transition to a new job.
I have also personally invested hundreds of hours writing, editing and reviewing docs for Bevy. That's what got me involved in the first place, and the team has done a great job. A fully revised book is also in the works, but getting the subtle details right are critical.
As for serious projects: I've spoken with about a half-dozen commercial teams, including one with a team size of about 10 and a lifespan of nearly two years. Their feedback is remarkably positive given the immaturity of Bevy and the supporting ecosystem. While there are missing features that they want (hi bevy_ui), and annoying papercuts (yep, those scheduling concerns sure are annoying), they've over all been wildly impressed been how easy to maintain, reliable and performant Bevy has been for them.
> The scheduling rework that you're complaining about is extremely high priority
I see.
> I have also personally invested hundreds of hours writing, editing and reviewing docs for Bevy
Do you refer to the API docs and/or examples, or something else? I think it's important to have updated and more or less extensive API documentation, but it's not a proper resource for people to learn. AFAIK the only other semi-official learning resource is the cheat book, which is fundamental, but also incomplete.
> As for serious projects: I've spoken with about a half-dozen commercial teams [...] they've over all been wildly impressed been how easy to maintain, reliable and performant Bevy has been for them.
I don't have this clear. Are 5/6 teams actually building commercial games with Bevy, or they just planning to do it in the future? This is a crucial distinction.
Strongly agreed on the need for better introductory material; the existing book is extremely incomplete.
> I don't have this clear. Are 5/6 teams actually building commercial games with Bevy, or they just planning to do it in the future? This is a crucial distinction.
I know of 2 released commercial projects, the CAD team, a few indie devs who have started and 3 or so small studios who are looking to start. There's a little thread in the Discord where I've rounded folks up: [Bevy in production](https://discord.com/channels/691052431525675048/995713618526...).
