Jump to content
  • Advertisement
Sign in to follow this  
Ryan_001

Entity/Component question

This topic is 2218 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

There's been a few Entity/Component questions on various game forums and reading them has piqued my interest. I've been browsing around Google and the various Blogs/sites it has sent me to and have come across some interesting pages, but am still left with a few questions about Entity/Component systems.

The 'flavor' of EC systems that interested me the most was where components are primarily just data (bags of data, as I've seen them called), and have no methods attached (other than say simple get/set methods where convenient) and most of the logic is defined in 'system' functions (as I've seen them called) which perform their logic on all the entities that have the required component(s).
Ok so that in mind I have a couple questions:

1) Do EC systems allow for duplicate components of a the same type in the same Entity, and if so how do they manage them? For example, say I was using a buff/debuff system ala WoW, WC3, or LOL. Would/could I model each buff or debuff as a component, adding and removing them from the Entity as necessary? Or is this a too granular approach, and each component must be unique? I'm sure I could think of other situations as well where having multiple components of the same type could be useful, but I'm not sure how they would be handled.

2) Despite the logic being in 'system wide' functions that can easily handle entity interdependence (ie. the 'render' function could get all the entities that have light components, and then render all the entities that have renderable components with the light data, without the entities ever needing to know of each other), is there a way to easily add inter-component dependencies? For example say I have a priest entity with the 'heal' component. How would I model a 'talent tree' component that modified the 'heal' component?

3) This is a bit more esoteric question. When implementing a function to be called on a group of entities, there seems to be a similarity to database queries, where I select all the entities that have a given set of components to be passed on to the function. Is this just coincidence, or is there a deeper relationship between database-type queries and EC 'functions' that I'm not aware of? Would it make sense to allow more complex queries over entities (select all entities with component X but not component Y, ect...)? How would this all play out?
Anyways just some general questions/musing. Any thoughts are appreciated and thanks in advance for your time ;)

Share this post


Link to post
Share on other sites
Advertisement
1) Many E/C systems that I've used don't allow more than 1 component of a specific type per entity, but IMHO, this is a very silly restriction.
Depending on how you keep track of the 'connections', it's pretty simple:struct Component { Entity* parent; }//if components track their owner
or
struct Entity{ vector<Component*> children };//if entities track their children
2) As usual - a link/reference/pointer is just another blob of data in the bag struct Heal { Entity* target; }; struct TalentTree { Heal* heal; }3) Systems that are pools of components is basically the same as the RDMS concept of tables/records (where tables = systems and records = components). I don't know if that's intentional, more likely just that tables are just a recurring "design pattern" or idiom across most software.

Share this post


Link to post
Share on other sites
So, if you cross-post your question, here is my cross-posted answer:

Whether your EC system allows multiple components is merely a design question. It is a bit easier to write an EC system which allows only one component of any type per entity. How to manage them depends strongly on how the basic entity system is implemented. In my case, I have a mapping from component types to a struct that contains the entity identifier and the component. If I wanted to add multiple components of the same type, I could either turn the struct into a struct of entity identifier plus list of components or I could turn the mapping into a mapping that allows multiple values per key (like a multimap in C++ for example). You have to consider your function call interface, though. My EC system allows me to state requests like "call this function object for every entity that contains component types A, B, C and D.". The matching components would then be passed by reference as parameters to the specified function object, so that the function objects may actually be really small and are easy to write. If you allowed multiple components of the same type, this interface needed to contain lists or arrays of components, which could then not be pure references anymore.
So, it is possible and it is not that hard to do really, but you need to be aware that it will change a lot in the way you write the rest of your code.
Interdependencies as in your question #2 can be handled by adding another tiny function that requests all entities which have a 'heal' component as well a 'nasty_modifier_for_heal' component and do something with them. I personally would implement the talent tree itself outside of the entity system and use it to add specific talents or modifiers to the priest entity, but there may be different opinions on this one.
In fact, I used an article I found on the interwebs (http://entity-systems.wikidot.com/rdbms-with-code-in-systems) as the basis of my own EC system (though rewritten to match C++-mentality). In this article series, the resemblence of a relational database system is pointed out very clear. I think the resemblence comes from the fact, that the EC system maybe modeled quite easily using an entity (look at the name ;-)) releationship database model. If you think, such complex queries make the rest of your coding easier, go ahead and implement it. There are no reasons I could think of that would discourage such a query system. Be adviced though, that you will have a much harder time to get a nice and clean interface for the game logic coders (yourself?) by doing this.

Share this post


Link to post
Share on other sites
Thank-you for the insights. I posted the question on TIGSource 2 days ago and got no answers so that's why I posted here. I haven't implemented anything yet, just trying to gather ideas. Seems everyone has a different take on the EC problem and was just trying to get an idea of what people are thinking.

One thing that's interesting is that it seems common to relate EC to a data base, but everytime I've seen it described as such the mapping from EC construct to database construct has been different.

Anyways thanks for the replies, more to read and think about ;)

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!