Jump to content
  • Advertisement
Sign in to follow this  
atelier

entity component based architecture in C++

This topic is 2036 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello, I wrote minimum entity component based architecture in c++.

 

But I don't know this is true entity component based architecture.

 

So, please advice me if you know component based architecture. 

 

And sorry my code is little long. I attached files.

 

Thanks.

Share this post


Link to post
Share on other sites
Advertisement

Well, since there's no exact definition of what an entity component based architecture is, I guess a program which has got some entities, components and systems qualifies.

 

A few things:

typedef std::map<std::string, void*> ComponentMap;

In some methods you are using templates for the component type, but than you derive all your components from a IComponent (which is empty), so I guess you should choose, between templates, void* and IComponent*.

Also, I'd consider some kind of handle instead of a string for the key, its faster to compare and if you only need to remove one specific component from your entity, but have 2 of the same type, than you can gamble on which one is removed, but this could be done later.

template <class T>
    void addComponent(const std::string& name, T component) {
        mComponentMap[name] = &component;
    }

You are storing the address of component, but in main you are just passing a local temp variableohmy.png

 

And you now, the usual, don't put your implementation into header files, don't code stuff like systems straight into EntityManager( or you'll have to edit it every time).

 

edit: yayph34r.png

Edited by BloodyEpi

Share this post


Link to post
Share on other sites

Your code is still in an early stage, so one cannot tell much about it. It is in fact the beginning of a CES. But notice that there is no standard or just typical CES architecture; there are many possible ways of implementing it.

 

Things that came to my mind when looking at your code are these:

1.) Looking up components in maps using strings as keys (hasComponent, getComponent) is very inefficient.

2.) Your EntityManager has too many responsibilities. Managing entities should neither include updating them nor rendering them. Instead, "managing" means to deal with the lifecycle of entities, perhaps generating IDs, and granting access to cached entities by their ID.

3.) Updating entities is a task that is not monolithic. Look at the structure of a game loop to see the several steps. Your monolithic approach of EntityManager::update() will not work in the end.

4.) Notice please that some updates are asynchronous (i.e. the animation sub-system has computed a new position), while other are called contextually (i.e. processing the input state at the beginning of the game loop). E.g. it is unlikely that PositionComponent::update() is invoked synchronously.

 

My advice is to think in sub-systems, and to use components to store data and to fine control sub-systems. This is mainly for 3 reasons: First, the game loop defines a sequence of tasks that need (more or less) be processed in a specific order; this maps naturally to sub-systems. Second, some of the tasks are component overlapping, e.g. collision/proximity detection and perhaps resolution; this is not a task done well from the centric view of a single component. Third, interconnection between components can be handled more conveniently.

Edited by haegarr

Share this post


Link to post
Share on other sites

 

Things that came to my mind when looking at your code are these:

2.) Your EntityManager has too many responsibilities. Managing entities should neither include updating them nor rendering them. Instead, "managing" means to deal with the lifecycle of entities, perhaps generating IDs, and granting access to cached entities by their ID.

 

To haegarr.

 

Thank you for good advice.

About your second mind...

I understand what you mean,  certainly EntityManager has many responsibilities.

But how can I design this EntitySystem...

 

so... EntityManager has to do managing entity ids, adding and removing entities, and get entities.

And, Who Should do "update" and "draw" entities?

 

I think I have to create new class like EntitySystem.

 

 

 

 

Well, since there's no exact definition of what an entity component based architecture is, I guess a program which has got some entities, components and systems qualifies.

 

A few things:

typedef std::map<std::string, void*> ComponentMap;

In some methods you are using templates for the component type, but than you derive all your components from a IComponent (which is empty), so I guess you should choose, between templates, void* and IComponent*.

Also, I'd consider some kind of handle instead of a string for the key, its faster to compare and if you only need to remove one specific component from your entity, but have 2 of the same type, than you can gamble on which one is removed, but this could be done later.

template <class T>
    void addComponent(const std::string& name, T component) {
        mComponentMap[name] = &component;
    }

You are storing the address of component, but in main you are just passing a local temp variableohmy.png

 

And you now, the usual, don't put your implementation into header files, don't code stuff like systems straight into EntityManager( or you'll have to edit it every time).

 

edit: yayph34r.png

 

To Bloody.

Thank you for pointing it out.

Yes... I know "void*" and passing local variable issues...

I have no idea how to design ;(

 

Yeah... really difficult to design it.

Share this post


Link to post
Share on other sites

From what I've seen people either:

- use inheritance for the components, so you store you components in a vector like std::vector<key, IComponent*> (may wanna use smart pointers)

or

- use templates. So your components become simple structs, but you cant store all your different component types in one vector since they have different types, in return you get more speed if a system operates on one component type vector, since they are all lined up somewhere in memory. Its probably better to store all components of all entities in one place(vs. every component in its entity) and have the entities just keep some handles to their components.

 

For the systems, I'd just have some method on the entity manager, which you pass a system into, the entity manager can then run this system on all components.

 

And for putting components into your entities, I guess the easiest way would be something like: addComponent(std::unique_ptr<IComponent>).

 

You also need to consider the possibility that systems need more than one component type, like rendering would need a position.

Edited by BloodyEpi

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!