I'd just like to mention that the release notes are one of the best I've read.

Same goes for PR descriptions like for the ECS v2 PR [1]. That's more text than half of open source libraries have documentation.

[1] https://github.com/bevyengine/bevy/pull/1525

You mention:

    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.

Bevy is modular, in the sense that you can remove higher-level parts/layers if you don't want to use them.

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.

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.

0: https://github.com/bevyengine/bevy/issues/1613

Yes! Marker components, as we like to call them are a common and encouraged pattern :)

Has basic 2D drawing (lines, rectangle, bezier curve etc) added yet? I remember it was in the plans in the very beginning.

No, but the https://github.com/Nilirad/bevy_prototype_lyon crate does a very nice job here :)

Officially, not yet, but there is a good community-maintained plugin: `bevy_prototype_lyon`.

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.

What have the biggest challenges been?