Windup 产品策划案：面向国产小游戏的 2D 角色素材生成资产工作台

[huyanxius]

项目 1 · 产品策划案

关联PR：#2

---

一、Windup 是什么

Windup 是面向缺乏美术产能的个人开发者与小型团队的 2D 角色素材生成资产工作台,覆盖从角色构思、动作生成、逐帧质检到引擎导入的完整链路。用户提供文字描述或参考图,即可为指定角色生成成套动作,并将其作为可长期管理、可复用的资产留存;最终交付物为一个可直接放入游戏项目使用的资源包,免去手工去背、切帧与对齐等重复工序。

与现有工具的根本区别在于"交付的是资产,而非图片"。现有产品止步于"生成完":交付图片或动图后责任即终止,角色资产的管理、迭代、复用与进入引擎均留给用户,其形态中只有"一次生成"、没有"角色资产"。Windup 将"从生成到进入引擎"的整条纵深做全——主界面是一个常驻的角色资产库,角色、造型、动作、帧以资产树长期留存,当日生成的角色可于日后回来补充动作、修正缺陷帧、重新导出,生成记录均可追溯;交付的是可直接进入项目、可持续迭代的角色资产。

在此基础上,Windup 面向国产小游戏生态进行适配。微信小游戏以 Cocos 为主力引擎,故适配 Cocos 即服务于微信等小游戏:导出资产按 Cocos 的图集格式、命名与导入规范组织,导入即可播放。同时,以角色母版约束保障跨动作、跨批次的视觉一致性,由工程系统而非模型概率输出保障;并保持开源、中文原生与生成模型 / 路线的可替换,不绑定单一厂商。

Windup 的底层逻辑是"母版约束生成 + 确定性工程后处理",并由统一工作流按动作类型调度生成路线。基于该架构,产品可延伸至非角色素材与长期资产复用管理,并可接入 Godot、Unity 等引擎。

---

二、背景与战略决策

2.1 背景与机会

生图模型已能稳定产出高质量的角色原画,"能否画出"基本得到解决;但从一张角色图到游戏引擎可直接调用的资产之间——动画生成、去背、切帧、按引擎规范导入、素材复用与项目管理——仍存在完整的工程链路空白,"能否用上"是当前真正的难点,其手工返工成本可达生成环节的十倍以上。该空白对目标用户具体表现为四个痛点:

• 交付止步于图片:工具产出的是单张图片而非可用资产;从图片到进入引擎,需手工完成去背、切帧、脚底线对齐、批量命名与引擎导入,该环节耗时远高于生成本身。
• 质量与成本双重失控:同一角色扩展为多帧、多动作时外观发生漂移(配饰位移、配色偏移、比例变化),结果往往是彼此相似却非同一角色;此类问题无法通过调整提示词稳定纠正,只能反复重试,而每次生成均产生费用,质量与成本同步失控。
• 质量缺乏检验:细微偏差(如脚底线数像素漂移)肉眼难以察觉,进入引擎播放后表现为抖动;工具不提供质检,缺陷帧混入交付物;且"一次生成"的形态中不存在"单帧不合格"的概念,发现问题只能整段重新生成。
• 生产不可持续:游戏素材需持续迭代(补充新动作、随版本重做),而现有工具只有"一次生成"、没有"角色资产"的概念;若需在既有角色上继续生产,只能重新描述、重新导入、从头执行整条流程。

骨骼动画路线在当前技术条件下尚不成熟:视觉模型难以准确理解图像坐标,导致部件拆分与锚点设置失准、骨架层级混乱(有公开失败记录);其可覆盖的资产类型有限(像素风、复杂动画难以实现);且资产质量缺乏客观判据,无法建立自动质检。此为本项目不采用骨骼路线的依据之一。

竞品方面,海外垂类产品(Ludo.ai、Meowa、PixelLab 等)已能生成可用的单段动画,其中 Ludo、Meowa 最为成熟。但以"从生成一张图到进入引擎可用"为轴衡量,现有产品均止于左端:它们选择横向铺开品类,与纵深方向天然冲突。因此,"从生成贯通至进入引擎"的纵深尚无人做全,此为第一个空白。

第二个空白在国内小游戏生态:据中国音数协游戏工委《2025 年中国游戏产业报告》(2025 年 12 月发布),小程序游戏年收入 535 亿元,且全行业年度增长中过半来自小游戏。国内 2D 游戏的主要分发渠道为微信、抖音等小游戏平台;以微信为例,官方口径开发者规模约五十万、其中八成为三十人以下团队,开发管线高度集中于 Cocos 引擎(其小游戏畅玩榜前 100 中 Cocos 占约 61%)。然而现有素材工具中,无一针对该生态进行适配。

