chore:文档补全
This commit is contained in:
@@ -0,0 +1,115 @@
|
||||
# AjK2wPpI7iOFo5kOImVcEe1WnNS
|
||||
|
||||
Source: https://dianchukeji.feishu.cn/wiki/AjK2wPpI7iOFo5kOImVcEe1WnNS
|
||||
|
||||
|
||||
# 1.工作内容概述
|
||||
# 2.进度
|
||||
## 2.1 调研接入抖音/微信平台的方案
|
||||
综合二合项目本身的特点和各个平台的优缺点,调研了几个方案,最终选择综合的方案C:先上线微信验证技术,然后针对抖音玩家和算法偏好进行新一轮的美术包装和视觉反馈设计,再上抖音
|
||||
## 2.2 基础功能线——对已有系统的优化——优化棋盘和订单系统的一些bug
|
||||
**问题**
|
||||
**修法**
|
||||
订单最多只能承接5单,这5单还都是随机生成的,没有固定订单系统的数值设计
|
||||
新增 configs-src/orders/main_20.yaml 和对应 schema,通过这些配置,能够规范设计最多20单的订单数值:例如物品种类、物品数量
|
||||
以前做完一批订单后,游戏容易没东西可做
|
||||
出完再自动补下一批”,这样主棋盘不会断。
|
||||
以前每单奖励都是固定的数值
|
||||
现在每一单都能单独配金币奖励,前面简单一点,后面奖励和难度一起往上走。
|
||||
以前生成器解锁是静态的
|
||||
现在改成了“攒够金币、推进到剧情节点后,逐步解锁新生成器”,比如先开面包,再慢慢开饮料、甜点。
|
||||
以前存档可能会把进度弄丢
|
||||
现在把“做到第几单”和“已经解锁了哪些生成器”都存起来,退出再进不会回退。
|
||||
以前按钮点了和实际状态可能对不上
|
||||
现在“新增”按钮会先判断有没有可解锁的生成器,再去生成物品,避免玩家点了没反应或者逻辑错乱。
|
||||
## 2.3 W2线——广告接入—— 用Mock模式跑通广告位的全流程
|
||||
目前能够完整跑通广告位的流程,后续只需要在微信开发者工具上,把当前模拟的假的广告,换成真实的广告API即可
|
||||
## 2.4 完成整个项目配置方案的设计和实现
|
||||
- 整个配置方案的设计:
|
||||
设计规则层:JSON Schema + Agent 生成配置内容时约束
|
||||
↓ 约束
|
||||
源配置层:YAML 配置表
|
||||
↓ 构建脚本转换、校验、合并
|
||||
运行时层:JSON 配置表
|
||||
↓ Cocos 加载
|
||||
游戏逻辑层:棋盘、订单、生成器、广告、埋点
|
||||
- 这样设计的优点是:
|
||||
- 人和AI都能同时配置一套表格。如果使用Excel去配置数据,就会出现人能配,但是AI能难配的情况。因为AI操控Excel表格的能力是很弱的,但是AI操控YAML和JSON 是非常简单的。
|
||||
- 这样就能为后续实现**AI批量生成关卡**打下基础,到时候可以优先让AI来批量配置数据,人来检验配置是否正确
|
||||
- 实际配置表的效果
|
||||
- item-chain.schema和物品合成链:后续如果要配置任意物品合成链条的设计,都需要遵循schema的标准。也就是说,schema上要求的内容,是一定能够在yaml上体现的。
|
||||
在这里可以看到,item-chain.schema上要求的chainId、name、id、level、icon等属性,都可以在下面的bread.yaml中看到
|
||||

|
||||

|
||||
## 2.5 基本程序策划工作流文档的编写,还差一点收尾
|
||||
预计明日开会前完成2个文档编写
|
||||
# 3.收获与反思
|
||||
- 现在基本进入关卡内容生成阶段,但是这个阶段的复杂程度还是超出了我的想象
|
||||
- 这个关卡的正常游玩需要各个系统的配合,不能出现bug
|
||||
- 关卡中的棋盘摆放设计、数值设计,以及棋盘中的物品怎么和订单系统配合保证不卡关等等,各个设计之间都是互相联动互相影响的
|
||||
- 这一块需要后续进行深度调研学习
|
||||
# 4.下一步计划
|
||||
- 基础功能线
|
||||
- 优化棋盘和订单系统:目的是为后续关卡的正常游玩做好保障
|
||||
- 关卡设计和数值设计:完成w2要求的初版关卡和数值设计,玩家能够正常游玩前20个订单
|
||||
- 研究关卡设计和数值设计,特别是研究关卡设计的规律,为后续使用AI批量生成关卡打下基础
|
||||
- W2商业化线
|
||||
- 广告接入:在开发者工具中进行广告测试
|
||||
- 接入数据埋点:争取跑通游戏数据分析平台 GameAnalytics的流程
|
||||
- 美术线
|
||||
- 主要根据关卡设计的需要,新增物品链条等美术资源
|
||||
# 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 步最小化)**
|
||||
- **可玩包 + 内部测试**
|
||||
- **复盘报告 + 资产沉淀**
|
||||
可玩包、问题清单、复盘文档
|
||||
从启动到看见第一个广告点的路径完整可走通
|
||||
30%
|
||||
目前订单系统完成;
|
||||
- 广告点接入正在进行:
|
||||
一 在微信开发者工具中进行测试
|
||||
- 埋点接入正在进行
|
||||
- 争取跑通游戏数据分析平台GameAnalytics的流程
|
||||
**W2 后:横向对比与资产沉淀**
|
||||
整理所有可复用资产、参与横向对比会议、总结共性问题
|
||||
资产沉淀清单 + 复盘报告
|
||||
每人完成可迁移使用的:资产沉淀清单+复盘报告
|
||||
还在积累实践经验,编写工作流文档思路。后续计划:
|
||||
- 复盘报告
|
||||
- 编写工作流文档
|
||||
- 完成资产沉淀清单(见第一个文档,需要重点关注schema)(第二个文档的十二也有)
|
||||
- 风险注意:https://merge2iaa-selectionanalysis.netlify.app/的六、产品风险分析很有价值,开发时需要注意
|
||||
- **空间压力设计失误**
|
||||
- **订单节奏不合理**
|
||||
- **合成反馈不够满足**
|
||||
- **美术风格不统一**
|
||||
Reference in New Issue
Block a user