ECS with Enumeration Components

I found an article that discusses the issue more thoroughly than me. So I’ll make this writing a summary of his.

Enumeration components, or polymorphic components, sounds like a word of nah in an ECS architecture. However, there are times when the variation is needed, e.g. a state machine with Running, Walking and Standing states.

Two inferior solutions exist.

1. Create syntactically independent components that are added & removed from entities as their states change. This approach has the benefit of not having to do branching in each system which only cares about a few states, but incurs unneglectable overhead in archetype ECS’s when modifying entities. Even in sparse-set ECS’s, it is not good for as states evolve the set will be swarmed by very sparse state tables. After all, that is like scattering every internal details across the public space, totally ruining information locality and going back to the “good-old global variables days”.
2. Use polymorphic components, such as enumerations or virtual tables. This is the most OOP way and might be easy to think of, but is de facto a surrender to the old mindset, which loses the virtue of ECS. In this way, it is likely that we create “god” systems that control everything about entities that have states, which hurts the maintainability, the efficiency, and results in inefficient dispatching.

The best solutions points to the eternal idea prominent in databases: split tables. Oh sorry, I mean storing different states in the same state machines separately. Actually, this idea perfectly coheres to that of ECS’s: structures of arrays. It’s only that we are doing it in a smaller, more internal scope.

Specifically, we store the 3 states Running, Walking and Standing separately in their arrays. The arrays serve as maps from states to entities unordered. for each entity that has this state, the component MovementState no longer holds the actual states, but indices into the array (of course, for implementations this can be pointers etc.). When we want to process entities with the Walking status, we simply go find the state array (it is a resource, not a component) and iterate through it. When we want to switch among states, we just pop the entry and re-push into another array.

An open issue of this approach, is that both the linked-list method in the referenced article and the array-swap method I used introduce lower cache-friendliness. As the state switches go on, the order of the entities with the same states will be randomly shuffled. A potential solution might be to periodically sort the array, but real benchmarks and profiling should come first.

Some Nagging

It is a common misunderstanding that the ECS system is so simple that we no longer have to think of abstraction and encapsulations, but that’s wrong. Abstraction and encapsulation, as well as many other concepts, are not unique to OOP, but to Software Engineering in the whole. Even with an ECS architecture, we still have to design the hierarchies, and the skills we developed in OOP might still of use now. There is no easy way.

Designing the structure of a program is an intrinsically hard task. Yet there exist too many programmers who dream of a magic pattern which if they apply they instantaneously get rid of the difficulties as long as they apply the boilerplates.

How is that possible? whatever we say, OOP, FP, OOD, and now ECS, we introduce more and more to our terminology, gaining nothing. The hypes, due to the laziness in many programmers, will continue without end. I only hope that out of the many fancy words new learners can grasp the very basis of program designing.

ECS with Enumeration Components

原文：https://www.cnblogs.com/seideun/p/14401920.html