chore:文档补全
This commit is contained in:
Evilom
@@ -0,0 +1,119 @@
|
||||
# HuUIwA39fi3UsqkdfhTcE9hRnde
|
||||
|
||||
Source: https://dianchukeji.feishu.cn/wiki/HuUIwA39fi3UsqkdfhTcE9hRnde
|
||||
|
||||
|
||||
# 1.工作内容概述
|
||||
# 2.进度
|
||||
## 2.1 修复UI严重卡住开发进度
|
||||
- 修复情况：
|
||||
- 今天把原来的棋盘从7x7修改为7x9，对标浪漫餐厅。
|
||||
|
||||
- 但是棋盘变高，超出了原有大小。所以我希望对棋盘的位置进行微调，但是棋盘格子无法在编辑器的预览界面中进行预览。
|
||||
|
||||
- 于是我让Claude在编辑器预览中，新增棋盘格子节点，绑定游戏内的棋盘格子。但是效果很差。
|
||||
- 棋盘格子的美术样式跟之前的相比，差距很大，不美观
|
||||
- 同时claude修改后，bug非常多，整个游戏无法进行游玩。经常是改了A就会出现B，改了B就会出现C。整体开发效率非常低。
|
||||
|
||||
- 卡住原因：个人认为主要有以下几点
|
||||
- claude的代码能力相比gpt还是比较弱
|
||||
- claude的输出速度虽然非常快，但claude修复bug的时候，很多细节情况都考虑不清，很容易留下bug。导致整体开发效率，看起来快；实则都是bug。
|
||||
- 个人对cocos引擎中，配置UI的方法不清楚，没有经验。之前选择的方法是，在游戏运行时生成UI，结果到了目前项目开发的中后期时，调试UI比较麻烦；此时想转向为规范的UI配置流程就比较困难
|
||||
- 反思
|
||||
- 这次使用公司API的Claude大约50多美金，却仍然无法修复UI问题。个人认为使用claude进行代码开发，性价比极低。后续仍然回到以gpt codex为核心的开发工具上，不再使用claude。claude只作为备用。
|
||||
- 我使用的是敏捷开发方法，虽然开发速度快，但是遇到这种因为引擎不熟悉而导致的问题，就很容易碰壁卡住。后续要针对这个UI问题，积累经验，防止下次犯错。
|
||||
- 下一步计划：
|
||||
- 跟雨默探讨学习cocos的UI怎么配置，才适合长期维护
|
||||
- 用AI深入研究cocos的官方文档，看看cocos中UI配置的最佳实践是什么
|
||||
## 2.2 与AI讨论出自动化批量关卡生成方案的最终版本
|
||||
跟AI讨论了比较久的时间，以下为设计的概述
|
||||
### 2.2.1 关卡设计模板化与数值规律化
|
||||
- 目标是把“关卡怎么设计才合理”这件事，整理成AI能理解的规则、参数和公式。
|
||||
- 它把关卡拆成两个核心
|
||||
- 核心做法是把经验规则模板化，包括：
|
||||
- 难度曲线：不是一直变难，而是“爬升-峰值-回落”的锯齿节奏。
|
||||
- 模板序列：规定一章里哪些类型的 slice 先出现、后出现。
|
||||
- 棋盘模板：把棋盘摆放分成区域策略、摆放模式、合法性约束三层。后续可以根据这三层，生成多种多样的模板，方便后续的批量生成
|
||||
- 数值公式：体力、合成次数、空间压力、金币产出都能估算。
|
||||
## 2.2.1 AI批量生成关卡执行方案
|
||||
- 目标是在方案一规则已经明确的前提下，真的把大量关卡配置批量生成出来。
|
||||
- 它采用“两级生成”：
|
||||
- 人工先定章节骨架：这一章有哪些 slice、每个位置是什么模板、难度大概多少。
|
||||
- AI 再逐个生成具体 slice 配置：订单、棋盘变化、奖励等。
|
||||
- 为了保证质量，方案二不是“AI 一次生成就直接用”，而是多一层保障：
|
||||
- 自动校验
|
||||
- 自动修复
|
||||
- 全章一致性检查
|
||||
- 最后人工试玩验收
|
||||
- 也就是说，AI 在这里更像“配置生产助手”，不是“完全替代策划”
|
||||
## 2.3 基础功能线：完成体力限制的生成器生成机制
|
||||
- 点击生成器生成物品时，每生成一次，就消耗1点体力（暂定数值）
|
||||
- 体力耗尽后，提示看广告补充体力或使用钻石购买体力
|
||||
## 2.4 基础功能线：新增动画——完成订单时，订单缩小并退出
|
||||
- 动画表现是：当前订单会渐变退出；同时其他订单会有左移的一个动画
|
||||
- 相比之前的效果：更加流畅顺滑，玩家的体验感会更好
|
||||
# 3.收获与反思
|
||||
- 这个UI问题严重卡住进度，是开发至今遇到的最大卡点，明天争取修复。
|
||||
- 这个UI问题不修复，其他功能都无法正常推进
|
||||
# 4.下一步计划
|
||||
- 基础功能线——修复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 步最小化）**
|
||||
- **可玩包 + 内部测试**
|
||||
- **复盘报告 + 资产沉淀**
|
||||
可玩包、问题清单、复盘文档
|
||||
从启动到看见第一个广告点的路径完整可走通
|
||||
45%
|
||||
目前订单系统完成；
|
||||
埋点接入完成，但是还有一些小问题需要修复;
|
||||
- 广告点接入正在进行：
|
||||
一 在微信开发者工具中进行测试
|
||||
**W2 后：横向对比与资产沉淀**
|
||||
整理所有可复用资产、参与横向对比会议、总结共性问题
|
||||
资产沉淀清单 + 复盘报告
|
||||
每人完成可迁移使用的：资产沉淀清单+复盘报告
|
||||
还在积累实践经验，编写工作流文档思路。后续计划：
|
||||
- 复盘报告
|
||||
- 编写工作流文档
|
||||
- 完成资产沉淀清单（见第一个文档，需要重点关注schema）（第二个文档的十二也有）
|
||||
- 风险注意：https://merge2iaa-selectionanalysis.netlify.app/的六、产品风险分析很有价值，开发时需要注意
|
||||
- **空间压力设计失误**
|
||||
- **订单节奏不合理**
|
||||
- **合成反馈不够满足**
|
||||
- **美术风格不统一**
|
||||
Reference in New Issue
Block a user