Hello there everyone,

I'm writing a small game while creating a component-based entity system. The game is coded in C++ and I'm using OOP to design it. I've read a lot on the matter and I think I came up with a viable solution.
There is an Entity class which has a vector of Component object. The Component class is only an interface class from which the other components inherits.

My first question comes here: I want to be able to retrieve a derived component (for example, the ComponentTransform which has functions such as setPosition()) and use its functions. So I wrote a little function in the Entity class which is as follow (most of the code is omitted):

class Entity
{
public:
Entity();
~Entity();


template <class T>
T* getComponent()
{
std::string name = typeid(T).name();

if (name.find("Transform") != std::string::npos)
return dynamic_cast<T*>(retrieveComponent("Transform"));

return NULL;
}

private:
std::vector<Component*> m_Component;
Component* retrieveComponent(std::string name);
}; // Class


The "retrieveComponent" function only returns the Component in the vector which has the same name that is passed as an argument. Is it a viable solution? I mean, is it considered OOP to check the class name with "typeid", which in this case returns "class ComponentTransform" and to then cast a pointer of the type passed? I didn't wanted to come up with a return function which returns the component from its name, because that would be error-prone from the user, but as the name check is made inside the class definition, it is safer. Is it OOP? Or at least, is it a more viable solution that to use:

pEntity->getComponent("Transform")->foo();


Now, here's my second question, regarding the update process. Each components implements 5 functions. 3 of those are named "preUpdate()", "onUpdate()", "postUpdate" (I let you guess what they do). The way I'm updating the game right now is as follow:

I have two managers: an EntityManager, which holds a vector of every Entity and a ComponentManager, which holds a vector for every type of components, which means that I have:

std::vector<ComponentTransform*> m_ComponentTransform;
std::vector<ComponentModel*> m_ComponentModel;

I'll explain why in a few moments. Now, my EntityManager is called first, which calls an "update()" method from every Entity objects in the vector. This functions enables or disables its components as needed. Then, the ComponentManager "update()" method is also called. which calls the "xxUpdate()" method from the components in a specific order. For example, ComponentModel objects' "xxUpdate()" method is called before ComponentRender's. This is way, I can truly separate the code from which components: the ComponentModel sets the mesh to render, then the ComponentRender draws it on screen, etc.

What I wanted to know is: is it a good way of updating the game data? For now, it doesn't seem to slow anything nor to be inconvenient for the coder, but still, I was wondering if there was a better way of doing it.

Tell me if there is something that I didn't explained well. I would really like to have your comments on my way of doing this as well as suggestions you could make.

Having the component name in the retrieval method violates the Open Closed principle and is certainly not OOP.

Yes, and I forgot to specify that this particular function is private in the Entity class. Is it still considered non-OOP? What would be my alternatives to retrieve a component without having to make a lot of dynamic_casting to check if the type is the correct one?

How about something like this?

problem here of course is if the component doesn't exist in the entity. I actually solved this paradigm by using slots to call functions on classes that might be there.


#include <list>
#include <cstdio>
#include <cstdlib>
#include <string>

struct IComponent
{
virtual const int& getComponentTypeIdent(void) const = 0;
};

template<class T>
struct IComponent_ : IComponent
{
static bool check_ID(const IComponent* comp)
{
return comp->getComponentTypeIdent() == IComponet_ID;
}
static T* convertComponent(const IComponent* comp)
{
return check_ID(comp) ? (T*)comp : 0;
}
const int& getComponentTypeIdent(void) const
{
return IComponet_ID;
}
static const int IComponet_ID;
};
template<class T>
const int IComponent_<T>::IComponet_ID = (int)&IComponent_<T>::IComponet_ID;

struct IEntity
{
template<class T>
T* getComponent(void)
{
std::list<IComponent*>::iterator it = Components.begin();
while (it != Components.end())
{
if (IComponent_<T>::check_ID(*it))
{
return IComponent_<T>::convertComponent(*it);
}
++it;
}
printf("Failed on retriving a component from an Entity\n");
return 0;
}
std::list<IComponent*> Components;
};

struct superComp : IComponent_<superComp>
{
void puh(void)
{
printf("superComp\n");
}
};

struct superComp1 : IComponent_<superComp1>
{
void puh1(void)
{
printf("superComp1\n");
}
};

struct superComp2 : IComponent_<superComp2>
{
void puh2(void)
{
printf("superComp2\n");
}
};
int main(int argc, char* argv[])
{
IEntity entity;
entity.Components.push_back(new superComp);
entity.Components.push_back(new superComp1);

entity.getComponent<superComp>()->puh();
return 0;
}


My implementation looks like this:


template <typename CompType>
CompType* Entity::getComponent()
{
return static_cast<CompType*>( getComponent(CompType::COMPONENT_ID) );
}

Component* Entity::getComponent(const CompIdType& compId )
{
ComponentMap::iterator i = m_components.find( compId );
if ( i == m_components.end() )
return NULL;
else
return i->second.get();
}


CompIdType is a std::string.
ComponentMap is a std::map
Every component must have a COMPONENT_ID static variable.


@Sudi:

I think my solution is similar to yours (appart from IComponent_). But it's interesting how you use the line

[font="Courier New"]const int IComponent_<T>::IComponet_ID = (int)&IComponent_<T>::IComponet_ID;[/font]

to create IDs automatically.

What do the 'I's mean in front of the class name? Is that an Interface? If yes, why IEntity?

Thank you guys for your answers as well as suggestion. So is it considered OOP to have a public enum in the Component class, then having a static const int variable defined by the values in the enum in each of the subclasses to check if the type of component is the good one?

Also, I would like to know if you have any input of my update procedure that I described in my first post?

As for your updating of components the only things that jumps out at me is first what exactly your entity manager has to do? Why do components need to be enabled or disabled? And second, why are you storing pointers to components in both the entity and the component manager? Does the entity really need to be able to query it's components directly? Could you instead store a mapping from components to their owning entity in your component system and direct all queries through that? And at that point do you even really need an Entity class? Could your entities just be a unique id?
[/quote]
I think that removing the Entity class is a good idea. I'm planning on doing that too in may game, because the code doesn't depend on the Entity class by itself. In components, I have code like:

getOwnerEntity()->getComponent<CompPhysics>();

This would be replaced by

componentManager->getComponentInEntity<CompPhysics>(getOwnerEntityId());