MS1 产品策划案评审：Windup（Refs #1 · 仅评审不合并）#2
Conversation
![fennoai[bot]](https://avatars.githubusercontent.com/in/1924301?s=60&v=4){kind=small}
|
感谢 review，三处一致性问题均已修订（commit d4fb4aa）：
|
|
|
||
| - 建角色 = 输入描述或上传参考图 → 产出身份 + 首个造型的基准帧候选 → 用户确认 → 角色卡锁定。 | ||
| - 加造型 / 换装 = 在角色下新建造型，选用已有穿戴资产或新建 → 产出该造型基准帧。 | ||
| - 锁定后角色卡只读；改形象生成新版（旧版保留，已生成动作不受影响）。 |
There was a problem hiding this comment.
改形象生成新版（旧版保留，已生成动作不受影响）
具体是指？
这里“角色卡”这个概念好像有点乱，在有的描述中，它是跟角色一一对应的，如
角色卡是这套静态内容的事实来源,一切动作生成都受它约束
锁定后角色卡只读
在有的描述中，它似乎跟角色是多对一的关系，如
角色卡 = 角色身份卡（跨造型不变）+ 当前造型的基准帧与外观。生成任何一帧的约束 =「角色身份 + 当前造型基准帧」。
另外“角色身份”跟“角色身份卡”是同一个东西吗？“角色”跟“角色卡”的关系我也有点迷茫
There was a problem hiding this comment.
这个确实有点混了，我们打算这样拆分，把角色/穿戴资产/动作分别分开，他们都不能独立作为最终素材，需要相互组合才能用：
独立：
1.角色：指跨造型稳定的部分——名字、脸、年龄、体型、关键标志（如断刃、独眼）、参考图。角色身份与造型无关，角色身份确定后可以更换造型而角色特征保持基本不变。
2.穿戴资产：指独立的服饰、服装、装备，例如长剑
3.动作：角色做出的动作，可被每个角色复用，例如walk
组合：
4.造型：角色+穿戴资产的结合，有点类似于人物的立绘
5.动作实例：角色+穿戴资产+动作，这个就是拿去生成可动资产的前一步素材或者直接是可以用的资产
这样可以吗
There was a problem hiding this comment.
5.动作实例：角色+穿戴资产+动作，这个就是拿去生成可动资产的前一步素材或者直接是可以用的资产
这个应该是“造型+动作”吧？造型会确定角色和穿戴资产信息，但是不等价于角色+穿戴资产
这里说的组合关系本身我没什么大的问题，不过这么表述有点复杂且跟用户侧的心智模型有差别 🤣 比如“那个包含了一份稳定信息（名字、脸、年龄、...）也包含了一个或多个造型的东西”在这套定义里边是没有名字的，但是一般来说我们会觉得那个东西才是“角色”
反而是原来文档中的设定问题不大，只是明确区分不同的概念（尤其是不要误用名字）就好
1.角色：指跨造型稳定的部分——名字、脸、年龄、体型、关键标志（如断刃、独眼）、参考图。角色身份与造型无关，角色身份确定后可以更换造型而角色特征保持基本不变。
这里也是一个“误用名字”的例子，这里叙述中提到了一个“角色身份”的概念，但是这个“角色身份”跟“角色”似乎是同一个概念；这就很容易让人困惑
There was a problem hiding this comment.
Ok 明白了，那么我的理解是，依然用原proposal这几处，然后我们就改误用名字的问题：
1.不再乱定义，我们就把角色卡、角色、角色身份、角色身份卡同一归为角色。然后：
角色=这个人，基于我们常识理解，不单指这个人的外貌，而是外貌+衣着，但是和动作无关。
2.下面的造型和穿戴资产不变。造型就是角色穿特定衣服的样子，比如某个英雄的皮肤，角色就是这个英雄本身，无论穿什么衣服，只要是这个人就是这个角色
这样 ok吗
There was a problem hiding this comment.
谢谢老师，这两点很关键。我们从架构落地的角度把概念和命名收敛如下，供提案对齐（最终表述以提案为准）：
先接受纠正：动作实例 = 造型 + 动作（造型已经确定了「角色身份 + 穿戴」，不必再拆成「角色 + 穿戴 + 动作」）。
命名的根子问题正如您点的——是「角色」这个名字被两处占用了。我们定一条红线：「角色」只留给用户心智里那个整体，身份层另起名。
| 概念 | 是什么 | 一句话 |
|---|---|---|
| 角色 | 角色身份 + 一个或多个造型的整体 | 用户说的「这个角色」，名字属于它 |
| 角色身份 | 跨造型不变的部分（脸/体型/关键标志/参考图） | 角色的一个层，不再叫「角色」 |
| 造型 | 角色身份 + 一组穿戴 → 一张基准帧 | 换装/形态 = 新造型 |
| 动作实例 | 造型 + 动作 → 成套帧 | — |
| 角色卡 | 角色的事实来源快照（锁定只读）= 角色身份 + 当前造型基准帧 + 结构化描述 | 每角色当前一张；生成约束从它取 |
这样您最初问的几处歧义就消了：
- 「角色卡是 1:1 还是多对一」：它是「角色 + 当前造型」的快照视角、不是并列实体，跟着当前造型走 —— 每个角色当前一张卡。
- 「角色身份 vs 角色」：不再是同义词 —— 角色是整体，角色身份是它的一个层。
- 「改形象生成新版」：= 角色卡出新版本、旧版保留、已生成动作不受影响。
这套命名我们已落进架构 #3 的数据模型（一处一名）。提案侧的最终措辞请 @huyanxius 拍，我们架构按此对齐即可。
| 边界： | ||
|
|
||
| - 本期动作为单方向（横版，反向靠镜像）；多方向是规格取值扩展，不改概念结构。 | ||
| - MS1 只在单造型上跑通 idle / walk；动作跨造型 / 跨角色复用为自然延伸。 |
There was a problem hiding this comment.
MS1 的目标不是跑通（应该也来不及真的跑通），如果说产品上有一个“核心流程的跑通”节点，那是 MS2
当然这里的描述可以不用关联具体的 MS来说，直接说“第一版产品”或“核心流程”或像上一句一样说“本期”包括什么什么就好
| 这样做的考虑： | ||
|
|
||
| - 生成路线可替换是关键决策：产品对外承诺的是帧层面的输出契约（尺寸、对齐、一致性），不绑定单一模型；路线信息收在批次里，换路线不动概念结构。 | ||
| - 完整记录是开源可复现差异化的基础：任何人可按批次记录重放整条链路。 |
There was a problem hiding this comment.
任何人可按批次记录重放整条链路。
什么情况下一个人会想按批次记录“重放”链路？他的目的是？
There was a problem hiding this comment.
这个确实有点过头了，因为我们当时想的是：
我们做的是一个开源产品，会有一些人有测试和自己部署和测试的需求，想要按批次记录重放链路。如记录生成质量和在质量下降的时候去用历史批次的完整条件去定位问题。
但是在我们平台用户视角下，用户关注的是最终交付产品的质量，确实不会有太多重放链路的需求。
There was a problem hiding this comment.
明白了，那这个需求先不考虑吧，它面向的用户是平台本身的开发者，大概率会跟实现方案强相关；等后续我们真正实现了不同的方案，可能才更清楚应该怎么去满足
但是在我们平台用户视角下，用户关注的是最终交付产品的质量
是的，如果把我们的“用户”分成 1) 直接使用我们平台的用户 2) 自部署或基于我们平台二次开发的用户；先把前者的需求满足好显然更重要
|
|
||
| 行为： | ||
|
|
||
| - 只有全部帧通过的动作才进入导出包；有帧未通过则该动作不可导出，不产出残缺包。 |
There was a problem hiding this comment.
所以会有一个“通过”的概念吗？每个动作都有一个状态记录是否“通过”，用户在 UI 上通过显式的交互（如点击某个按钮）来标记某个动作通过？
There was a problem hiding this comment.
我们有设计一个通过的概念，系统先会对生成的素材进行一次检查，如果有高度不统一、背景去除不完整等等等会自动打回重新生成（我们 livedemo 上就能有演示）。
另外对于用户来说也有一个显式交互的概念，让用户自己判断每一帧的动画是否能用。
但是这个可能不一定在前期（图片生成后）一个个标记，因为后期生成质量提高且素材量大就容易带来没必要的重复劳动，这个显式交互一版可以放在用户后续对一些看起来明显有问题的图片进行查验或者重新生成的时候，例如对某一帧标记不通过，系统能够重新生成。
（但是这个也是针对逐帧生成，对于视频生成的工作流明显是不适用的，那么也可以考虑在前期大架构是否要真的加入）
There was a problem hiding this comment.
但是这个也是针对逐帧生成，对于视频生成的工作流明显是不适用的，那么也可以考虑在前期大架构是否要真的加入
以这个功能为例，我会建议在现在的设计中把这个“检查/通过”的机制做在动作上，毕竟对每个可能的工作流，“动作”都是一个合适的交付单元。
然后对每个具体的工作流，它对应的“对单个动作的检查逻辑”可以各不相同，不管这个检查是系统自动做的还是用户做的；以用户检查为例，我们可以抽象“对单个动作的检查 UI”，然后每个不同的工作流去提供不一样的检查 UI，比如
- 逐帧生成的检查 UI 可以是给用户逐帧检查，然后可以顺便提供编辑单帧的能力
- 视频生成的检查 UI 可以是给用户直接播放视频，然后可能顺便提供裁剪视频或重新生成整个视频的能力
| 行为： | ||
|
|
||
| - 只有全部帧通过的动作才进入导出包；有帧未通过则该动作不可导出，不产出残缺包。 | ||
| - 按项目的目标环境出包：首期为 Cocos Creator / 微信小游戏（图集与命名符合其导入习惯，目录按远程加载组织——角色资源默认不进 4MB 主包）；Web 通用预览始终可用。 |
There was a problem hiding this comment.
“Cocos Creator / 微信小游戏”算一个环境吗？
比如
- Cocos / Web
- Unity / 微信小游戏
也分别算一个环境？
所以可以认为“环境”信息是同时定义了引擎和平台？
There was a problem hiding this comment.
我觉得可以这样认为，环境=引擎+平台。
因为这里我们要考虑的有两个，第一是微信小游戏平台的加载策略，即4MB 主包+远程加载，第二是 Cocos 引擎有其独有的图集格式、命名与导入习惯，如果要做适配的话两个缺一不可
而我们把微信小游戏和 Cocos 绑在一起做第一优先主要是基于：
1.国内小游戏市场很大，微信小游戏是国内小游戏的大平台之一
2.微信小游戏畅玩榜61% 左右由 Cocos 开发。
所以微信小游戏+Cocos 引擎可以很大程度上代表了我们国内小游戏的环境，也作为我们要针对的主要用户群体。
There was a problem hiding this comment.
微信小游戏+Cocos 引擎可以很大程度上代表了我们国内小游戏的环境，也作为我们要针对的主要用户群体。
这个我没问题
第二是 Cocos 引擎有其独有的图集格式、命名与导入习惯
这个也是好理解的，我大概能想到针对不同引擎我们可能导出的包是什么样的格式区别
第一是微信小游戏平台的加载策略，即4MB 主包+远程加载
这个我还不太清晰，以“4MB 主包+远程加载”这个需求为例，我们为了满足这个需求在导出产物上的差别具体会是什么样的？
There was a problem hiding this comment.
根据我们目前查到的一些资料来说，如果只到平台导出产物这一步，两者没有区别。导出的 PNG 帧、图集、JSON,不管目标环境要不要 4MB+远程加载,都是同一份文件。差别只在后续开发者拿到文件的配置步骤，但是这个前期并不算是我们做的工作
那么这样看来，其实小游戏的平台策略或许就不是我们前期考虑的问题？
There was a problem hiding this comment.
那么这样看来，其实小游戏的平台策略或许就不是我们前期考虑的问题？
嗯是的，不过当前的文档也没有特别去针对 Cocos Creator / 微信小游戏做什么功能上设计，只是定义为一种“环境”，这个没问题的，我们应该预想到后边会支持不同的引擎和平台。
只是既然用了“环境”这个概念，那就需要定义清楚什么是“环境”；比如上面还提到
目标环境（如"手绘横版 / Cocos Creator / 微信小游戏"）
这里的“手绘横版”也是让人困惑的
There was a problem hiding this comment.
因为我们前面提到了
- 记录题材、美术风格、目标环境（如"手绘横版 / Cocos Creator / 微信小游戏"）。
这里的手绘应该是对应的美术风格，横版应该是题材（横版动作游戏），然后Cocos Creator / 微信小游戏指向目标环境
huyanxius
left a comment
huyanxius
left a comment
There was a problem hiding this comment.
因为我们前面提到了
记录题材、美术风格、目标环境（如"手绘横版 / Cocos Creator / 微信小游戏"）。
这里的手绘应该是对应的美术风格，横版应该是题材（横版动作游戏），然后Cocos Creator / 微信小游戏指向目标环境
4 participants
本 PR 承载 MS1 产品策划案《Windup》全文，供导师/助教逐行评审。