2.2 目标用户与核心问题

主用户为国内小游戏赛道的个人开发者与微型团队中的程序、策划及非专业美术成员:具备引擎使用与游戏逻辑开发能力,但缺乏美术产能;常见于横版动作、平台跳跃、Game Jam、独立原型及微信小游戏开发。首期优先服务已有角色设定或参考图、需快速补齐基础动作、并使用 Cocos Creator / 微信小游戏或 Web 预览链路的用户。

核心问题:如何以较低成本,将 AI 生成的视觉设定转化为符合国内小游戏工程规范、可直接进入引擎运行的连贯动作资产,并支持其后续的持续管理与复用。

2.3 战略决策与边界

一句话决策:放弃泛用型动画生成路线,以国产小游戏(微信 / Cocos)为主线,在八周内打通单一链路——从一句角色描述到可直接进入引擎播放的角色资产。该链路的完整性在于:生成仅为第一步,其后的管理、质检、资产复用、成本与效率权衡直至引擎导入,均属于同一套工作流,亦为多数竞品尚未覆盖的部分。基于此,确立四项决策:

• 决策一 · 只做人物资产。备选为横向覆盖全品类素材,或纵向专注人物。选择人物:人物是玩家直接操纵的对象与交互体验的核心,重要性最高;其难度亦最大——场景、道具以静态图即可满足,人物须动态呈现并在多帧、多动作间保持同一性,恰为当前 AI 尚未充分解决的部分。全品类为竞品已有路径,且与纵深方向冲突。
• 决策二 · 采用序列帧,不做骨骼动画。备选为骨骼动画(输出 Spine 等)或序列帧。选择序列帧:骨骼路线依赖模型从单图反推结构,是视觉模型的已知弱项;可覆盖的资产类型有限;骨骼资产的修复要求绑定、蒙皮等专业知识,超出目标用户能力;且质量缺乏客观判据、无法建立自动质检。序列帧则全引擎原生支持、质量可完全转化为自动检查,唯一代价为帧间易漂移,而这正由母版约束与自动质检控制。
• 决策三 · 首发微信 + Cocos。备选为初期即通用适配多引擎,或首发做深单一环境。选择后者,依据为 2.1 的生态调研。需说明:导出的逐帧 PNG、图集与元数据为全引擎通用格式,Unity、Godot 可直接手动导入;首发将 Cocos 一条链路做至"进入项目即可使用",属适配的优先级排序,而非将资产锁定于 Cocos。
• 决策四 · 成本与质量按动作类型选择路线。备选为全部动作采用低成本逐帧生成、全部采用高成本视频生成、或按动作类型分配路线。选择按动作类型分配:多数角色使用同一批默认动作(idle、walk、jump 等),数量有限,可预先将其生成工作流优化到位(姿势设定、参考提供、提示词),采用逐帧生成(image-to-image)这一低成本路线即可满足质量要求——质量来自预先优化,而非更高成本的模型;定制动作(如拔刀、拔枪)无法预先优化,若沿用低成本路线则需反复重试、总成本更高,故改用图生视频加抽帧(image-to-video)这一高成本但一次成型的路线,总体成本反而更低。另设三渲二(3D-to-2D)为备选扩展路线。三条路线最终收敛至同一交付物——序列帧,这也是更换路线无需改动产品的原因。

本期范围:单角色、单造型,支持默认动作(idle、walk、run、jump 等)的生成与验收,以及项目视角模式(侧视 / 俯视 / 2.5D)的多视角生成。

明确延后与不做:

• 降级支持:Godot、Unity 等引擎的自动化适配延后。
• 不做:骨骼动画(不输出 Spine 数据);UI、场景、道具、tileset、宣传图及 3D 等非角色类资产;完整引擎插件。风格不锁定,生成模板为架构中的可替换配置;本期先在像素风格域内将质量收敛至可用。

---

三、基本概念

3.1 项目(Project)

项目是组织角色的顶层单位,对应一款游戏或一次 Game Jam,类似工作区,于创建时设定。

• 记录三项独立信息:题材(如横版动作)、美术风格(如像素)、视角模式(侧视 / 俯视 / 2.5D)。
• 项目级的风格与视角约束作用于其下所有角色,新建素材默认继承,以保证多角色间的一致性。
• 视角模式决定角色所需母版数量;题材与风格作为生成约束。

边界:项目内的角色与资产管理为核心能力;同一角色或资产的跨项目复用为后续。

3.1.1 资产模型总览

