Sign in to follow this  
irras88

Interested in Component/Entity Systems

Recommended Posts

So I've been reading/working through this Allegro book of mine and it's very helpful and all but... it's pretty much completely written in C. No OO concepts here at all and I'm learning quickly that this is a fast route to a dead end.

However, after stalking through the forums a little bit I discovered the existence of component programming and entity systems and began looking for resources on the subjects, but I am coming up a little dry. I get the basic structures of each, but I can't seem to find a good detailed explanation of them. Or perhaps I'm not looking in the right places.

Could someone link me to some resources on the subjects? I'd love it if you could include some working source-code examples of small games that use these systems, so I can get a clearer idea on the implementation.

Share this post


Link to post
Share on other sites
[quote name='irras' timestamp='1310567297' post='4834836']
So I've been reading/working through this Allegro book of mine and it's very helpful and all but... it's pretty much completely written in C. No OO concepts here at all and I'm learning quickly that this is a fast route to a dead end.

However, after stalking through the forums a little bit I discovered the existence of component programming and entity systems and began looking for resources on the subjects, but I am coming up a little dry. I get the basic structures of each, but I can't seem to find a good detailed explanation of them. Or perhaps I'm not looking in the right places.

Could someone link me to some resources on the subjects? I'd love it if you could include some working source-code examples of small games that use these systems, so I can get a clearer idea on the implementation.
[/quote]

Entity/Component systems differ widely in implementation and concept, so don't take any single source as gospel, but [url="http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/"]these[/url] articles do a good job of at least explaining some of the logic behind their use. It is a good place to get started. Also, Entity/Component systems have the added benefit of not requiring heavy OOP knowledge ahead of time in order to understand and work with.

Share this post


Link to post
Share on other sites
Thanks, that was a pretty good read.

Are all Entity/Component systems run off of a database or otherwise programmed in the style of a database? Or do entity systems (in a more general sense) involve the use of aggregation instead of inheritance?

I want to ask more questions but even after reading all that and reading other stuff, I feel like I'm missing something... either with my own limited programming expertise or with entity systems themselves... Maybe if I dive into creating something really simple using what I know about entity systems, I'll come to some conclusions.

Share this post


Link to post
Share on other sites
[quote name='irras' timestamp='1310665581' post='4835350']
Are all Entity/Component systems run off of a database or otherwise programmed in the style of a database?
Or do entity systems (in a more general sense) involve the use of aggregation instead of inheritance?
[/quote]

They're not all run off a database. They tend to work in the style of a database since databases often need to do similar separation and mixing of data. [url="http://en.wikipedia.org/wiki/Database_normalization"]Normalization[/url] as a concept is useful for data layout in general, and is essentially the driving concept behind entity systems.

Share this post


Link to post
Share on other sites
I see. Makes sense.

One huge thing I can't wrap my head around is how input is done in this kind of system. If a single entity has an input component and a separate component that holds the "physical" data of that entity, how does the input component apply those changes to the "physical" component? It seems to me that this violates part of what makes this system what it is.

Share this post


Link to post
Share on other sites
[quote name='irras' timestamp='1310680032' post='4835446']
I see. Makes sense.

One huge thing I can't wrap my head around is how input is done in this kind of system. If a single entity has an input component and a separate component that holds the "physical" data of that entity, how does the input component apply those changes to the "physical" component? It seems to me that this violates part of what makes this system what it is.
[/quote]


Some entity/component systems allow the logic to exist inside the component who self-updates, and notifies the entity if other components should be modified, while others seperate logic into independent "systems" that operate and update the components. In this case, Input could be a system that updates components as needed, or notifies other systems that updates need to be made to the components for which those systems are responsible. Almost all entity/component frameworks use some sort of messaging or eventing system for notifications.

Share this post


Link to post
Share on other sites
[quote name='arbitus' timestamp='1310683270' post='4835463']
Some entity/component systems allow the logic to exist inside the component who self-updates, and notifies the entity if other components should be modified, while others seperate logic into independent "systems" that operate and update the components. In this case, Input could be a system that updates components as needed, or notifies other systems that updates need to be made to the components for which those systems are responsible. Almost all entity/component frameworks use some sort of messaging or eventing system for notifications.
[/quote]

So basically, the component does the grunt work and then tells it's entity what needs to be changed
OR
Scratch the notion of an input "component" and turn it into an overarching system that works on all entities.

...that's pretty much what I figured. I guess I just need to keep racking my brain for the code implementation... thanks.

Share this post


Link to post
Share on other sites
My advice is to just start playing with it and make it do something. Do whatever feels most natural in order to accomplish the task. You can always refactor and re-examine the architecture later, once you are more familiar with it. Entity/component systems are hard to grok until you actually use them to do something.

Share this post


Link to post
Share on other sites
Yeah I'm currently attempting to do that now [img]http://public.gamedev.net/public/style_emoticons/default/biggrin.gif[/img]

Thanks for the help.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this