Not really. I know the theory behind the thing, but you're going right over all of the things that matter.
How are the components wired together, or your entities and the systems? How do they know where to go and how to interact with things.
If a component is purely data, why would they be wired together? In which entities they go really depends on you. A component is just data that make up an entity. It represents the characteristics of an entity.
When you add killHistory, how is that hooked into the other entities so that it gets updated? What happens when things can die from not-damage?
The killHistory component was just a way to avoid direct communication between 2 different systems. In the example I've mentioned, the scoringSystem works on entities that have both a killHistory and score components. You could have a system directly communicate with another if you wanted to. If something can die from some other causes than damage, then you'd have an other system do logic for that. If a player can be poisoned, create a poisoningSystem which diminishes the health component if an entity also has a drugged component for example. It really is up to you. The mechanism is there for you to program using a data driven paradigm.
Edit all of the different things that can cause something else to die? No. The entire point of these structures is to make it that components can be added without going back and screwing around with existing ones.
Yes, components can be added, but using the requirements I have mentioned earlier, a system must also be in place to do logic based on these components. If you create component "foo" and there is no system that processes it, then there is no point. Systems apply logic depending on specific components they work with.
You don't spell out how these cascading effects actually align so they don't cause cycles or thrashing or work at all since they're order dependent. You don't spell out how components see state changes. Keeping the last known state is... no. Events just end up in some cascading ball of poo.
I have specific classes as the core of my engine that help out with these things. When I create a new system, I apply component requirements. This system will only process entities with these requirements. I then add this system in my system manager which works with my entity manager. The entity manager keeps track of "families" for each system. A family is a list of entities that have the proper components required by each registered system in the system manager. I also have an event manager that can run systems periodically, right away, or even in a certain order. For example, my rendering system is triggered by my event manager at a pace of 60 fps. As far as components seeing state changes... they don't. Again components have no logic what so ever. Systems see if entities have updated changes. I have yet to implement that as part of my core, but there are multiple ways to approach that problem depending on your engine architecture.
Sorry to be curt
No problem, I'm just trying to help...
Determining what components were available to the entity via configuration, including tying all of the dependencies together.
I don't think I understand this. Only dependencies I have are component requirements for each system. I solved this using families (tracked in my entity manager).
Communicating between components within a common entity.
Again, communication can only happen where there is logic. Only systems can interacts with each other, though I try to avoid that so that each system only deals with itself instead of keeping references to other systems. Sometimes though, there is no way around it.
Exposing the aggregate functionality so that the entity was more than 'update this every frame or so' (unless you found that unnecessary)
I don't think I understand this either. An entity has no logic either. Systems update using my event manager. Either I run a system every certain intervals or immediately. For example, my rendering system has a octree sub-system to partition my space. When my even manager triggers my renderer to run @ an interval of 60fps, the renderer will ask the event manager to run the octree system once before rendering.
Right now, the existing code base is by and large a giant (both wide and deep) inheritance hierarchy, populated by string dictionaries and wired together with tin cans and string (generic ValueChanged events). This blows goats.
- Read some data that defines a device.
- Using that data, populate the features that the device can support. There are ~300 features, and for the sake of discussion, they share no natural traits. They all have various behaviors that need to be set and otherwise twiddled, and tend to interact with one another. A given device will almost always have >100 features. About 8 of them are on every device.
- Allow new configs, and new features that can be deployed independently of existing ones.
If a conventional OO design can do these things well, that would be awesome. But I don't see it. I also don't see how a component system can be implemented without getting into a giant grey gooey mess that is impossible to debug and fragile as hell.
I still have no idea what you're trying to do. What do you mean by device & features? Perhaps an entity system isn't the way to go? But without a clear understanding of what your goals are, I'm afraid I can't help much.
An entity system is useful for data driven applications. A game will have many assets and resources hence it is why an entity system is useful. A level designer or content creator can use tools. These tools create files that represent entities and their components. At load time, the engine parses the files and generates the entities and adds the correct components. It then registers everything, and if the systems are already in place to process these entities with these components, everything should run automatically.
Edited by french_hustler, 25 July 2012 - 11:33 PM.