chore:文档补全
This commit is contained in:
Evilom
@@ -0,0 +1,108 @@
|
||||
# Hy4Vw8qvtiNG2mkS0d5c5T06ntd
|
||||
|
||||
Source: https://dianchukeji.feishu.cn/wiki/Hy4Vw8qvtiNG2mkS0d5c5T06ntd
|
||||
|
||||
|
||||
# 一、工作概述
|
||||
1.完成UI动态适配，可根据不同分辨率设备动态压缩拉伸，确保整体布局不会漂移混乱
|
||||
2.进一步调研订单的难度数值，总结优化原有的订单刷新机制和配置数值
|
||||
3.新增界面转场加载动画，优化订单人物重复出现、副链没有生产路径等功能性问题
|
||||
# 二、主要产出
|
||||
## 2.1-UI的动态适配
|
||||
### 2.1.1-实现的功能
|
||||
- 启动时会先抓取场景里关键 UI 的原始 RectTransform 快照
|
||||
- 后续不同分辨率都从这套母版往回压缩，而不是重新生成一套布局
|
||||
- 会读取屏幕宽高、安全区
|
||||
- 支持 Unity 安全区，也预留了微信小游戏安全区提供者
|
||||
- 只在启动、尺寸变化、安全区变化时重算，不是每帧跑
|
||||
- MainGrid 不再单纯靠重新算 stretch 尺寸
|
||||
- 现在保留母版 offsetMin / offsetMax，再通过 localScale 做整体缩放
|
||||
- 这样比“直接改宽高+格子重排”更接近你在编辑器里摆的效果
|
||||
- 有 RequestLayoutUpdate()
|
||||
- 方便后续动态弹窗、延迟生成 UI、微信环境初始化后再触发一次适配
|
||||
### 2.1.2-出现的问题
|
||||
原因：AI常规走硬编码路径导致UI每次运行时都会从上往下自动重排，走的是代码中的编排逻辑而不是当前场景的UI参数
|
||||
解决方案：去掉硬编码的编排逻辑，并定义好之后AI再进行UI相关的编码时必须遵守以下接口要求：
|
||||
禁止未经归类的布局数字直接进入 UI 代码。
|
||||
以后新增 UI 代码里的数字分 4 类：
|
||||
- 允许直接写：纯动画插值参数；时间、速度、透明度、曲线参数；不参与布局的视觉特效数值
|
||||
- 必须走配置或模板：anchorMin / anchorMax / pivotanchoredPosition / sizeDelta / offsetMin / offsetMax字体大小、边距、按钮区域、弹窗区域动态 UI 的面板结构和摆放规则
|
||||
- 必须走适配层：跟分辨率、安全区、母版布局有关的值、棋盘、顶部栏、底栏、大区块位置尺寸
|
||||
- 允许例外，但必须声明、某些强耦合特效 UI、某些调试辅助 UI、某些一次性过渡逻辑
|
||||
- 原因：界面的每个UI都采取自己的适配基准在做适配，没有统一的标准参照，导致每个模块各顾各的，整体就表现出不统一、混乱的界面布局。
|
||||
|
||||
- 解决方案：定义好母版，后续的动态调整都要基于母版的统一和协调性来进行调整，即全局约束布局结构，局部保留一定的可调性适配一些极端分辨率的适配需求。
|
||||
- 问题表现：在进行动态分辨率的压缩和拉伸时，界面背景被顶部安全区挤压导致出现顶部黑边；调整棋盘的缩放规则时，没有带上棋盘背景，导致棋盘脱离棋盘背景
|
||||
- 解决方法：提前分模块定义好每个区域的约束和区域间的关系，例如界面背景是底层装饰背景，独立层级不与其他层级UI联系；棋盘和棋盘的背景对齐绑定，不能单独调整，需做整体的共同适配。
|
||||
## 2.2-订单数值调研
|
||||
### 2.2.1-成本调研
|
||||
主要对浪漫餐厅前期物品的成本进行数据推算和记录，便于AI辅助分析，推理出订单池的数值设计框架或者设计思路和方向，包括前期订单的难度区间定义、订单的投放节奏和投放的基础规则
|
||||
|
||||
5级面包链生成器的物品权重反推
|
||||
|
||||
面包、咖啡、土豆生成链不同等级物品基于当前生成器合成所需消耗的体力成本
|
||||
|
||||
前期订单的体力成本对应完成难度
|
||||
### 2.2.2-AI基于数据分析
|
||||
|
||||
上手期的订单投放节奏反推，辅助确定前期的体验节奏和目标
|
||||
|
||||
用于留存器订单池的难度数值参考，基本确定4个难度区间简单（4-20）、普通（21-45）、困难（46-80）、BOSS（81-128）。后续的剧情订单以及订单生成器的规则将参考以上的数据进行设计
|
||||
### 2.2.3-订单刷新机制的补充和思考
|
||||
补充了订单队列逻辑和显示槽的保底逻辑
|
||||
## 2.3-优化调整
|
||||
2.其他优化：
|
||||
- 修复了订单人物重复出现的问题：原因是新订单刷新时没有检测当前场上已有订单的人物占用
|
||||
- 修复了副链银链在前期没有产出路径的问题，原因是负责配置生成器的AI没有读取本地设计文档的前期体验规划，而只是基于我的功能提示词，去推算了一条配置链，导致前期最高出现3级生成器，但3级生成器不产出银链物品。
|
||||
# 三、收获和反思
|
||||
## 3.1-收获
|
||||
- 留存期的订单投放节奏设计：
|
||||
浪漫餐厅留存期13条预设数据分布约为 4:3:2:1（Easy偏向）。设计逻辑：休闲合成类游戏的核心循环是"频繁的小正反馈"，而非"平衡的挑战"。大多数订单应该让玩家感觉"随手就能交"，少数高难订单作为留存锚点。139体力订单超出了"单订单体力上限100"的设定。这不是 Bug 而是刻意设计——Boss 订单作为里程碑，给玩家一个"攒了很久终于交付"的高峰体验，配合超额奖励（×2.0）强化完成感。
|
||||
收获：体力 cap 不是所有订单的硬上限，而是"常规订单"的上限。需要一个显式的超限档（Boss）来制造节奏高点。同时必须有冷却机制（间隔5单）防止挫败感堆叠，保持玩家大部分时间都能轻松完成目标获得正反馈。
|
||||
## 3.2-反思
|
||||
- AI硬编码的问题：经过这段时间的实践，发现AI在制作UI功能时，普遍存在硬编码的问题，导致UI可调性差，大部分UI的问题都是硬编码导致。目前通过给项目设置了UI编码接口，大幅限制了AI硬编码的操作空间，让AI只能在有限定义的范围内进行硬编码，其他统一走配置
|
||||
# 四、明日计划
|
||||
1.测试调整后的订单刷新机制和数值配置，记录体验、数值结构或者机制上的问题，进行调整和优化，看是否需要补充新的数据或机制，测试标准就是前期体验顺畅，无机制漏洞，订单目标引导清晰且有节奏感。
|
||||
2.优化订单提示、人物素材、剧情旁白等美术方面。
|
||||
3.尝试降包或接入服务器来打包进行真机测试，测试是否能完成打包、真机的UI是否能动态适配等
|
||||
# 五、当前进度和规划
|
||||
时间
|
||||
模块
|
||||
交付物
|
||||
交付标准
|
||||
完成情况
|
||||
本周任务完成进度（%）
|
||||
D6
|
||||
Bug修复 + 节奏调整
|
||||
修复版本、调整记录、修正后的节奏判断
|
||||
所有P0修复，高概率P1修复，剧情衔接和订单难度曲线调整完成，结合提测反馈修正数值判断
|
||||
1.完成动态分辨率适配功能
|
||||
2.完成订单节奏的前期数值调研反推
|
||||
3.优化订单人物重复出现、副链没有生产路径等功能性问题
|
||||
4.新增转场动画
|
||||
20%
|
||||
D7
|
||||
音频接入 + 专项验证
|
||||
音频接入版本、音频问题清单、专项测试记录、广告与资源中断节奏补充结论
|
||||
BGM和音效全部接入，激励广告/存档/设置专项验证通过，无奖励重复发放、无进度丢失
|
||||
未完成
|
||||
0%
|
||||
D8
|
||||
美术资源补齐 + 护栏草案
|
||||
二轮美术资源包、美术替换清单、二合数值护栏草案
|
||||
缺失头像/立绘/插图/图标/按钮补齐，统一命名规范，替换低质量占位，护栏草案从样本上升为可复用结论
|
||||
未完成
|
||||
0%
|
||||
D9
|
||||
提审项收口 + 真机回归
|
||||
提审清单、提审说明模板、自查记录、真机回归记录、数值护栏修订记录
|
||||
隐私政策/协议/版本号/客服入口齐全，未开放入口移除，真机完整回归1轮无白屏/崩溃/死路
|
||||
未完成
|
||||
0%
|
||||
D10
|
||||
提审版打包 + 护栏沉淀
|
||||
提审版包、提审说明、最终交付清单、最终数值护栏文档
|
||||
核心流程稳定，广告奖励正常，UI无未开放入口，剧情/美术/音频达可展示标准，数值护栏可复用
|
||||
未完成
|
||||
0%
|
||||
规划风险提醒：探索与收口失衡【最高优先级】、空间压力设计失误、订单节奏不合理、广告点打断体验、合成反馈不够满足、 美术风格不统一、 第一版系统定义过早、单人 AI 工具使用不熟
|
||||
Reference in New Issue
Block a user