hecs

hecs 提供了一个高性能、极简的实体-组件-系统 (ECS) 世界。它是一个库，而不是一个框架。取代显式的 "System" 抽象，可以从常规代码中轻松查询 World 的实体。根据您的喜好组织您的应用程序！

Bevy 分支信息

这是 Bevy 项目对 hecs 的分支，其中包含适应 Bevy 游戏引擎需求的变化。一些显著变化

• 实体索引现在可查询，并且默认不返回查询中。这既提高了易用性，也在某些情况下显著提高了性能。
• 公开更多接口，以便我们可以在核心 hecs 代码库之上构建更高级的 API（多线程、函数作为系统、世界构建器、调度等）
• 更改跟踪

为什么使用 ECS？

实体-组件-系统架构使得组合松散耦合的状态和行为变得容易。ECS 世界由以下组成

• 任意数量的 实体，代表不同的对象
• 与每个实体相关联的一组 组件 数据，其中每个实体最多有一个任何类型的组件，并且两个实体可能具有不同的组件

然后通过 系统 来操作这个世界，每个系统都访问具有特定组件类型集合的所有实体。系统实现自包含的行为，如物理（例如，通过访问 "位置"、"速度" 和 "碰撞" 组件）或渲染（例如，通过访问 "位置" 和 "精灵" 组件）。

可以在不干扰现有逻辑的情况下向复杂应用程序添加新的组件和系统，这使得 ECS 范式非常适合定义在相同一组对象上定义多个重叠行为的应用程序，特别是如果将来将添加新行为的话。这种灵活性使其与传统方法区分开来，传统方法基于异构集合的显式定义的对象类型，其中实现新行为组合（例如，既是车辆又是任务给予者的车辆）可能需要深远的变化。

性能

除了具有出色的可组合性之外，ECS 模式还能提供卓越的速度和缓存局部性。内部跟踪具有相同组件的实体组。每个组都有一个密集的、连续的数组来存储每种类型的组件。当系统访问具有特定组件集的所有实体时，可以通过具有这些组件超集的每个组进行快速的线性遍历。这实际上是一个列式数据库，具有相同的优点：CPU 可以准确地预测内存访问，绕过不需要的数据，最大化缓存使用并最小化延迟。

为什么不选择 ECS？

ECS 世界并不是万能的数据结构。大多数游戏会在其他结构中存储大量的状态。例如，许多游戏维护一个空间索引结构（例如，一个瓦片地图或边界体积层次结构），用于在某个位置附近找到实体和障碍物，以便在搜索整个世界之前高效地进行碰撞检测。

如果您需要根据组件类型以外的标准搜索特定实体，请考虑在您的世界旁边维护一个专用索引，存储 Entity 处理程序和所需的其他数据。在生成相关实体时将它们插入索引中，并包含一个组件，允许在销毁实体时高效地将它们从索引中删除。

其他库

如果没有其他人出色地引入和开发 Rust 生态系统中的 ECS 模式，hecs 就不会存在。特别是

• specs 在推广 Rust 中的 ECS 方面发挥了关键作用
• legion 通过稀疏组件减少了样板代码并提高了缓存局部性

hecs 通过进一步简化，将范式简化为一个最小化、轻量级且易于使用的核心，在性能或灵活性上没有妥协。

免责声明

这不是一个官方的 Google 产品（实验性的或其他），这只是 Google 拥有的代码。