260521日-韦译

用户6299

5月22日修改

1.工作内容概述

1.
调研接入抖音/微信平台的方案​

2.
基础功能线——对已有系统的优化——优化棋盘和订单系统的一些bug​

3.
W2线——广告接入—— 用Mock模式跑通广告位的全流程（预计明日进入微信开发者工具进行测试）​

4.
完成了整个项目配置方案的设计和实现，其中的重点是物品链schema的设计与实现。能够帮助后续使用AI批量生成关卡、关卡数值​

5.
基本程序策划工作流文档的编写，还差一点收尾（预计明日早上完成2个工作流文档的编写）​

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中看到​

common.docs_name - LarkCCM_Docs_Menu_Image

260521日-韦译​

260521日-韦译