Logic in Entity Components Systems

Question

I'm making a game that uses an Entity/Component architecture basically a port of Artemis's framework to c++,the problem arises when I try to make a PlayerControllerComponent, my original idea was this.

class PlayerControllerComponent: Component {
public:
    virtual void update() = 0;
}; 

class FpsPlayerControllerComponent: PlayerControllerComponent {
public:
    void update() {
        //handle input
    }
};

and have a system that updates PlayerControllerComponents, but I found out that the artemis framework does not look at sub-classes the way I thought it would. So all in all my question here is should I make the framework aware of subclasses or should I add a new Component like object that is used for logic.

Answer 1

Components can have functions. What you want to try to stay away from is having a lot of functionality in them. The functions should be simple things. For example, my inventory component has a function for adding an item to the inventory:

public boolean addItem(ItemAttribute item) {
    if (items.size() < maxItems) {
        items.add(item);
        return true;
    }
    return false;
}

It's more than a setter function, but doesn't have anything sophisticated. I would leave the function creation up to the individual deploying the framework though. Don't force an update function on them, let them decide what to implement.

Make sure you check out the example games that are on the Artemis site. Those should help you see how components are employed.

Also, check out this answer I gave with Artemis, specifically, in mind.

So with your example. The player control component wouldn't need much data in it at all. Nor functionality. However, simply attaching it to an entity that also had a position would make the PlayerControlSystem pick up that component and process the incoming keyboard input. Sometimes you can think of components like flags for systems. The component is really only there so that the system adds that entity to its processing group.

Components should be objects that the system can access. When a system accesses a component it should be able to access its data and whatever simple functionality it has.

There should be a different system for each control type and a different component for each control type. If you want to compress that into a single system or a single component you can, but it'll just end up in a switch statement like described in Sidar's answer.

Answer 2

In my Artemis port it would look something like so:

My component:

 class PlayerControllerComponent : public artemis::Component{
       enum PlayerControl{
         TPS,FSP,TD
       };
      public:
       PlayerControl pc;
       PlayerControllerComponent(PlayerControl pc){
         this->pc = pc;
       }

    };

And the system would be something like so:

class PlayerControlSystem: public artemis::EntityProcessingSystem {

    private:

        artemis::ComponentMapper<PlayerControllerComponent > pcm;

    public:
        PlayerControlSystem() {

            setComponentTypes<PlayerControllerComponent>();
        };

        virtual void begin() {
            //before logic
        }

        virtual void end() {
            //after logic
        }

        virtual void initialize() {
            pcm.init(*world);
        };

        virtual void processEntity(artemis::Entity &e) {

            PlayerControllerComponent & ent = *pcm.get(e);

                   switch(ent.pc)
                   {
                      case TPS:
                        //call internal function for TPS
                       break;
                        case FPS:
                        //call internal function for FPS
                       break;
                          case TD:
                        //call internal function for TD
                       break;

                   };
        };
};

I have to admit that I'm still trying to wrap my head around Artemis completely. But since the bitset for components is so specific systems are more 1:1 with components. So this is how I would do it.

Answer 3

Your input component doesn't need any logic. It needs a control scheme since that's going to differ among entities but that's all. The rest should be handled by the system. It's the same as it is for rendering and physics, just detect which entity has the component and act upon it. Putting input handling logic in the component is a dead end because there's only so much it can do before you start creating hacks.

Trying to avoid one switch statement at a cost of creating inheritance chains is a poor decision since you gain absolutely nothing. You need the same logic for handling the input. The switch statement was created for situations like this one, it doesn't make your application less robust. Also adding a new type of control is going to be easier with a switch statement; just add one more case and a function to handle it. Otherwise you're bloating your inheritance chains more and relying on run-time type checking, again, gaining nothing in return.

Answer 4

My suggestion is to use abstract pure virtual class as Interfaces OR template policy. Your system can accept only components that inherit from a specified interface OR that implements template policies. In this way your system will be aware of the fact that your component has an Update function in this way.

you could do something like this:

class Test
{
    std::vector<Interface *> items;
    public: 

        void AddComponent(T& param) 
        {
            items.push_back(&param);
        };

        void Update()
        {
            for (unsigned i = 0; i < items.size(); i++)
                items[i]->Update();
        }
};

OR

template <class T>
class Test
{
    std::vector<T *> items;
    public: 

        void AddComponent(T& param) 
        {
            items.push_back(&param);
        };

        void Update()
        {
            for (unsigned i = 0; i < items.size(); i++)
                items[i]->Update();
        }
};

The second one does not need the use of the interfaces, however the compiler will not compile the code if T does not implement a public Update function.

Answer 5

I would create the FpsPlayerControllerComponent as a sub-class of Component and create a system which process the entities that contain this component.

If you find you need another PlayerController, say, TpsPlayerController, just create a new subclass of Component and a new system, this way, your code will not need switchs or ifs.

Systems are generally more generic than that, but I think the controller system can be implemented that way, because you will probably not need FpsPlayerController and TpsPlayerController at the same time.

Answer 6

Logic in these systems? There is almost none. :) After chatting for some time about this problem with other GD.SE users, we came to a conclusion that many of us weren't really convinced by these systems that everyone's an expert with.

The original idea of components in programming was somewhere along these lines:

class MyRendererComponent { function MyFunction(){..}; data MyData; };
class MyOtherComponent { function MyOtherFunction(){..}; data MyOtherData; }
class MyEntity { MyRendererComponent C; MyOtherComponent C2; ... };

With this approach, components behave any way the entities want them to behave. Put logic into this the same way you'd put it into entities. There might appear to be some redundant glue code in this approach but all things considered, this one actually proves to require less work than any other system.

All of the other approaches are mainly meant for data-driving the engine heavily (enabling entity composition in game editors), which is what most people don't actually need (most don't even have editors). Even GTA3 didn't need it. And I'd most probably be right if I said that you don't have a bigger game in development...