RFC: Bevy vs flecs

[andrewgazelka]

We are experimenting with moving to Bevy.

I could see this as a great way to join forces with Valence and potentially FerrumC. However, there are definitely going to be draw backs. I am making this issue to request for comments with respect to us moving to bevy. I have already outlined some potential issues that need to be resolved before we can move over.

• refactor: bevy #882

Note this would not be our first architecture change. We used to use evenio. See:

• RFC: Architecture #423

---

https://discord.com/channels/1222556172385783890/1366122267930656920

note for my main issue (ugly gets Sander is willing to spend some time for our use case if we stay on flecs)

[TestingPlant]

I don't have a strong opinion about either Bevy or Flecs, but I don't believe it's worth the time to convert Hyperion to use Bevy. If we were to switch however, my main argument to support switching to Bevy would be to avoid issues with soundness and crashes that we've experienced in Flecs occasionally. I don't believe minor API issues (such as with get) is enough to justify switching because all libraries will have their own minor API issues that might only become apparent once we switch. Also, our decision to use Flecs currently doesn't seem to be a significant barrier to new contributors, so I'm doubtful that switching to Bevy will help with getting more contributors.

[TestingPlant]

Now that I've been working on debugging the Hyperion crashes for a while, I believe it'd be a good idea to try switching to Bevy. I have not used Bevy ECS before, but this is what I predict the pros and cons will be:

Pros of switching to Bevy:

• Better error messages - It's very easy to accidentally trigger an assertion on the C side of Flecs especially with multi-threaded systems, and the assert messages are not very useful for diagnosing the issue. See Possible undefined behavior with bots connected #761 (comment) for the Flecs errors we have encountered. Debugging these asserts have consumed a substantial amount of development time.
• Less issues with undefined behavior
• Native async support using bevy::tasks::AsyncComputeTaskPool

Cons of switching to Bevy:

• Possible performance problems - I have not compared the performance of Bevy vs Flecs. However, even if Bevy is slower, I believe the development time saved by not needing to debug crashes, especially those caused by multi-threaded systems, will allow us to focus more on optimizing Hyperion to compensate. If we try switching to Bevy, we can benchmark Hyperion and determine which ECS has better performance. If Bevy is slower than Flecs, we should evaluate whether the advantages outweigh the amount of performance loss.

Other considerations:

• I believe we should remove HandlerRegistry, CommandRegistry, and PacketSwitchQuery and use events from the ECS system we choose. If we migrate to Bevy, it'd be easier to make this change while converting to Bevy.
• We will still need RuntimeLifetime or similar to pass packets which contain references to the the original packet data through ECS events as both Bevy and Flecs require 'static.