This days I'm doing some research on Component based entity systems. I had a first aproximation using a blackboard pattern at Entity level and components sharing this blackboard to do communication.
Doing this research I found an entity framework called Artemis, that follows a FRP structure for the entity managment. The idea seems pretty good and I'm thinking of integrating in my engine. But, I have some questions that need to be solved to fully understand this "odd" arquitecture:
1) In my first aproximation the way components shared data is pretty straight forward following the blackboard pattern. How should this be done following FRP? It seems, each system would be the ones holding all depencencies to components (Making components totally decoupled). I mean, if the collision system needs to know about physic component, movable system, etc... The collision system would import all this components and do all needed work with them. Is this right?
2) Would each system be a homogeneus or heterogeneus component container? I guess systems has to be homogeneus related to the component type they hold because the system need to know the component data to play with it during updates. This leads me to next question:
3) Doen't this arquitecture leads to have too many system/components?
4) How does an event system fit in this structure? I ussually have slot/signals in game objects for this but it seems with artemis structure there's no "Entity" concept.
Sorry for the long question and thanks in advance.
Functional reactive programming (FRP) in games. Some doubts and thoughts
I'm also building an entity-component system based somewhat of Artemis. I'm not quite at the point where I can evaluate how worthwhile it is yet though.
Yes, sort of. The way I do things, each system declares what kinds of entities it is interested in. For example, the collision system says "let me know about all entities that have both a Physics and Placement component". When an entity is added that satisfies those conditions, the collision system would be notified, and it can store off the entity id.
So the systems end up storing the entity ids of all entities that they are interested in. Then they can go through that list during their update cycle.
Not sure exactly what you mean by that, but I'll take a guess: The systems don't need to store the components, they just need to be able to access them quickly to iterate through them. The components are still stored/managed by some other object (I believe this was called ComponentMapper or something like that in the Artemis framework). So for instance, the collision system, as its iterating through its entities, would say "give me the Physics and Placement components for entity 1234".
I haven't thought this through enough. Can you give an example of a kind of event? Right now I have a sort of messaging system where you can send a message to an entity (by id). Currently I have it so that two types of things can "answer" a message:
- a system (e.g. the AnimationSystem will answer all "PlayThisClip" messages)
- a custom script attached to an entity via a Script component
I haven't gotten far enough along to know if this will be sufficient.
btw, I have some more details on my blog here: http://mtnphil.wordp...-system-part-2/
1) In my first aproximation the way components shared data is pretty straight forward following the blackboard pattern. How should this be done following FRP? It seems, each system would be the ones holding all depencencies to components (Making components totally decoupled). I mean, if the collision system needs to know about physic component, movable system, etc... The collision system would import all this components and do all needed work with them. Is this right?
Yes, sort of. The way I do things, each system declares what kinds of entities it is interested in. For example, the collision system says "let me know about all entities that have both a Physics and Placement component". When an entity is added that satisfies those conditions, the collision system would be notified, and it can store off the entity id.
So the systems end up storing the entity ids of all entities that they are interested in. Then they can go through that list during their update cycle.
2) Would each system be a homogeneus or heterogeneus component container? I guess systems has to be homogeneus related to the component type they hold because the system need to know the component data to play with it during updates. This leads me to next question:
3) Doen't this arquitecture leads to have too many system/components?
Not sure exactly what you mean by that, but I'll take a guess: The systems don't need to store the components, they just need to be able to access them quickly to iterate through them. The components are still stored/managed by some other object (I believe this was called ComponentMapper or something like that in the Artemis framework). So for instance, the collision system, as its iterating through its entities, would say "give me the Physics and Placement components for entity 1234".
4) How does an event system fit in this structure? I ussually have slot/signals in game objects for this but it seems with artemis structure there's no "Entity" concept.
I haven't thought this through enough. Can you give an example of a kind of event? Right now I have a sort of messaging system where you can send a message to an entity (by id). Currently I have it so that two types of things can "answer" a message:
- a system (e.g. the AnimationSystem will answer all "PlayThisClip" messages)
- a custom script attached to an entity via a Script component
I haven't gotten far enough along to know if this will be sufficient.
btw, I have some more details on my blog here: http://mtnphil.wordp...-system-part-2/
I'm not familiar with Artemis, and not that familiar with reactive programming so most of the commentary will be extrapolation which may not be entirely correct.
As data goes into a component, that causes reactions that causes different data to go into other components until the data has been sunk by something that has no visible output.
1) In my first aproximation the way components shared data is pretty straight forward following the blackboard pattern. How should this be done following FRP?
As data goes into a component, that causes reactions that causes different data to go into other components until the data has been sunk by something that has no visible output.
2) Would each system be a homogeneus or heterogeneus component container?
[/quote]
It depends on how you structure your systems. In FRP you'll likely compose your containers as message handlers instead of the more conventional model.
3) Doen't this arquitecture leads to have too many system/components?
[/quote]
Entity systems always do. Though 'too many' is misleading. If that's how granular you want the things, then any system is going to need many components to meet those requirements.
4) How does an event system fit in this structure? I ussually have slot/signals in game objects for this but it seems with artemis structure there's no "Entity" concept.
[/quote]
It essentially makes your entire game a giant cascading event system.
Author
@phil_t, thanks for the comments, I'm reading your blog and some of the links you provided.
@Telastin: Could you please give a bit more information on point 4. Wasn't able to get what you wanted to mean.
Thanks in advance.
@Telastin: Could you please give a bit more information on point 4. Wasn't able to get what you wanted to mean.
Thanks in advance.
@Telastin: Could you please give a bit more information on point 4. Wasn't able to get what you wanted to mean.
In FRP, you end up chaining together functions which are then triggered via input/time just as events are. This can be pictured as a cascading sort of effect where one input triggers its handlers which in turn trigger different events and so on. When done this way, the game becomes essentially a giant cascading event structure.
I am a little late coming to this discussion but I have been interested in both applying FRP to games and entity/component systems. I don't think that Artemis is an FRP system, at least not as I understand FRP. FRP is about connecting values so that updates to inputs are automatically reflected in their outputs. Here is some hypothetical FRP code in a hypothetical language:
Spreadsheet applications like Excel work in a similar manner. If you have a formula and then update one of the input values, the output values are automatically updated as well. Artemis does not work like this. Artemis is all about sets of systems that loop through entities, processing sets of components.
That's not to say you could not have an Entity/Component FRP system. I think (but have not thought through) that the Components would act as Signals that plug in through various Systems.
let a = 5;
let b = a + 2;
print b; // prints 7
let a = 10;
print b; // prints 12, NOT 7Spreadsheet applications like Excel work in a similar manner. If you have a formula and then update one of the input values, the output values are automatically updated as well. Artemis does not work like this. Artemis is all about sets of systems that loop through entities, processing sets of components.
That's not to say you could not have an Entity/Component FRP system. I think (but have not thought through) that the Components would act as Signals that plug in through various Systems.
i would say that Artemis is FRP-like, in that its reactive in that any change to a component will have an immediate affect on the entity without the entity being "updated" and an immediate affect on the way systems operate on it... i guess it could be said to be functional since the systems should perform a unique function and only a unique function (ideally) and therefore should be functional in behavior and not procedural.
In your example, the relationship would be that a and b are functional variables (synonymous to systems) and they are literally pointers to functions, with a being the function of "get integer" and b being function of "sum function a with integer". The integers in this case are components, so swapping component 5 with component 10 causes functional variable b to have a different valuation the next time it is read.
In your example, the relationship would be that a and b are functional variables (synonymous to systems) and they are literally pointers to functions, with a being the function of "get integer" and b being function of "sum function a with integer". The integers in this case are components, so swapping component 5 with component 10 causes functional variable b to have a different valuation the next time it is read.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
