Shipyard 0.6 release

[leudz]

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.

Most notable changes:

• Workload
  For almost a year I had the chance to work at a company not only using an ECS but shipyard. A lot of small changes occurred because of it and a big one.
  We didn't use shipyard's workloads directly but shipyard_app. The thing I love about it is that you can jump to the plugin definition. In 0.5 workloads were identified with a String so there was no easy way to go to the workload definition.
  With 0.6 workloads are built inside functions and the function itself becomes the identifier, just like systems.
  There is also new traits to control systems ordering SystemModificator and WorkloadModificator.

  use shipyard::{IntoWorkload, Workload};
  
  fn sys1() {}
  fn sys2() {}
  fn sys3() {}
  fn sys4() {}
  fn workload1() -> Workload {
      (sys1, sys2).into_workload()
  }
  fn workload2() -> Workload {
       (workload1, sys3, sys4).into_workload()
  }
  

• Tracking
  Shipyard can track component insertion/modification/removal/deletion. This tracking is now part of the type system which is a big ergonomic improvement.
  Methods specific to a certain kind of tracking are checked at compile-time instead of runtime.
  In addition, modification is flagged on DerefMut with a Mut wrapper preventing multiple fields borrow. This wrapping now only happens for components that track modification.
  New Component and Unique traits had to be introduced reducing ergonomics for very small projects as all components need to implement these traits.
  But at the same time they serve as documentation, greatly appreciated in bigger projects.
• Visualizer
  The visualizer is a gui tool. Currently it allows to visualize which components are borrowed in which systems and vice versa.
  It will continue to grow and include more tools in the future.
• Tracing feature
  This cargo feature enables spans on workloads and systems. They can then be used with tracy for example to profile your application.
• Custom Views
  Custom views are not a new addition but some work went into them to make them more capable and easier to use.
  Proc macros are available for the basic case and a new chapter is dedicated to them with a concrete example.
• ECS in non-game projects
  ECS is not often used in non-game projects so I was very curious to hear what benefits my then future manager saw in it. They sent me an interesting notion doc (Why ECS tho?). The full document requires a bit of domain knowledge but not the tldr:

  • Flexible association of data makes it easier to model the domain
  • It's super simple to collect only things you care about (all expressions, or, all references) without bringing the whole world (avoiding "You wanted a banana but what you got was a gorilla holding the banana" re: OO)
  • Parallelisability of work (person work, not computer work) due to the thin slices
  • Clear separation of system responsibilities
  • Fits nicely into a game loop type architecture
  • Also, likely, but not confirmed and less considered - performance benefits for myriad reasons

A big thanks to Boxy, Cole, dakom, eldyer and Will! This release would not have been possible without you!