Evilom
147 lines
8.5 KiB
Markdown
147 lines
8.5 KiB
Markdown
# PKGLw8F4GiykqMkhWNhcH7Utnxg
|
||
|
||
Source: https://dianchukeji.feishu.cn/wiki/PKGLw8F4GiykqMkhWNhcH7Utnxg
|
||
|
||
|
||
# 1.工作内容概述
|
||
# 2.进度
|
||
## 2.1 继续调研拆解《浪漫餐厅》的关卡设计和数值设计规律
|
||
- 订单内容合奖励
|
||
|
||
- 剧情任务花费
|
||
|
||
- 剧情任务节点奖励
|
||
|
||
- 等级经验和奖励
|
||
|
||
- 棋盘摆放
|
||
|
||
## 2.2 把《浪漫餐厅》的关卡设计和数值设计规律与《庄园合合》的进行对比
|
||
整体而言，2者在棋盘摆放上的差异并不大，主要的差异集中在订单、金币相关的数值设计上
|
||
分析样本：2个游戏的前15个订单
|
||
- 订单刷新方式
|
||
- 《庄园合合》的订单刷新方式，主要按剧情节点的阶段进行划分。设计较为线性、固化，有明显规律可以摸索。
|
||
- 例如：第n个剧情节点到第n+1个剧情节点，会固定设计几个订单
|
||
- 《浪漫餐厅》的订单刷新方式则较为复杂。后续和刘鹏讨论后发现，有以下规律
|
||
|
||
|
||
> :writing_hand:
|
||
完全复刻《浪漫餐厅》订单刷新方式的难度较大，需要考虑是否转向参考《庄园合合》先完成一版数值合关卡设计，再转向《浪漫餐厅》这样的复杂订单刷新方式
|
||
- 卡点难点
|
||
- 《庄园合合》前期难度较低，卡点难点较少。很少出现需要玩家点击多次，从0开始生成订单所需物品的情况，大多数情况都是在棋盘上设计好了很明确的二合路径，能够快速合成出订单所需物品
|
||
- 《浪漫餐厅》则完全相反，卡点极多
|
||
- 例如：这里红框的订单需要高级薯条物品，但是高级薯条物品是副链，生成的概率极低。玩家极其容易在这卡住一段时间。
|
||
|
||
|
||
- 前期的商业规划不同
|
||
- 《浪漫餐厅》在前期便放出很多额外额外奖励箱，有金币、体力、钻石。
|
||
- 金币会比较严重地影响前期的关卡数值。
|
||
- 某种程度上，给予更多的奖励也是在帮玩家渡过前期的卡点难点
|
||
|
||
|
||
|
||
- 《庄园合合》前期给予的额外奖励极少。只有一些体力奖励和少量的金币、钻石。相比《浪漫餐厅》要少得多。给的大多数奖励是生成器。
|
||
|
||
## 2.3 商业化线——学习降低包体大小体积的方法，尝试打包出来
|
||
- 调研学习：用AI调研出以下优化包体大小的方法。
|
||
- 整体的思路其实就3种：
|
||
- 降低美术资源大小：降低分辨率、做某些特殊处理
|
||
- CDN：把优先级低的资源放在服务器，不进小游戏包体，游戏过程中按需加载
|
||
- 分包
|
||
- 参考雨默的方法，目前先使用降低美术资源大小和分包2个方法优化包体
|
||
- CDN较为复杂，这个阶段暂不考虑
|
||
|
||
- 优化成果
|
||
- 优化前
|
||
- 整个微信构建物：48.93 MB+
|
||
- 主包：5.57MB
|
||
- 现在
|
||
- 整个微信构建产物：33.36 MB
|
||
- 主包：4.00 MB
|
||
- 问题：主包4MB距离打包出来还差一段距离，明天集中解决。
|
||
- 微信主包的最大包体限制：2MB
|
||
|
||
## 2.4 继续学习并实现cocos UI多分辨率适配方法
|
||
- 学习了cocos 官方对于按钮的处理
|
||
- 官方的用widget组件处理按钮的对齐，能够使得按钮始终距离屏幕边缘有一定距离，做到贴边对齐
|
||
|
||
- 昨天完成了背景图的适配，今天完成了整体UI结构的适配、按钮的贴边对齐
|
||
- 720x1080设计分辨率下的UI
|
||
|
||
- 393×852分辨率下的UI
|
||
|
||
# 3.收获与反思
|
||
- 今天在降低包体大小和优化UI时，遇到2个比较难解决的bug。使用gpt5.4 high，修复了3 4次都无法根除。但是使用5.5 xigh，修复了2次便解决了。
|
||
- 遇到比较难解决的bug，应当上最强模型，并且打开最强的思考强度
|
||
# 4.下一步计划
|
||
- 基础功能线
|
||
- 继续完善自动化批量关卡生成方案（特别是根据学到AI配表的知识，进行优化）
|
||
- 继续调研拆解《浪漫餐厅》的关卡设计和数值设计规律
|
||
- 使用自动化批量关卡生成方案，复刻《浪漫餐厅》的关卡。目标是复刻至少40单的游戏内容量（大概1个小时左右的游玩流程）
|
||
- 开发等级功能，根据等级发放奖励
|
||
- 商业化线
|
||
- 降低包体大小体积，尝试打包出来
|
||
- 明天重点学习怎么降低主包的体积大小
|
||
- 继续学习cocos UI多分辨率适配方法，完成多分辨率适配
|
||
- 整体的UI适配已经完成，明天的重点是调整细节
|
||
# 5.项目规划
|
||
参考：
|
||
https://jasminehuang477-cmd.github.io/share_hyper_casual_game_design_guide/#s10
|
||
https://merge2iaa-selectionanalysis.netlify.app/
|
||
- 开发计划：
|
||
- **任务详情看第二个文档的十、两周开发建议节奏**
|
||
- **非开发计划中的内容，不优先开发**
|
||
**阶段**
|
||
**核心任务**
|
||
**产出物**
|
||
**验收标准**
|
||
**完成情况**
|
||
**W0：方向确认**
|
||
- 确定主题、驱动方式（订单/图鉴/轻量解锁）、物品链草案、
|
||
- 工具链确认
|
||
主题文档、物品链草稿
|
||
能用一句话说清楚"做什么主题的二合类、合到什么"
|
||
完成，核心目标对标《浪漫餐厅》
|
||
**W1：核心合成闭环**
|
||
- **工具链熟悉 + 工程搭建**
|
||
- **物品链 Schema + AI 配置生成**
|
||
- **棋盘 + 合并核心逻辑**
|
||
- **生成器系统**
|
||
- **基础 UI + AI 美术占位**
|
||
item_chain_schema.json、可运行原型
|
||
合成基础循环可演示，物品链有解、不卡死
|
||
完成
|
||
**W2：产品闭环与可玩包**
|
||
- **订单系统**
|
||
- **广告点接入**
|
||
- **埋点接入（7 事件）（参考：第二个文档的：九、第一版 MVP 的探索范围与收口原则）**
|
||
- **新手引导（3 步最小化）**
|
||
- **可玩包 + 内部测试**
|
||
- **复盘报告 + 资产沉淀**
|
||
可玩包、问题清单、复盘文档
|
||
从启动到看见第一个广告点的路径完整可走通
|
||
80%
|
||
- 订单系统完成；
|
||
- 埋点接入完成;
|
||
- 广告点接入暂缓，先等关卡做好：
|
||
一 尝试用咸鱼账号进行测试
|
||
- 新手引导流程完成
|
||
- 可玩包的程度还需要以下2件事件
|
||
- 性能优化
|
||
- 关卡设计：目前设计并实现了自动化批量关卡生成系统，已经能够用该系统生成第一批可游玩的关卡
|
||
- 打包成小游戏包
|
||
- 降低包体大小体积(正在进行中，进度40%)
|
||
- 不同分辨率适配（正在进行中，进度70%）
|
||
**W2 后：横向对比与资产沉淀**
|
||
整理所有可复用资产、参与横向对比会议、总结共性问题
|
||
资产沉淀清单 + 复盘报告
|
||
每人完成可迁移使用的：资产沉淀清单+复盘报告
|
||
还在积累实践经验，编写工作流文档思路。后续计划：
|
||
- 复盘报告
|
||
- 编写工作流文档
|
||
- 完成资产沉淀清单（见第一个文档，需要重点关注schema）（第二个文档的十二也有）
|
||
- 风险注意：https://merge2iaa-selectionanalysis.netlify.app/的六、产品风险分析很有价值，开发时需要注意
|
||
- **空间压力设计失误**
|
||
- **订单节奏不合理**
|
||
- **合成反馈不够满足**
|
||
- **美术风格不统一** |