Evilom
112 lines
8.4 KiB
Markdown
112 lines
8.4 KiB
Markdown
# NLKrw7OJsirClOkhlHFcVeUCn5c
|
||
|
||
Source: https://dianchukeji.feishu.cn/wiki/NLKrw7OJsirClOkhlHFcVeUCn5c
|
||
|
||
|
||
# 一、工作概述
|
||
# 二、主要产出
|
||
## 2.1-订单系统修复和优化
|
||
### 2.1.1-初版迭代
|
||
初版根据AI自测和实际跑测反馈的数据，让AI自我迭代，对原方案进行优化调整
|
||
- 难度评价维度不够：其引入了等级因素进行难度评价维度的扩展，便于更直接的进行难度监测，增加可供难度调整决策的量化数据。
|
||
- 保底机制不够完善：增加了批量去除重复订单、订单难度评价数量从3拓展到5个以及跨链自适应等调节措施
|
||
|
||
- 去人物等级因素：AI的大体优化思路没问题，但具体的操作方向有偏差，例如二合中难度不应该受人物等级制约，而是当前的物品的生产能力，用100体力（上限）能产出多少的1级合成物品，决定了玩家能在单位时间段内完成什么样难度的的订单。因此需要去掉人物等级的影响，依然以产能为主要判断因素，同时少量引入时间因素，例如玩家长时间卡在一个订单，后续订单就需要适当降低难度。
|
||
- 补充和优化保底机制：总体来说AI的保底策略都很有必要，能够规避不少的极端风险，但有些保底的数值需要人工细调，例如过渡的订单难度，AI设定的难度太低了，体现不出阶段的变化感。同时还存在一些保底没有覆盖的地方例如：留存期不能出现空槽，保持场上至少有一个订单，订单不能出现低于3级的物品，避免后续的订单物品标记过多/未产生合成操作就完成订单的错误认知。
|
||
|
||
### 2.1.2-订单阻隔问题：
|
||
- 问题：通过实测发现订单阶段转换存在阻隔问题，AI自诊后发现是阶段转换的剧情条件没有匹配上，核心原因是前期体验的流程配置和订单系统的配置没有互通，订单系统AI只是基于我给的调研数据设定的在剧情4来进行阶段转换，但前期体验剧情并没有配置剧情4，所以最后的结果就是不能顺利进入循环留存阶段。
|
||
- 解决方案：日志检查锁定问题，再通过添加校验机制，在每次加载时确保所有配置了前置条件的引用都存在，避免空引用情况
|
||
|
||
## 2.2-降包导出
|
||
### 2.2.1-降包
|
||
让构建产物满足微信小游戏包体限制（首包 ≤ 20MB，分包 ≤ 20MB），能在微信开发者工具中运行真机测试。
|
||
|
||
> [嵌入电子表格]
|
||
|
||
|
||
> [嵌入电子表格]
|
||
|
||
全部通过微信限制，可正常真机测试。
|
||
### 2.2.2-分辨率适配验证
|
||
- 已实现效果：能够适配大多数机型的分辨率，整体的大模块布局结构没有问题。
|
||
- 目前还存在的问题：棋盘背景和棋盘没有对齐，可能是分辨率配置没有同步到微信开发者工具中/在修改前面出现的问题是修改了对齐逻辑，明天还需要抽时间调整一下
|
||
|
||
- 其他问题及解决方案：
|
||
- 微信里运行效果和 Unity 编辑器不一致。
|
||
- 棋盘、订单区会整体上移或错位。
|
||
- 底部导航会顶到棋盘，甚至发生重叠。
|
||
- 某些分辨率下格子大小被压缩，运行后和编辑场景不一样。
|
||
- 把 Resources 里的适配配置同步成和 StreamingAssets 一致
|
||
- 保证微信运行时和编辑器使用同一套参数
|
||
- 顶部安全区只给顶部区域留空间
|
||
- 不再拿它去压缩订单区、棋盘区的整体比例
|
||
- 不再只看宽度
|
||
- 同时检查容器宽度和高度，取更保守的缩放值
|
||
- 保证格子尽量保持正方形，不乱形变
|
||
- 让 9:20 的正确布局关系成为基准
|
||
- 其他分辨率都从这套模板推导，不再“拍脑袋重算位置”
|
||
## 2.3-bug修复
|
||
### 2.3.1-订单人物刷新混乱
|
||
原因：采用了两套独立的记录逻辑，但更新时间不统一；AI读取每套逻辑的快照时，发现都是正确合理的，但实际两套逻辑在运行时的时序是独立的，导致记录已经出现人物A，但缓存中仍然可选人物A，从而出现多个订单出现同一人物；AI 写完 _availableCharacterIndices 的重建逻辑后，代码看起来是完整的——有初始化、有排除、有回退。这满足了 AI 的"代码完整性检查"。但"每行逻辑单独看都对"不等于"所有行在实际执行顺序下组合起来也对"。AI 缺乏对运行时时序的敏感度。
|
||
解决方案：删掉缓存，每次需要时直接从 记录实时计算可用列表。只保留一个真值来源。
|
||
### 2.3.2-生成器点击动画被覆盖
|
||
- 问题：AI做动画时只关注了"对谁播放动画"，没有去追踪这个动画目标在后续流程中会不会被别的代码删掉。这个项目的 UI 刷新机制是"全部销毁再重建"，而不是"保留已有对象只更新内容"。这种销毁式刷新和动画天然冲突，但在写动画代码时没有去检查刷新逻辑的实现方式。
|
||
- 解决方案：给任何 UI 元素做动画之前，先确认这个元素的生命周期——它在动画播放期间会不会被其他代码销毁或重建。如果会，就需要在动画期间保护它不被销毁（像现在用的集合标记方案），或者改为对不会被销毁的父容器做动画。
|
||
# 三、收获和反思
|
||
## 3.1-收获：
|
||
- AI编程的一些常规问题和约束设计：
|
||
## 3.2-反思：
|
||
- 降包导出和分辨率适配：
|
||
- StreamingAssets 和 Resources 里如果必须双份存在，就必须建立同步机制，改一份就同步另一份，不能手改两边
|
||
- 永远明确哪个分辨率是设计真值，适配系统只负责从真值推导，不负责“重新设计布局”
|
||
- 棋盘背景、棋盘容器、格子、底部导航这种强关联区域，必须一起定义约束
|
||
- 不要只改其中一个对象
|
||
- 顶部安全区：只做避让，底部安全区：优先转成底部控件和内容区净空，不轻易拿安全区去压整个主布局
|
||
# 四、明日计划
|
||
1.完善前期体验的流程配置，包含订单和棋盘配置的统一调整
|
||
2.补充音效、震动反馈等基础的反馈效果，优化流程反馈体验
|
||
3.补齐美术资源和剩余两条合成链的配置，同步加入到前期体验流程配置中
|
||
# 五、当前进度和规划
|
||
时间
|
||
模块
|
||
交付物
|
||
交付标准
|
||
完成情况
|
||
本周任务完成进度（%）
|
||
D1
|
||
Bug修复 + 节奏调整
|
||
修复版本、调整记录、修正后的节奏判断
|
||
所有P0修复，高概率P1修复，剧情衔接和订单难度曲线调整完成，结合提测反馈修正数值判断
|
||
1.完成动态分辨率适配功能
|
||
2.完成订单节奏的前期数值调研反推
|
||
3.优化订单人物重复出现、副链没有生产路径等功能性问题
|
||
4.新增转场动画
|
||
20%
|
||
D2
|
||
音频接入 + 专项验证
|
||
音频接入版本、音频问题清单、专项测试记录、广告与资源中断节奏补充结论
|
||
BGM和音效全部接入，激励广告/存档/设置专项验证通过，无奖励重复发放、无进度丢失
|
||
1.完成订单系统测试并修复明显bug和配置冲突
|
||
2.完成降包导出和分辨率适配验证
|
||
3.修复
|
||
0%
|
||
D3
|
||
美术资源补齐 + 护栏草案
|
||
二轮美术资源包、美术替换清单、二合数值护栏草案
|
||
缺失头像/立绘/插图/图标/按钮补齐，统一命名规范，替换低质量占位，护栏草案从样本上升为可复用结论
|
||
未完成
|
||
0%
|
||
D4
|
||
提审项收口 + 真机回归
|
||
提审清单、提审说明模板、自查记录、真机回归记录、数值护栏修订记录
|
||
隐私政策/协议/版本号/客服入口齐全，未开放入口移除，真机完整回归1轮无白屏/崩溃/死路
|
||
未完成
|
||
0%
|
||
D5
|
||
提审版打包 + 护栏沉淀
|
||
提审版包、提审说明、最终交付清单、最终数值护栏文档
|
||
核心流程稳定，广告奖励正常，UI无未开放入口，剧情/美术/音频达可展示标准，数值护栏可复用
|
||
未完成
|
||
0%
|
||
规划风险提醒：探索与收口失衡【最高优先级】、空间压力设计失误、订单节奏不合理、广告点打断体验、合成反馈不够满足、 美术风格不统一、 第一版系统定义过早、单人 AI 工具使用不熟 |