Evilom
329 lines
8.2 KiB
Markdown
329 lines
8.2 KiB
Markdown
# 2026 0630日报-韦译
|
||
|
||
|
||
Source: https://feishu.cn/docx/Q9yAwY4QsiNqUbkl32ocHWm5nYf
|
||
|
||
|
||
# 1.工作内容概述
|
||
|
||
编写拆解分析报告大纲
|
||
|
||
架构优化
|
||
|
||
继续拆解《浪漫餐厅》数值
|
||
|
||
学习积累二合类的数值设计基础知识
|
||
|
||
优化美术资源和功能
|
||
|
||
仓库界面
|
||
|
||
切换界面按钮
|
||
|
||
# 2.进度
|
||
|
||
## 2.1 编写拆解分析报告大纲
|
||
|
||
主要参考之前总结的拆解思路，进行编写
|
||
|
||
先讲述拆解本身，阐述拆解出的数据
|
||
|
||
再从拆解出的数据，分析得出一些结论和认知
|
||
|
||
再谈论运用到目前项目中的效果
|
||
|
||
## 2.2 架构优化
|
||
|
||
### 2.2.1 优化了生成器多次生成时卡顿的问题
|
||
|
||
架构优化思路
|
||
|
||
旧架构：每次切换场景初始化生成器、物品等内容的状态时，没有做缓存和并发保护。同一时间生成多个，则非常容易卡顿。
|
||
|
||
新架构：懒初始化与重复初始化保护
|
||
|
||
SaveManager 补了 lazy init 测试和保护。
|
||
|
||
GameRuntime 有 ready 缓存、并发 ready promise 复用、失败后可重试。
|
||
|
||
结果：跨场景读存档/初始化状态更安全，不会因为某个场景先后顺序不同导致额外初始化或卡死。
|
||
|
||
### 2.2.2 优化了切换场景加载时间长的问题
|
||
|
||
架构优化思路
|
||
|
||
旧架构：
|
||
|
||
是主界面和游戏界面，分别走2套不一样的实现流程，同一类资源会重复加载，导致加载时间较长
|
||
|
||
存档、配置、Manager 图、体力恢复、体力保存同步这些操作，每切换一层场景都要重新加载一次
|
||
|
||
新架构
|
||
|
||
统一 Home/Game 运行时初始化
|
||
|
||
新增/使用 GameRuntime.ensureReady()，Home和 Game 都走同一个运行时入口。
|
||
|
||
把存档、配置、Manager 图、体力恢复、体力保存同步这些跨场景逻辑收进一个幂等入口。
|
||
|
||
结果：场景来回切换时不再重复初始化一堆Manager、定时器、事件监听，减少重复监听和重复保存导致的卡顿风险。
|
||
|
||
场景切换路径收敛
|
||
|
||
Home/Game 通过 SceneTransitionManager 做切换与 ready 标记。
|
||
|
||
Game 启动完成后 markReady('Game')，Home完成后 markReady('Home')。
|
||
|
||
结果：切场景不再只是“直接 loadScene”，而是有统一的加载中状态、重复切换保护、目标场景 ready 等待，体感上切换场景速度更快。
|
||
|
||
### 2.2.3 目前效果
|
||
|
||
快速生成多个物品不卡顿
|
||
|
||
短时间切换场景不卡顿
|
||
|
||
## 2.3 继续拆解《浪漫餐厅》数值
|
||
|
||
目前拆解到
|
||
|
||
第20个订单
|
||
|
||
第11个剧情任务节点
|
||
|
||
等级4的相关奖励
|
||
|
||
6种奖励设计：
|
||
|
||
## 2.4 学习积累二合类的数值设计基础知识
|
||
|
||
动态成本模型：理论成本不等于真实成本
|
||
|
||
道具全生命周期成本建模”：静态成本（理论成本）基于 2n−12^{n-1}2n−1
|
||
|
||
动态成本则要考虑生成器产出高等级道具后的期望折减。第 n 级道具的动态成本可以写成：
|
||
|
||
其中：
|
||
|
||
2n−1：理论基础成本
|
||
|
||
E(L)：某等级生成器的平均产出价值
|
||
|
||
Cn：实际期望点击成本
|
||
|
||
作用：比静态成本，更接近玩家体验。
|
||
|
||
例如：某个订单到底要玩家花多少体力？
|
||
|
||
目标：Lv.10 道具
|
||
|
||
静态成本（理论成本）：512
|
||
|
||
生成器等效产出：1.6
|
||
|
||
真实期望成本：512 / 1.6 = 320 次点击
|
||
|
||
静态成本（理论成本）跟真实成本，相差很大，不能一概而论
|
||
|
||
订单难度模型：把多个道具需求合成一个难度分
|
||
|
||
订单难度可以简单定义为：
|
||
|
||
如果一个订单要求：Lv.6 汉堡 + Lv.4 饮料 + Lv.3 甜点
|
||
|
||
那么难度是：
|
||
|
||
## 2.5 优化美术资源和功能
|
||
|
||
仓库界面
|
||
|
||
调整了物品的精确位置
|
||
|
||
更换新版的美术资源：之前的仓库边缘有痕迹，看着很旧
|
||
|
||
进行了后处理，解决物品模糊问题
|
||
|
||
优化前
|
||
|
||
优化后
|
||
|
||
切换界面按钮
|
||
|
||
参考《浪漫餐厅》，调整到游戏的右下角
|
||
|
||
# 3.收获与反思
|
||
|
||
拆解《浪漫餐厅》的速度偏慢，相比先前的进度，只多拆解了10个订单，2个等级的内容。
|
||
|
||
主要原因在于
|
||
|
||
一边优化拆解表格的设计，一边记录。整体速度降下来很多
|
||
|
||
订单、奖励、剧情、等级，这4者是深度耦合的，不能单独拆开来看。每完成一个订单，就要考虑订单和其他三者的关系。需要思考的东西过多，相比其他调研要慢很多。
|
||
|
||
花费过多时间在剧情任务节点与订单之间的关系了。
|
||
|
||
因为我个人想调查清楚，什么时候会出现下一个订单，进而研究订单刷新机制。
|
||
|
||
我希望更完整地记录，订单出现位置、时间、逻辑，方便后续让AI更好地反推出相关数值
|
||
|
||
后续改进：跟刘鹏讨论后，得出以下2点经验
|
||
|
||
整个游戏设计就分为2个阶段，新手期和循环期，新手期的设计是需要细致记录的，循环期的关卡和数值反而是有一定规律的。所以要重点分析新手期的整个流程，以及循环期的规律即可。分析好这些内容后，后面就没有必要再记录这么细致的内容。
|
||
|
||
新手期的数值记录，就是比较枯燥的，需要有耐心
|
||
|
||
# 4.下一步计划
|
||
|
||
调研拆解
|
||
|
||
继续拆解、记录实机数据
|
||
|
||
学习积累二合类的数值设计基础知识（对于数值调研拆解，基础数值设计知识很重要）
|
||
|
||
研究AI建模分析的方法
|
||
|
||
美术线
|
||
|
||
在拆解调研的空余时间中，抽空优化相关美术资源
|
||
|
||
# 5.项目规划
|
||
|
||
参考：
|
||
|
||
https://jasminehuang477-cmd.github.io/share_hyper_casual_game_design_guide/#s10
|
||
|
||
https://merge2iaa-selectionanalysis.netlify.app/
|
||
|
||
开发计划：
|
||
|
||
任务详情看第二个文档的十、两周开发建议节奏
|
||
|
||
非开发计划中的内容，不优先开发
|
||
|
||
拆解调研任务
|
||
|
||
目标
|
||
|
||
核心任务
|
||
|
||
完成情况
|
||
|
||
完成《浪漫餐厅》关卡/数值相关设计拆解分析，说明从中收获了哪些二合类游戏设计的关键认知，输出拆解分析报告并进行内部分享
|
||
|
||
写拆解分析报告大纲
|
||
|
||
对《浪漫餐厅》关卡/数值相关设计进行拆解分析
|
||
|
||
实机记录数据（完成后才方便做下面的内容）
|
||
|
||
需要反思如何改进
|
||
|
||
学习数值拆解调研的方法
|
||
|
||
研究AI建模分析的方法
|
||
|
||
ok—在网上学习数值调研拆解相关的方法
|
||
|
||
ok—向楚真日报学习
|
||
|
||
问刘鹏
|
||
|
||
学习积累二合类的数值设计基础知识（对于数值调研拆解，基础数值设计知识很重要）
|
||
|
||
从微观反推宏观内容：研究对具体设计组合的抽象、理解、演化方向预判
|
||
|
||
数值拆解方向
|
||
|
||
（核心）订单数值
|
||
|
||
棋盘关卡
|
||
|
||
需要结合订单刷新机制
|
||
|
||
总结《浪漫餐厅》关卡/数值相关设计的规律
|
||
|
||
总结二合类游戏设计的关键认知
|
||
|
||
整理以上2点内容，进行内部分享
|
||
|
||
使用自动化批量关卡生成方案+分析的关卡和数值设计规律+订单刷新机制，铺量关卡。目标是铺至少40单的游戏内容量（大概1个小时左右的游玩流程）
|
||
|
||
### 25%
|
||
|
||
上线前要完成的任务
|
||
|
||
目标
|
||
|
||
核心任务
|
||
|
||
完成情况
|
||
|
||
关卡和数值设计铺量
|
||
|
||
对《浪漫餐厅》关卡/数值相关设计进行拆解分析
|
||
|
||
需要跟之前的订单刷新机制结合起来
|
||
|
||
总结《浪漫餐厅》关卡/数值相关设计的规律
|
||
|
||
用AI生成并配置好类似规律的关卡和数值
|
||
|
||
### 30%
|
||
|
||
基础功能
|
||
|
||
文本提示信息框——完成
|
||
|
||
购买弹窗——暂时搁置
|
||
|
||
边缘系统
|
||
|
||
### 75%
|
||
|
||
商业化
|
||
|
||
上架微信小游戏
|
||
|
||
UI适配（已经跑通流程，只需要再操作一遍）
|
||
|
||
打包优化（已经跑通流程，只需要再操作一遍）
|
||
|
||
### 30%
|
||
|
||
更换新主题的美术资源
|
||
|
||
持续优化美术资源生成管线
|
||
|
||
目前还差
|
||
|
||
仓库界面
|
||
|
||
个人信息界面
|
||
|
||
思考问题
|
||
|
||
继续解决美术风格的饱和度问题和AI味道问题
|
||
|
||
物品链和生成器链考虑优化美术资源
|
||
|
||
将笔刷、毛刷等物品加入，弥补目前物品链物品过于相似的问题
|
||
|
||
### 95%
|
||
|
||
优化
|
||
|
||
手感调优
|
||
|
||
上线前测试找bug
|
||
|
||
### 40%
|
||
|
||
风险注意：https://merge2iaa-selectionanalysis.netlify.app/的六、产品风险分析很有价值，开发时需要注意
|
||
|
||
空间压力设计失误
|
||
|
||
订单节奏不合理
|
||
|
||
合成反馈不够满足
|
||
|
||
美术风格不统一 |