Shipyard 0.4 release

announcements
1

Shipyard is an Entity Component System crate. ECS is a pattern mostly used in games but not only. It fits really well with Rust, allowing easy composition and lifetime management.

What's new

  • Rework of systems and types used to borrow storage
  • Workloads had to be reworked to handle this change
  • Workloads can now return errors
  • Iterator and IntoIterator are now supported

For 0.3 users there's a migration guide to help with all the changes.

Example:

use shipyard::*;

struct Health(f32);
struct Position {
    _x: f32,
    _y: f32,
}

fn in_acid(positions: View<Position>, mut healths: ViewMut<Health>) {
    for (_, mut health) in (&positions, &mut healths)
        .iter()
        .filter(|(pos, _)| is_in_acid(pos))
    {
        health.0 -= 1.0;
    }
}

fn is_in_acid(_: &Position) -> bool {
    // it's wet season
    true
}

fn main() {
    let world = World::new();

    world.run(
        |mut entities: EntitiesViewMut,
         mut positions: ViewMut<Position>,
         mut healths: ViewMut<Health>| {
            entities.add_entity(
                (&mut positions, &mut healths),
                (Position { _x: 0.0, _y: 0.0 }, Health(1000.0)),
            );
        },
    );

    world.run(in_acid);
}
4 Likes
2

I'm curious if anyone has insight on how you could integrate something like Shipyard with a web-app framework like Yew or Seed? My thinking is that the webapp's Model (using the Elm Architecture terminology) would be contained in the ECS World. Interactions in the webapp would trigger an Update function that would interact with the World in some way and then re-render the View of the current World. Is this at all apt?

1 Like
3

For anyone who might be interested in the same question I had, the author of Seed has been awesome enough to include an example integrating a Shipyard world within a Seed app.

Many thanks to @MartinKavik.

1 Like
4

I had a very similar thought, wondering if/how to mix it with Dominator :slight_smile:

In the end, I put together a todomvc example, though it has not been migrated to shipyard 0.4 - and it was very experimental in spirit, also kicking the tires around another idea (using lit-element for the dom components)... so I'm not sure if I'm going to upgrade it. It was more like a r&d process than something to carry forward.

With that in mind, I do think it's possible for shipyard to hold Signals or something like Elm's Model.

However.... I'm not sure if that's really going to be so beneficial in such a direct merger. There's sortof like this overlap between them, where they're both interested in being "state management" as well as "view management", if that makes sense, and they weren't designed with eachother in mind, so it felt a little messy.

For example - shipyard has this concept of update packs which can be used to create some sort of reactive setup (but you gotta DIY). And the Elm (or redux or whatever) approach often wants things to "run" now (by setting properties or dispatching events), not by calling into some other framework (which adds cognitive overhead). In my example the cognitive difficulty was, I guess, more like "who owns the signals"... I think that example is decently contained, but I really worry about how it would go at scale.

That said, one area where I think they could fit together very nicely is where each is independently responsible for something and they communicate rather than share state. For example, shipyard could be used to power the main game and some elm-like-thing could be used to power a ui/hud/menu.

I think this is an area that could definitely use more innovation and experimentation, looking forward to see what you do with it! :smiley:

2 Likes
5

I really appreciate your thoughts and will have to look into Dominator. The README on your todomvc example is really nice and explains the logic behind such an integration very well.

1 Like
6

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.