What designs are there for a component based entity system that are user friendly but still flexible?

Question

I've been interested in the component based entity system for a while, and read countless articles on it (The Insomiac games, the pretty standard Evolve Your Hierarchy, the T-Machine, Chronoclast ... just to name a few).

They all seem to have a structure on the outside of something like:

Entity e = Entity.Create();
e.AddComponent(RenderComponent, ...);
//do lots of stuff
e.GetComponent<PositionComponent>(...).SetPos(4, 5, 6);

And if you bring in the idea of shared data (this is the best design I've seen so far, in terms of not duplicating data everywhere)

e.GetProperty<string>("Name").Value = "blah";

Yes, this is very efficient. However, it isn't exactly the easiest to read or write; it feels very clunky and working-against-you.

I personally would like to do something like:

e.SetPosition(4, 5, 6);
e.Name = "Blah";

Though of course the only way to get to that kind of design is back in the Entity->NPC->Enemy->FlyingEnemy->FlyingEnemyWithAHatOn kind of hierarchy this design tries to avoid.

Has anyone seen a design for this kind of component system which is still flexible, yet maintains a level of user friendliness? And for that matter, manages to get around the (probably the hardest problem) data storage in a good way?

What designs are there for a component based entity system that are user friendly but still flexible?

Answer 1

One of the things that Unity does is provide some helper accessors on the parent game object to provide a more user friendly access to common components.

For example, you might have your position stored in a Transform component. Using your example you would have to write something like

e.GetComponent<Transform>().position = new Vector3( whatever );

But in Unity, that gets simplified to

e.transform.position = ....;

Where transform is literally just a simple helper method in the base GameObject class (Entity class in your case) that does

Transform transform
{ 
    get { return this.GetComponent<Transform>(); }
}

Unity also does a few other things, like setting a "Name" property on the game object itself instead of in its child components.

Personally I don't like the idea of your shared-data-by-name design. Accessing properties by name instead of by a variable and having the user also have to know what type it is just seems really error prone to me. What Unity does is that they use similar methods as the GameObject transform property within the Component classes to access sibling components. So any arbitrary component you write can simply do this:

var myPos = this.transform.position;

To access the position. Where that transform property does something like this

Transform transform
{
    get { return this.gameObject.GetComponent<Transform>(); }
}

Sure, it's a little more verbose than just saying e.position = whatever, but you get used to it, and it doesn't look as nasty as the generic properties. And yes, you would have to do it the roundabout way for your client components, but the idea is that all your common "engine" components (renderers, colliders, audio sources, transforms, etc) have the easy accessors.

Answer 2

I would suggest some kind of Interface class for your Entity objects would be nice. It could do the error handling with checking to make sure an entity contains a component of the appropriate value as well in one location so you would not have to do it everywhere you access the values. Alternately, most of the designs I have ever done with a component based system, I deal with the components directly, requesting, for example, their positional component and then accessing/updating the properties of that component directly.

Very basic at a high level, the class takes in the entity in question and provides easy-to-use interface to the underlying component parts as follows:

public class EntityInterface
{
    private Entity entity { get; set };
    public EntityInterface(Entity e)
    {
        entity = e;
    }

    public Vector3 Position
    {
        get
        {
            return entity.GetProperty<Vector3>("Position");
        }
        set
        {
            entity.GetProperty<Vector3>("Position") = value;
        }
    }
}

Answer 3

In Python you can intercept the 'setPosition' part of e.SetPosition(4,5,6) via declaring a __getattr__ function on Entity. This function can iterate through the components and find the appropriate method or property and return that, so that the function call or assignment goes to the right place. Perhaps C# has a similar system, but it might not be possible due to it being statically typed - it presumably can't compile e.setPosition unless e has setPosition in the interface somewhere.

You could also perhaps make all your entities implement the relevant interfaces for all components you might ever add to them, with stub methods that raise an exception. Then when you call addComponent, you just redirect the entity's functions for that component's interface to the component. A bit fiddly though.

But perhaps easiest would be to overload the [] operator on your Entity class to search the attached components for the presence of a valid property and return that, so it can be assigned to like so: e["Name"] = "blah". Each component will need to implement its own GetPropertyByName and the Entity calls each one in turn until it finds the component responsible for the property in question.

Answer 4

To expand on Kylotan's answer, if you're using C# 4.0, you can statically type a variable to be dynamic.

If you inherit from System.Dynamic.DynamicObject, you can override TryGetMember and TrySetMember (among the many virtual methods) to intercept component names and return the requested component.

dynamic entity = EntityRegistry.Entities[1000];
entity.MyComponent.MyValue = 100;

I wrote a bit about entity systems over the years, but I assume I can't compete with the giants. Some ES notes (somewhat outdated and do not necessarily reflect my current understanding of entity systems, but it's worth a read, imho).

Answer 5

I see a lot of interest here in ES on C#. Check it out my port of the excellent ES implementation Artemis:

https://github.com/thelinuxlich/artemis_CSharp

Also, a example game to get you started on how it works(using XNA 4): https://github.com/thelinuxlich/starwarrior_CSharp

Suggestions are welcome!

Answer 6

I decided to use C#'s excellent reflection system. I based it off the general component system, plus a mixture of the answers here.

Components are added very easily:

Entity e = new Entity(); //No templates/archetypes yet.
e.AddComponent(new HealthComponent(100));

And can be queried either by name, type, or (if common ones like Health and Position) by properties:

e["Health"] //This, unfortunately, is a bit slower since it requires a dict search
e.GetComponent<HealthComponent>()
e.Health

And removed:

e.RemoveComponent<HealthComponent>();

Data is, again, accessed commonly by properties:

e.MaxHP

Which is stored component-side; less overhead if it doesn't have HP:

public int? MaxHP
{
get
{

    return this.Health.MaxHP; //Error handling returns null if health isn't here. Excluded for clarity
}
set
{
this.Health.MaxHP = value;
}

The large amount of typing is aided by Intellisense in VS, but for the most part there is little typing - the thing I was looking for.

Behind the scenes, I am storing a Dictionary<Type, Component> and having Components override the ToString method for name checking. My original design used primarily strings for names and things, but it became a pig to work with (oh look, I have to cast everywhere as well the lack of easy to access properties).