Evilom
117 lines
6.7 KiB
Markdown
117 lines
6.7 KiB
Markdown
# TMn9wgM9LiP3OBkiLdOc72z4nmh
|
||
|
||
Source: https://dianchukeji.feishu.cn/wiki/TMn9wgM9LiP3OBkiLdOc72z4nmh
|
||
|
||
|
||
# 一、工作概述
|
||
# 二、主要产出
|
||
## 2.1-订单方案细化
|
||
### 2.1.1-订单方案迭代过程
|
||
- 16个固定订单，纯链式解锁(unlock_order_id)
|
||
- 权重排序决定展示优先级
|
||
- 无阶段划分，无循环补充，池耗尽即无订单
|
||
- 无动态难度，无订单生成器
|
||
确定核心架构：
|
||
|
||
> [嵌入电子表格: KgEHssqEahygp7tBpKEc...]
|
||
|
||
关键决策：
|
||
- 展示槽 + 待补充池双层结构
|
||
- 待补充池上限6，FIFO出队
|
||
- 剧情订单不舍弃等空位，生成订单超限舍弃
|
||
- 离线最多补偿1批
|
||
- Easy档固定单物品，Medium/Hard支持1~3物品
|
||
- 成本模型：cost(lvN) = 2^(N-1)，体力花费 = cost / playerE
|
||
- 难度三档：Easy(4~11体力)、Medium(12~25体力）、Hard(26~50)
|
||
- 硬上限：单订单 < 100体力
|
||
- 动态配比：最近3单平均体力 vs 目标值(15)，ratio偏高→多出Easy，偏低→多出Hard
|
||
- 奖励公式：cost × 1.5 × 档位倍率(1.0/1.2/1.5)
|
||
问题：Phase 2原有13单(B+C4+D5)产出118金，扣除剧情消耗50金后余额68金，Phase 3入口若设48金则多出20金，不够"紧"。
|
||
方案：砍掉 order_d03(混合数量10金) + order_d05(跨链10金)，推迟到Phase 3作为首批剧情订单。
|
||
结果：
|
||
- Phase 2 缩为8单，总收入98金
|
||
- 支出：剧情2(25) + 剧情3(25) = 50金
|
||
- 余额 = 98 - 50 + 引导5 = 48金 = Phase 3入口费用 → 紧平衡 ✓
|
||
- OrderData.json 重写（Phase 1引导单 + Phase 2的8单 + Phase 3的3个剧情单）
|
||
- 新增 OrderPoolConfig.json（全部可配置参数）
|
||
- OrderData.cs 扩展 phase/source_type 字段
|
||
- 新增 OrderPoolConfig.cs 数据模型
|
||
- ConfigManager 注册加载 + 新增按阶段查询接口
|
||
- 修复 CanFulfillOrder/TrySubmitOrder 的聚合逻辑（支持同item多条目格式）
|
||
- 多数量需求改为独立条目展示（jade_01×3 → 3个独立图标）
|
||
**其他新增模块**
|
||
|
||
> [嵌入电子表格: KgEHssqEahygp7tBpKEc...]
|
||
|
||
### 2.1.2-订单刷新机制推测
|
||
根据调研的订单数据和录频分析对订单刷新机制进行反推，满足以下特性：
|
||
## 2.2-动画动效优化
|
||
### 2.2.1-生成器动画制作：
|
||
### 2.2.2-订单结算动画
|
||
### 2.2.3-新手引导动画
|
||
### 2.2.4-剧情系统动画优化
|
||
优化动画整体播放时间由0.7缩减至0.2s，减少播放时间过长导致的拖带感
|
||
## 2.3-存档系统实现
|
||
设计文档中规划的所有核心功能均已落地：
|
||
- 架构层：ISaveDataProvider 模块化 + ISaveStorage 平台抽象 + A/B轮写容错，全部到位
|
||
- 数据层：4个模块（棋盘/订单/剧情/引导）的存档数据模型完整，订单模块还超额实现了池状态保存
|
||
- 安全层：SHA256校验、先写数据后更新meta、回退机制、防抖、版本迁移链均已实现
|
||
- UI层：手动保存按钮+反馈+Editor调试菜单均可用
|
||
|
||
# 三、收获和反思
|
||
## 3.1-收获
|
||
## 3.2-反思
|
||
- 于是后面选择让AI对比出问题的UI界面和浪漫餐厅的UI界面，自己分析问题并设计调整方案执行，最后一次性解决布局和UI结构乱的问题。
|
||
- 这和直接让它对照着改也有一定区别，在最开始进行剧情系统界面搭建时我就让AI照着浪漫餐厅的界面去改，但结果是它不能还原比例关系、布局结构，思考可能的原因是AI基于参考图去做布局搭建时，因为影响UI的元素过多，AI又是稳定为主，有些比例关系和原图不对应，AI就会采取相对保守的参数。例如第一版的界面，对话气泡缩放就很小，所以后续可以采用让AI先做一版，然后不断让它分析自己调的这版和参考的区别，已实现无限接近。
|
||
|
||
布局存在问题
|
||
|
||
让AI对照成熟的UI界面分析问题并给出具体方案并执行
|
||
# 四、下周一计划
|
||
# 五、当前进度和规划
|
||
时间
|
||
模块
|
||
交付物
|
||
交付标准
|
||
完成情况
|
||
本周任务完成进度（%）
|
||
D1
|
||
范围冻结 / 计划收口 / 数值调研启动
|
||
冲刺版主计划、功能清单、美术音频清单初稿、数值调研口径与样本池
|
||
所有 P0 范围冻结，无关键歧义；数值调研目标、字段范围、样本池明确
|
||
完成数值调研启动
|
||
明确后续两周的具体目标，量化需求和交付物
|
||
20%
|
||
D2
|
||
剧情系统框架 / 设置系统框架 / 调研准备
|
||
剧情系统框架、设置系统框架、存档方案、首个竞品记录样本起稿
|
||
剧情页和设置页能在工程里打开；竞品记录模板可用并开始首个样本记录
|
||
完成剧情系统和设置系统的功能实现和UI的原型搭建
|
||
完成存档功能的方案制定
|
||
补充少量美术和调研数据
|
||
20%
|
||
D3
|
||
合成链扩展 / 订单扩展 / 首批竞品采样
|
||
合成链配置初版、订单配置初版、高优先级资源列表、首批竞品轻量采样表
|
||
4 条链都能生成、合成、被订单引用；至少完成 2 个竞品核心循环采样
|
||
完成竞品前期的1h的调研数据整理
|
||
补充1条副链用于前期循环的构建
|
||
20%（合成链还有2条待补充）
|
||
D4
|
||
剧情接入 / UI 正式化 / 中期节奏记录
|
||
剧情脚本初版、剧情触发规则、引导改造版本、正式 UI 接入版本、中期节点记录补充表
|
||
开场、3 节点、结尾钩子可播放且不阻断主流程；核心界面不再依赖纯色块占位；已有中期节奏记录
|
||
1.对剧情批量生成工具做适配，为后续正式剧情接入做工具调试
|
||
2.补充订单、设置、对话界面的UI
|
||
3.实装剧情系统、设置系统以及新合成链条
|
||
4.前期体验参数正式录入
|
||
20%
|
||
D5
|
||
基础功能系统 / 提测版收口 / 数值基线
|
||
存档系统初版、合规入口初版、提测版包、联调记录、Bug 清单、首轮数值基线结论
|
||
可完整玩 10-15 分钟，无 P0 阻断；设置/存档/协议入口可用；已形成一轮可用于参数排查的数值基线判断
|
||
1.完成生成器、订单结算、新手引导和剧情系统的动画优化
|
||
2.对订单刷新机制进行和数值填充进行方案细化（待测试）
|
||
3.实现存档系统，可记录棋盘、订单以及剧情的进行状态。
|
||
15%（目前前期体验的具体流程还没跑通，还需要多次测试调整）
|
||
规划风险提醒：**探索与收口失衡【最高优先级】、空间压力设计失误、订单节奏不合理、广告点打断体验、合成反馈不够满足、 美术风格不统一、 第一版系统定义过早、单人 AI 工具使用不熟** |