About

I'm a software engineer who works on game development part time. I teach game development (on gamedev.stackexchange.com and lynda.com). I'm always working on something, and I'll post updates here. Let me know if there's a game development topic you want to know more about, I probably know the answer, or at least where to get one.

Sunday, February 16, 2014

Entity system differences

I was recently posed the question:

In your opinion, what are the biggest advantages of system-driven entity component system (as described in your answer here) as opposed to putting logic right into components themselves (similar to how Unity does things)?

The advantages depend on the requirements of the game. The two styles are pretty similar really, so the biggest advantages are going to derive from personal style preferences.

The main differences I can see are when and where things get processed. With the system approach, you know that processing will take place grouped by component type. With the Unity approach, processing will take place by entity. For example, a simple set of entities (E1 and E2) with their components:

E1: C:Movement, C:Pathfinding, C:Attack
E2: C:Movement, C:Pathfinding, C:Attack

With Unity the overall processing order might look like:

E1:C:Pathfinding
E1:C:Movement
E1:C:Attack
---
E2:C:Pathfinding
E2:C:Movement
E2:C:Attack

Notice everything grouped by the entity. With a system like the one described in my answer everything would run grouped by system:

E1:C:Pathfinding
E2:C:Pathfinding
---
E1:C:Movement
E2:C:Movement
---
E1:C:Attack
E2:C:Attack

So in the end, the same code gets run, but the order is different. While Unity does have some features to change the order, like using Update() vs LateUpdate(), it's not going to group things by components for all entities.

As I said, the advantages of changing the order really depend on the requirements of the game. In a lot of cases, the design of a game could easily be adapted to work with either system. So when designing your own system, it's important to keep these differences in mind and make the design work appropriately for your style.

4 comments:

  1. There is another, more subtle difference. In the systems approach you often have better data locality. For example when performing path finding: in a system everything related to path finding can be brought into cache and mostly stay there untill path finding has been performed for all entities. In a component based approach path finding data might be thrown out of the cache in favour of other data that the component needs to process before the next component starts and has to load path finding data again.

    ReplyDelete
  2. Thank you, Michael.

    So really the biggest thing is how it fits your coding style and design at hand. For me, it's more natural to put logic right into components. But roytriesscheijn has a good point, too, though.

    ReplyDelete
  3. Great point Roy. When processing all the components of one type together, it's easier to also cache common data. One might be able to do this with the component based approach as well, having some kind of per-frame cache, but the implementation would likely be more-error prone and harder to predict behavior. Thanks for your input.

    ReplyDelete
  4. Yep, it's one of those things where it depends on what you're doing. Personally, if I were designing my own system from the start, I'd go with the systems approach. I can see more flexibility and opportunities for customization/optimization.

    ReplyDelete