Artemis

Component or rather relation/property?

Introduction

I like the concept that everything can be anything but i also like to name things for what they really stand for.

In context of Artemis framework when you are extending instead of implementing Component objects you need to envelop specific component implementation in relational object that can be used as Artemis component.

For example WorldPosition could be anything (x, y) coordinates in 2D space or (x, y, z) coordinates in 3D space, but can be also and id for node in some graph vertex space. Now think how much do you need to rewrite if you use some graph framework for manipulating such GraphWorldPosition instead of just writing

// this is component
public class GraphWorldPosition extends GraphNode implements Component {}

And don`t think is to much of abstraction most navigation algorithms use graphs as base structure for path finding.

My thoughts about it

Examples

Components need to extend Component instead there should be an interface to implement. For example you have some class for manipulating point position to use it as component you need to make a class that links this real implementation with component slot for entity. In this way you shouldn`t name component a component but rather a relation.

Look at this example of an Entity that has two properties for it`s current position and desired destination both with internally use WorldPosition for navigation purpose.

// this is just an relation 1-1 entity to world position
public class ObjectPosition extends Component
{
    public WorldPosition position;// component
}

// another relation 1-1 entity to world position
public class ObjectGoal extends Component
{
    public WorldPosition position;// component
}

If you would use relational database for representing link between object position and world positions tables, components would represent a foreign key linking entity to world position.

Hmm..

BETTER DON`T DO THIS

Thinking more over it maybe desired destination should be really an entity with component ObjectPosition than above example would look like thise:

// 1-1 relation entity to entity
public class ObjectGoal extends Component
{
    private Entity destination;// entity

    public void set(Entity entity)
    {
        // check if it`s valid entity for goal - you don`t have to do it here
        if (entity.getComponent(ObjectPosition.class) != null)
        {
            destination = entity;
        }
    }

    public Entity get()
    {
        // check if it`s valid entity for goal - but you must do it here 
        // or whenever you try to us this component
        if (destination.getComponent(ObjectPosition.class) != null)
        {
            return destination;
        }
    }
}

But now you need to check if entity is valid destination by checking if destination has ObjectPosition component.

This gives you little advantage you can render something over destination in same engine that uses ObjectPosition for drawing any other renderable entity an you don`t need to know if WorldPosition is hold any other strange Component like ObjecGoal.

It`s not an advantage if you point to already renderable entity that has own distinct look and you accidentally replace it with render look for destination.