Evilom
308 lines
10 KiB
Markdown
308 lines
10 KiB
Markdown
# 2026.07.02日报-刘鹏
|
||
|
||
|
||
Source: https://feishu.cn/docx/WskKwiukWiDedpkHmvfcotP8nVd
|
||
|
||
|
||
# 一、工作概述
|
||
|
||
以剧情为节点，调研了前45段剧情对应的金币需求数量、奖励投放内容、对应是否升级、升级投放奖励以及新机制系统等，为后续阶段性节奏的编排提供决策支持
|
||
|
||
收集了6种类型奖励道具的具体数据并反推其价值，记录推算过程的中间产物价值，用于辅助后续奖励投放编排的决策
|
||
|
||
探索序列帧制作人物动画的可行性，得到初步验证的结果
|
||
|
||
# 二、主要产出
|
||
|
||
## 2.1-剧情节点拆解
|
||
|
||
通过游戏录频统计记录了前45段剧情对应的阶段性变化，以及金币消耗、奖励投放等重要参数内容，为后续阶段性节奏的编排，包括剧情和新链、新机制的投放节奏，以及如何设定金币和投放的奖励价值等数值框架设计提供决策依据和数据支撑。
|
||
|
||
以剧情阶段为节点进行的阶段性数据统计
|
||
|
||
#### 一、系统编排节奏
|
||
|
||
##### 1.1 系统编排总表
|
||
|
||
##### 1.2 系统设计思路
|
||
|
||
#### 二、奖励投放节奏：既是在给予玩家阶段性强激励反馈，也是在“给下一轮推进能力”
|
||
|
||
##### 2.1 奖励投放结构表
|
||
|
||
##### 2.2 关键奖励节点表
|
||
|
||
##### 2.3 奖励方法
|
||
|
||
奖励不是结果，而是下一轮推进的启动器。
|
||
|
||
也就是说，设计者发奖励时想的不是“玩家得了什么”，而是：
|
||
|
||
接下来他还能不能继续玩
|
||
|
||
新系统开了之后，他会不会立刻卡住
|
||
|
||
下一波复杂度上升时，他有没有缓冲
|
||
|
||
具体的奖励投放会参考后续拆解的奖励价值表格
|
||
|
||
#### 三、金币缺口数值框架控制“推进节拍”
|
||
|
||
现在把剧情 1-45 的金币成本整理后，可以看出非常清晰的节拍框架。
|
||
|
||
##### 3.1 金币成本档位表
|
||
|
||
##### 3.2 成本分布观察
|
||
|
||
前期高频：24 / 26
|
||
|
||
中期主频：26 / 54
|
||
|
||
后期主频：60 / 90
|
||
|
||
这说明它不是连续平滑涨，而是分档切换。
|
||
设计者其实在用不同成本档来切不同“推进节奏”：
|
||
|
||
小目标：给推进感
|
||
|
||
中目标：给小蓄力
|
||
|
||
大目标：给阶段门槛
|
||
|
||
##### 3.3 按等级段统计的金币总成本
|
||
|
||
已补上 剧情6 = 24 后：
|
||
|
||
##### 3.4 可推导的金币框架模型
|
||
|
||
可以把它粗略概括成：
|
||
|
||
更具体地说：
|
||
|
||
24/26/30 是基础推进成本
|
||
|
||
46/54/60 是中阶段门槛
|
||
|
||
80/90 是大阶段门槛
|
||
|
||
当节点承担“新系统/重要奖励/阶段跳变”职责时，会叠加更高门槛
|
||
|
||
##### 3.5 对应玩家体验推导
|
||
|
||
这种框架带来的玩家体验不是“稳定变难”，而是：
|
||
|
||
经常出现“差一点就够”的短缺口
|
||
|
||
偶尔出现“这次要攒一轮”的中缺口
|
||
|
||
在关键阶段感受到“这是大门槛”的长缺口
|
||
|
||
所以金币成本不是只管经济平衡，它还在管：
|
||
|
||
节奏长短
|
||
|
||
目标重量
|
||
|
||
阶段感强弱
|
||
|
||
## 2.2-道具拆解
|
||
|
||
道具价值计算总结
|
||
这次的核心做法，是把所有奖励尽量统一换算成“等额体力价值”，这样不同类型的道具就能直接横向比较。
|
||
|
||
本次比较关键的几个公式
|
||
|
||
## 2.3-序列帧人物动画制作
|
||
|
||
今天把 AI 批量生成人物头像序列帧动画的方案推进到了“可用验证”阶段，整体链路已经跑通。
|
||
|
||
已完成内容
|
||
|
||
确定了基础方案：使用 Image2 + AI提示词 + 角色参考图 生成默认状态、目标表情图和中间帧。
|
||
|
||
已覆盖的表情方向包括：眨眼、高兴、沮丧、愤怒、疑惑等。
|
||
|
||
生成了一版 9 宫格完整序列帧图，并进行了人工裁剪抠图。
|
||
|
||
让 AI 编写了动画脚本并完成预制体制作。
|
||
|
||
已验证 3 帧闭眼动画方案可实现。
|
||
|
||
当前结论
|
||
|
||
这套生产链路已经验证可实现 90%以上 的效果，说明方向是成立的。
|
||
|
||
当前主要未解决的问题是：状态切换时仍存在轻微抖动。
|
||
|
||
已定位的抖动原因
|
||
目前判断抖动主要来自两类问题：
|
||
|
||
AI 生成的序列帧图像本身存在位置偏移。
|
||
|
||
切图不够精确，空白背景影响像素图像中心定位，导致序列帧播放时产生偏移。
|
||
|
||
当前解决方向
|
||
|
||
继续优化 AI 生图提示词，但这条路稳定性较弱，不作为唯一主线。
|
||
|
||
增加更多中间帧，计划提升到约 30帧，降低切换突兀感。
|
||
|
||
采用更精确的切图方式，或增加统一中心定位/锚点校正方法，提升序列帧播放稳定性。
|
||
|
||
# 三、收获和反思
|
||
|
||
## 3.1-收获:
|
||
|
||
拆解收获：这块，收获不只是拿到了《浪漫餐厅》的等级、奖励和系统开放信息，更重要的是看清了它背后的节奏语法。比较明确的认识是：好的前期设计不是平均加内容，而是分阶段切换复杂度来源。前期靠新链条制造新鲜感，中期靠新机制制造深度，后期靠长节拍和大补给维持长期目标。在物品价值计算方面，找到了新的驱动AI计算的方式，通过提供基础的数据和计算目标，让AI尝试计算，中间需要其他数据和规则询问我来补充，同时计算过程中我发现有些时候AI计算比较死脑筋，这时候需要人工干预采取更加简单的计算方法，后续我觉得可以将一些计算的逻辑沉淀下来整理成skill，便于后续AI展开计算。
|
||
|
||
## 3.2-反思：
|
||
|
||
团结AI使用：这两天尝试了团结AI来制作人物动画，第一版主要是使用团结AI自己基于头像参考图去生产序列帧，但整体的效果比较差，通过查阅文档总结出来主要是约束环境上团结AI支持的序列帧动画主要是全身（站立、奔跑等少量状态）状态和模型上对图像识别的能力较弱等问题，最终使得这套流程在团结引擎上没有跑通。现在第二版采用codex来完成图像制作，团结AI使用素材来制作序列帧，即提升了素材的可用性，又充分利用团结AI对Unity引擎的高支持性，实现了可编辑的序列帧动画
|
||
|
||
# 四、明日计划
|
||
|
||
继续梳理拆解剧情节点表格拆解的剧情节奏和等级核心数值。
|
||
|
||
继续完善人物头像动画的实现方案，尝试解决抖动问题，并标准化生产流程
|
||
|
||
优化订单反馈效果，增加进入和退出提交等动效反馈
|
||
|
||
# 五、当前进度和规划
|
||
|
||
时间
|
||
|
||
模块
|
||
|
||
交付物
|
||
|
||
交付标准
|
||
|
||
完成情况
|
||
|
||
本周任务完成进度（%）
|
||
|
||
D1
|
||
|
||
订单机制拆解和配置同步
|
||
|
||
剧情系统背景切换和旁白配置
|
||
|
||
仓库、合成动效问题优化
|
||
|
||
订单机制完整流程图和配置结构
|
||
|
||
剧情系统背景可切换，旁白可居中配置
|
||
|
||
仓库、合成动效突兀出现在其他二级
|
||
|
||
输出订单系统完整流程图，包含生成、刷新、完成、奖励发放、异常中断等关键节点，并整理对应配置字段说明。
|
||
|
||
订单相关配置可定位、可修改、可同步，形成一份配置说明文档。
|
||
|
||
剧情系统支持按节点切换背景，切换后显示正确、无错位、无丢失。
|
||
|
||
拆解浪漫餐厅订单显示和补充机制，完善整个订单刷新机制配置
|
||
|
||
剧情系统界面背景和旁白配置方案落地
|
||
|
||
仓库界面优化、合成动效UI触发逻辑优化
|
||
|
||
20%
|
||
|
||
D2
|
||
|
||
广告位 ID 替换
|
||
|
||
新手引导补全
|
||
|
||
背包解锁阶梯设计 + 配置
|
||
|
||
AdService.cs → 微信后台真实 ID
|
||
|
||
增加"合并两个 gen_craft_lv1 → gen_craft_lv2"的引导步骤
|
||
|
||
设计 4→20 格的解锁节奏，写入 BackpackUnlockConfig.json
|
||
|
||
广告位替换为真实 ID，并完成基础验证。
|
||
|
||
新增合并引导步骤，流程可正常触发。
|
||
|
||
完成 4→20 格背包解锁节奏设计并写入配置。
|
||
|
||
拆解浪漫餐厅关卡设计框架，完成资源循环和目标控制部分拆解，为后续订单机制和资源循环框架提供设计决策支持
|
||
|
||
总结梳理已完成的数值框架汇总到总结拆解方案，方便后续检查和调整
|
||
|
||
优化顶部状态栏UI、新增头像和体力补充广告埋点
|
||
|
||
20%
|
||
|
||
D3
|
||
|
||
XP 等级数值设计
|
||
|
||
XP 系统配置实现
|
||
|
||
顶部状态栏改造
|
||
|
||
等级曲线、XP 来源权重、等级奖励表
|
||
|
||
配置 reward_xp、升级判定逻辑、存档
|
||
|
||
去钻石栏、加头像框+等级、体力按钮接广告埋点
|
||
|
||
完成等级曲线、XP 来源和奖励表设计。
|
||
|
||
XP 获取、升级判定和存档逻辑可正常运行。
|
||
|
||
顶栏完成等级展示改造，体力按钮接入广告埋点。
|
||
|
||
继续拆解完善关卡设计框架目标控制和节奏编排部分的详细设计思路和方法拆解，梳理成拆解文档
|
||
|
||
在确保不会过度影响棋盘空间编排节奏的前提下，对仓库格子的释放节奏做适配棋盘空间的节奏编排和落地
|
||
|
||
拆解等级经验相关的数值和数值框架，确定前期等级成长节奏。
|
||
|
||
20%
|
||
|
||
D4
|
||
|
||
AudioManager 实现
|
||
|
||
音频资源配置
|
||
|
||
推送通知接入
|
||
|
||
BGM/SFX 播放管理器、音量控制、Settings 联动
|
||
|
||
AudioConfig.json + 接入已有的 merge_sfx_id
|
||
|
||
微信订阅消息模板、触发逻辑（体力满/订单刷新/回流）
|
||
|
||
完成 BGM/SFX 播放管理和设置联动。
|
||
|
||
音频配置可用，并接入现有音效资源。
|
||
|
||
完成体力满、订单刷新、回流等通知触发逻辑。
|
||
|
||
以剧情为节点，调研了前45段剧情对应的金币需求数量、奖励投放内容、对应是否升级、升级投放奖励以及新机制系统等，为后续阶段性节奏的编排提供决策支持
|
||
|
||
收集了6种类型奖励道具的具体数据并反推其价值，记录推算过程的中间产物价值，用于辅助后续奖励投放编排的决策
|
||
|
||
探索序列帧制作人物动画的可行性，得到初步验证的结果
|
||
|
||
D5
|
||
|
||
完成新链剧情配置包含背景、旁白图片
|
||
|
||
完成人物动画制作
|
||
|
||
完整剧情配置
|
||
|
||
人物动画制作完整workflow或者skill
|
||
|
||
新链剧情背景、旁白图片等配置补齐，系统可完整跑通。
|
||
|
||
完成人物动画制作 workflow 或 skill，支持批量生成。
|
||
|
||
规划风险提醒：探索与收口失衡【最高优先级】、空间压力设计失误、订单节奏不合理、广告点打断体验、合成反馈不够满足、 美术风格不统一、 第一版系统定义过早、单人 AI 工具使用不熟 |