apecs
Asyncronous Parallel Entity Component System
Why
apecs is an entity-component system written in Rust that supports traditional syncronous
systems as well as asyncronous systems that can evolve over time. This makes it great for
general applications, quick game prototypes, DIY engines and any simulation that has discrete
steps.
Asyncronous systems
Async systems are system functions that are async. Specifically async systems have this type
signature:
use ;
async
The Facade type is like a window into the world. It can fetch resources from the
world asyncronously. This allows your async system to affect different parts of the
world at different times.
Syncronous systems are great for tight loops that are always iterating over the same data. In other words sync systems are highly optimized algorithms that run in the hot path. But they don't quite fit in situations where the system's focus changes over time, or when the system needs to wait for some condition before doing something different. Async systems are a good fit for situations where we're mutating different resources at different times, and when doing things fast (as in "as fast as possible") isn't necessary. Async systems are therefore a good fit for high-level orchestration.
For example you might use an async system to setup your title screen, wait for user input and then start the main game simulation by injecting your game entities.
Another example might be an app that has a dependency graph of work to complete. An Async system can hold the dependencies as a series of async operations that it is awaiting, while syncronous systems do the hot-path work that completes those async operations as fast as possible.
Goals
- productivity
- flexibility
- observability
- very well rounded performance, competitive with inspirational ECS libraries
- like
specs,bevy_ecs,hecs,legion,shipyard,planck_ecs
- like
Features
- syncronous systems with early exit and failure
use *; let mut world = default; world .with_system .unwrap; world.run; assert_eq!; - async systems, ie systems that end and/or change over time (for scenes, stories, etc)
- fetch resources from the world asyncronously. If they have not been added and can be
created by default, they will be.
WriteandReadwill create default resources during fetching, andWriteExpectandReadExpectwill not. - resources are acquired without lifetimes
- when resources are dropped they are sent back into the world
use *; async let mut world = default; world .with_async_system; world.run; assert_eq!; - fetch resources from the world asyncronously. If they have not been added and can be
created by default, they will be.
- support for async futures
use *; let mut world = default; world .with_async; world.run; - fetch data (system data) derive macros
use *; let mut world = default; let mut my_data: MyData = world.fetch.unwrap; *my_data.u32_number = 1; - system scheduling
- compatible systems are placed in parallel batches (a batch is a group of systems that can run in parallel, ie they don't have conflicting borrows)
- systems may depend on other systems running before or after
- barriers
use *; let mut world = default; world // one should run before two .with_system_with_dependencies.unwrap // two should run after one - this is redundant but good for illustration .with_system_with_dependencies.unwrap // exit_on_three has no dependencies .with_system.unwrap // all systems after a barrier run after the systems before a barrier .with_system_barrier .with_system.unwrap; assert_eq!; world.tick; assert_eq!; world.tick; world.tick; assert!; - component storage
- optimized for space and iteration time as archetypes
- queries with "maybe" and "without" semantics
- queries can find a single entity without iteration or filtering
- add and modified time tracking
- parallel queries (inner parallelism)
use *; // Make a type for tracking changes ; // Entities and Components (which stores components) are default // resources let mut world = default; world .with_system.unwrap .with_system_with_dependencies.unwrap .with_system_with_dependencies.unwrap; assert_eq!; world.tick; // entities are created, components applied lazily world.tick; // f32s are modified, u32s and strings are synced world.tick; // f32s are modified, u32s and strings are synced let q_bundle: = world.fetch.unwrap; assert_eq!; - outer parallelism (running systems in parallel)
- parallel system scheduling
- parallel execution of async futures
- parallelism is configurable (can be automatic or a requested number of threads, including 1)
use *; let mut world = default; world .with_system.unwrap .with_system.unwrap .with_system.unwrap .with_parallelism; world.tick; - plugins (groups of systems, resources and sub-plugins)
use *; ; // now we can package it all up into a plugin let my_plugin = default .with_system .with_system .with_system; let mut world = default; world.with_plugin.unwrap; world.tick; - fully compatible with WASM and runs in the browser
Roadmap
- your ideas go here
Tests
I like firefox, but you can use different browsers for the wasm tests. For the most part they're there just to make sure apecs works on wasm.
Benchmarks
The apecs benchmarks measure itself against my favorite ECS libs:
specs, bevy, hecs, legion, shipyard and planck_ecs.
Caveats
apecsuses generic associated types. This means it can only be compiled with nightly.