Flax is a performant and easy to use Entity Component System.
The world is organized by simple identifiers known as an Entity, which can have any number of components attached to them.
Systems operate and iterate upon entities and their attached components and provide the application logic.
See a live demo of asteroids using wasm here.
```rust
// Declare static components
use flax::*;
component! {
health: f32,
regen: f32,
pos: (f32, f32),
player: (),
items: Vec
let mut world = World::new();
// Spawn an entity let p = EntityBuilder::new() .set(health(), 50.0) .tag(player()) .set(pos(), (0.0, 0.0)) .set(regen(), 1.0) .set_default(items()) .spawn(&mut world);
let mut query = Query::new((health().as_mut(), regen()));
// Apply health regen for all match entites for (health, regen) in &mut query.borrow(&world) { health = (health + regen).min(100.0); }
```
Queries with logic can be abstracted into a system, and multiple systems can be collected into a schedule.
```rust
let regensystem = System::builder() .with(Query::new((health().asmut(), regen()))) .for_each(|(health, regen)| { health = (health + regen).min(100.0); }) .boxed();
let despawnsystem = System::builder()
.with(Query::new(entityids()).filter(health().le(0.0)))
.write::
let mut schedule = Schedule::from([regensystem, despawnsystem]);
schedule.execute_par(&mut world)?;
```
Flax provides first class many-many relations between entities, which is useful for tree scene hierarchies, graphs, and physics joints between entities.
Relations can be both state-less or have associated data, like spring or joint strengths.
Relations are cache friendly and querying children of does not require random access. In addition, relations are cleaned up on despawns and are stable during serialization, even if the entity ids migrate due to collisions.
See the guide for more details.
```rust component! { child_of(parent): () => [Debug], }
let mut world = World::new();
let parent = Entity::builder() .set(name(), "Parent".into()) .spawn(&mut world);
let child1 = Entity::builder() .set(name(), "Child1".into()) .setdefault(childof(parent)) .spawn(&mut world);
```
Compared to other ecs implementations, a component is simply another Entity
identifier to which data is attached. This means the same "type" can be added to
an entity multiple times.
A limitation of existing implementations such as specs, planck, or hecs is that newtype wrappers need to be created to allow components of the same inner type to coexist.
This leads to having to forward all trait implementations trough e.g
derive-more or dereferencing the newtypes during usage.
By making components separate from the type the components can work together without deref or newtype construction.
```rust component! { velocity: Vec3, position: Vec3, }
let vel = world.get(entity, velocity())?; let mut pos = world.get_mut(entity, position())?; let dt = 0.1;
*pos += *vel * dt; ```
On a further note, since the components have to be declared beforehand (not
always true, more on that later), it limits the amount of types which can be
inserted as components. This fixes subtle bugs which come by having the type
dictate the component, such as inserting an Arc<Type> instead of just Type,
which leads to subsequent systems not finding the Type on the entity.
Having statically declared componenents makes the rust type system disallow these cases and catches these bugs earlier.
During development of a game in school I used the hecs ECS. It is an awesome
library, and the author Ralith has been wonderful in accepting
contributions and inquiries.
Despite this, I often made subtle bugs with similar types. The game engine was
cluttered with gigantic newtypes for Velocity, Position with many deref
coercions in order to coexist.
This library makes use of unsafe for type erasure and the allocation in storage of ComponentBuffers and Archetypes.
License: MIT