核心思路:角色代表"一个人"(身份稳定),其外观由造型与穿戴拼装;穿戴与动作均为可独立复用的资产。资产库(Asset Library)为常驻主界面,以下资产在其中长期存在、可持续回溯扩展。

信息结构:

项目
├─ 角色（稳定身份 + 名下一个或多个造型；与动作无关）
│   └─ 造型（角色 + 一套穿戴资产 → 拥有独立母版）
│        └─ 动作实例（造型 + 动作，按视角分别存在 → 帧）
├─ 穿戴资产库（服装 / 服饰 / 装备，独立成卡，可跨角色复用）
└─ 动作库（动作定义，可复用的规格模板）

3.2 角色(Character)

角色代表"一个人"而非单张图片:其自身记录跨造型稳定的信息——名字、面部、年龄、体型、关键标志(如断刃、独眼)、参考图,并在名下持有一个或多个造型。同一人物更换造型后仍为同一角色:无论着装如何,只要是同一人物即为同一角色。角色与动作无关。

行为:

• 创建角色:输入描述或上传参考图 → 产出稳定信息与首个造型的母版候选 → 用户确认后锁定。
• 锁定后,角色的稳定信息与既有造型母版转为只读;修改形象即新建或修改造型,原造型及其已生成动作不受影响。
• 每帧生成以「角色稳定信息 + 所属造型母版」为约束,自动质检据此逐项比对。

这样做的考虑:

• 将"人物本身"与"着装、动作"分离,同一角色方可拥有多套造型并复用同一批动作;否则每套着装只能作为互不相关的新角色处理。
• 命名约定:"稳定信息 + 名下全部造型"的整体即为角色,身份为其属性,不再单独命名。

边界:角色仅服务于视觉约束,人设背景、世界观等叙事内容暂缓;本期仅做单角色 · 单造型,多造型 / 换装为后续延伸(数据模型预留接口)。

3.3 造型与穿戴资产(Outfit & Wearable)

造型是角色着一套具体穿戴后的形态(相当于角色的皮肤),即「角色 + 一组穿戴资产」,每个造型拥有独立母版。同一角色可有多个造型(常态、金甲、受伤态等),换装即切换或新建造型。

穿戴资产是构成造型的可复用组件——服装、服饰、装备(如长剑、红围巾),各自独立成卡,可跨角色、跨造型复用,创建一次即可多处套用。

这样做的考虑:资产的可提取、可迁移、可复用是贯穿全模型的原则;将角色拆分为身份与可复用组件,正是为使同一件穿戴资产可供多个角色使用。

边界:本期为单造型,穿戴复用限于同一项目内,跨项目复用为后续。

3.4 母版(Master Sheet)

母版是角色某一朝向的标准参考图(定妆图),是一致性的事实基准——后续每帧生成均以其为约束逐项比对。

• 在多视角项目中,母版构成"母版视角集合":侧视一张即可(反向经镜像获得),俯视 / 2.5D 需 4 或 8 向。
• 多造型情形下,每个造型拥有独立母版,并共用角色的身份约束。
• 各朝向母版独立生成,不以伪透视替代,每个朝向作为独立资产绘制。

3.5 动作与动作实例(Action & Action Instance)

动作是"运动方式"的可复用定义——名称、文字描述、姿势参考(可选)及规格(帧数、画布尺寸、FPS、是否循环、锚点、脚底线、生成模式)。默认动作(idle、walk、run、jump 等)可直接选用,定制动作(如拔刀居合)以文字描述创建,难以描述时可上传姿势参考图;一份定义可套用于任意造型。

动作实例是某造型下某动作、某视角的一套完整帧。金甲造型的 walk 与布衣造型的 walk 为两个实例,共用同一份 walk 定义。

行为:

• 用户在角色 / 造型下添加动作,形成动作清单,可批量选择多个一并提交;每个动作实例独立生成、独立检查、独立通过。
• 规格挂载于动作定义层,同一实例的全部帧共享同一套画布、脚底线与锚点。

这样做的考虑:

• 定义与实例分层,动作方成为可复用资产,与"生产者、着装"解耦。
• 动作是检查与交付的单元:一个动作实例整体判定"通过 / 退回";不同生成路线对同一动作可采用各自的检查方式(逐帧生成对应逐帧检查,视频生成对应整段播放 / 裁剪检查),将"检查 / 通过"机制固定于动作层,对任意生成路线均成立。

边界:本期在单造型上完成默认动作(idle、walk、run、jump 等);跨造型 / 跨角色复用为后续。

3.6 帧(Frame)

帧是生成与检查的最小单位,一个动作实例由按序排列的若干帧构成。

字段:序号、图片、所属动作实例、所属生成记录、状态、实测偏差。

