Evilom
143 lines
8.4 KiB
Markdown
143 lines
8.4 KiB
Markdown
# PuiOw5HETi9pnekp6wlctOIvn0c
|
|
|
|
Source: https://dianchukeji.feishu.cn/wiki/PuiOw5HETi9pnekp6wlctOIvn0c
|
|
|
|
|
|
# 1.工作内容概述
|
|
# 2.进度
|
|
## 2.1 参与AI游戏开发问题交流会，整理笔记和收获
|
|
### 2.1.1 AI配表问题
|
|
- 设计具体数值和表格字段
|
|
- 设计的时候，可以跟AI来讨论数值设计。
|
|
- 人管数值大方向和体验，AI来输出具体的数值
|
|
- 配表部分配表部分
|
|
- 核心：配表的时候，重点是确定性，AI不能出一点错误，出错问题很大
|
|
- 方法
|
|
- 方法一（较为稳健）：AI出具体数值，人来配置，AI来检查
|
|
- 方法二：如果要AI来配，要保证准确性为100%
|
|
- 让AI用脚本来写入，不能直接填
|
|
- 原因：脚本是规范化程序，如果配得有问题，能够直接报错原因
|
|
- 不要让AI来配置表格的原因
|
|
- 自己不去配表，全让AI配，整个表就是黑盒，很难排查问题
|
|
- AI配表还是有出错的概率，如果不是百分百对，就仍然有很大风险
|
|
- 源表格的选择
|
|
- yaml：ai好读好改，人好读，但不好改
|
|
- excel：目前这个阶段，还是尽量用excel
|
|
- excel有mcp，AI也能直接改。但是最好不要让AI来配置表格
|
|
|
|
> :coconut:
|
|
后续计划，根据以上学到的内容，改造自己的AI配表方案
|
|
### 2.1.2 AI编程问题
|
|
主要围绕架构设计展开
|
|
- 架构设计思路：
|
|
- 架构和业务是要分开设计的,业务逻辑上要解耦,做成基于架构的设计的填空题
|
|
- 架构设计在单一品类的游戏中，大概率是不变的，是具备高可复用性的。
|
|
- 案例：一套二合的游戏架构/mmo的游戏架构，能做很多个同类型的项目
|
|
- 设计架构的原则
|
|
- 高可复用性：一个代码设计能够重复利用
|
|
- 例如：程序老师举的例子，在UI中只分层全屏弹窗、小弹窗、浮动组件3种UI。所有UI都能用这三种组件来构成开发。
|
|
- 低耦合度：即各个系统互不影响，修改A系统不影响B系统
|
|
- 怎么学习和积累
|
|
- 自己去网上学习相关内容
|
|
- 找一款参考对标的游戏，自己设计一套架构，看看能否顺利复现，如果可以，就证明方向大概率是对的；如果不可以，则需要调整方向
|
|
- 带着问题去拆解分析网上的游戏源代码架构，看看他们是怎么解决/呈现这些问题的
|
|
- 核心：带着问题——没有问题就无法进步
|
|
- 案例：自己学习到的架构设计原则是，高可复用、低耦合——去看看这些架构有没有实现
|
|
|
|
> :coconut:
|
|
后续计划：根据以上收获，对项目进行一次重构
|
|
## 2.2 调研拆解《浪漫餐厅》的关卡设计和数值设计规律
|
|
- 今天主要拆解了前15单的一个棋盘摆放规律
|
|
|
|
## 2.3 学习cocos UI多分辨率适配方法，完成多分辨率的初版开发
|
|
### 2.3.1 cocos官方的多分辨率适配方法
|
|
2种核心概念：设计分辨率和屏幕分辨率
|
|
- 设计分辨率 是内容生产者在制作场景时使用的分辨率蓝本，而 屏幕分辨率 是游戏在设备上运行时的实际屏幕显示分辨率。
|
|
主要有2种模式进行缩放适应不同分辨率
|
|
- 适配宽度模式（Fit Width）：设计分辨率宽高比小于屏幕分辨率，适配宽度避免黑边
|
|
|
|
- 适配高度模式（Fit Height）：设计分辨率宽高比大于屏幕分辨率，适配高度避免黑边
|
|
|
|
### 2.3.2 完成背景图的适配多分辨率
|
|
- 整体的设计思路使用的是**适配高度模式，拉伸背景图的高度而不拉伸宽度**。目前无论是棋盘背景图还是顶部的背景图，都可以适配不同分辨率。
|
|
目前的问题：开发过程中，游戏中的UI也被进行同等大小地缩放了，导致一些按钮错乱，明天需要修复这一块内容。
|
|
- 开发默认的720x1980分辨率
|
|
|
|
- 苹果12/13的428x926的分辨率
|
|
|
|
## 2.4 调研二合类游戏的数值模型
|
|
- 目前通过AI搜索和我人工搜索，都没找到可直接复用的二合类游戏数值模型
|
|
- 后续的计划：通过对《浪漫餐厅》的数值和关卡设计调研，用AI辅助，搭建数值模型和数学模型
|
|
|
|
|
|
# 3.收获与反思
|
|
- 今天收获了很多AI编程的工程化/架构思维的知识，以及隔壁项目组对于AI配表的成熟看法。这些对我当前的项目都有很大的帮助。后续需要先对这些内容进行消化，应用到后续的开发中
|
|
# 4.下一步计划
|
|
- 基础功能线
|
|
- 继续完善自动化批量关卡生成方案（特别是根据今天学到AI配表的知识，进行优化）
|
|
- 继续调研拆解《浪漫餐厅》的关卡设计和数值设计规律
|
|
- 使用自动化批量关卡生成方案，复刻《浪漫餐厅》的关卡。目标是复刻至少40单的游戏内容量（大概1个小时左右的游玩流程）
|
|
- 商业化线
|
|
- 降低包体大小体积，尝试打包出来
|
|
- 继续学习cocos 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 步最小化）**
|
|
- **可玩包 + 内部测试**
|
|
- **复盘报告 + 资产沉淀**
|
|
可玩包、问题清单、复盘文档
|
|
从启动到看见第一个广告点的路径完整可走通
|
|
75%
|
|
- 订单系统完成；
|
|
- 埋点接入完成;
|
|
- 广告点接入暂缓，先等关卡做好：
|
|
一 尝试用咸鱼账号进行测试
|
|
- 新手引导流程完成
|
|
- 可玩包的程度还需要以下2件事件
|
|
- 性能优化
|
|
- 关卡设计：目前设计并实现了自动化批量关卡生成系统，已经能够用该系统生成第一批可游玩的关卡
|
|
- 打包成小游戏包
|
|
- 降低包体大小体积
|
|
- 不同分辨率适配（个人认为比较难，优先完成第一项）
|
|
**W2 后：横向对比与资产沉淀**
|
|
整理所有可复用资产、参与横向对比会议、总结共性问题
|
|
资产沉淀清单 + 复盘报告
|
|
每人完成可迁移使用的：资产沉淀清单+复盘报告
|
|
还在积累实践经验，编写工作流文档思路。后续计划：
|
|
- 复盘报告
|
|
- 编写工作流文档
|
|
- 完成资产沉淀清单（见第一个文档，需要重点关注schema）（第二个文档的十二也有）
|
|
- 风险注意：https://merge2iaa-selectionanalysis.netlify.app/的六、产品风险分析很有价值，开发时需要注意
|
|
- **空间压力设计失误**
|
|
- **订单节奏不合理**
|
|
- **合成反馈不够满足**
|
|
- **美术风格不统一** |