420 lines
11 KiB
Markdown
420 lines
11 KiB
Markdown
# MetaCore 第一阶段 Roadmap
|
||
|
||
生成时间：2026-04-04
|
||
状态：草案
|
||
范围：第一阶段主干能力推进节奏
|
||
读者：产品、架构、引擎、编辑器、渲染、工具链、测试、交付
|
||
|
||
## 目的
|
||
|
||
这份文档把已经完成的能力清单、里程碑和 backlog，进一步收敛成一份真正可执行的 roadmap。
|
||
|
||
它回答的问题是：
|
||
|
||
- 第一阶段应该按什么节奏推进
|
||
- 每个阶段的主目标是什么
|
||
- 哪些工作可以并行，哪些不能乱序
|
||
- 每个阶段什么时候可以退出
|
||
- roadmap 完成后，团队是否可以进入正式开发
|
||
|
||
## 相关文档
|
||
|
||
- [metacore-engine-feature-baseline.md](D:/MetaCore/docs/designs/metacore-engine-feature-baseline.md)
|
||
- [metacore-phase1-m1-m4-tasklist-and-acceptance.md](D:/MetaCore/docs/designs/metacore-phase1-m1-m4-tasklist-and-acceptance.md)
|
||
- [metacore-phase1-m1-m4-workstreams.md](D:/MetaCore/docs/designs/metacore-phase1-m1-m4-workstreams.md)
|
||
- [metacore-m1-backlog.md](D:/MetaCore/docs/designs/metacore-m1-backlog.md)
|
||
- [metacore-m2-backlog.md](D:/MetaCore/docs/designs/metacore-m2-backlog.md)
|
||
- [metacore-m3-backlog.md](D:/MetaCore/docs/designs/metacore-m3-backlog.md)
|
||
- [metacore-m4-backlog.md](D:/MetaCore/docs/designs/metacore-m4-backlog.md)
|
||
|
||
## 核心判断
|
||
|
||
第一阶段 roadmap 的目标不是“把所有功能都铺满”，而是按正确顺序做通一条引擎主干：
|
||
|
||
1. 项目与资源进入引擎
|
||
2. 内容在引擎中可被制作
|
||
3. 内容与 UI 可被复用和组织
|
||
4. 项目可被独立发布和运行
|
||
|
||
如果这四条链依次成立，第一阶段就是健康推进的。
|
||
|
||
## Roadmap 总览
|
||
|
||
```text
|
||
Stage A：M1 项目与资源主干
|
||
-> Stage B：M2 模型、材质、场景制作闭环
|
||
-> Stage C：M3 Prefab 与 UI 基础
|
||
-> Stage D：M4 Player、打包、发布闭环
|
||
```
|
||
|
||
推荐理解方式：
|
||
|
||
- `Stage A`：让项目和资源进入系统
|
||
- `Stage B`：让内容制作成立
|
||
- `Stage C`：让应用组织成立
|
||
- `Stage D`：让交付成立
|
||
|
||
## 建议节奏
|
||
|
||
如果以较稳健的第一阶段推进为目标，建议按 4 个执行阶段推进，而不是把所有 backlog 同时铺开。
|
||
|
||
建议节奏可以按下面理解：
|
||
|
||
- `Stage A`：先收地基
|
||
- `Stage B`：再做内容生产
|
||
- `Stage C`：再做复用与 UI
|
||
- `Stage D`：最后收发布闭环
|
||
|
||
如果团队规模较小，建议严格串行主里程碑，只允许少量前瞻设计并行。
|
||
如果团队规模较大，可以在主依赖不被破坏的前提下，让后一个阶段做设计预研，但不建议大规模越级实现。
|
||
|
||
---
|
||
|
||
## Stage A：M1 项目与资源主干
|
||
|
||
### 目标
|
||
|
||
建立统一项目语义、统一资源入口和基础可见性。
|
||
|
||
### 本阶段要证明什么
|
||
|
||
MetaCore 不再只是“能打开一个编辑器”，而是正式围绕项目和资源工作。
|
||
|
||
### 主任务来源
|
||
|
||
- [metacore-m1-backlog.md](D:/MetaCore/docs/designs/metacore-m1-backlog.md)
|
||
|
||
### 核心任务
|
||
|
||
- 统一项目根目录解析
|
||
- 统一项目描述文件模型
|
||
- 项目创建与打开流程
|
||
- startup scene 规则统一
|
||
- Asset Database 初始化主干
|
||
- meta / GUID / package 记录统一
|
||
- 资源导入基础入口
|
||
- Project 面板第一版
|
||
- 资源刷新、重命名、移动基础规则
|
||
- 样板项目规范化
|
||
- M1 回归测试矩阵
|
||
|
||
### 可并行部分
|
||
|
||
- 项目描述文件模型
|
||
- Project 面板第一版
|
||
- 样板项目规范化
|
||
|
||
### 不应乱序的部分
|
||
|
||
- 没有统一项目解析，不应推进正式项目创建流程
|
||
- 没有 Asset Database 主干，不应推进正式导入入口
|
||
- 没有资源可见性，不应进入 M2 主实现
|
||
|
||
### 退出条件
|
||
|
||
- 用户可以创建并打开项目
|
||
- Editor / Player 对项目解析一致
|
||
- Project 面板可见项目资源
|
||
- 资源进入项目后进入 Asset Database
|
||
- meta / GUID / package 基础记录稳定
|
||
|
||
### 阶段产出
|
||
|
||
- 一个稳定的项目入口
|
||
- 一个稳定的资源入口
|
||
- 一个可用的资源浏览起点
|
||
|
||
---
|
||
|
||
## Stage B：M2 模型、材质、场景制作闭环
|
||
|
||
### 目标
|
||
|
||
建立正式的内容制作闭环。
|
||
|
||
### 本阶段要证明什么
|
||
|
||
MetaCore 可以从“围绕资源工作”进一步变成“围绕内容制作工作”。
|
||
|
||
### 主任务来源
|
||
|
||
- [metacore-m2-backlog.md](D:/MetaCore/docs/designs/metacore-m2-backlog.md)
|
||
|
||
### 核心任务
|
||
|
||
- 首批模型导入策略定型
|
||
- 模型资产数据模型
|
||
- `glTF/.glb` 导入器第一版
|
||
- Mesh / Material / Texture 导入产物落地
|
||
- 导入归一化规则
|
||
- Project 面板模型资源增强
|
||
- 模型资源实例化到场景
|
||
- Scene 层级编辑增强
|
||
- Transform / Gizmo 工作流打磨
|
||
- 材质资源正式化
|
||
- 材质 Inspector 与材质指派工作流
|
||
- 基础光照工作流
|
||
- Scene 保存/重开中的资源引用稳定化
|
||
- 重导入与引用保持
|
||
- M2 回归测试矩阵
|
||
|
||
### 可并行部分
|
||
|
||
- 导入器第一版
|
||
- Project 面板模型资源增强
|
||
- Scene 层级编辑增强
|
||
- Transform / Gizmo 打磨
|
||
|
||
### 不应乱序的部分
|
||
|
||
- 没有模型资产数据模型，不应直接铺开多个格式导入器
|
||
- 没有 Scene 中资源引用规则，不应推进复杂重导入逻辑
|
||
- 没有正式材质资源，不应继续在 `MeshRenderer` 上堆临时字段
|
||
|
||
### 退出条件
|
||
|
||
- 第一种正式支持模型格式可导入
|
||
- 模型资产可进入场景
|
||
- 用户可以编辑 Transform、材质和灯光
|
||
- Scene 可保存并重开
|
||
- 重导入不打断核心引用
|
||
|
||
### 阶段产出
|
||
|
||
- 一条可用的 3D 场景制作链
|
||
- 一套正式进入场景的模型与材质资源语义
|
||
|
||
---
|
||
|
||
## Stage C：M3 Prefab 与 UI 基础
|
||
|
||
### 目标
|
||
|
||
建立内容复用链和基础应用界面链。
|
||
|
||
### 本阶段要证明什么
|
||
|
||
MetaCore 不只是能做静态场景，而是开始具备“做应用”的基础能力。
|
||
|
||
### 主任务来源
|
||
|
||
- [metacore-m3-backlog.md](D:/MetaCore/docs/designs/metacore-m3-backlog.md)
|
||
|
||
### 核心任务
|
||
|
||
- Prefab 资源模型正式化
|
||
- 从对象树创建 Prefab
|
||
- Prefab 实例化工作流
|
||
- Prefab Apply / Revert 第一版
|
||
- Prefab 编辑器表达
|
||
- UiDocument 正式资源化
|
||
- UI 节点模型与基础控件
|
||
- UI 编辑器第一版
|
||
- UI 运行时渲染第一版
|
||
- UI 与项目/Scene 引用关系
|
||
- Prefab / UI 资源进入构建链
|
||
- M3 回归测试矩阵
|
||
|
||
### 可并行部分
|
||
|
||
- Prefab 主线
|
||
- UI 主线
|
||
|
||
### 不应乱序的部分
|
||
|
||
- 没有 Prefab 资源模型，不应直接做复杂 Apply / Revert
|
||
- 没有 UiDocument 正式资源化，不应推进复杂 UI 编辑器
|
||
- 没有 Player UI 显示，不应把 UI 只停留在编辑器侧
|
||
|
||
### 退出条件
|
||
|
||
- Prefab 复用链成立
|
||
- UI 文档与基础 UI 编辑链成立
|
||
- Player 可以显示基础 UI
|
||
- Prefab 和 UI 都进入正式构建链
|
||
|
||
### 阶段产出
|
||
|
||
- 一条内容复用链
|
||
- 一条基础界面制作链
|
||
|
||
---
|
||
|
||
## Stage D：M4 Player、打包、发布闭环
|
||
|
||
### 目标
|
||
|
||
让项目内容脱离开发环境，进入正式交付形态。
|
||
|
||
### 本阶段要证明什么
|
||
|
||
MetaCore 第一阶段不是“只能在开发机里演示的编辑器”，而是能产出独立运行结果的引擎工具。
|
||
|
||
### 主任务来源
|
||
|
||
- [metacore-m4-backlog.md](D:/MetaCore/docs/designs/metacore-m4-backlog.md)
|
||
|
||
### 核心任务
|
||
|
||
- Player 项目加载链统一
|
||
- 构建输出目录规范
|
||
- cook 规则固定化
|
||
- 编辑器打包入口
|
||
- 独立输出目录生成
|
||
- 发布态资源加载一致性
|
||
- 运行时日志与错误诊断
|
||
- 发布目录与移交规范
|
||
- clean machine 验证流程
|
||
- M4 回归测试矩阵
|
||
|
||
### 可并行部分
|
||
|
||
- 编辑器打包入口
|
||
- 发布目录与移交规范
|
||
- 日志与诊断补强
|
||
|
||
### 不应乱序的部分
|
||
|
||
- 没有统一 Player 加载链，不应定义正式交付目录
|
||
- 没有稳定输出目录，不应宣称具备交付闭环
|
||
- 没有 clean machine 验证，不应把发布链视为完成
|
||
|
||
### 退出条件
|
||
|
||
- 用户可以从项目生成独立 Windows 输出目录
|
||
- 输出目录包含运行所需最小内容
|
||
- Player 脱离 Editor 与源工程目录可运行
|
||
- 场景、模型、材质、UI、配置可正确加载
|
||
|
||
### 阶段产出
|
||
|
||
- 一条完整的发布链
|
||
- 一套可以移交的交付目录
|
||
|
||
---
|
||
|
||
## 关键依赖关系
|
||
|
||
### 硬依赖
|
||
|
||
- `M2` 依赖 `M1`
|
||
- `M3` 依赖 `M2`
|
||
- `M4` 依赖 `M3`
|
||
|
||
### 可前置设计、不可前置实现的项
|
||
|
||
- 可以在 `M1` 后半段开始预研 `glTF/.glb` 导入器设计
|
||
- 可以在 `M2` 后半段开始预研 Prefab / UI 数据模型
|
||
- 可以在 `M3` 后半段开始预研打包目录和 Player 加载链
|
||
|
||
### 当前不应抢占主线的事项
|
||
|
||
- 更广泛的模型格式矩阵
|
||
- 更复杂的 RuntimeData 增强
|
||
- VR/XR 工作流
|
||
- B/S 产品化
|
||
- AI 辅助编辑
|
||
- 高级渲染 feature
|
||
|
||
## 风险与节奏控制
|
||
|
||
### 风险 1：过早横向铺太多资源类型
|
||
|
||
控制方式：
|
||
|
||
- 先把 `glTF/.glb` 做成正式闭环
|
||
- 不要在第一条链没稳时分散到多个复杂格式
|
||
|
||
### 风险 2：编辑器体验先行、底层语义未收敛
|
||
|
||
控制方式：
|
||
|
||
- 资源、Prefab、UI 都必须先有正式模型，再补编辑器体验
|
||
|
||
### 风险 3：发布链最后才发现路径和资源假设不成立
|
||
|
||
控制方式：
|
||
|
||
- 从 M1 开始就统一 Editor / Player / Tool 的项目语义
|
||
- 从 M2 / M3 开始就让正式资源进入构建视角
|
||
|
||
### 风险 4：团队同时做太多里程碑，导致每条链都不闭环
|
||
|
||
控制方式：
|
||
|
||
- 一次只让一个主里程碑处于实现主导状态
|
||
- 后续里程碑只允许预研和设计前置
|
||
|
||
## 建议管理节奏
|
||
|
||
### 每个阶段建议包含 4 类评审点
|
||
|
||
1. 设计评审
|
||
2. 实现评审
|
||
3. 样板项目回归
|
||
4. 退出评审
|
||
|
||
### 每个阶段建议维护的状态
|
||
|
||
- `Design Ready`
|
||
- `Implementation In Progress`
|
||
- `Feature Complete`
|
||
- `QA In Progress`
|
||
- `Accepted`
|
||
|
||
### 每个阶段都应回答的三个问题
|
||
|
||
1. 这条主链现在是否真的跑通了
|
||
2. 目前是否还依赖临时 fallback 或 demo 假设
|
||
3. 如果现在暂停开发，这一阶段成果是否可被下阶段稳定继承
|
||
|
||
## Roadmap 完成后，是否可以开始开发
|
||
|
||
结论：
|
||
|
||
**可以开始开发，而且应该开始。**
|
||
|
||
但要注意，不是“roadmap 一写完就全团队同时铺开所有 backlog”，而是：
|
||
|
||
- roadmap 完成，说明方向、依赖和退出条件已经足够清晰
|
||
- 下一步应进入正式执行
|
||
- 执行顺序应从 `M1 P0` 开始，而不是并行开满 M1-M4
|
||
|
||
更准确地说，roadmap 完成后，团队应进入：
|
||
|
||
**按里程碑收敛的正式开发阶段。**
|
||
|
||
这意味着：
|
||
|
||
- 先把 M1 P0 任务卡开出来
|
||
- 给每张卡指定 owner、依赖和验收方式
|
||
- 以 M1 退出条件为第一阶段短期目标
|
||
- M2/M3/M4 只做必要的前置设计，不抢主线资源
|
||
|
||
## 建议的立即下一步
|
||
|
||
Roadmap 之后，建议马上做这 5 件事：
|
||
|
||
1. 把 `M1 backlog` 转成实际任务卡
|
||
2. 给 `M1 P0` 任务指定 owner
|
||
3. 建立第一版看板
|
||
4. 明确样板项目作为固定回归输入
|
||
5. 开始执行 `M1-01` 到 `M1-07`
|
||
|
||
## 结论
|
||
|
||
roadmap 的意义，不是再增加一层文档，而是把前面的设计文档收口成“可开始执行”的节奏。
|
||
|
||
所以答案很明确：
|
||
|
||
**是的，roadmap 完成后就应该开始开发。**
|
||
|
||
但正确的开始方式是：
|
||
|
||
- 从 M1 开始
|
||
- 从 P0 开始
|
||
- 从主链开始
|
||
- 从可验收的任务卡开始
|
||
|
||
只要按这个节奏推进，MetaCore 第一阶段就会从“概念正确”进入“执行正确”。
|