chore:文档补全
This commit is contained in:
Evilom
@@ -0,0 +1,119 @@
|
||||
# Fuy3wIlHviBkS8kyxS4czxJpn8g
|
||||
|
||||
Source: https://dianchukeji.feishu.cn/wiki/Fuy3wIlHviBkS8kyxS4czxJpn8g
|
||||
|
||||
|
||||
# 1.工作内容概述
|
||||
# 2.进度
|
||||
## 2.1 商业化线——学习降低包体大小体积的方法，成功打包到真机进行测试
|
||||
- 分包
|
||||
- 概念：分包即把小游戏包切分为多个不同的包体，分为主包和其他包。主包是最先加载的，其他包体按需加载。
|
||||
- 官方描述：把内容划成多个Asset Bundle，构建时这些 Bundle 会生成小游戏分包；启动时只下主包，分包由游戏过程中手动加载。
|
||||
- 配置步骤
|
||||
- 让AI在项目里做“资源与代码层拆分”，具体拆成以下几个包
|
||||
|
||||
- 在Cocos 编辑器里做“Asset Bundle / 微信分包配置”
|
||||
- 在项目设置——Bundle配置中，单独设置为小游戏为小游戏分包
|
||||
|
||||
- 在构建发布面板中，选择主包压缩类为小游戏分包
|
||||
|
||||
- 降采样
|
||||
- 第一轮：调 .NET System.Drawing 直接缩放 PNG，虽然成功打包，但是包体仍然不够小
|
||||
- 第二轮：使用sharp库进行降采样，使得包体下降足够多
|
||||
- sharp库：**sharp 是一个 Node.js 图片处理库**，典型用途就是把大图转换成更小、更适合 Web 使用的 JPEG、PNG、WebP、AVIF 等格式，并且可以调整尺寸。它底层使用的是 libvips，所以处理速度很快。是小游戏降低包体大小的经典工具库。
|
||||
|
||||
- 真机调试录屏
|
||||
## 2.2 商业化线——学习cocos UI多分辨率适配方法，完成多分辨率的初版开发
|
||||
- 今天主要完成了cocos UI多分辨率适配在微信开发工具上的调试。
|
||||
- 目前在微信开发者工具上切换手机分辨率时，UI能够自动适配
|
||||
- 但是还有一些小问题
|
||||
- 微信开发者工具中看着没问题，但是切换到真机调试时，有些UI会错乱。明天进行调整
|
||||
- 真机调试中，上下的黑边很明显，后续考虑要怎么解决
|
||||
## 2.3 优化线——震动反馈效果：正在开发，预计明日完成
|
||||
- 设计思路：参考《浪漫餐厅》，主要有以下3种
|
||||
- 物品/生成器从静止（在格子中静止）到移动，拖拽开始瞬间的震动
|
||||
- 物品/生成器从移动到静止（在格子中静止），拖拽完成的震动（一和二的震动强度一样，较小）
|
||||
- 2个物品二合时，轻微震动（相比一和二，三的震动会稍微强一些）
|
||||
- 完成订单时，触发7次震动，表示获得多个金币（震动强度会跟三比较解决）
|
||||
- 新增设置按钮，可以调节震动反馈。
|
||||
- 明天实装美术资源+调整UI
|
||||
## 2.4 修复bug：订单间隔过近的bug
|
||||
- 之前的订单，距离过近非常别扭
|
||||
|
||||
- 修复效果
|
||||
|
||||
# 3.收获与反思
|
||||
- 微信开发者工具，cocos引擎，真机调试——这三者都有可能出现独立的bug需要解决。
|
||||
- 例如：这次的UI的bug有些在微信开发者工具上没有，在真机调试才出现
|
||||
- 后续需要在这三方进行独立测试，最后以真机的体验为准
|
||||
# 4.下一步计划
|
||||
- 继续调研拆解《浪漫餐厅》的关卡设计和数值设计规律
|
||||
- 商业化线
|
||||
- 优化真机调试环境下的UI bug
|
||||
- 继续优化打包，制定好后续的打包方案
|
||||
- 用咸鱼流量主账号进行广告测试
|
||||
- 基础功能线
|
||||
- 剧情演绎：展示人物对白，推进剧情
|
||||
- 优化线
|
||||
- 震动反馈效果
|
||||
# 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 步最小化）**
|
||||
- **可玩包 + 内部测试**
|
||||
- **复盘报告 + 资产沉淀**
|
||||
可玩包、问题清单、复盘文档
|
||||
从启动到看见第一个广告点的路径完整可走通
|
||||
90%
|
||||
- 订单系统完成；
|
||||
- 埋点接入完成;
|
||||
- 广告点接入暂缓，先等关卡做好：
|
||||
一 尝试用咸鱼账号进行测试
|
||||
- 新手引导流程完成
|
||||
- 可玩包的程度还需要以下2件事件
|
||||
- 性能优化
|
||||
- 关卡设计：目前设计并实现了自动化批量关卡生成系统，已经能够用该系统生成第一批可游玩的关卡
|
||||
- 打包成小游戏包
|
||||
- 降低包体大小体积(正在进行中，进度40%)
|
||||
- 不同分辨率适配（正在进行中，进度70%）
|
||||
**W2 后：横向对比与资产沉淀**
|
||||
整理所有可复用资产、参与横向对比会议、总结共性问题
|
||||
资产沉淀清单 + 复盘报告
|
||||
每人完成可迁移使用的：资产沉淀清单+复盘报告
|
||||
还在积累实践经验，编写工作流文档思路。后续计划：
|
||||
- 复盘报告
|
||||
- 编写工作流文档
|
||||
- 完成资产沉淀清单（见第一个文档，需要重点关注schema）（第二个文档的十二也有）
|
||||
- 风险注意：https://merge2iaa-selectionanalysis.netlify.app/的六、产品风险分析很有价值，开发时需要注意
|
||||
- **空间压力设计失误**
|
||||
- **订单节奏不合理**
|
||||
- **合成反馈不够满足**
|
||||
- **美术风格不统一**
|
||||
Reference in New Issue
Block a user