Best Practices

Component best practices

• We recommend using int entities instead of the Entity class.
• 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. On the other hand, 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, never in Components.
• Avoid referencing assets and entities directly.
  • Entity references will go stale if you delete them elsewhere and cause bugs(having an entity id stored and deleting the entity but forgetting to update your own id reference)! Safely refer to entities via identifiers like tag or group. Or manage the references via a system or manager by listening in on the EntitySubscription.
  • Don't refer to assets directly, but use an identifier for easy persistence. Use a specialized entity system to load and serve asset components.
    • It's recommended to annotate asset components - eg, a SpriteComponent holding a Sprite - with @Transient. Makes potential serialization easier.
• All non-@Transient component should be made up of primitives, strings and simple data structures - serializable stuff. It will make a move to persistence or networking a lot easier.