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.
Interested in Component/Entity Systems
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.
Entity/Component systems differ widely in implementation and concept, so don't take any single source as gospel, but these 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.
Author
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.
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.
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?
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. Normalization as a concept is useful for data layout in general, and is essentially the driving concept behind entity systems.
Author
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.
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.
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.
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.
Author
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.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement