chore:文档补全
This commit is contained in:
Evilom
@@ -0,0 +1,157 @@
|
||||
# FMV0w4C8ai0oJXkxzhFcygeqnQB
|
||||
|
||||
Source: https://dianchukeji.feishu.cn/wiki/FMV0w4C8ai0oJXkxzhFcygeqnQB
|
||||
|
||||
|
||||
# 一.工作内容概述
|
||||
- 搭建美术Agent Team，跑通多agent协作资产交付流程
|
||||
- 重新确认项目美术风格方向
|
||||
# 二.美术Agent Team搭建
|
||||
当前项目在 UI 生图和资源交付过程中，已经不只是单纯生成效果图，而是逐步进入到“正式资产生产”的阶段。因此需要建立一套更稳定的多 Agent 协作流程，用来解决以下问题：
|
||||
- **正式资产交付**
|
||||
- 不只生成概念图或临时效果图，而是要能够输出可入库、可复用、可接入 Cocos 项目的资源文件。
|
||||
- 资源需要经过切片、透明背景处理、命名规范、QC 检查等步骤，避免后续人工返工。
|
||||
- **控制美术风格统一性**
|
||||
- 之前单次生图容易出现风格漂移、细节不稳定、不同批次资源不一致的问题。
|
||||
- 因此需要引入 art-director 角色，专门负责方向把控、概念审核和最终风格验收。
|
||||
- **支持后续功能拓展**
|
||||
- 除了生成图片资源，还需要配套完成资产管理、库存更新、配置文件生成等工作。
|
||||
- 后续如果继续推进自动拼 UI Agent，也需要提前沉淀 layout JSON、资源清单、命名规范等结构化数据。
|
||||
因此，这次搭建的目标不是单个生图脚本，而是面向正式生产的**美术资源生成协作流程**。
|
||||
## 实现思路
|
||||
本次将美术生产流程拆分为三个 Agent 角色，由主 session 进行统一调度和确认。
|
||||
### art-director：负责美术方向和风格验收
|
||||
art-director 的定位是主美 / 美术总监，主要负责：
|
||||
- 根据项目已有的 art_direction.md、style_anchors.md 等文档分析美术方向；
|
||||
- 判断新需求是否符合当前项目视觉定位；
|
||||
- 审核 asset-artist 生成的 concept 图；
|
||||
- 检查 sheet 和最终资源是否存在风格偏移；
|
||||
- 根据 asset_inventory.md 判断是否已有资源可以复用。
|
||||
这里特意限制 art-director **没有最终决策权**。它只负责提出审核意见，所有结果都需要汇报给主 session，再由主 session 展示给用户确认，避免 Agent 自行推进导致方向失控。
|
||||
### asset-artist：负责资源生成、图集生成、切片和 QC
|
||||
asset-artist 是实际执行生图和资源处理的角色，主要负责：
|
||||
- 根据 art-director 的方向指导生成 concept；
|
||||
- 根据 concept 制定 split_list；
|
||||
- 按相似尺寸、比例规划 sheet_plan；
|
||||
- 调用生图脚本生成资源 sheet；
|
||||
- 透明背景处理；
|
||||
- 通过脚本进行自动切片；
|
||||
- 执行最小 QC 检查并输出 qc_summary.txt。
|
||||
在 concept 生成阶段，流程分为两轮：
|
||||
- **Round 1：动态分析**
|
||||
- 如果有参考图，则通过 Responses API vision 分析参考图布局；
|
||||
- 如果没有参考图，则先优化生图 prompt。
|
||||
- **Round 2：脚本生成**
|
||||
- 调用脚本生成 concept 或资源 sheet。
|
||||
分成两轮是因为之前测试过的几个第三方API provider无法在同一个Responses API请求中同时加入文本文本 prompt、图片参考和生图工具调用，因此类似“对着参考图，按照要求生成图片”的任务无法通过这种方式单次完成。
|
||||
### asset-manager：负责资源入库和项目接入准备
|
||||
asset-manager 负责把 asset-artist 生成的资源转化为项目可用资产，主要工作包括：
|
||||
- 将最终资源放入项目对应路径；
|
||||
- 更新 asset_inventory.md；
|
||||
- 更新或生成相关 *_config.json；
|
||||
- 生成 layout JSON；
|
||||
- 验证 Cocos 项目中是否可以正常引用；
|
||||
- 汇报入库结果，再交由 art-director 做最终验收。
|
||||
这个角色的意义在于，资源生成完成后，不再停留在“图片文件交付”阶段，而是继续向项目资产体系推进。
|
||||
尤其是 layout JSON 的生成，后续可以作为自动拼 UI Agent 的输入，让后续流程不只是拿到图片，而是能进一步理解资源位置、尺寸、布局关系和模块结构。
|
||||
## 流程确认点设计
|
||||
为了避免 Agent 自动执行过程中导致方向偏移，当前流程中设置了三个关键确认点。
|
||||
### concept 确认
|
||||
asset-artist 生成 concept_draft.png 后，先由 art-director 审核：
|
||||
- 是否符合项目美术方向；
|
||||
- 是否和现有风格一致；
|
||||
- 是否具备拆分为正式资源的可能性。
|
||||
审核后汇报主 session，再由用户确认是否进入下一阶段。
|
||||
### split_list 确认
|
||||
concept 确认后，asset-artist 不直接生成所有资源，而是先制定 split_list。
|
||||
split_list 需要明确：
|
||||
- 哪些元素需要拆分；
|
||||
- 哪些元素可以合并复用；
|
||||
- 哪些文本、数字、标签不需要保留；
|
||||
- 按钮是否拆成底板、icon、红点等最小可复用单元；
|
||||
- 哪些资源后续需要进入配置文件或 layout JSON。
|
||||
这个确认点可以减少后续切图阶段的返工。
|
||||
### sheet 结果确认
|
||||
资源 sheet 生成后，需要再次展示给用户确认。
|
||||
这一步主要检查：
|
||||
- sheet 中的元素是否完整；
|
||||
- 是否和 concept 保持一致；
|
||||
- 是否出现风格漂移；
|
||||
- 是否有多余文本、错误图标、错误比例；
|
||||
- 是否适合进入抠图、切片和 QC 阶段。
|
||||
确认后再继续执行切片和交付。
|
||||
## 当前验证结果
|
||||
目前已经完成了美术 Agent Team 的基本配置整理，并初步跑通了简单任务流程。
|
||||
当前验证结果如下：
|
||||
|
||||
> [嵌入电子表格: FDzEsifIeh61gStemTdc...]
|
||||
|
||||
整体来看，目前这套流程已经具备基础可用性，能够从用户需求出发，经过美术方向确认、概念生成、拆分方案、资源 sheet、切片 QC，最终交付一组较完整的资源。
|
||||
## 后续计划
|
||||
后续主要围绕 **能力边界验证** 和 **流程稳定性优化** 继续推进。
|
||||
# 三.项目美术风格方向调整
|
||||
## 背景
|
||||
今天主要围绕游戏美术包装方向进行了进一步调整，重点从“普通可爱型角色 + 精致休闲 UI”，转向更具辨识度和社交传播潜力的 **meme 化角色 + 简洁清晰界面**。
|
||||
之前尝试过的方案整体完成度较高，界面也比较精致，包含手帐贴纸、纸张材质、胶带、便签、侦探元素等装饰。但在持续对比竞品和传播型角色后，发现原方案存在几个问题：
|
||||
- **角色辨识度不足**
|
||||
之前的小鸡形象更偏常规 Q 版萌宠，虽然可爱，但缺少一个能被用户快速记住的核心特征。玩家看到后更容易概括为“可爱小鸡”，而不是“那个很欠的小鸡”“那个表情很贱的小黄鸡”。
|
||||
- **角色气质过于普通**
|
||||
早期方案中的小鸡多是开心、卖萌、侦探、举放大镜等常规情绪，和市面上大量休闲小游戏吉祥物差异不大。它适合做装饰，但不一定适合成为社交传播中的梗点。
|
||||
- **美术包装偏精致，但传播点不够强**
|
||||
手帐风、纸张质感、贴纸边框等元素本身有风格，但如果角色本身没有强情绪和强人格，最终画面会更像“精致的休闲游戏界面”，而不是“用户愿意截图转发的梗图”。
|
||||
- **界面一度存在信息和装饰过多的问题**
|
||||
早期局内页和主界面加入了较多纸张、胶带、图标、装饰符号，虽然氛围丰富，但会影响主玩法区域的清晰度。尤其对项目这类依赖格子判断和颜色识别的玩法来说，画面必须优先保证易读。
|
||||
因此，本次调整的目标是：**在保留 2D 手帐贴纸风轻松感的基础上，增强角色的 meme 感、贱萌感和辨识度，同时简化界面装饰，让玩法区域更清晰，角色更适合社交传播。**
|
||||
## 常见主流 meme 梗图分析
|
||||
在风格调整过程中，对黄豆表情、熊猫头 meme、奶龙类角色和部分竞品角色进行了分析。整体来看，传播型角色通常具备轮廓简单、表情强烈、情绪模糊、易二创等特点。相比普通可爱角色，这类形象更容易被用户记住，也更适合用于截图、分享图和表情包延展。因此本次角色方向从普通 Q 版小鸡，调整为更具 meme 感和贱萌气质的小黄鸡。
|
||||
## 调整思路
|
||||
基于以上分析，本次美术方向的核心调整思路可以概括为：**用“圆润体型”保证亲和力，用“熊猫头 meme 式面部表情”建立传播记忆点，再用简洁清晰的 UI 布局保证玩法可读性。**
|
||||
具体调整包括以下几个方面：
|
||||
### 小鸡面部采用熊猫头 meme 方向
|
||||
本轮调整中，小鸡面部不再只做普通可爱表情，而是明确引入 **熊猫头 meme 的面部特征**，作为角色辨识度和传播感的核心来源。
|
||||
熊猫头 meme 本身具有很强的互联网认知基础，常见特征包括：
|
||||
- 半眯眼；
|
||||
- 斜眼看人；
|
||||
- 似笑非笑；
|
||||
- 表情略欠；
|
||||
这些特征和当前想要塑造的“贱萌小黄鸡”非常契合，可以让角色从普通 Q 版吉祥物，变成更容易被记住、截图和传播的 meme 化角色。
|
||||
具体落地时，不是完全生硬地贴一张真人脸，而是保留熊猫头 meme 的核心神态，并与小黄鸡圆润、软萌的身体结合，形成一个更有反差感的角色：**外形可爱，表情很欠。**
|
||||
这样既能保持轻休闲游戏的亲和力，又能强化角色的社交传播属性。
|
||||
### 界面从复杂手帐风转向简洁贴纸风
|
||||
早期手帐风尝试中，纸张边缘、胶带、回形针、便签、印章等装饰较多。
|
||||
这些元素虽然能强化氛围，但在局内界面中会影响玩法信息聚焦。
|
||||
因此最终调整为：
|
||||
- 保留温暖米白背景；
|
||||
- 保留轻微贴纸感和圆角卡片；
|
||||
- 减少纸张破边和复杂纹理；
|
||||
- 减少无功能装饰；
|
||||
- 强化按钮、棋盘、规则信息的清晰度。
|
||||
整体从“丰富手帐拼贴”调整为：**简洁 2D 贴纸 UI + 少量手帐质感点缀。**
|
||||
### 局内界面优先保证玩法可读性
|
||||
局内页面的重点是棋盘，因此最终风格更接近图 2 的简洁 UI：
|
||||
- 顶部资源栏简化；
|
||||
- 关卡标题居中；
|
||||
- 目标说明只保留核心信息；
|
||||
- 棋盘占据最大视觉空间；
|
||||
- 格子颜色清晰；
|
||||
- 按钮数量控制在底部；
|
||||
- 字号足够大；
|
||||
- 卡片边框轻量化；
|
||||
- 色盲模式不遮挡按钮和棋盘核心区域。
|
||||
局内界面从“氛围感优先”调整为“清晰度优先”，但仍保留小黄鸡和贴纸风的品牌感。
|
||||
## 调整后风格
|
||||
调整后整体方向确定为：**2D 简洁贴纸风 + 熊猫头 meme 小黄鸡**
|
||||
界面上，减少复杂手帐装饰和纸张拼贴，只保留轻量的圆角卡片、柔和底色和清晰按钮，让主界面和局内棋盘更干净易读。
|
||||
角色上，小黄鸡采用圆润二头身体型，保留蛋壳帽作为识别点，面部引入熊猫头 meme 的欠揍表情特征，形成“外形可爱、表情很贱”的反差感。
|
||||
配色上，整体采用 **暖米白 + 奶油黄 + 少量高饱和功能色** 的组合：暖米白用于背景和基础卡片，奶油黄用于角色和品牌主色，高饱和功能色则用于按钮、提示、奖励和关键交互反馈。
|
||||
这种风格相比之前更简洁，也更有传播点：
|
||||
- 界面更清晰；
|
||||
- 角色更有辨识度；
|
||||
- 表情更适合截图转发；
|
||||
- 配色更轻松明快；
|
||||
- 更容易延展成表情包和分享图。
|
||||
最终目标是让游戏不只是“看起来可爱”，而是具备一个用户能快速记住并愿意传播的视觉符号。
|
||||
效果图，非正式UI，仅做风格参考。后面会基于这个方向持续优化
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user