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 拍，我们架构按此对齐即可。
| 行为： | ||
|
|
||
| - 只有全部帧通过的动作才进入导出包；有帧未通过则该动作不可导出，不产出残缺包。 | ||
| - 按项目的目标环境出包：首期为 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 / 微信小游戏指向目标环境
|
我看有新的 PR，这个 PR 是不是可以 close 了？ |
ok，已 close |
|
已由更新版的 PR#38取代，本PR close |
4 participants
本 PR 承载 MS1 产品策划案《Windup》全文，供导师/助教逐行评审。