2
\$\begingroup\$

Whenever an entity is being added to an entity controller (which is essentially just a bag of entities), I scan through it's components to figure out if I need to register additional entity processors (game systems). For instance, if I add an entity which has a SpriteComponent attached to it for the first time, the EntityController resolves the e.g. SpriteRenderSystem using a factory and a simple specification, which is then being registered within the controller.

Now I'd like to make it possible to figure out whether the component of an entity has changed. I was suggested in off-topic discussion elsewhere that I should use an eventing system to raise component change events in order to have the entity rescanned.

However this has two problems, I think:

  • The entity, which was a simple component bag beforehand, now holds a dependency to a event bus.

  • An event bus traditionally raises global fire-and-forget events. My entitiy controllers are the base of scenes (individual game states to activate/deactivate entities together) - and there can be many scenes active at once. When a component changed event fires, then I ask myself: In which entity controller is the affected entity? Scanning all controllers for whether they contain the entity sounds expensive.

Another option would simply make the entity aware of the entity controllers in order to signal "Hey, I have changed!". However should an entity know where it's currently attached to?

\$\endgroup\$
2
\$\begingroup\$

Whenever a Entity is added to a Entity Controller (EC), this EC registers to ComponentAdded and ComponentRemoved events from the Entity.

When a Component is added or removed from an Entity, fire the proper event.

The event handler of EC is called, then you can insert or remove the Entity from Systems according to the Components it has at the moment.

\$\endgroup\$
  • \$\begingroup\$ So in C#, this would be best being done using plain old event delegates? \$\endgroup\$ – artganify Jan 26 '16 at 15:03
  • \$\begingroup\$ Yes. I don't see any contraindication for that. My ECS is based on events and it works very well! These events aren't meant to be used by the game code, so it's all encapsulated inside the ECS library. \$\endgroup\$ – Emir Lima Jan 26 '16 at 16:16
  • \$\begingroup\$ Well, I was worried a little because I code against a contract (IEntity) which only provides the entity's id and it's components. Based on that, I have an implementation (EntityBase) which I use for in-game stuff and EntityMetadata which is being serialized. Providing events on the contract didn't make any sense because then I'd be forced to implement the events on the serializable class, which is not really nice. But it does the job, I think. :) So thank you very much. \$\endgroup\$ – artganify Jan 27 '16 at 19:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.