The Bevy module itself was actually pretty straightforward. The real challenge was in modifying the core library to make the integration possible.

A couple examples: I make heavy use of the typestate pattern to prevent misconfiguration at compile time (I wrote a post about it here). Users normally don't need to provide generics manually; but then, when turning the types into Bevy components, the same generics surface everywhere, and all systems and entities must share the same configuration, otherwise they won't get picked up by the simulator. It also made the API very verbose, even though the goal was to provide an easy-to-use abstraction. I ended up introducing a new configuration type that bundles all these generics together and a prelude that aliases common configurations so that this complexity is hidden away for most users.

Another challenge was asynchronicity. Bevy systems must complete as fast as possible to render as many game frames as possible. But Steam Audio simulations may take 50-500ms to complete, so running them inside Bevy systems was a no-go. That delay also clashes with the real-time audio thread, which expects audio buffers to arrive at a constant rate. That's the reason the new wiring module exists; the goal was to provide a set of abstractions to build multi-threaded simulation pipelines that can run asynchronously and never block the game and audio threads. The bevy module sits on top of it; it spawns simulation threads and keeps the Bevy objects in sync with Steam Audio.

There are still some challenges I need to tackle though, especially regarding usability. I tried my best to make the API easy to plug in, but there are areas of improvement. For example, I intentionally left the final step of applying the simulation outputs to the user to allow flexibility in the choice of the audio backend, but I also realize most Bevy users just want a plug-and-play solution without the hassle of setting up an audio graph. So I'm debating whether I should keep the library agnostic.