The best way i've found to think of ECS Frameworks is to think of them like a database.
Components are Rows in a Table (Component Types), Entities are Primary Keys, and Systems are mechanisms that operate (Create, Read, Update, Delete) on one to many tables (component types) based on their current Primary Key (Entity) of interest.
Treat Entities like a unique ID (literally just an ID container, and nothing more). They shouldnt track anything, let an Entity Management class do that. Entities can literally be as simple as a bit array with their id being their index with true being active and false representing deactivated/unactivated entities. Although i prefer a very lightweight class with just an int for ID (allows me to map to component arrays to quickly establish ownership of a component in the array {it owns the component at the ID's index}). Components should strictly be data containers and nothing more (avoid observer patterns if you can, let a manager take care of that during an update cycle), and let Systems do all the work and communications. These simple concepts will help you do well, and keep things decoupled which will give you TONS of flexibility and allow for easier expansion as you add more features.
Granularity in your components is important. They should describe enough to get the job done, but not more than is required. Don't make them monolithic and dont make them microscopic. This prevents you from having too many specialized systems or too many component retreivals. If you find you use your Velocity component always with a positional component, perhaps you should merge them into a movement or spatial component. Instead of components for each joint in a model, perhaps just have a skeleton component that encompases all the joints required. Don't have a "player" component, just tag an entity as "the player" and build it as you would any other entity.
Finally, when you write your systems, try to keep them as generic as possible. A missile system shouldn't care if its a player or a monster shooting something, only that you have an emission point, a projectile, and a direction. This keeps specialization down and allows you to construct entities alot easier. Systems can be active (execute every update cycle), Passive (execute when called by another system or event), Semi-active (delayed or intermittent), etc. so don't think they all have to behave the same either.
Anyway, hope that helps
Fascinating. I never thought about it like that, but it makes sense. Once again (sorry), I have a couple questions. Organizing the data like that is easy enough, and delegating each component type to its own manager is easy enough as well. The part that I'm still a little confused about is where the overall entity logic should be. For instance, if your player is just another entity, and its components are spread out among all these independent systems, how do you collaborate when them in order to build game logic? I'd imagine you have some sort of player controller that handles input and such, but you also need logic to handle things like whether the player is dead yet, if he can throw a grenade or not, whether he's invincible, etc. How would your system wrap things up neatly into a usable higher level entity (i.e. an object that holds the entity primary key + whatever component keys it needs).
This becomes difficult once you require a completely data driven architecture, because you can't just create a player class that holds the primary key of the entity and links to its components. Either you're going to need to be able to query the entity manager for specific components (which gets back to Hodgeman's point about requiring one of everything), or point components at each other. If we think about the entity as data, and the systems themselves as logic, it's hard for me to wrap my mind around how this would work in real life--because the logic is so fragmented among systems.
I really like your idea of an xml template/instance architecture. Is that something you developed for a hobby project? Do you have some source code samples you could share? Or maybe a sample xml file? It sounds really neat.
Thanks for taking the time to answer my questions. I wish I could meet one of you guys in person and talk about it over a white board. It's tough communicating stuff like this over text sometimes.
*edit* I've been some blogs, and I came across this excerpt on piemaster.net about the Artemis framework:
The logic is instead encapsulated in the Systems that accompany the entities and components. A ‘System’ is simply an object that reads and updates the data in any relevant components. You could say it’s simply the update function of the relevant components refactored into its own object.
I say “relevant components” because of how the systems do their processing. Instead of the game iterating imperatively through all of the entities and updating each in turn, the systems take more of a functional programming approach. Each system specifies a set of components that it’s interested in, and then in each frame it processes only those entities that contain all specified components.
Furthermore, each system exists to perform a specific role, updating all instances of the relevant components before passing control to the next system. You could say that the components are processed in cross-sections across all entities at once, rather than entities (and all of their child components) being processed in chunks.
So somehow, the systems themselves compose the game logic, and when they so require, they can bring in various components with certain qualities.