Evilom
120 lines
6.5 KiB
Markdown
120 lines
6.5 KiB
Markdown
# WskKwiukWiDedpkHmvfcotP8nVd
|
||
|
||
Source: https://dianchukeji.feishu.cn/wiki/WskKwiukWiDedpkHmvfcotP8nVd
|
||
|
||
|
||
# 一、工作概述
|
||
# 二、主要产出
|
||
## 2.1-剧情节点拆解
|
||
通过游戏录频统计记录了前45段剧情对应的阶段性变化，以及金币消耗、奖励投放等重要参数内容，为后续阶段性节奏的编排，包括剧情和新链、新机制的投放节奏，以及如何设定金币和投放的奖励价值等数值框架设计提供决策依据和数据支撑。
|
||
|
||
以剧情阶段为节点进行的阶段性数据统计
|
||
|
||
#### 一、系统编排节奏
|
||
##### 1.1 系统编排总表
|
||
|
||
> [嵌入电子表格: BTOAsTFX4hd0svttNkFc...]
|
||
|
||
##### 1.2 系统设计思路
|
||
|
||
> [嵌入电子表格: BTOAsTFX4hd0svttNkFc...]
|
||
|
||
#### 二、奖励投放节奏：既是在给予玩家阶段性强激励反馈，也是在“给下一轮推进能力”
|
||
##### 2.1 奖励投放结构表
|
||
|
||
> [嵌入电子表格: BTOAsTFX4hd0svttNkFc...]
|
||
|
||
##### 2.2 关键奖励节点表
|
||
|
||
> [嵌入电子表格: BTOAsTFX4hd0svttNkFc...]
|
||
|
||
##### 2.3 奖励方法
|
||
|
||
> [嵌入电子表格: BTOAsTFX4hd0svttNkFc...]
|
||
|
||
**奖励不是结果，而是下一轮推进的启动器。**
|
||
也就是说，设计者发奖励时想的不是“玩家得了什么”，而是：
|
||
- 接下来他还能不能继续玩
|
||
- 新系统开了之后，他会不会立刻卡住
|
||
- 下一波复杂度上升时，他有没有缓冲
|
||
具体的奖励投放会参考后续拆解的奖励价值表格
|
||
#### 三、金币缺口数值框架控制“推进节拍”
|
||
现在把剧情 1-45 的金币成本整理后，可以看出非常清晰的节拍框架。
|
||
##### 3.1 金币成本档位表
|
||
|
||
> [嵌入电子表格: BTOAsTFX4hd0svttNkFc...]
|
||
|
||
##### 3.2 成本分布观察
|
||
- 前期高频：24 / 26
|
||
- 中期主频：26 / 54
|
||
- 后期主频：60 / 90
|
||
这说明它不是连续平滑涨，而是**分档切换**。
|
||
设计者其实在用不同成本档来切不同“推进节奏”：
|
||
- 小目标：给推进感
|
||
- 中目标：给小蓄力
|
||
- 大目标：给阶段门槛
|
||
##### 3.3 按等级段统计的金币总成本
|
||
已补上 剧情6 = 24 后：
|
||
|
||
> [嵌入电子表格: BTOAsTFX4hd0svttNkFc...]
|
||
|
||
##### 3.4 可推导的金币框架模型
|
||
可以把它粗略概括成：
|
||
更具体地说：
|
||
- 24/26/30 是基础推进成本
|
||
- 46/54/60 是中阶段门槛
|
||
- 80/90 是大阶段门槛
|
||
- 当节点承担“新系统/重要奖励/阶段跳变”职责时，会叠加更高门槛
|
||
##### 3.5 对应玩家体验推导
|
||
这种框架带来的玩家体验不是“稳定变难”，而是：
|
||
- 经常出现“差一点就够”的短缺口
|
||
- 偶尔出现“这次要攒一轮”的中缺口
|
||
- 在关键阶段感受到“这是大门槛”的长缺口
|
||
所以金币成本不是只管经济平衡，它还在管：
|
||
- 节奏长短
|
||
- 目标重量
|
||
- 阶段感强弱
|
||
## 2.2-道具拆解
|
||
|
||
**道具价值计算总结**
|
||
这次的核心做法，是把所有奖励尽量统一换算成“**等额体力价值**”，这样不同类型的道具就能直接横向比较。
|
||
|
||
> [嵌入电子表格: BTOAsTFX4hd0svttNkFc...]
|
||
|
||
**本次比较关键的几个公式**
|
||
## 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
|
||
20%
|
||
D2
|
||
20%
|
||
D3
|
||
20%
|
||
D4
|
||
D5
|
||
规划风险提醒：**探索与收口失衡【最高优先级】、空间压力设计失误、订单节奏不合理、广告点打断体验、合成反馈不够满足、 美术风格不统一、 第一版系统定义过早、单人 AI 工具使用不熟** |