XianForce's Blog

So I've been looking at the structure of my Entity System, and it is horribly ugly. I'm like halfway between a Hierarchal and Component Entity System. So I'm going to revise the Entity System into a Component Entity System. One huge thing that I've found to be a problem, and what I've been working on the most, is making sure projectiles don't disappear when the entity that fired them is destroyed. When that entity is destroyed, it's weapon system is destroyed, along with any bullets it fired. I'd have to set up a system to handle the destruction and creation of the bullets, and have the weapon system have a dependency on it.

Well my new Entity System will solve these issues and others :D. My abstract Component class will look like this:

class IComponent

{

private:

std::string mComponentType;

Entity* m_pOwner;

public:

IComponent();

virtual ~IComponent();

virtual void OnUpdate() = 0;

virtual void OnSerialize() = 0;

virtual void OnDeserialize() = 0;

virtual void OnDebug() = 0;

std::string GetComponentType() const { return mComponentType; }

void SetComponentType(std::string compType) { mComponentType = compType; }

Entity* GetOwner() const { return m_pOwner; }

void SetOwner(Entity* owner) { m_pOwner = owner; }

};

I may add Init and Quit functions depending on the components I'll need, but that will be later.

So each component will derive from this interface and implement all these functions. Each frame when an Entity is updated, it will iterate through all it's components and update them. If I want to access debug information, that's what OnDebug will handle. Serialization of a component will basically 'save the settings' of that component'. With it, I can Serialize all of an entities components, so that I essentially have that entity saved, and can recreate it. Deserialization reads this information. So it can be thought of as a 'Save' and 'Load'.

This all sounds fine and dandy, but how exactly does this help solve my dependency issues? Well I'm going to create a few 'Factories'. Factories are basically objects that help construct complex objects. With this Component Entity System, I'll have a Component Factory and an Entity Factory.

These Factories will have dependencies on every major system (and perhaps subsystems) of the game. So construction will be something like:

EntityFactory->ConstructEntity("ThisEntity");

//In the definition of that function...

Component* transformComponent = new TransformComponent();

Entity* pEntity = new Entity();

transformComponent->SetDependency(Camera);

pEntity->AttachComponent(transformComponent);

EntityManager->AttachEntity(pEntity);

The actual code will be slightly different, but the idea is still there. In this example, the Transform Component has a dependency on the Camera. Which will actually be a dependency in game. The Transform will be a 4x4 matrix which represents an Entity's position, orientation, and scaling on the screen. It is in Screen Coordinates. The Entity's world position will be handled by another component, the LocationComponent. This means that the TransformComponent also has a dependency on the LocationComponent. So how do we solve this? Well thanks to a few posts from GyroVorbis, I've thought of a system that is likely similar to their's (probably less intense though...).

So basically, Entities will be a container of Components, and will have all the virtual functions that Components have (which will just iterate through and make the call to each Component). It will contain a map of Components with Strings as the key. Since each component holds a pointer to it's owner, it can do something like: m_pOwner->GetComponent(). The GetComponent function will take in a string that represents the type of component. Then a handy dandy find algorithm (courtesy of STL) I can see if that type exists in that map. If it's there, return it, and it's now a happy day :D.

So I think this will definitely be an improvement in code structure, which will help development along once I'm finished :D.

Just so you have an idea, these are the components I plan to have in Charge so far:

-WeaponComponent

-AnimationComponent

-MovementComponent

-LocationComponent

-CollisionComponent

-RenderComponent

-HealthComponent

-InputComponent

-AIComponent (This will very likely be broken down into multiple components...)

Well that's it for now, back to refactoring :/