So I have this data-oriented-ish entity-component system.
The purpose of this is to be able to define entities entirely through their properties, and being able to assign or remove properties at runtime.
I'm running into problems with my current implementation and I am thinking about reworking the entire thing.
And since Casey has started tackling this topic on HMH the timing feels quite appropriate.
An overview of the current structure.
There's the notion of a "layer" which acts as the entity manager and gets a bunch of component managers assigned to it. The component managers all use a base struct that contains general information, like mapping entities to component indices or "instances".
Component instances are then iterated through various arbitrary systems that are nothing more than functions. These are the backbone of the program, performing all logic, draw-calls etc.
What works well so far :)
Since the data is packed together it's easy to process in the systems.
What doesn't :(
Interactions between components of different types. If an entity has more than one component chances are high that those components are supposed to affect each other in some way.
It's basically the same issue that Casey described with the "Act-React" model. A lot of querying has to be done in order to find out if an entity has a certain combination of components.
Performance aside, this adds extra complexity and code to the systems processing the data.
While I don't understand how Casey will implement his entity system, the idea of putting all properties in one struct made me think about the relationship between components of different types.
It seems to me that most cases will be about sharing properties, or one dictating the properties of the other, basically transferring of data.
So if the properties shared the same data in the first place then no additional relationships would need to be implemented in the systems.
The very rough idea for the new system.
Component managers are reduced to the functions they used previously to manipulate the data. Entities are used as the key for locating that data.
The function usage implies that the entity "has" the relevant property.
Since functions have access to all properties they can override operations done before them, or blend for that matter.
So what's the problem?
I don't really know how to implement this, let alone I'm not sure if this approach is feasible.
The biggest question-mark is mapping entities to their properties, and vice versa. This could potentially result in way more queries than what I have currently, but I'm not well read into techniques like hashing and lookup-tables so I imagine that there must be some way of solving this effectively.
To conclude this long-ass post, I'm hunting for ideas. Any topics I should read into? How would you approach an entity system of this kind?