Bevy Defer
A simple asynchronous runtime for executing async coroutines.
Motivation
Async rust is incredible for modelling wait centric tasks like coroutines. Not utilizing async in game development is a huge waste of potential.
Imagine we want to model a rapid sword attack animation, in async rust this is straightforward:
swing_animation.await;
show_damage_number.await;
damage_vfx.await;
swing_animation.await;
show_damage_number.await;
damage_vfx.await;
At each await point we wait for something to complete, without wasting resources
spin looping a thread or defining a complex state machine in a system.
What if we want damage number and damage vfx to run concurrently and wait for both
before our next attack? It's simple with async semantics!
join! ;
swing_animation.await;
Why not bevy_tasks?
bevy_tasks has no direct world access, which makes it difficult to write game
logic in it.
The core idea behind bevy_defer is simple:
// Pseudocode
static WORLD_CELL: ;
Futures spawned onto the executor can access the World
via access functions, similar to how database transaction works:
WORLD_CELL.with
As long as no references can be borrowed from the world, and the executor is single threaded, this is perfectly sound!
Spawning a Task
You can spawn a task onto bevy_defer
from World, App, Commands, AsyncWorld or AsyncExecutor.
Here is an example:
commands.spawn_task;
World Accessors
The entry point of all world access is AsyncWorld,
for example a Component can be accessed by
let translation = AsyncWorld
.entity
.
.get
This works for all the bevy things you expect, Resource, Query, etc.
See the access module and the AsyncAccess trait for more detail.
You can add extension methods to these accessors via Deref if you own the
underlying types. See the access::deref module for more detail. The
async_access derive macro can be useful for adding method to
async accessors.
We do not provide a AsyncSystemParam, instead you should use
one-shot system based API on AsyncWorld.
They can cover all uses cases where you need to running systems in bevy_defer.
Async Basics
Here are some common utilities you might find useful from an async ecosystem.
-
AsyncWorld.spawn()spawns a future. -
AsyncWorld.spawn_scoped()spawns a future with a handle to get result from. -
AsyncWorld.yield_now()yields execution for the current frame, similar to how coroutines work. -
AsyncWorld.sleep(4.0)pauses the future for4seconds. -
AsyncWorld.sleep_frames(4)pauses the future for4frames.
Bridging Sync and Async
Communicating between sync and async can be daunting for new users. See this amazing tokio article: https://tokio.rs/tokio/topics/bridging.
Communicating from sync to async is simple, async code can provide channels
to sync code and await on them, pausing the task.
Once sync code sends data through the channel, it will
wake and resume the corresponding task.
Communicating from async to sync require more thought. This usually means mutating the world in an async function, then a system can listen for that particular change in sync code.
async
The core principle is async code should help sync code to do less work, and vice versa!
Signals and AsyncSystems
AsyncSystems and Signals provides per-entity reactivity for user interfaces.
Checkout their respective modules for more information.
Implementation Details
bevy_defer uses a single threaded runtime that always runs on bevy's main thread inside the main schedule,
this is ideal for simple game logic, wait heavy or IO heavy tasks, but CPU heavy tasks should not be run in bevy_defer.
The AsyncComputeTaskPool in bevy_tasks is ideal for this use case.
We can use AsyncComputeTaskPool::get().spawn() to spawn a future on task pool and call await in bevy_defer.
Usage Tips
The futures and/or futures_lite crate has excellent tools to for us to use.
For example futures::join! can be used to run tasks concurrently, and
futures::select! can be used to cancel tasks, for example despawning a task
if a level has finished.
Versions
| bevy | bevy_defer |
|---|---|
| 0.12 | 0.1 |
| 0.13 | 0.2-latest |
License
License under either of
Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0) MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT) at your option.
Contribution
Contributions are welcome!
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.