Crate bevy_impulse

source ·
Expand description

sense-think-act workflow

Bevy impulse is an extension to the Bevy game engine that allows you to transform bevy systems into services and workflows that can be used for reactive service-oriented programming.

§Services

One primitive element of reactive programming is a service. In bevy impulse, a Service is a bevy system that is associated with an entity and can be created using Commands::spawn_service or App::add_service.

When you spawn a service you will immediately receive a Service object which references the newly spawned service. If you do not want to hang onto the Service object, you can find previously spawned services later using the ServiceDiscovery system parameter.

Sometimes Service is not quite the right fit for your use case, so bevy impulse offers a generalization of services callled Provider which has some more options for defining a reactive element.

§Workflows

For complex async workflows, a single bevy system may not be sufficient. You can instead build workflows using .spawn_workflow on Commands or World. A workflow lets you create a graph of nodes where each node is a service (or more generally a provider) with an input, an output, and possibly streams.

There are various operations that can be performed between nodes, such as forking and joining. These operations are built using Chain.

When you spawn your workflow, you will receive a Service object that lets you use the workflow as if it’s an ordinary service.

§Impulses

Services and workflows are reusable building blocks for creating a reactive application. In order to actually run them, call Commands::request which will provide you with an Impulse. An impulse is a one-time-use reaction to a request which you can chain to subsequent reactions using Impulse::then. Any impulse chain that you create will only run exactly once.

Once you’ve finished building your chain, use Impulse::detach to let it run freely, or use Impulse::take to get a Recipient of the final result.

Re-exports§

Modules§

Structs§

  • AsyncCallback
    Use AsyncCallback to indicate that your system or function is meant to define an async Callback. An async callback is not associated with any entity, and it must return a Future<Output=Response> that will be polled by the async task pool.
  • AsyncMap
    Use AsyncMap to indicate that your function is an async map. A Map is not associated with any entity, and it cannot be a Bevy System. These restrictions allow them to be processed more efficiently.
  • AsyncService
    Use AsyncService to indicate that your system is an async Service. Being async means it must return a Future<Output=Response> which will be processed by a task pool.
  • BlockingCallback
    Use BlockingCallback to indicate that your system is meant to define a blocking Callback. Callbacks are different from services because they are not associated with any entity.
  • BlockingMap
    Use `BlockingMap`` to indicate that your function is a blocking map. A map is not associated with any entity, and it cannot be a Bevy System. These restrictions allow them to be processed more efficiently.
  • BlockingService
    Use BlockingService to indicate that your system is a blocking Service.
  • ContinuousService
    Use ContinuousService to indicate that your system is a Service that runs incrementally inside of a schedule with each update of the Bevy ECS.
  • ImpulsePlugin
    This plugin simply adds flush_impulses() to the Update schedule of your applicatation. For more fine-grained control you can call flush_impulses yourself and configure its relationship to other systems as you see fit.

Traits§

  • Sendish
    This trait is used as a trait bound that is equivalent to Send except when the single_threaded_async feature is active, in which case it is no longer a bound at all because the single threaded async executor does not require tasks to be Send.

Type Aliases§