chore:文档补全
This commit is contained in:
Evilom
@@ -0,0 +1,69 @@
|
||||
# PXVywSG2bisQxskF9i1cQSqGndb
|
||||
|
||||
Source: https://dianchukeji.feishu.cn/wiki/PXVywSG2bisQxskF9i1cQSqGndb
|
||||
|
||||
|
||||
# 1.工作内容概述
|
||||
# 2.进度
|
||||
## 2.1 完成类《浪漫餐厅》的解锁格子机制
|
||||
- 简单分析可知，《浪漫餐厅》的棋盘格子有以下机制：
|
||||
一 四种类型的格子：可直接解锁的格子，锁住的格子，无物品的可合成格子，有物品的可合成格子。
|
||||
二 可直接解锁的格子中的物品，可以直接二合；同时，把临近一格的锁住的格子，变成可直接解锁的格子。之后，这个格子变成有物品的可合成格子。
|
||||
- 复刻效果
|
||||
## 2.2 把目前的小型闯关制度，改成类《浪漫餐厅》的大型关卡长时间推进机制
|
||||
- 简单分析可知，该机制的规则大致如下
|
||||
- 概述：玩家在home场景和game场景可以来回切换，切回game场景时保留原来game场景的进度；整个game场景的关卡游玩时间比较长，长达几个小时。
|
||||
- 棋盘中初始的物品布局
|
||||
- 中间是少量的无物品的可合成格子和有物品的可合成格子作为初始格子，目前暂时设定为9个初始格子，这9个格子是互相连接的，不能有间隔；
|
||||
- 周围是可直接解锁的格子和锁住的格子，并且遵循可直接解锁的格子在内层，锁住的格子一般在外层的规律。
|
||||
- 目前的实现不注重关卡设计和数值设计的实现，优先实现功能。第一关重点验证大型关卡长时间推进机制和棋盘的渐进式解锁格子机制，能够保证玩家从初始格子一步步拓展到其他格子，能够正常游玩下去即可。
|
||||
- 关卡存档继承：在home场景和game场景切换时，能够继承原有的game场景进度
|
||||
## 2.3 游戏内ui继续改进：订单区域背景图、餐桌、餐盘
|
||||
- 使用image2生成了订单区域背景图、餐桌、餐盘
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- 但是在接入的时候，发现ui和美术资源的搭配有比较大的问题，agent不能很好地理解ui与美术资源的关系。后续考虑用：1 人工介入 2 绘制2d拆解示意图给ai看 这2种方法尝试达到目标效果。
|
||||
|
||||
## 2.4 根据实践经验继续沉淀美术工作流
|
||||
- 喵吉托 meow art对比image2：喵吉托的平台只适合喵吉托他们自己训练的特定类型的美术，要求出其他类型的美术需求，往往会生成一个四不像，效果很差。其他的美术需求适合使用image2，image2理解能力强，image2能够承载大部分的美术需求。
|
||||
- 案例：仿照生成浪漫餐厅中的餐盘和餐桌，同样的提示词给到image2和喵吉托的美术平台，喵吉托的美术平台很难理解，生成出来的仍然是icon。image能够很好地理解并生成。
|
||||
|
||||
|
||||
- 思考：估计是他们平台的提示词中，强制生成特定的美术类型，无法修改。
|
||||
## 2.5 研究并整理AI原生的配置方案
|
||||
- 配置方案的目标：后续计划整个项目都是AI原生的配置结构，绝大部分配置工作都可以让AGENT来操控配置。
|
||||
- 对于人工的要求是
|
||||
- 1 配置内容不是黑盒，如果AGENT出错了，仍然可以由人工来核验和修改
|
||||
- 2 人工指挥AGENT直接完成配置工作，例如我指挥codex来完成复杂的配置工作，即整个配置工作是对AGENT友好的。
|
||||
- 经过调研，得出以下方案
|
||||
- 方案 A：YAML 源文件 + JSON Schema + 构建管道
|
||||
- 源文件用 YAML 编写（支持注释、缩进更清晰、token 更少），构建时用 Node.js 脚本一键转成 JSON 放进resources/configs/，运行时 Cocos 原生加载 JSON，包体零影响。同时配一套 JSON Schema，Agent每次改完可以自检，人工也能一眼看出哪里不合法。
|
||||
- 优点：可读性最好，注释可以记录设计意图，Agent 生成 YAML 的语法错误率低于 JSON（括号/逗号更少），Schema提供自动校验门控。
|
||||
- 缺点：需要维护一个构建脚本，CI/编辑器预览前需要先跑转换。
|
||||
- 方案 B：保持 JSON + Schema 校验（不换格式）
|
||||
- 不改格式，在现有 JSON 基础上加 $schema 引用和一个 validate 脚本。用 _comment 字段约定注释（Agent 写，人工读）。
|
||||
- 优点：零构建步骤，Cocos 直接加载，改动最小。
|
||||
- 缺点：JSON 没有原生注释，_comment 是 hack，Agent 生成 JSON 时括号/逗号错误率更高，可读性差。
|
||||
- 最终采用方案A，方案A可以总结为：
|
||||
- YAML 源文件（人和 Agent 读写）
|
||||
- JSON 运行时文件（Cocos 加载，自动生成，不手动编辑）
|
||||
- 构建脚本（devDependency，不进包体）
|
||||
- Schema 校验（Agent 写完自检，人工可验）
|
||||
- 最终效果还要看这次项目的实践
|
||||
# 3.收获与反思
|
||||
- 游戏内比较复杂的UI实现，仍然无法完全靠AI来实现，这一点在美术工作流中需要沉淀。
|
||||
# 4.下一步计划
|
||||
- 继续推进开发任务：
|
||||
- 把目前的小型闯关制度，改成类《浪漫餐厅》的大型关卡长时间推进机制
|
||||
- 游戏内ui继续改进：订单区域背景图、餐桌、餐盘已生成，但是接入仍需要调整ui
|
||||
- 目前游戏的性能有点差，需要优化
|
||||
- 研读三份报告，调整自己的开发计划：今天大致读了一下，报告的重点主要是明确指出具体的工作目标，例如：沉淀出具体的schema，方便下一个项目复用。但是还没有研究深入，明天需要进一步研读，调整自己的开发计划，保证开发计划能够达成工作目标。
|
||||
- 根据使用gpt以及喵吉托平台生成美术资源的实战经验，先整理出大致思路，沉淀出一套初步的AI美术工作流。然后着手写文档。
|
||||
- 初步的程序策划工作流已经整理好思路了，后面开始着手写文档。
|
||||
# 5.项目进度回顾和计划
|
||||
- 明天需要进一步研读报告，调整自己的开发计划
|
||||
Reference in New Issue
Block a user