状态机:待审核 → 通过 / 退回。每帧生成后先经自动质检(对母版比对一致性、对规格比对对齐与偏差),不合格自动标记退回;用户再行逐帧审核,退回可精确至单帧或单段并附备注,并携带相邻帧作为上下文单独重生成,已通过的帧不受影响。

这样做的考虑:竞品普遍存在"一套帧中单帧不合格即须整套重生成、且失败仍计费"的问题;帧级状态机将失败局部化,使返工范围由一套降至一帧。

边界:帧不支持手绘编辑(本期无画笔工具),修正的唯一方式为重生成。

3.7 生成记录(Generation Run)

生成记录是一次生成调用的完整记录,是可追溯的载体。

字段:提示词、参考条件(母版版本、姿势参考)、生成路线、模型与工具、次数、耗时、成本、产出帧列表。

行为:每帧可溯源至产生它的记录;记录对用户可见,包括某角色的累计生成次数、成本与所用路线;提交前显示预估消耗,生成后记入实际消耗。

这样做的考虑:产品对外承诺的是帧层面的输出契约(尺寸、对齐、一致性),不绑定单一模型;路线信息收敛于记录,更换路线不影响概念结构。

边界:本期不做配额与预算管理。

3.8 工作流引擎与入口(Workflow Engine)

工作流引擎是将上述概念串联并执行的底层机制:一次"生成动作"请求按动作类型自动路由至相应生成路线(决策四的落地);一段完成的流程可保存为模板,复用的是一套已验证的生产规范(尺寸、视角、动作数、帧率、命名、导出规则),可为新角色重放。

引擎之上设两个入口,二者操作同一条流程:

• Quick Start:标准任务以一句自然语言完成(如"创建一个横版像素骑士,需 idle、walk 与 attack 动作")。系统解析需求 → 选择角色与母版 → 建立动作节点 → 套用项目规格 → 执行 → 在需人工判断处暂停 → 输出资产包。用户无需搭建流程,底层仍为完整工作流。
• 画布(Canvas):面向需要精细控制的生产任务,以节点与连线呈现资产依赖、并行生产多个动作、局部返工(回到生产链的准确位置而非从头执行),并为不同动作指定不同生产方法;亦可打开 Quick Start 已建立的流程进行修改。

这样做的考虑:交互层与底层引擎分离,自然语言与画布仅为两种入口,底层的路线调度与质检门禁完全共用,而非两套系统。将流程保存为模板,使"复用生产规范"而非"复用图片"成为团队协作与批量生产的基础。

3.9 导出包与环境(Delivery Package)

导出包是最终交付物:一个角色若干已通过动作的完整快照,可直接放入游戏项目使用。

内容:GIF 预览、逐帧透明 PNG、sprite sheet(图集)、JSON 元数据(帧序、FPS、锚点、脚底线)、目标引擎导入说明。

行为:仅全部帧通过的动作可进入导出包,不产出残缺包;用户自行选择本次打包的已完成动作,不强制全量。

环境即"引擎 + 平台"(如 Cocos Creator + 微信小游戏),为项目的目标环境。微信小游戏以 Cocos 为主力引擎,故本期对 Cocos 的适配即覆盖微信小游戏的运行——导出包在 Cocos 运行时(含其微信小游戏构建)播放即达成微信适配。微信 4MB 主包与远程加载的分包组织属平台部署层细节,不改变导出产物本身,本期不展开;导出器按引擎以适配器组织,扩展引擎即新增一个导出目标,不影响产品。

这样做的考虑(交付序列帧而非骨骼数据):序列帧为全引擎原生支持的最低公分母、无运行时依赖,其质量判据(漂移像素、对齐、导入可播)可完全转化为自动化测试;骨骼资产要求绑定、蒙皮等运行时知识,超出目标用户能力,且质量缺乏客观判据。

---

四、核心流程与原型

Windup 的主界面为常驻资产库,资产贯穿全流程、可随时回溯。一次完整生产如下(标注:AI 生成 / 人工确认 / 工程自动):

