Expand description
SPECS Parallel ECS
This library provides an ECS variant designed for parallel execution and convenient usage. It is highly flexible when it comes to actual component data and the way it is stored and accessed.
Features:
- depending on chosen features either 0 virtual function calls or one per system
- parallel iteration over components
- parallel execution of systems
High-level overview
One could basically split this library up into two parts: The data part and the execution part.
The data
World
is where component storages, resources and entities are stored.
See the docs of World
for more.
Component
s can be easily implemented like this:
use specs::prelude::*;
struct MyComp;
impl Component for MyComp {
type Storage = VecStorage<Self>;
}
Or alternatively, if you enable the "derive"
feature, you can use a
custom #[derive]
macro:
use specs::{prelude::*, Component};
#[derive(Component)]
#[storage(VecStorage)] // default is `DenseVecStorage`
struct MyComp;
You can choose different storages according to your needs.
These storages can be join
ed together, for example joining a Velocity
and a Position
storage means you’ll only get entities which have both of
them. Thanks to rayon, this is even possible in parallel! See ParJoin
for more.
System execution
Here we have System
and Dispatcher
as our core types. Both types
are provided by a library called shred
.
The Dispatcher
can be seen as an optional part here;
it allows dispatching the systems in parallel, given a list
of systems and their dependencies on other systems.
If you don’t like it, you can also execute the systems yourself
by using RunNow
.
System
s are traits with a run()
method and an associated
SystemData
, allowing type-safe aspects (knowledge about the
reads / writes of the systems).
Examples
This is a basic example of using Specs:
extern crate specs;
use specs::prelude::*;
// A component contains data which is
// associated with an entity.
struct Vel(f32);
impl Component for Vel {
type Storage = VecStorage<Self>;
}
struct Pos(f32);
impl Component for Pos {
type Storage = VecStorage<Self>;
}
struct SysA;
impl<'a> System<'a> for SysA {
// These are the resources required for execution.
// You can also define a struct and `#[derive(SystemData)]`,
// see the `full` example.
type SystemData = (WriteStorage<'a, Pos>, ReadStorage<'a, Vel>);
fn run(&mut self, (mut pos, vel): Self::SystemData) {
// The `.join()` combines multiple components,
// so we only access those entities which have
// both of them.
// This joins the component storages for Position
// and Velocity together; it's also possible to do this
// in parallel using rayon's `ParallelIterator`s.
// See `ParJoin` for more.
for (pos, vel) in (&mut pos, &vel).join() {
pos.0 += vel.0;
}
}
}
fn main() {
// The `World` is our
// container for components
// and other resources.
let mut world = World::new();
world.register::<Pos>();
world.register::<Vel>();
// An entity may or may not contain some component.
world.create_entity().with(Vel(2.0)).with(Pos(0.0)).build();
world.create_entity().with(Vel(4.0)).with(Pos(1.6)).build();
world.create_entity().with(Vel(1.5)).with(Pos(5.4)).build();
// This entity does not have `Vel`, so it won't be dispatched.
world.create_entity().with(Pos(2.0)).build();
// This builds a dispatcher.
// The third parameter of `add` specifies
// logical dependencies on other systems.
// Since we only have one, we don't depend on anything.
// See the `full` example for dependencies.
let mut dispatcher = DispatcherBuilder::new().with(SysA, "sys_a", &[]).build();
// This dispatches all the systems in parallel (but blocking).
dispatcher.dispatch(&mut world);
}
You can also easily create new entities on the fly:
use specs::prelude::*;
struct EnemySpawner;
impl<'a> System<'a> for EnemySpawner {
type SystemData = Entities<'a>;
fn run(&mut self, entities: Entities<'a>) {
let enemy = entities.create();
}
}
See the repository’s examples directory for more examples.
Re-exports
pub extern crate hibitset;
pub extern crate rayon;
pub extern crate shred;
pub extern crate shrev;
pub extern crate uuid;
pub use crate::changeset::ChangeSet;
pub use crate::join::Join;
pub use crate::storage::Storage;
pub use crate::world::Builder;
pub use crate::world::EntityBuilder;
Modules
Provides a changeset that can be collected from an iterator.
Specs errors
Joining of components for iteration over entities with specific components.
Prelude module
Save and load entities from various formats with serde.
Component storage types, implementations for component joins, etc.
Entities, resources, components, and general world management.
Structs
Like, Dispatcher
but works asynchronously.
The BatchAccessor
is used to notify the main dispatcher of the read and
write resources of the System
s contained in the batch (“sub systems”).
The BatchUncheckedWorld
wraps an instance of the world.
You have to specify this as SystemData
for a System
implementing
BatchController
.
A BitSet
is a simple set designed to track which indices are placed
into it.
Vector storage, like VecStorage
, but allows safe access to the
interior slices because unused slots are always initialized.
Dense vector storage. Has a redirection 2-way table between entities and components, allowing to leave no gaps within the data.
The dispatcher struct, allowing systems to be executed in parallel.
Builder for the Dispatcher
.
Entity
type, as seen by the user.
Wrapper storage that tracks modifications, insertions, and removals of
components through an EventChannel
.
HashMap
-based storage. Best suited for rare components.
Lazy updates can be used for world updates
that need to borrow a lot of resources
and as such should better be done at the end.
They work lazily in the sense that they are
dispatched when calling world.maintain()
.
A null storage type, used for cases where the component doesn’t contain any data and instead works as a simple flag.
Allows to fetch a resource in a system immutably.
A reader ID which represents a subscription to the events pushed to the
EventChannel
.
The static accessor that is used for SystemData
.
Vector storage. Uses a simple Vec
. Supposed to have maximum
performance for the components mostly present in entities.
A Resource container, which provides methods to insert, access and manage the contained resources.
Allows to fetch a resource in a system mutably.
Enums
Either an Accessor
of the system T
or a reference to it.
Traits
A trait for accessing read/write multiple resources from a system. This can be used to create dynamic systems that don’t specify what they fetch at compile-time.
The BatchController
describes things that allow one to control how batches
of systems are executed.
Abstract component type. Doesn’t have to be Copy or even Clone.
The purpose of the ParJoin
trait is to provide a way
to access multiple storages in parallel at the same time with
the merged bit set.
Trait for fetching data and running systems. Automatically implemented for systems.
A static system data that can specify its dependencies at statically (at
compile-time). Most system data is a SystemData
, the DynamicSystemData
type is only needed for very special setups.
UnprotectedStorage
s that track modifications, insertions, and
removals of components.
Type Definitions
A wrapper for a read Entities
resource.
Note that this is just Read<Entities>
, so
you can easily use it in your system:
Allows to fetch a resource in a system immutably.
This will panic if the resource does not exist.
Usage of Read
or Option<Read>
is therefore recommended.
A storage with read access.
Allows to fetch a resource in a system mutably.
This will panic if the resource does not exist.
Usage of Write
or Option<Write>
is therefore recommended.
A storage with read and write access.
Derive Macros
Custom derive macro for the Component
trait.
Custom derive macro for the ConvertSaveload
trait.
Used to #[derive]
the trait SystemData
.