Shipyard is an Entity Component System focused on usability and speed.
While usable it is far from finished, there's a lot of planned features, nearly all being backward compatible additions.
Most discussions about current and future features happen on zulip, feel free to join to follow the development or ask any question.
If you are new here, the user guide is a great place to learn all about Shipyard!
```rust use shipyard::prelude::*;
struct Health(f32); struct Position { x: f32, y: f32 }
fn run(pos: &Position, mut health: &mut Health) { (&pos, &mut health).iter() .filter(|(pos, )| isinacid(pos)) .foreach(|(pos, mut health)| { health.0 -= 1.0; }); }
fn isinacid(pos: &Position) -> bool { // it's wet season true }
let world = World::new();
{ let (mut entities, mut positions, mut healths) = world.borrow::<(EntitiesMut, &mut Position, &mut Health)>();
entities.add_entity(
(&mut positions, &mut healths),
(Position { x: 0.0, y: 0.0 },
Health(1000.0))
);
}
world.run_system::
I initially started to make an ECS to learn how it works. After a failed attempt and learning a lot from it and other ECS out there I started to work on Shipyard.
Specs was already well established as the go-to Rust ECS but I thought I could do better and went with EnTT core data-structure: sparse sets.
It turned out to be extremely flexible and is still the core of Shipyard. You can pay for what you want: iteration speed, memory, ease of use,...
And it allowed amazing features: - No component boilerplate - Very simple systems - Powerful inner and outer system parallelism - Ability to add/remove components while adding/removing entities - Chunk iteration - And a lot more!
Today I wouldn't say Shipyard is better or worse than Specs, it's just different. I'm really happy with it and the future looks very promising, especially: - Pipeline - Events - Nested packs - Shared components - Iterator blueprint
system
proc macro!Send
components!Sync
componentsThis crate uses unsafe
both because sometimes there's no way around it, and for performance gain.
Releases should have all invocation of unsafe
explained.
If you find places where a safe alternative is possible without repercussion (small ones are sometimes acceptable) feel free to open an issue or a PR.
Licensed under either of
at your option.
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.