Functional reactive programming (FRP) in games. Some doubts and thoughts

Question

These days, I'm doing some research on component-based entity systems. I had a first approximation, using a blackboard pattern at the entity level, and with 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 management. The idea seems pretty good, and I'm thinking of integrating in to my engine. I have some questions that need to be solved to fully understand this "odd" architecture:

1. In my first approximation, 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 dependencies to the components, making components totally decoupled. If the collision system needs to know about physic component, movable system, etc; the collision system would import all of these components, and do all needed work with them. Is that right?

2. Would each system be a homogeneous or heterogeneous component container? I guess its system has to be homogeneous, related to the component type it holds, because the system needs to know the component data, to play with it during updates. This leads me to next question:

3. Does this architecture lead to too many system/components?

4. How does an event system fit in to this structure? I usually have slot/signals in game objects, for this, but it seems there is no "Entity" concept with the Artemis structure.

Answer 1

Not an expert, but doing something fairly similar; my thoughts:

1) In general, each system will scan the components (of all entities) that are of a type in which it is interested for some condition that it can handle. A “Gravity” system might ignore “position” components that have a “flying” flag, for example. One way of handling the component data locking and preserving immutable data (although I haven't looked into Artemis) is to remove the “previous” state from the set, pass it into the system, and have that system return the “new” immutable state.

2) I believe the answer is “homogenous,” although I'm unclear as to how you mean it. Each component (e.g. “position” or “affinity to spontaneously combust”) is a “record;” every component of a given type has the same fields; but every type of component has distinct (and non-duplicated) fields.

3) Entity systems are designed around that idea. The “ideal” system would have one system for every type of interaction in the game. In real life, sometimes things that are closely related are ganged together for efficiency.

4) Events can be replaced by state changes in the components. Entity systems, of course, don't lend themselves to having “objects” in the OOP sense; but where an “entity” is a “game object,” an “event” could be:

• attaching a new component to the entity (making it susceptible to effects from other systems)
• changing the state of that component (thus, systems listening for that state change would be triggered)

The “blackboard system” dispatcher would them be responsible for observing new records being inserted and triggering the systems that might want/need to handle those records in their new state, subject to (perhaps) timer-based rate limits or other effects.

Answer 2

I worked with both "componentbased game-objects" and "functional reactive programming". As you've used "functional programming" in the title already, I will give an answer from an functional programming perspective, but still keep in mind your componentbased perspective.

Doing this research I found an entity framework called Artemis, that follows a FRP structure for the entity managment.

This doesn't make any sense. Please look up the definition of FRP! FRP is a concept on how to handle calculations and depdencies between data in reaction to an external event. I took a quick look at Artemis and I think it's called a componentbased game-object architecture.

The idea seems pretty good and I'm thinking of integrating in my engine.

Please consider extending an existing engine.

@1

shared data is pretty straight forward following the blackboard pattern

Believe me, you don't want to share data. You're creating something similar to a global variable, and we all learned that we shouldn't use them, didn't we? Mathematically speaking you're breaking functional dependency and you will get in a lot trouble with interdependencies and in the long run your brain will explode.

How should this be done following FRP?

You differ between intra-object communication (via reactive values. think signal/slots) and inter-object communication (via messages).

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?

The collision system handles functionality concerning more than one game object, thus it must be separate from an independent actor and only communicate via messages. The collision system doesn't need to know anything except the position and physical extension of the object.

@2 see BRPocock's answer. But yet again, the system shouldn't know anything about a components data.

@3

Doesn't this architecture leads to have too many system/components?

Correct. Object-oriented programming at it's best ;)

@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.

Aren't there any identites of some kind? If not, than I assume there's an "implicit protocol" based on component types. Have fun then!