Component

Components are pure data classes with optionally some helper methods.

Example Components

All components extend the Component class, which the framework relies on to differentiate them from other classes.

public class Position extends Component {
    public float x;
    public float y;

    public Position(float x, float y) {
        this.x = x;
        this.y = y;
    }
}

public class Health extends Component {

    public int health;
    public int damage;

    public String[] deathSfxId;
    public String[] damageSfxId;
    public String woundParticle;

    public Health(int health) {
        this.health = health;
    }
}

Using components

see Entity how to add and remove components to entities.

Performant Components

Components can be pooled for performance critical environments.

Best Practices

• Small and focused components are easier to reuse.

The advantage of having lightweight components is that it's usually more apparent what a system does by inspecting which components are included by the aspect. If I see a Position component, I know for certain that the system acts on coordinates. Otoh, a Sprite component - containing stuff like rotation, scaling, position, texture, alpha-modulation, size and whatnot - is much harder to tell at a glance what data the system specifically acts on.

• Place game logic into entity systems and managers, never in Components.
• Avoid referencing assets and entities directly.
  • Entity references will go stale and cause bugs! Safely refer to entities via identifiers like uuid, tag or group.
  • Don't refer to assets directly, but use an identifier for easy persistence. Use managers to serve assets to your systems.
• Strive for Serializable components. It will make a move to persistence or networking a lot easier.