unity ecs 状态机_为什么在ECS中存储状态机是一个坏主意。

unity ecs 状态机

Edit: a previous version of this post contained a description of a naive sparse set implementation, whereas actual implementations use more optimal solutions. I changed the post to reflect this.

编辑：这篇文章的先前版本包含对天真的稀疏集实现的描述，而实际的实现则使用更优化的解决方案。 我更改了帖子以反映这一点。

Disclaimer: I am the author of Flecs, a C/C++ Entity Component System. Flecs Discord: https://discord.gg/ZSSyqty

免责声明：我是Flecs (C / C ++实体组件系统)的作者。 Flecs Discord： https ：//discord.gg/ZSSyqty

If you are using an ECS (Entity Component System) for the development of a game, chances are that at some point you had to ask yourself whether you wanted to store the state machine in ECS. I have, and I reached the conclusion that it was a bad idea, for more than one reason. In this post I will go over why this is a bad idea, why having state machines in ECS would be nice nonetheless, and how I overcame the issues with them in Flecs.

如果您使用ECS(实体组件系统)进行游戏开发，则很有可能在某些时候您必须问自己是否要将状态机存储在ECS中。 我已经得出结论，这是一个坏主意，原因有多个。 在这篇文章中，我将探讨为什么这是一个坏主意，为什么在ECS中拥有状态机仍然会很好，以及我如何在Flecs中克服它们的问题。

First let’s talk about those issues. At first state machines don’t seem like a big problem. Most ECS implementations allow applications to define tags, which are essentially components without data. A state in a state machine, it seems, could easily be mapped to a tag. When we want to move an entity between states, we remove one tag and add another. Seems easy enough.

首先让我们谈谈这些问题。 起初，状态机似乎不是一个大问题。 大多数ECS实施允许应用程序定义标签，这些标签本质上是没有数据的组件。 看来，状态机中的状态很容易映射到标签。 当我们想在状态之间移动实体时，我们删除一个标签，然后添加另一个标签。 似乎很容易。

It turns out that each ECS flavor has unique challenges when trying to implement state machines this way. Let’s start with …

事实证明，尝试以这种方式实现状态机时，每种ECS风格都面临独特的挑战。 让我们从…开始

原型 (Archetypes)

Archetype-based ECS implementations store entities that have the same components together in an “archetype”. They are known for their fast iteration speeds, as components are always stored in contiguous arrays. The more entities are stored in a single archetype, the better these ECS implementations perform. Examples of Archetype-based implementations are Unity DOTS, Flecs and Legion.

基于原型的ECS实施将具有相同组件的实体存储在一个“原型”中。 它们以快速的迭代速度而闻名，因为组件始终存储在连续的数组中。 在单个原型中存储的实体越多，这些ECS实施的效果就越好。 基于原型的实现示例包括Unity DOTS ， Flecs和Legion 。

State machines though can easily cripple an archetype-based ECS. The first reason is that state machines introduce fragmentation. That is a fancy way of saying that they increase the number of archetypes. Why is this a bad thing? Each archetype switch introduces cache misses, which makes data retrieval from RAM less efficient.

尽管状态机可以轻易削弱基于原型的ECS。 第一个原因是状态机引入了碎片。 这是一种幻想的说法，它们增加了原型的数量。 为什么这是一件坏事？ 每个原型交换机都会引入高速缓存未命中，这会使从RAM检索数据的效率降低。