在本系列文章的第一篇中，我们将解释什么是Unity的ECS以及它可以为您的游戏做什么。
Unity ECS的主要优势是默认性能。 为了实现这一目标，ECS摆脱了传统的面向对象编程（即大多数Unity开发人员都熟悉的以GameObject和MonoBehaviour为中心的工作流程），转向了面向数据的设计。 为了说明它们之间的差异，让我们比较一下每种方法如何构建代表玩家角色的对象：
使用面向对象的编程，您将创建一个GameObject来表示玩家角色，然后附加MonoBehaviours以赋予GameObject功能，例如玩家控制器，健康状况和物理属性。 这些MonoBehaviours包含数据（例如生命值）和修改该数据的代码（例如，当玩家受到伤害时减少生命值）。
使用面向数据的设计，您将创建一个实体来表示玩家角色，然后附加组件以存储数据。 ECS组件不应与GameObject组件（例如MonoBehaviours）混淆。 与GameObject组件不同， ECS组件不包含任何逻辑，它们仅存储数据。 我们用于对实体及其组件执行操作的代码以系统的形式存在。 系统是脚本。 它们对世界上所有实体和组件都起着作用。
为了继续前面的减少生命值的示例，系统将对具有健康和损坏组件的所有实体进行分组，并相应地减少受影响的组件。
ECS有什么好处？
面向数据的设计的内存布局可确保ECS生成的代码在内存地址之间的跳转比传统的面向对象编程要少得多。
此外，由ECS引导的内存布局允许进一步利用缓存预取来优化代码，CPU使用此过程来确保在需要时已将下一个数据位加载到缓存中。 Unity ECS范例通过使用大小相等的可线性迭代的组件块来实现此目的。 CPU不必处理各种大小的随机存储对象，而只需要处理线性存储在同一内存区域中的这些大小统一的块。 这使得CPU的工作更加轻松，有点像玩1×1块的俄罗斯方块。
通过将数据（实体和组件）和逻辑（系统）分离，ECS还可以生成更加模块化，易于阅读的代码。 作为开发基于Unity ECS构建于Unity的Improbable的SpatialOS游戏开发工具包（GDK）的开发人员的我特别感兴趣。 ECS从概念上反映了SpatialOS的核心概念（实体，组件以及对其进行操作的工作人员），使其非常适合SpatialOS GDK。
为什么每个人都没有使用ECS？
有了所有这些好处，您可能会想知道：为什么每个人都没有使用ECS？ 首先，ECS并不适合所有人。 在Improbable，我们为它感到兴奋，因为它适合SpatialOS支持的大型，人口众多和持久的游戏，但是某些游戏（例如基于回合的策略游戏）根本不需要这种性能。
其次，ECS仍处于试验开发阶段。 Unity现有的大多数工具和系统仍仅设计用于GameObjects和MonoBehaviours 。
用于SpatialOS的ECS和MonoBehaviour工作流程
为了减轻这些痛苦，SpatialOS GDK for Unity提供了两个工作流程选项：
- 以MonoBehaviour为中心的工作流程，可与Unity完全开发的MonoBehaviour工具，工作流程和API配合使用。
- 利用ECS开发范例和相关性能改进的ECS工作流程。
至关重要的是，这些工作流不是相互排斥的。 考虑到当前缺乏围绕ECS的工具，我们预计您将使用MonoBehaviours编写大部分或全部游戏。 无论您选择哪种工作流程，您的游戏仍将利用我们使用ECS编写的高性能GDK核心模块。 我们的目标是通过我们自己的API和抽象层，尽早为您带来ECS的好处。 这种方法将使您免受Unity对其ECS所做的大多数重大更改的影响，因此您可以根据自己的意愿专注于编写游戏。
在下一篇文章中，我们将详细探讨这两个工作流程，并研究每个工作流程的代码示例。 在此之前，这里还有更多有关Unity的ECS和Improbable的SpatialOS GDK for Unity的资源。
ECS资源列表
- Unity的ECS样本存储库
- 视频播放列表：实体组件系统简介
- 高桥敬二郎的ECS技术演示Voxelman
- 适用于Unity Github的SpatialOS GDK
本文最初于2018年9月24日发布在improbable.io上
