从0搭建ECS：跨品类评估

文章目录

• 概述
• [从 0 时的总判断](#从 0 时的总判断)
• [从 0 时 ECS 的通用优点](#从 0 时 ECS 的通用优点)
• • 组合扩展比继承树便宜
  • 模拟状态天生好快照、好回放、好单测
  • 一帧因果可以写成协议
  • 查询"所有符合条件的实体"是一等公民
  • 在原生引擎上才有明显的性能故事
  • 逻辑和表现从第一天就能分开
• [从 0 时 ECS 的通用缺点](#从 0 时 ECS 的通用缺点)
• • 前几个月会更慢
  • 一次性、强叙事、强角色的内容很别扭
  • 调试基础设施必须第一天就有
  • [容易做成假 ECS](#容易做成假 ECS)
  • 引擎和语言会吃掉一部分收益
  • [全项目 ECS 几乎一定过度设计](#全项目 ECS 几乎一定过度设计)
• [从 0 评估时看哪几根轴](#从 0 评估时看哪几根轴)
• [按主流品类评估（从 0）](#按主流品类评估（从 0）)
• • RTS
  • [自走棋 / 自动战斗 / 塔防](#自走棋 / 自动战斗 / 塔防)
  • MOBA
  • [ARPG / 类暗黑](#ARPG / 类暗黑)
  • [FPS / TPS / 吃鸡](#FPS / TPS / 吃鸡)
  • 格斗
  • [回合制 RPG / JRPG](#回合制 RPG / JRPG)
  • [卡牌对战 / TCG](#卡牌对战 / TCG)
  • [Roguelike / Roguelite](#Roguelike / Roguelite)
  • [生存建造 / 沙盒](#生存建造 / 沙盒)
  • [城市建造 / 经营模拟 / 群体仿真](#城市建造 / 经营模拟 / 群体仿真)
  • MMORPG
  • [SLG / 4X](#SLG / 4X)
  • 体育
  • 竞速
  • [平台跳跃 / 横版动作 / 关卡冒险](#平台跳跃 / 横版动作 / 关卡冒险)
  • [弹幕 / 清版射击](#弹幕 / 清版射击)
  • [三消 / 解谜 / 放置 / 超休闲](#三消 / 解谜 / 放置 / 超休闲)
  • [视觉小说 / 剧情向](#视觉小说 / 剧情向)
• [品类对照表（从 0）](#品类对照表（从 0）)
• [网络模型怎么选，和 ECS 什么关系](#网络模型怎么选，和 ECS 什么关系)
• [从 0 搭建时推荐的强度，而不是"纯不纯"](#从 0 搭建时推荐的强度，而不是“纯不纯”)
• • [强度 A：模拟核轻量 ECS（多数项目的最佳起点）](#强度 A：模拟核轻量 ECS（多数项目的最佳起点）)
  • [强度 B：原生数据导向 ECS](#强度 B：原生数据导向 ECS)
  • [强度 C：全游戏 ECS](#强度 C：全游戏 ECS)
  • [强度 D：确定性状态机，不叫 ECS](#强度 D：确定性状态机，不叫 ECS)
  • [从 0 的默认选择：](#从 0 的默认选择：)
• [从 0 时的通用分层（跨品类都能用）](#从 0 时的通用分层（跨品类都能用）)
• [从 0 决策：你该不该第一天上 ECS](#从 0 决策：你该不该第一天上 ECS)
• [从 0 搭建的最终判断](#从 0 搭建的最终判断)

概述

如果没有任何历史包袱，从第一天就搭 ECS，值不值得？对不同主流品类答案不一样。

这里说的"从 0 搭建 ECS"是指：

• 模拟核一开始就是 World + EntityId + Component(纯数据) + System(固定顺序)
• 不先铺 对象 继承树，再回头拆
• 输入进 Command，表现只读 Event / Snapshot

从 0 时的总判断

从 0 上 ECS，主要服务于这三样，不是"架构高级"：

• 大量同类实体每帧批量更新
• 行为靠组合而不是深继承（单位、技能、Buff、投射物互相拼）
• 一份可回放、可校验、可单测的模拟状态
  缺这三样，从 0 上 ECS 通常是亏的：同样的玩法用对象模型更短、更好调、更好招人。

跨品类总结：

• 强烈建议从 0 就上（至少模拟核）：RTS、自走棋/自动战斗、塔防、弹幕、群体仿真、需要 lockstep/回放的对战
• 建议混合（模拟核 ECS，角色控制/镜头/UI 仍 OOP）： ARPG、MOBA、FPS/TPS/吃鸡、生存建造、体育、Roguelike、MMORPG 战斗服
• 通常不要从 0 上：回合制 RPG、卡牌对局、格斗、竞速、三消/解谜、放置、超休闲、视觉小说、偏剧情的动作冒险

无论哪一品类，下面都成立：

• Simulation World 可以是 ECS √
• Presentation 可以是 OOP 或轻量 Render ECS ×
• Game Modules（背包、任务、商店、社交、活动）不要 ECS √

从 0 时 ECS 的通用优点

以下内容任何从 0 的新游戏都成立。

组合扩展比继承树便宜

• 新单位、新技能、新状态，多数时候是加组件和新系统分支，而不是再开一个子类。
• 玩法越"词条化、Buff 化、技能派生化"，这个优点越大。

模拟状态天生好快照、好回放、好单测

Component 是纯数据时：

• 回放 = 初始状态 + 命令流
• 不同步 = 对比某一帧组件
• 单测 = 造一个 World，推进 N 帧，断言血量和事件
  从 0 做竞技、回放、观战、服务器校验时，这个收益比"代码看起来像 ECS"大得多。

一帧因果可以写成协议

• System 顺序是公开契约：移动先于碰撞，碰撞先于伤害，伤害先于死亡。
• 从 0 就这样写，后面加系统时有地方挂，不容易变成"这个对象自己 tick，那个 Manager 也 tick"。

查询"所有符合条件的实体"是一等公民

• 索敌、范围伤害、带某 Buff 的单位、所有投射物，都是 query，不必维护一堆平行列表。
• 列表漏同步是 OOP 模拟里的常见不同步源。

在原生引擎上才有明显的性能故事

• C++ / C# DOTS / Rust 这类环境里，archetype、SoA、多线程 System 能把成千上万单位、弹幕、粒子代理跑起来。
• 这是从 0 选 Unity DOTS、Bevy、flecs 的正当理由。
• TypeScript / Lua / 普通 Unity MonoBehaviour 上，这个优点要打折。
• 从 0 用 JS 写 ECS，主要买的是组织和确定性，不是缓存命中。

逻辑和表现从第一天就能分开

• 从 0 就可以规定：模拟核不引用场景节点、动画事件、音效回调。
• 后面无论接 lockstep、服务器权威，还是单机，这条边界都值钱。

从 0 时 ECS 的通用缺点

前几个月会更慢

• "英雄走一步、放一个技能"在 OOP 里一个类就能看完。
• ECS 要拆 Transform、SkillBook、Casting、Projectile、HitEvent 和一串系统。
• 团队没习惯前，原型速度明显更慢。

一次性、强叙事、强角色的内容很别扭

• Boss 三阶段演出、过场、独特机关、玩家专属操作手感，用对象和状态机更自然。
• 硬塞进通用系统，会变成满屏特殊 Tag 和 if (isBoss)，既不像 ECS，也不如 OOP 好读。

调试基础设施必须第一天就有

从 0 上 ECS，最低配要有：

• 实体检查器：某 ID 当前有哪些组件
• 帧命令日志
• System 耗时
• 关键事件流
• 随机种子游标（如果要确定性）
  没有这些，ECS 比 OOP 更难查。不要假设"上了框架自然能查"。

容易做成假 ECS

• Component 里写 takeDamage()，System 里持有场景节点，Entity 又变成胖对象------这是从 0 最常见的失败模式。
• 失败后比一开始就 OOP 更难救，因为调用链和数据所有权都不在一个类里。

引擎和语言会吃掉一部分收益

技术栈	从 0 上 ECS 的真实收益
C++ / flecs、EnTT	高，性能和组织都划算
Unity DOTS	高，但和 GameObject/动画/物理生态摩擦大
Unity MonoBehaviour	中低，Entitas 一类能买组织，买不到 DOTS 性能
C# 自研 + 普通对象	中，适合模拟核，不必全引擎 DOTS
TypeScript / Laya / Cocos	中低，主要买确定性组织，不要为 SoA 投入
虚幻 Actor	低到中，官方主路径仍是 Actor；模拟核可自研，全盘 ECS 成本高

全项目 ECS 几乎一定过度设计

• 背包格子、邮件、活动日历、引导、聊天、充值，不是每帧扫描的同类实体。
• 从 0 就把它们放进 World，会把业务模块做成难用的通用数据库。

从 0 评估时看哪几根轴

先给项目打这 7 分：

轴	越高越该上 ECS	越低越不该上
同时存活的模拟对象	成百上千单位、子弹、格子代理	个位数角色
行为组合程度	技能/Buff/词条任意拼	每个对象都是独特剧本
每帧模拟密度	移动、碰撞、AI、伤害每帧都跑	点一下结算一次
确定性需求	lockstep、回滚、回放、服务器校验	单机、看起来对就行
网络模型	帧命令、状态快照、预测对账	弱联网或纯单机
内容生产量	几十上百种单位和技能	几个主角几个关卡
团队对数据导向的熟悉度	能接受查组件和系统	强依赖对象断点和继承

经验规则：

• 7 轴里有 4 轴明显偏高：从 0 给模拟核上 ECS
• 只有 1～2 轴高：混合，或先 OOP 把玩法做出来
• 确定性需求很高但实体很少：先做确定性状态机/回滚，不必上 ECS
• 实体很多但不要求确定性：ECS 仍然值得，主要为了批处理和组合

按主流品类评估（从 0）

RTS

典型：即时战略、大量兵种、编队、寻路、战斗。

• 优点：这是 ECS 最经典的主场。单位同质、系统通用、lockstep 或回放几乎是标配。选中、移动、攻击、生产都可以是 Command。
• 缺点：寻路、流场、形成编队仍是硬问题，ECS 不替你解决 AI 质量。UI（建造菜单、科技树）不要进 World。
• 确定性：通常刚需。System 顺序、稳定遍历、种子随机必须第一天定。
• 从 0 建议：模拟核必须 ECS。 不要先写 Soldier : Unit。

自走棋 / 自动战斗 / 塔防

典型：卡牌养成在局外，战场上自动对打；或塔防一波波兵线。

• 优点：战场实体多、技能和 Buff 组合爆炸、天然适合固定逻辑帧。
• 缺点：局外（卡组、商店、羁绊图鉴、账号成长）用模块化即可。如果把商店也做成 System，会把简单 UI 流程变复杂。
• 确定性：PVP 刚需；PVE 也建议同一套模拟核，方便校验和回放。
• 从 0 建议：战场从 0 就 ECS；局外不要 ECS。 这是最划算的品类之一。

MOBA

典型：十个英雄很独特，兵线、眼、子弹、野怪很多。

• 优点：小兵、投射物、范围技能、视野单位很适合 ECS。英雄技能如果走数据驱动，也能进同一套伤害/Buff 管线。
• 缺点：英雄操作手感、动画取消、镜头、商店出装是 OOP/状态机更顺。MOBA 现在主流是服务器权威，不是客户端 lockstep，ECS 帮的是服务器模拟和帧同步对账，不是"客户端每人跑一份"。
• 确定性：服务器模拟要可复现；客户端预测和和解是另一套问题。
• 从 0 建议：混合。 世界模拟 ECS，英雄输入和表现状态机可以在模拟核外交一层。不要幻想十个英雄全靠通用系统覆盖所有"独特手感"。

ARPG / 类暗黑

典型：一到三名玩家，屏幕上大量怪物、掉落、子弹、地面效果。

• 优点：刷怪、掉落物、DoT、词条、范围伤害非常适合组件组合。掉落和怪物 AI 用 query 很干净。
• 缺点：玩家技能手感、装备 UI、任务、剧情对话不适合 ECS。Boss 战如果强演出，会不断打特例。
• 确定性：单机/合作 PVE 往往不需要 lockstep；如果要反外挂校验或回放，模拟核仍值得纯数据。
• 从 0 建议：战斗世界 ECS，玩家控制器和 UI 用 OOP。 词条和 Buff 从 0 就要做成数据，不要做成继承。

FPS / TPS / 吃鸡

典型：枪、弹道、角色移动、载具，网络多为服务器权威 + 客户端预测。

• 优点：子弹、投掷物、可破坏物、拾取物、大量角色代理可以用 ECS 批处理。服务器上同时模拟很多玩家时，数据导向有优势。
• 缺点：第一人称手感、动画、枪械状态、预测和解、滞后补偿，不是 ECS 能"自动变好"的东西。这些系统强依赖时间和历史缓冲，用专用结构往往比通用 World 更合适。物理引擎通常在 ECS 外面。
• 确定性：一般不做全帧 lockstep（延迟和操作手感不允许）。要的是服务器权威、快照、和解。ECS 有助于状态拷贝，但不等于回滚网码。
• 从 0 建议：服务器世界状态可以 ECS；客户端角色控制不要一上来全 DOTS。 Unity 上尤其要评估 DOTS 和动画/物理/网络插件的摩擦。

格斗

典型：两人、帧表、指令、受击框，常见回滚同步。

• 优点：确定性、每帧快照、回滚，和"纯数据状态"很合。ECS 能当存储，方便拷贝整个世界。
• 缺点：实体太少，组合优势用不上。真正难的是帧表、取消、判定优先级、输入缓冲。业界主流是固定对象 + 确定性状态机 + 回滚，不是通用 ECS。
• 确定性：刚需，但靠帧数据和固定小数/整数，不靠 ECS。
• 从 0 建议：先做确定性状态机和回滚。 不必为两个角色上 ECS；如果引擎已有现成 ECS 快照，当存储可以用，不要当玩法架构。

回合制 RPG / JRPG

典型：菜单、回合、技能选择、剧情、队伍。

• 优点：几乎没有。战斗也可以用小型状态机或指令队列，实体数量和每帧密度都不够。
• 缺点：叙事、UI、回合流程才是主体。ECS 会把"选菜单 -> 放技能 -> 播动画 -> 结算"拆得很难读。
• 确定性：可以要（回放、校验），一个战斗状态对象 + 指令日志就够。
• 从 0 建议：不要上 ECS。 战斗用明确的 Round / Command / Formula。

卡牌对战 / TCG

典型：炉石、月圆类对战；桌面实体通常几十以内。

• 优点：如果随从有大量光环、亡语、触发链，用事件队列 + 纯数据状态很好查。这更像 reducer / 事件溯源，不一定要叫 ECS。
• 缺点：对局是离散结算，不是每帧移动碰撞。UI、卡组构筑、动画时间轴才是工作量。
• 确定性：刚需。规则引擎必须纯函数、顺序稳定、随机有种子。
• 从 0 建议：做确定性规则引擎，不必上 ECS。 只有"战场上还有自动移动和碰撞"时（自走棋），才回到第 2 类。

Roguelike / Roguelite

• 优点：状态异常、道具叠加、光环、地面效果很多，组合能力强。格子世界的单位、子弹、陷阱适合组件化。
• 缺点：生成器、房间剧本、叙事事件用模块更顺。即时动作肉鸽和回合格子肉鸽要分开看：前者更接近 ARPG，后者更接近回合制。
• 确定性：种子生成和回放很常见，纯数据世界有帮助。
• 从 0 建议：即时肉鸽的战斗核可以 ECS；回合格子肉鸽用数据状态机通常够。 道具效果从 0 就要数据化，这比"是不是 ECS"更重要。

生存建造 / 沙盒

典型：采集、建造、动物群、大量掉落物、夜晚循环。

• 优点：世界里同类实体极多（树、动物、子弹、建筑零件）。ECS 或等价的 chunk + 组件很适合。群体 AI、生长、腐坏都是批量系统。
• 缺点：玩家建造交互、合成 UI、地形体素、物理沙箱常常在 ECS 外。开放世界流式加载、存档粒度，要单独设计，不是加个 World 就结束。
• 确定性：多人联机少见 lockstep，多为服务器权威。单机则更在意存档和性能。
• 从 0 建议：世界模拟从 0 按数据导向做（ECS 或 chunk 组件）。 玩家操作和 UI 保持 OOP。

城市建造 / 经营模拟 / 群体仿真

典型：市民、车辆、物流、工厂、管道。

• 优点：第二经典主场。成千上万代理、同一套需求/移动/工作系统。ECS 或纯 SoA 都常见。
• 缺点：UI、经济数值表、建造工具是另一套。路径和空间索引仍要专用结构。
• 确定性：回放和"同一地图同一种子"有价值，但不一定要锁帧对战。
• 从 0 建议：模拟核从 0 上 ECS 或等价 SoA。 不要用一个 Citizen 大类堆十年。

MMORPG

• 优点：同一张图里大量玩家和 NPC、AOI、技能、Buff，服务器模拟层很适合 ECS 或等价组件扫描。
• 缺点：任务、社交、交易、公会、活动、剧情全是业务模块。客户端主要是表现和 UI。兴趣管理和数据库才是更大的架构题。
• 确定性：一般不 lockstep。要的是服务器权威、技能校验、状态同步。
• 从 0 建议：战斗/场景模拟服可以 ECS；网关、数据库、任务、客户端 UI 不要 ECS。

SLG / 4X

典型：大地图养成、行军、回合或半即时，战斗常是战报或小战场。

• 优点：大地图上的行军、地块、驻军可以当数据实体，但 tick 频率通常很低。小战场如果是自动战斗，等同自走棋/RTS 子集。
• 缺点：养成、科技、联盟、邮件、活动是业务主体。把整张大地图做成每帧 ECS 扫描，多半浪费。
• 确定性：战报回放需要确定性战斗核；大地图更在意协议和存档。
• 从 0 建议：大地图用模块 + 定时器/事件。 只有自动战斗或实时小战场从 0 上 ECS。

体育

• 优点：场上是有限但同类的运动员、球、碰撞，物理和 AI 批量更新合适。回放、战术数据也适合纯状态。
• 缺点：动画、镜头、规则判罚、网络延迟补偿很重。物理常外挂专业引擎。
• 确定性：电竞级回放/对战需要；休闲体育不一定。
• 从 0 建议：比赛模拟层可以 ECS；动画和镜头不要强行 DOTS。

竞速

• 优点：车辆少。物理、轮胎、回放才是核心。ECS 几乎帮不上组合问题。
• 缺点：手感绑定物理引擎和输入采样。为几辆车上 World 是多余抽象。
• 确定性：回放和联网需要固定步长物理，这和 ECS 正交。
• 从 0 建议：不要上 ECS。 固定物理步长 + 输入记录即可。

平台跳跃 / 横版动作 / 关卡冒险

• 优点：敌人、子弹、可收集物多的话，场景实体可以用 ECS。
• 缺点：玩家手感、关卡脚本、镜头、一次性机关是主体。Metroidvania 的能力解锁更像角色状态机。
• 确定性：单机通常不需要；合作或竞速平台游戏才要。
• 从 0 建议：默认 OOP。 只有"同屏大量敌人/子弹"时给这层上 ECS。

弹幕 / 清版射击

• 优点：子弹数量巨大，批处理几乎是刚需。ECS 或纯数组（SoA）都非常合适。
• 缺点：关卡时间轴、Boss 弹幕脚本仍要独立的编排器。不要用 System 去写剧本。
• 确定性：回放和成绩校验有价值。
• 从 0 建议：子弹和敌人运动从 0 用 ECS 或 SoA。 弹幕脚本用数据时间轴，不要用继承。

三消 / 解谜 / 放置 / 超休闲

• 优点：基本没有。棋盘是小状态，放置是定时器和数值。
• 缺点：ECS 启动成本高于玩法本身。
• 确定性：三消如果要录像，一个棋盘数组就够。
• 从 0 建议：不要上 ECS。

视觉小说 / 剧情向

• 从 0 建议：不要上 ECS。 流程是脚本、资源和 UI。

品类对照表（从 0）

品类	实体规模	组合程度	确定性常见需求	从 0 建议	主要买什么
RTS	很高	高	很高	模拟核 ECS	批量单位 + lockstep
自走棋 / 自动战斗 / 塔防	高	很高	很高	战场 ECS，局外模块	技能 Buff 组合 + 同步
MOBA	中高	英雄低、兵线高	服务器要可复现	混合	小兵投射物批处理
ARPG	高	高	中	战斗 ECS + 玩家 OOP	刷怪词条掉落
FPS / 吃鸡	中高	中	权威同步，少 lockstep	世界状态可 ECS，角色控制谨慎	服务器批量代理
格斗	很低	低	极高	确定性状态机 + 回滚	快照，不是组合
回合制 RPG	低	中	中	不要 ECS	指令和公式
TCG	低	中高	很高	规则引擎，不必 ECS	触发链顺序
即时肉鸽	中高	很高	中高	战斗核 ECS	道具状态叠加
生存建造	很高	中	中	世界模拟 ECS	海量同类实体
城市 / 工厂仿真	很高	中	中	模拟核 ECS/SoA	群体代理
MMORPG	很高（服务器）	中	权威校验	场景战斗 ECS，业务模块化	服务器扫描
SLG / 4X	大地图低，小战场高	中	战报要	只给战斗回放上 ECS	战报可复现
体育	中	中	中高	比赛层可 ECS	回放和批量 AI
竞速	低	低	中高	不要 ECS	固定物理步长
平台动作	低到中	低	低	默认 OOP	手感优先
弹幕	极高	低到中	中	ECS 或纯 SoA	子弹批处理
三消 / 放置 / 超休闲	低	低	低到中	不要 ECS	无
视觉小说	无	无	无	不要 ECS	无

网络模型怎么选，和 ECS 什么关系

从 0 时，先选网络模型，再决定 ECS 要不要为确定性服务。
#mermaid-svg-wM099rax21Ol4Yp5{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-wM099rax21Ol4Yp5 .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-wM099rax21Ol4Yp5 .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-wM099rax21Ol4Yp5 .error-icon{fill:#552222;}#mermaid-svg-wM099rax21Ol4Yp5 .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-wM099rax21Ol4Yp5 .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-wM099rax21Ol4Yp5 .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-wM099rax21Ol4Yp5 .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-wM099rax21Ol4Yp5 .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-wM099rax21Ol4Yp5 .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-wM099rax21Ol4Yp5 .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-wM099rax21Ol4Yp5 .marker{fill:#333333;stroke:#333333;}#mermaid-svg-wM099rax21Ol4Yp5 .marker.cross{stroke:#333333;}#mermaid-svg-wM099rax21Ol4Yp5 svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-wM099rax21Ol4Yp5 p{margin:0;}#mermaid-svg-wM099rax21Ol4Yp5 .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-wM099rax21Ol4Yp5 .cluster-label text{fill:#333;}#mermaid-svg-wM099rax21Ol4Yp5 .cluster-label span{color:#333;}#mermaid-svg-wM099rax21Ol4Yp5 .cluster-label span p{background-color:transparent;}#mermaid-svg-wM099rax21Ol4Yp5 .label text,#mermaid-svg-wM099rax21Ol4Yp5 span{fill:#333;color:#333;}#mermaid-svg-wM099rax21Ol4Yp5 .node rect,#mermaid-svg-wM099rax21Ol4Yp5 .node circle,#mermaid-svg-wM099rax21Ol4Yp5 .node ellipse,#mermaid-svg-wM099rax21Ol4Yp5 .node polygon,#mermaid-svg-wM099rax21Ol4Yp5 .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-wM099rax21Ol4Yp5 .rough-node .label text,#mermaid-svg-wM099rax21Ol4Yp5 .node .label text,#mermaid-svg-wM099rax21Ol4Yp5 .image-shape .label,#mermaid-svg-wM099rax21Ol4Yp5 .icon-shape .label{text-anchor:middle;}#mermaid-svg-wM099rax21Ol4Yp5 .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-wM099rax21Ol4Yp5 .rough-node .label,#mermaid-svg-wM099rax21Ol4Yp5 .node .label,#mermaid-svg-wM099rax21Ol4Yp5 .image-shape .label,#mermaid-svg-wM099rax21Ol4Yp5 .icon-shape .label{text-align:center;}#mermaid-svg-wM099rax21Ol4Yp5 .node.clickable{cursor:pointer;}#mermaid-svg-wM099rax21Ol4Yp5 .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-wM099rax21Ol4Yp5 .arrowheadPath{fill:#333333;}#mermaid-svg-wM099rax21Ol4Yp5 .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-wM099rax21Ol4Yp5 .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-wM099rax21Ol4Yp5 .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-wM099rax21Ol4Yp5 .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-wM099rax21Ol4Yp5 .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-wM099rax21Ol4Yp5 .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-wM099rax21Ol4Yp5 .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-wM099rax21Ol4Yp5 .cluster text{fill:#333;}#mermaid-svg-wM099rax21Ol4Yp5 .cluster span{color:#333;}#mermaid-svg-wM099rax21Ol4Yp5 div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-wM099rax21Ol4Yp5 .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-wM099rax21Ol4Yp5 rect.text{fill:none;stroke-width:0;}#mermaid-svg-wM099rax21Ol4Yp5 .icon-shape,#mermaid-svg-wM099rax21Ol4Yp5 .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-wM099rax21Ol4Yp5 .icon-shape p,#mermaid-svg-wM099rax21Ol4Yp5 .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-wM099rax21Ol4Yp5 .icon-shape .label rect,#mermaid-svg-wM099rax21Ol4Yp5 .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-wM099rax21Ol4Yp5 .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-wM099rax21Ol4Yp5 .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-wM099rax21Ol4Yp5 :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 网络模型
帧锁定 lockstep
回滚 rollback
服务器权威 + 预测
单机 / 弱联网
ECS 很值得：命令进 World，两端跑同一帧
ECS 可选：便于整世界拷贝；实体少时状态机更合适
ECS 值得放在服务器模拟；客户端 ECS 不是必须
ECS 只看实体规模和组合，不看同步

对应关系：

• Lockstep（RTS、自走棋 PVP、部分手游对战）：ECS 从 0 就该为"可序列化组件 + 固定 System 顺序 + 种子随机"服务。这是 ECS 和确定性重叠最大的地方。
• Rollback（格斗、部分平台合作）：要的是整帧状态可拷贝、可恢复。实体少时不必 ECS；实体多时 Component 数组更好拷贝。
• 服务器权威（MOBA、FPS、MMO、吃鸡）：ECS 优先放服务器。客户端预测用的是输入和短历史，不是再跑一份完整玩法 ECS。
• 单机：没有同步压力。只有单位多或词条多时才从 0 上 ECS。

不要颠倒顺序：先宣布"我们上 ECS"，再决定用 lockstep 还是权威服。应该先定同步模型，再决定模拟核怎么存。

从 0 搭建时推荐的强度，而不是"纯不纯"

同样叫 ECS，强度差很多。从 0 选错强度，比选错品类更常见。

强度 A：模拟核轻量 ECS（多数项目的最佳起点）

适合：TS、中小团队、自走棋、ARPG 战斗、塔防、肉鸽战斗。（注：第一年不要自研 archetype）

• World
• EntityId
• Map/Store 存组件
• query
• CommandBuffer
• 固定 SystemScheduler
• EventQueue
• Snapshot

强度 B：原生数据导向 ECS

适合：RTS、弹幕、城市仿真、Unity DOTS 服务器、C++ 大世界。

前提：实体量大到性能已是设计约束，且团队吃得住工具链。

• archetype 或 sparse set
• SoA
• 多线程 System
• Job / Burst 一类编译优化

强度 C：全游戏 ECS

所有 UI、任务、账号都进 World。

从 0 也不建议。 没有主流品类值得这样开局。

强度 D：确定性状态机，不叫 ECS

格斗、卡牌、回合制、竞速回放。

纯状态 + 命令 + 快照，不要硬套 System 扫描。

从 0 的默认选择：

• 先定品类和网络模型
• 战斗/世界模拟选 A
• 规模真的爆炸再升 B
• 永远不要选 C
• D 和 A 不冲突：卡牌规则引擎可以喂给战场 ECS，也可以独立存在

从 0 时的通用分层（跨品类都能用）

Game Modules 账号、背包、商店、任务、活动、社交

-> 只给模拟核发 Command，或根本不进战斗

Command Layer 输入、帧包、服务器指令

-> Simulation World

Simulation World ECS 或确定性状态机

-> Event / Snapshot

Presentation 模型、动画、镜头、特效、音效

-> 禁止回写模拟核

Replay / Debug 只消费命令和逻辑快照

• 这套分层在 RTS、自走棋、ARPG、MMO 战斗服上都成立。
• 区别只是 Simulation World 里有多少 System，以及要不要 lockstep。

从 0 决策：你该不该第一天上 ECS

按这个问题从上往下问，问到第一个"是"就停：

1. 同屏或服务器上会长期存在成百上千同类对象吗？
   • 是：模拟核从 0 上 ECS（强度 A 或 B）。
2. 技能、Buff、词条、单位类型会组合成爆炸内容吗？
   • 是：至少把这一层做成纯数据 + 系统管线，不必等全框架。
3. 需要 lockstep、回放、观战、服务器校验吗？
   • 是：先做确定性模拟规则；实体多就用 ECS 当载体，实体少就用状态机。
4. 核心体验是单个角色手感、剧情、菜单或棋盘规则吗？
   • 是：从 0 不要上 ECS。
5. 团队会为了赶原型把逻辑写回显示对象吗？
   • 是：先把边界纪律写进脚手架，否则 ECS 只是新的泥潭。

从 0 搭建的最终判断

• ECS 不是游戏类型补丁，是模拟核的组织方式。 只在"很多实体 / 很多组合 / 需要一份权威世界状态"时从 0 就该用。
• 确定性仍然独立于 ECS。 格斗和卡牌可以很确定却不用 ECS；弹幕可以上 ECS 却完全不确定。
• 最赚的从 0 场景： RTS、自走棋/自动战斗、塔防、弹幕、城市/工厂仿真、需要帧同步的对战战场。
• 最稳的从 0 场景： ARPG、MOBA、生存、MMO 战斗服用混合架构。
• 最亏的从 0 场景： 回合制、卡牌、格斗、竞速、三消、放置、剧情向。这些品类从 0 上 ECS，通常是把简单问题变难。
• 永远不要全游戏 ECS。 从 0 也不要。
• 语言和引擎会改结论： 原生引擎 + 海量实体，ECS 的性能故事成立；TS/Laya 从 0 上 ECS，只为组织和确定性，不要为 SoA 建框架。