Topic 1
背景 (Situation) ——【月相】上线前,动效需求量大、产能不足,需要以某种方式分摊压力,保证上线效果
提出核心问题 (Task)
基于需求量大的问题,需要从根本上提出疑问
1.Animation比较“脆弱”,应用在通用效果上易返工
预制结构、命名变化都会导致动画丢失; 每次预制有新内容加入,都需要动画人员来重新处理
2.通用动画当前无逻辑关联,出现同效果反复制作
当前只是制作人员的自我约束,新增就要重做,即便效果一致,浪费人力
引出核心目标
发现之前所谓的通用动画只存在在设计层面,落地层面并没有通用逻辑
可以减少当前 30% 的动效需求,为产能减负。同时解决后期维护问题
行动(Action)
—— 针对兼容性低,动效人员反复制作
AI写脚本工具,并进行测试确保可用性和兼容性无误
修改名称,改变结构位置都不影响(只要节点仍然存在)
代码绑定节点动画,不删除不丢失既然通用动画都是位移、缩放、透明度等基础属性,则通过代码制作更合适。逻辑绑定节点不会受到命名、位置等变动影响
脚本控件一键挂接,任何人员可完成这样谁都能直接挂接,无需浪费动效人员排期
( 只要有空余后进行参数优化即可)
针对通用动画只存在设计层面
用 AI编写参数模板化,使用时只能将节点挂入模板中。参数只能在模板中修改,确保通用性
动画模板化,重复效果无需制作,直接挂接即可不只是能够给节点附加动画,同时还可以保持参数模板。这样后续只要通过调整模板参数,则可全局应用一键修改迷,无需反复制作。
拖拽节点进入对应动画参组内,即完成挂接 直接在游戏中生效,无需其他岗位支持
结果(Result)
Untiy 通用动画脚本工具
将通用界面过渡动画组件化,游戏基本动效接近零成本挂接背景 (Situation) ——【月相】上线前,动效需求量大、产能不足,需要以某种方式分摊压力,保证上线效果
?
真的有那么多新需求吗?
发现实际有很多重复制作的通用效果
导致需求量大的真正原因是什么?
发现实际有很多重复制作的通用效果
预制结构、命名变化都会导致动画丢失; 每次预制有新内容加入,都需要动画人员来重新处理
当前只是制作人员的自我约束,新增就要重做,即便效果一致,浪费人力
需要通用动画有逻辑关联(母子件关系),同时预制修改和新增都有极高兼容性
如果可以有,什么价值?
如果可以有,什么价值?
—— 针对兼容性低,动效人员反复制作
( 只要有空余后进行参数优化即可)
使用后效果
结果(Result)
单界面动效制作效率提升
8倍
覆盖20+界面,累计节约人天
17.5
17.5
交互部门分享
已推广
单界面制作耗时从约4 小时缩短至约 0.5小时,且无需给动效、程序配合。策划、UE均可自行处理
2.5天完成批量挂接,有效缓解动效人力不足,并降低后续界面动效接入门槛
在部门内部完成一次分享,并有多个项目交互同学感兴趣,并进行适应性使用。同时存入部门跨项目工具
Topic 2
背景(Situation & Task) —— GUI产能受限,UE 需要提升高保真水平,补位上线质量利用 AI 提升高保真程度
整体思路(Action) —— Claude出提示词,Gemini生成结果 以claude code总结项目UI风格,并形成生成gemini提示词的工作流skill。再提供特定需求必要素材约束,整体打包给到Gemini进行最后一步生成
最终效果(Result)
保障了活动上线节奏,获得产品认可
【月相】运营活动 UI 生产
使用Gemini pro 辅助运营活动情绪以及背景图生成,辅助模块设计提效背景(Situation & Task) —— GUI产能受限,UE 需要提升高保真水平,补位上线质量利用 AI 提升高保真程度
整体思路(Action) —— Claude出提示词,Gemini生成结果 以claude code总结项目UI风格,并形成生成gemini提示词的工作流skill。再提供特定需求必要素材约束,整体打包给到Gemini进行最后一步生成
最终效果(Result)
单活动效率提升
3倍
累计节约人天
20
交互部门分享
项目认可
交互侧结合AI生成素材,产出可直接上线的UE 稿。单个活动从原本 UE+GUI
约3天压缩至约1天,单个活动周期缩短约 66.7%
已落地10个活动,累计节省约20人天
Topic 3
背景 (Situation)
—— 官方版本生成结构不够精简,有冗余、过深的节点,人工处理仍然比较麻烦
当前figma to unity 的官方版本会产生较多非需要的预制节点。人工调整的耗时仍然较高,为达到更好的自动化
洞察与目标(Task)
—— 经过使用测试和过往预制使用经验,发现以上问题。潜在导致预制过冗余,维护困难无论在节点深度还是数量相比资深的搭建人员仍然有一定优化空间
整体思路(Action)
—— 以“搬家”思考,整个搭建行动流程 搬出 —— 需要先判断有什么?什么要搬?怎么搬?搬入 —— 需要知道如何放置
—— 以全局规则和对应识别类型为结构,攥写md 文档
全局规则初步筛选处理(搬出前)fimga中无效节点不搬(如隐藏、空节点);复杂嵌套不搬,做结构打散;合图逻辑判断,避免错误合图或简单合并;位置参数转化为unity计算方式
具体类型实际处理(搬出后)特征识别定义,使AI能正确判断类型,再根据类型明确搬出数据和搬入存放方式(以合图为例,识别figma frame节点若均是图形,则整体导出单图片)
当前仍然在进行中...
Figma to Unity 设计转预制(进行中)
总结输出特征,攥写md规范,辅助提升自动化导入的效果背景 (Situation)
—— 官方版本生成结构不够精简,有冗余、过深的节点,人工处理仍然比较麻烦
当前figma to unity 的官方版本会产生较多非需要的预制节点。人工调整的耗时仍然较高,为达到更好的自动化
希望通过优化规则限制,使AI导入的效果更接近人为
洞察与目标(Task)
—— 经过使用测试和过往预制使用经验,发现以上问题。潜在导致预制过冗余,维护困难无论在节点深度还是数量相比资深的搭建人员仍然有一定优化空间
整体思路(Action)
—— 以“搬家”思考,整个搭建行动流程 搬出 —— 需要先判断有什么?什么要搬?怎么搬?搬入 —— 需要知道如何放置
—— 以全局规则和对应识别类型为结构,攥写md 文档
当前仍然在进行中...
以攥写处理组件、文本、图像合批、list提出重复item...