关于 ecs-design
ecs-design 是面向 Roblox 中 jecs 的 ECS 设计指导技能，以列式数据库模型帮助开发者设计组件、实体、系统、查询和 Archetype。
主要功能
- 01列式数据库式 ECS 模型
- 02组件粒度设计指导
- 03实体与关系选择
- 04查询和系统设计
- 05Archetype 碎片化指导
适用场景
- 01判断数据是否应放入实体
- 02决定拆分或合并组件
- 03设计查询与系统职责
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/ecs-design确认已加载。
包含的文件
除 SKILL.md 外，安装时一起下载的参考资料和脚本。
GENERATION.mdreferences/best-practices-components.mdbest-practices-entities.mdbest-practices-systems.mdcore-database-model.mdcore-query-design.md详细介绍
ECS 设计原则
适用于 Roblox 中 jecs 的设计指南。
核心思维模型
将 ECS 视为列式数据库：
| 数据库 | ECS |
|---|---|
| 表 | 原型（唯一的组件组合） |
| 列 | 组件类型 |
| 行 | 实体 |
| 查询 | 系统迭代 |
设计问题：“我会为此单独创建一个数据库列吗？”
核心参考
| 主题 | 描述 | 参考 |
|---|---|---|
| 数据库模型 | 将 ECS 视为列式数据库、规范化、碎片化 | core-database-model |
| 查询设计 | 多实体查询、约束分解、遍历 | core-query-design |
最佳实践
| 主题 | 描述 | 参考 |
|---|---|---|
| 组件设计 | 粒度选择、何时拆分或合并、标签与数据 | best-practices-components |
| 系统设计 | 单一职责、避免无谓工作、顺序、数据流 | best-practices-systems |
| 实体设计 | 何时创建实体、延迟创建、扩展模式 | best-practices-entities |
快速决策指南
| 问题 | 答案 |
|---|---|
| 这应该是一个实体吗？ | 只有当它需要随时间变化的实例级状态时 |
| 拆分还是合并？ | “是否有系统需要 A，但不需要 B？” |
| 标签还是数据组件？ | 标签用于稳定分类（可自由添加或移除），数据用于状态 |
| 关系还是实体引用？ | 需要反向查找时使用关系，否则使用实体成员 |
| 碎片化不好吗？ | 只有在原型数量达到数千且查询范围很广时 |
| 何时需要关注 DOD？ | 实体数量达到数千、每帧运行且受 CPU 限制时 |
常见错误
| 错误 | 不利之处 | 修正方式 |
|---|---|---|
| 单体组件 | 缓存浪费、耦合紧密 | 按访问模式拆分 |
| 组件过于原子化 | 查询复杂、状态无效 | 合并语义单元 |
| 频繁向大型实体添加或移除组件 | 会复制所有组件数据 | 改为修改数据组件 |
| 每个关联都使用关系 | 造成碎片化，却没有收益 | 仅用于单向关联时使用实体成员 |
| 在系统内缓存查询 | 每帧都会创建新的缓存 | 在模块作用域创建缓存查询 |
核心原则
- 按访问模式划分组件 — 将系统需要一起使用的数据归为一组
- 原型转换会复制数据 — 添加或移除组件时，会将所有数据复制到新的原型；对于小型实体，开销较低；对于大型实体，开销较高
- 实体成员与关系 — 正向查找使用实体成员，反向查找或分组使用关系
- 在模块作用域缓存查询 — 切勿在系统内调用
.cached() - 在查询中筛选 — 使用 with/without，而非代码条件判断
- 碎片化可能有帮助 — 关系支持高效的分组查询
评论
支持 Markdown