1. 创建或选择项目,设定题材、风格与视角模式(人工)。
2. 进入生成:入口二选一(Quick Start / 画布),起点三选一——从零开始(以文本或参考图定义风格)、上传参考图(可先行风格化)、或从资产库既有资产出发(人工)。
3. 按项目视角配齐母版视角集合,逐张经门禁与确认后,角色定稿锁定(AI 生成 / 人工确认)。
4. 定制动作清单,可批量选择;逐动作确认规格与生成模式,提交前显示预估消耗(人工)。
5. 前台或后台生成(AI)→ 自动质检(工程):不合格帧自动重生成,设次数上限,达上限即停止并提示调整规格或更换生成模式。
6. 检查台逐动作审核(人工):支持播放、暂停、逐帧、慢放;退回单帧或单段并携上下文重生成,其余帧不受影响;动作全部帧通过方为完成。
7. 选择本次打包的动作,导出资源包(人工 / 工程)。
8. 实时预览(人工):在预览画布中以 WASD 操控角色移动、切换动作、绑定按键,验证操作手感;不满意可退回检查台。
9. 选择目标引擎 / 平台,按引擎出包并附导入说明,放入项目即可播放(人工 / 工程)。

原型:本产品含界面,依 01 规范两步法,于文字定稿后附原型。MS2 起原型建立在真实工程代码之上,以一个仅用于展示、不合并的 PR 承载,用以明确目标形态与预期行为。

---

五、核心假设与验收

5.1 核心假设

#	核心假设	验证方式	通过标准	失败退路
1	目标用户需要的是可进入项目、可持续管理复用的动作资产,而非更多单张角色图	5–8 名目标用户对比单图工作流与 Windup 资产工作流,各完成一次任务	≥4 人独立完成,并认可资产化管理与工程导出的价值	收缩为角色基准管理与动作素材整理工具
2	母版(定妆参考 + 结构化描述 + 参考图)可将跨动作一致性提升至可用水平	普通提示词与本方案各生成同一批默认动作,按面部、服装、配色、体型盲评	≥80% 动作帧被多数评审判为同一角色,且优于提示词基线	收窄角色类型与主风格
3	默认动作(idle、walk、run、jump 等)足以支撑原型与小游戏核心玩法	以横版动作、平台跳跃、轻量战斗三个场景展示并访谈	≥4 人指出明确使用场景	聚焦最高频的 idle、walk
4	按动作类型选择路线(默认走逐帧、定制走图生视频)可兼顾成本与质量	默认动作与定制动作各走既定路线,记录成本、成功率、一致性	默认动作以低成本达标;定制动作一次成型的总成本优于低成本路线的反复重试	缩小定制动作范围,标注实验档
5	动作级统一规格(画布、脚底线、锚点、帧序、元数据)可显著降低接入成本	用户将同一动作包导入 Cocos Creator,记录耗时与手工校正步骤	无需重切帧、批量改名、逐帧调锚点即可首次播放	固定 Cocos 版本与项目模板,提供强预设
6	中文、开源、模型可替换构成相对闭源竞品的采用理由	向 5 名目标用户展示闭源成品与开源工作流,访谈试用与替换意愿	≥3 人认可可控性、可替换性或国内链路适配	差异化收敛至角色一致性与 Cocos / 小游戏交付

5.2 验收标准

统一用例:像素风骷髅剑士。

说明:用户流程项由现有产品串联验证,生成质量项由生成路线实测验证。本期交付为可验证的假设与打通的核心链路,系统性质量数据的实测为后续承诺,不作为本期既成事实。

现状(不使用本产品):各动作分别以提示词逐个尝试,进入 Cocos 前需手工完成去背、切帧、对齐、命名与配置,耗时以小时计且结果不稳定。

提议后形态(逐条可判定通过 / 不通过):

1. 全流程可跑通:5–8 名目标用户试用,≥4 人无需讲解即完成"角色输入 → 角色定稿 → 动作选择 → 逐帧审核 → 导出"全流程(假设 1)。
2. 产出物:单次任务产出同一角色(单造型)的默认动作序列(如 idle、walk、run、jump),各自可循环完整播放(假设 3)。
3. 角色一致性:动作帧盲评判为同一角色的比例 ≥80%,且优于纯提示词基线(假设 2)。
4. 对齐与帧间稳定:画布一致、背景透明,脚底线对齐无肉眼可见跳动(量化阈值初设为帧高 3% 以内,第 1–2 周实验校准)。
5. 单帧重生成一致性:任一帧单点重生成后,与相邻帧不出现可见抖动或角色漂移(本期路线的关键风险,纳入实验专项验证)。
6. 引擎适配:导出包在 Cocos Creator / 微信小游戏首次播放成功,无需重切帧、批量改名、逐帧调锚点(假设 5);本期仅验收 Cocos 靶子(即微信小游戏主力引擎),Godot、Unity 不在本期。
7. 过程可追溯:每帧可溯源至生成记录(提示词、参考、路线、次数、耗时、成本)。

边界与非法情况:缺失母版、动作帧不全或规格检查失败时明确报错,不导出残缺包;验收不含换装、骨骼、特效、UI / 道具 / 场景、3D、完整引擎插件。