How can I provide attribute extensibility in a component-based entity system?

Question

This question and its answers move against utilizing an entity component system where the component itself is just a generic class with an dynamic container for the attributes/properties of the component.

Some definitions for this thread:

• Entity = ID + collection of components
• Component = Container (std::map<attribute_name, attribute_value>) of attributes/properties, such as health, age, name, gender, etc.

I understand and am aware of the drawbacks (no compile-time type safety, added overhead of looking up values from the container). Nonetheless, I currently am working on/with such a system, with the following argument, which I would now like to put to the test: data-driven design.

If all the attributes of the component are in a dynamic container, it is very easy (in fact possible at all) to add new ones later on, outside of the source code. So you can easily script new attributes later on. And dumping/saving the state of the component is a piece of cake.

Compared to the proposal in the above mentioned thread, I also have an own class for each component, to implement some basic behavior and helper methods directly in them (but those also need to look up their values from the container).

Example:

My component base class has a map for all the attributes/property:

typedef std::map<std::string, PropertyBase*> PropertyMap;

So an actual component looks something like the following. In the constructor I populate the attributes I want the component to have, by adding them to the map. Later I can read and update them if needed, but always with a performance penalty, since I first have to find them in the std::map.

class Person : public ClonableComponent<Person>
{
public:
    Person(ComponentFactory* const pFactory, ComponentType type, ComponentID id, GameEntity* const pEntity) 
    : ClonableComponent(pFactory, type, id, pEntity)
{
    // General
    addProperty(new Property<int>("age", PROP_INT, 0));
    addProperty(new Property<String>("gender", PROP_STRING, "unknown"));        
    addProperty(new Property<String>("currentLocation", PROP_STRING, "unknown"));

    // Feelings
    addProperty(new Property<bool>("isTired", PROP_BOOL, false));
    addProperty(new Property<bool>("isHungry", PROP_BOOL, false));
    addProperty(new Property<bool>("isThursty", PROP_BOOL, false));
}

void enterLocation(GameEntity* pLocGE)
{
    if(pLocGE->hasComponent(COMP_TYPE_LOCATION))
    {
        updateProperty("currentLocation", pLocGE->getName());
        updateProperty("casinoEnteredDateTime", (int)std::time(0));
    }
}

void leaveLocation()
{
    updateProperty("currentLocation", std::string("unknown"));
}
};

However, that thread made me think, and I am now doubtful that my approach will work well in the long run (maintenance, scaling and performance wise) and I am therefore considering moving to an directly typed approach with no look-up overhead. At the same time I don't want to loose that data-driven extendability.

I thought of a hybrid approach: Keep all known variables as actual language variables but also add a container (std::map) for scripted/data-driven variables. Therefore I'd know that my internal access is very fast and only the later added scripted extension would have the slow look-up and the other mentioned penalties.

Question: What do you use / would propose as an approach for a data-driven ECS in terms of attribute storage/handling? How do you keep it extendable? Would you recommend such a hybrid approach (real variables internally, container for new, external definitions)?

Answer 1

If all the attributes are in a dynamic container, it is very easy (more correctly: possible at all) to add new ones later on, outside of the source code. So you can easily script new attributes later on.

Yes, but you can't do anything with new attributes added via scripts except via scripts without losing this "advantage." Once you need to refer to these values in source code, you should have just added a concrete field to a concrete type rather than something in a Dictionary or whatever.

If you want the ability for scripts to dynamically add new bits of data without recompilation (which is a very useful feature) than provide this functionality just to the ScriptComponent (or what have you) in your system. This sounds relatively identical to your "hybrid" approach anyway: I'd just caution that you shouldn't need the functionality anywhere but a component that is providing/running a script.

And dumping/saving the state of the component is a piece of cake.

This should not be the concern of the entity/component system. This should be the concern of the reflection/content representation system you use. It's trivial to implement without dynamic "property bag" dictionaries in languages like C# with good reflection support, and it's only slightly more work to do it in something like C++ with really poor reflection support. Consequently you shouldn't use this as a strong rationale for storing component attributes in a runtime associative array.

Would you recommend such a hybrid approach (real variables internally, container for new, external definitions)?

Basically, what I said above: don't use a runtime associative array for component attributes by default. If your scripting system needs that functionality, provide it via the components bound to the scripting system.

Answer 2

ECSs are somewhat complicated.

At first I used the following approach: Entities only contain a position vector and a set of components. A component contains a specific behavior and necessary data e.g. RenderComponent, PhysicsComponent etc. This is commonly referred to as ECS.

But this has some disadvantages: The data of an entity is closely entangled with the component functionality. Sooner or later a component needs to access and modify data stored in a different component type e.g. the MovementComponents needs to apply a force to the PhysicsComponents etc. So either directly access the other component via the entity, send an event causing the change in the other component or pull the needed value up into the entity. All bad solutions in my opinion. Also maintaining the lifecycle of each component type was quite a hassle.

Currently I'm using the following approach: An Entity consist of an unique id and a bag of keys and values (hash the key strings for ultimate performance ;-) ). Subsystems (e.g. physicsEngine, renderer) look for entities with property keys they can use and create components internally with the required behaviors. These components store the unique id of their entity and use it to read and modify the entities property values. You could even get rid of the entity class entirely, since it's only an id anyways and store the properties under the entity id in a global property store making the whole design more like a database. Jason Gregory calls this Property Centric Archictecture in his book Game Engine Architecture. Thief and Deus Ex used this approach.

It's trivial to inspect, store and load the game state. Easy to extend and I can create new behavior entirely in script (I'm using python for scripting - great language btw). Components are only known in their respective subsystem. I sacrificed compile time safety and OOP style data hiding sure and I might need some kind of templating mechanism to define and check properties. But for now this approach works suprisingly well.