Evilom/dc-docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: collect complete Feishu media assets

Browse Source
This commit is contained in:
Evilom
2026-07-11 12:30:54 +08:00
parent 3ea50649f6
commit bbafe770b3
662 changed files with 15404 additions and 14017 deletions
Download Patch File Download Diff File Expand all files Collapse all files
output/feishu-docs/QUlXwDxswi4ni3kkgzictj1Rn6e.md
+378
View File
@@ -0,0 +1,378 @@
# QUlXwDxswi4ni3kkgzictj1Rn6e
Source: https://dianchukeji.feishu.cn/wiki/QUlXwDxswi4ni3kkgzictj1Rn6e
# 1.工作内容概述
- 调研拆解
- 搜集循环期的订单和剧情数据
- 根据新数据，继续调研拆解订单刷新机制/订单投放节奏
- 调研拆解宏观难度调控设计
- 接入个人信息界面的美术资源
# 2.主要产出
## 2.1 搜集循环期的订单和剧情数据
- 调研到订单刷新机制时，发现有订单刷新机制本质上有2个阶段
- 剧情预设订单期
- 刷新机制：只有剧情预设订单
- 循环期：
- 刷新机制：剧情节点重组+动态生成订单+笑脸评分机制
- 之前调研循环期数据，得到的结论没有统一，数据说服力不够强。故需要深入调研第二波循环期的数据
- 目前调研到了第50单。除去剧情预设期的10单，循环期的订单有40单，足够支撑初步结论
![图片](../feishu-images/QUlXwDxswi4ni3kkgzictj1Rn6e_YX3Lb9w1AoKz.png)
## 2.2 根据新数据，继续调研拆解订单刷新机制/订单投放节奏
> :kiwifruit:
今日继续补充了以下内容
### 2.2.1 笑脸机制的进一步研究，得出了更多结论
- 笑脸机制
![图片](../feishu-images/QUlXwDxswi4ni3kkgzictj1Rn6e_BHmyb792sojz.png)
- 解锁时间：在完成剧情任务节点9后，解锁笑脸机制
- 具体机制
- 解锁笑脸机制时，会给当前订单赋予笑脸评分，评分从1到3都有
- 完成有笑脸评分的订单时，获得笑脸评分
- 笑脸评分满8分时，
- 新增一批带笑脸评分的订单
- 新增这批的笑脸评分默认为1
- 给之前旧订单也挂上笑脸评分
- 给旧订单的笑脸评分默认为2
- 给予奖励：奖励主要是新增的这批带笑脸评分订单的所需物品
- 笑脸订单不是替换旧订单，而是“批量补入 + 保留长挂单”
![图片](../feishu-images/QUlXwDxswi4ni3kkgzictj1Rn6e_B1vhbxrAloWn.png)
- 重要的规律：从数值角度来看，每次要完成当前所有订单时，还剩下1单时，大概率也是正好完成所有笑脸评分的时候。此时又开启一轮笑脸评分循环。
![图片](../feishu-images/QUlXwDxswi4ni3kkgzictj1Rn6e_ApBJbu9bPonf.png)
- 动态生成订单和笑脸评分机制如何合作
- 体感上来说是：
- 动态生成订单负责兜底，防止玩家没订单玩
- 此时玩家的目标分为几种：笑脸评分作为中目标缓和小目标和大目标之间的差距，让玩家觉得正反馈不是很遥远，不能推进剧情也还有笑脸评分这个正反馈。换句话说，笑脸评分是完成单个订单和推进剧情的阶段性目标。
- 小目标：完成单个订单
- 中目标：完成笑脸评分
- 大目标：推进剧情
- 从剧情预设订单期切入到循环期的条件
- 完成某个特定剧情任务节点：《浪漫餐厅》中是完成剧情任务节点5后
- 即剧情任务节点5后：动态生成订单介入
- 总结：循环期订单刷新机制可以拆成三层
![图片](../feishu-images/QUlXwDxswi4ni3kkgzictj1Rn6e_E4ZubRN4koEl.png)
![图片](../feishu-images/QUlXwDxswi4ni3kkgzictj1Rn6e_DpPab8P3Zowi.png)
- 第一层是普通动态补位，用于维持基础订单数量；
- 第二层是剧情节点重组，用于切换阶段和改写队列；
- 第三层是笑脸批量刷新，用于在队列收缩后重新拉满目标。
- 三层机制共同形成“清队列 -> 阶段反馈 -> 批量补目标 -> 再清队列”的循环节奏。
### 2.2.2 用AI进一步验证了之前得出的结论是否正确
编号
规律 / 假设
数据证据
相关性判断
建议结论
1
新手期 / 剧情预设订单期：订单按剧情配置进入订单槽
时间轴 1-16 行基本表现为完成订单或剧情节点后，按固定顺序出现订单 1-12；剧情节点 2 后出现订单 5、6；剧情节点 5 后出现订单 11、12
强支持
新手期主要是剧情预设订单驱动，订单刷新更像“配置队列按阶段放出”
2
新手期中，剧情节点是订单刷新的闸门
时间轴第 4、6、10、13、15、22、26 行多次出现“完成订单后进入剧情任务节点 / 完成剧情后再刷新”的节奏；例如剧情节点 2 后订单槽从 1 单扩为 2 单
强支持
剧情节点确实承担阶段闸门作用：玩家完成关键订单后，先推进剧情，再释放下一批订单
3
循环期由剧情节点重组、动态生成订单、笑脸评分机制共同构成
动态补位：第 57、61-63 行；剧情重组：第 60 行；笑脸批量刷新：第 50、68 行
强支持
循环期不是单一刷新器，而是三层机制叠加：普通补位、剧情重组、笑脸批量刷新
4
剧情节点重组会删除原有订单并新增订单
第 60 行：完成剧情节点 16 后，活跃订单变为订单 8、3、9、10；上一状态中的订单 5、6、7 消失，只保留订单 3，并新增订单 8、9、10
中强支持
剧情节点重组不是简单补位，而是会改写队列：删除部分旧单、保留少数长挂单、加入新阶段订单
5
动态生成订单会根据当前订单数量控制投放节奏
队列较满时多次不补单：第 51、52、58、64-67 行；队列减少后才出现补位：第 57、61-63 行
强支持
动态刷新不是每完成一单就补一单，而是看当前队列状态决定是否补入
6
笑脸订单不是替换旧订单，而是批量补入 + 保留长挂单
第 50 行刷新后活跃订单为 27、28、24、29、25，保留旧订单 24、25；第 68 行刷新后活跃订单为 14、15、16、17、12，保留旧订单 12
中强支持
这是最关键且证据最强的规律之一：笑脸刷新是扩队列 / 补目标，不是全量替换
7
循环期三层机制形成“清队列 -> 阶段反馈 -> 批量补目标 -> 再清队列”
第 49-52 行队列从多单收缩；第 50 行笑脸批量补目标；第 57 行动态补满；第 60 行剧情重组；第 64-68 行再次收缩并笑脸补入
强支持
可以作为循环期订单刷新机制的核心总结图 / 核心结论
8
订单槽数量跟剧情推进 / 等级绑定
初始 1 槽；剧情节点 2 后第 7 行出现 2 槽；剧情节点 5 后第 16 行出现 3 槽；剧情节点 9 后第 28 行出现 4 槽
强支持
订单槽开放节奏与剧情节点强绑定，至少前中期非常明确
### 2.2.3 梳理订单刷新机制的框架
### 2.2.4 进一步分析框架下的各个模块
#### 2.2.4.1 剧情预设模块
- **拆解目的**
- 剧情预设订单是按什么规则从配置进入队列的？
- 剧情预设订单的进入方式有几种？
- 剧情节点作为"闸门"的具体行为是什么？
- 预设订单的内容设计有什么规律？预设订单的内容设计有什么规律？
- **人为总结规律**
- 触发条件
- 触发条件 =完成剧情任务节点，而剧情节点的触发条件=金币达标金币达标
- 每次完成剧情任务节点后，系统补充一批预设订单到队列
- 在预设期（节点1-5），剧情节点是唯一的订单刷新闸门，没完成节点就没有新订单
- 进入方式
- 预设订单按配置顺序进入，不是随机的
- 每次节点触发后补入的数量 = 当前可用槽位数-当前已有订单数（即"填满"策略）
- 预设订单比动态订单优先级更高（从数据看，节点完成后立即出现预设订单，动态订单让位）
- 内容设计规律
- 引导单（新链/新生成器介绍）难度显著低于非引导单（24.18 vs 68.48）
- 节点1-5的预设订单全部承担教学功能（介绍轻篮、面粉、土豆、咖啡机等）
- 付费压力订单集中在节点11后出现（订单15/17/18），与复制品奖励机制介绍时机一致
#### 2.2.4.2 动态生成+移除模块
- 拆解目的
- 动态订单什么时候开始生成？
- 生成什么难度的订单？
- 生成多少个？
- 移除条件是什么？
- 人为总结规律
- 启动条件：
- 剧情任务节点5完成后，动态生成订单机制正式介入
- 生成逻辑：
- 不按配置生成，而是根据算法实时监测：
- 玩家状态
- 计时器
- 难度信息
- 最近订单难度
- 2.5的宏观难度调控设计，会给每个等级、剧情、笑脸机制阶段、订单设定难度
- 当前订单少时→生成更多；订单多时→生成更少（自适应填充）
- 按"订单组"为单位生成（1组≈1-3单），而非逐单生成
- 难度选择遵循"紧松交替"：最近N单偏高→下一组偏低压/中压；最近N单偏低→下一组偏高压
- 计时器规则：
- 订单不是无限生成的，需要间隔一段时间才能生成
- 间隔不是固定值，应由多维度动态计算：
- 难度信息
- 2.5的宏观难度调控设计，会给每个等级、剧情、笑脸机制阶段、订单设定难度
- 最近完成订单的难度
- 玩家游玩时长（越长→间隔可能越短，防止无聊）
- 玩家当前体力（体力低→间隔可能变长，避免浪费生成）
- 订单跟体力（订单的体力消耗/订单的完成难度）
- 移除机制
- 动态订单不仅新增，也会动态减少
- 最大可能规律：高难度订单如果太久没完成，则会被删除，换成低难度订单
- 移除触发条件 = 订单在槽位中停留时间 > 某阈值 AND 订单难度 > 某阈值
- 移除后不是空着，而是立即从动态池中抽一个低压/中压订单替换
- 只有动态生成的订单会被移除，剧情预设订单和笑脸机制订单不会被移除（因为它们承载叙事/进度功能）
#### 2.2.4.3 笑脸机制模块
- 拆解目的
- 笑脸评分的分配规则是什么？
- 笑脸满分后新增的一批订单有什么特征？
- 笑脸作为中层目标的节奏如何设计？
- 笑脸机制与动态生成是独立运作还是互相影响？
- 人为总结规律
![图片](../feishu-images/QUlXwDxswi4ni3kkgzictj1Rn6e_SerKbyVKZoTf.png)
- 解锁与启动：
- 完成剧情任务节点9后解锁笑脸机制
- 解锁时，当前所有在场订单被赋予笑脸评分（1-3分不等）
- 评分规则：
- 完成有笑脸评分的订单→获得该订单对应的笑脸分
- 初始满分阈值：6
- 满分阈值随着等级而提升
- 4级：6级
- 5级到N级：8级（N还没测出来，后续的数值也还没测出来）
- 评分分配与订单难度相关：低压订单→1分，中高压订单→2-3分（使得无论完成简单还是困难订单都有进度感，但困难订单贡献更大）
- 满分触发
- 满8分时触发三个动作：
- 新增一批带笑脸评分的订单（默认1分）
- 给之前旧订单也挂上笑脸评分（默认2分）
- 给予奖励（主要是新批次所需物品，降低新一轮启动成本）
- 节奏同步规律
- 当玩家完成当前所有订单剩最后1单时，大概率正好也是笑脸分攒满的时候
- 这说明评分总和被有意设计为特定数字，使得"清完一轮订单"与"完成一个笑脸周期"在时间上自然对齐
- 例如：满分阈值为8，4个订单槽 × 平均2分/单=8分，恰好一个完整的清场周期
- 与动态生成的协作：
![图片](../feishu-images/QUlXwDxswi4ni3kkgzictj1Rn6e_G9oMb7lpToA9.png)
- 动态生成→兜底，防止无订单；笑脸→提供阶段性正反馈，缓冲"完成单订单"到"推进剧情"之间的距离
- 笑脸满分触发的新批次订单 =直接进入综合队列池（而不是另开一条独立管道）
- 笑脸批次订单进入时可能暂时压制动态生成（因为一次性涌入多单，已经填满了需求）
#### 2.2.4.4 综合队列池模块
- 拆解目的
- 三条队列（预设/动态/笑脸）汇入后，优先级规则是什么？（谁先出？）
- 队列池有没有容量上限？
- 感觉是FIFO
- 池中订单的排序逻辑是什么？
- 池子是透明的还是隐藏的？
- 人为总结规律
- 优先级推断：
- 剧情预设订单优先级最高（数据表现：节点完成后，预设单立即出现，不存在"排队等待"现象）
- 笑脸批次订单优先级次之（笑脸满分后的新一批订单似乎也是立即补入）
- 动态生成订单优先级最低（是"填充剩余空间"的角色）
- 容量控制：
- 队列池存在容量上限（否则三条队列无限涌入会导致系统混乱）
- 上限可能与当前可用槽位数相关（如：上限=当前槽位数 × 2 或 × 3）
- 问题：如果队列中订单数量超过上限怎么办？
- 可能的策略是"动态生成暂停，直到池中数量降到阈值以下
- 排序逻辑：
- 同优先级内按FIFO（先进先出）
- 不同优先级间按来源排序：预设 > 笑脸 > 动态
#### 2.2.4.5 槽位分配模块
- 拆解目的
- 槽位数量扩展的精确触发条件是什么？
- 不同槽位是否有功能分化？
- 空槽出现后，补充速度有多快？
- 槽位的位置（从左到右/从上到下）是否对应难度梯度？
- 人为总结规律
- 开放规律
![图片](../feishu-images/QUlXwDxswi4ni3kkgzictj1Rn6e_LVwRbO7duozL.png)
- 初始1槽→ 节点2后2槽 → 节点5后3槽 → 节点9后4槽
- 节点2≈等级2，节点5≈等级3，节点9≈等级4
- 槽位扩展绑定的是"剧情节点"而非"等级"（两者在设计上几乎同步，但底层可能只检测节点完成）
- 槽位-难度分化
- 低位槽（1、2）承担快速回落或救济目标 ——低压/中压订单
- 高位槽（3、4、5）承担新阶段、高难度或长期目标—— 高压/尖峰订单
- 支撑证据：高难度的"长挂订单"（如订单15、17、25）似乎总在特定位置出现
- 动态移除也与槽位相关 ——高位槽的高难订单更容易触发超时移除
- 补充速度：
- 空槽出现后（订单完成），观察上来看不是绝对即时补充，但延迟很短
- 补充速度可能受计时器控制：
- 预设订单/笑脸订单→几乎即时（只要池中有货）
- 动态订单→受计时器节流（可能有几秒到几十秒的延迟）
### 2.2.5 得出分析结论
- 订单投放不是单纯随机刷新，而是“三路合流”：剧情预设订单、笑脸批次订单、动态生成订单共同进入订单池。
- 优先级大概率是：剧情预设 > 笑脸批次 > 动态订单。动态订单更像兜底，用来填空、调节节奏。
- 剧情节点是前期订单节奏的核心闸门，完成剧情节点后才会补入关键预设订单，槽位扩展也更像绑定剧情节点，而不是单纯绑定等级。
- 动态生成承担压力调控：订单少就补，多了就少补；高难订单长期没完成时，可能会被替换成低/中压订单。
- 笑脸机制是中层节奏器，把“完成单个订单”和“推进剧情”之间的空档填起来，让玩家清一轮订单时刚好获得阶段性正反馈。
## 2.2 宏观难度调控设计
### 2.2.1 拆解目的
- **难度主要由订单、笑脸机制、剧情、等级4层把控，需要分析之间的关系**
- 思考等级和剧情的关系，为什么a级和b级之间插入n个剧情，却在另外一个等级中插入m个剧情？
- 为什么要在这里设置这些等级
- 为什么在不同的等级之间设置不同的经验进度条
- 例如：1级到2级可能需要N个订单，而2级到3级可能需要M个订单
- 升级所需的经验数值为什么是这些数字？
- **关键问题：整个关卡的设计流程是怎么推导出来的？**
### 2.2.2 调研记录数据
- 相关的表主要是：时间轴表、订单表、剧情表、等级经验和奖励表
### 2.2.3 人为总结规律
- **关键问题：整个关卡的设计流程是怎么推导出来的？**
个人猜测如下：整个设计流程是从上导下推导出来的
- 订单、笑脸机制、剧情、等级，是4层目标/里程碑。（除了运营活动外）
- 小目标：订单
- 中目标：笑脸机制
- 大目标：剧情
- 超大目标：等级
- 而难度是串联这些目标的纽带
- 超宏观的难度曲线：设置在等级与等级之间，而等级由多个剧情组成
- 宏观的难度曲线：设置在剧情与剧情之间，而剧情由多个笑脸机制或者订单组成
- 中观的难度曲线：设置在笑脸机制和笑脸机制之间，而笑脸机制由多个订单组成
- 微观的难度需求：设置在订单与订单之间
- 视觉化理解
- 整体的组织逻辑为：
- 多个订单组成笑脸机制
- 多个笑脸机制组成剧情
- 多个剧情组成等级
- 由1.1.2可知：一段关卡=切片(slice)=在某个时间窗口内,由目标、节奏、状态三者交叉决定的玩家体验切片。
- 在实际落地层面可以理解为：slice=玩家当前订单+玩家当前笑脸机制进度+玩家当前剧情进度+玩家当前等级进度
- 玩家所处的任意时段，都属于某个slice
- 新手期和循环期的不同设计：主要是层级的编排不同
- 新手期是：订单——剧情——等级
- 循环期：订单——笑脸机制——剧情——等级
- **剧情节点基本都是 15xp。从“完成后的等级”反推：**
- 等级2：30xp
- 等级3：75xp
- 等级4：135xp
- 等级5：210xp
每级所需增量是 30、45、60、75，增量每级 +15。若 延续，等级6 很可能是 300xp。
- **等级经验本质是在控制“每级包含几个剧情节点”**
- 剧情节点基本固定给 15xp，所以等级经验不是孤立数值，而是在规定每个等级段有多长：
- 等级2：30xp = 2 个剧情节点
- 等级3：75xp = 2 + 3 个剧情节点
- 等级4：135xp = 2 + 3 + 4 个剧情节点
- 等级5：210xp = 2 + 3 + 4 + 5 个剧情节点
- 所以规律是：每升一级，多容纳 1 个剧情节点
- 如果延续这个公式，等级6 应该是：210 + 90 = 300xp
- 也就是等级5到6需要 6 个剧情节点。
## 2.4 接入个人信息界面的美术资源
- 效果如下
# 3.收获与反思
- 今天跟刘鹏讨论时发现，其实《浪漫餐厅》的订单刷新机制，本质上还是遵从着配置的方式来设计的，并不是我们之前想的新手期结束后，就只按动态算法来生成订单了。
- 从宏观角度看，其实无论是动态生成订单、还是剧情预设订单、笑脸刷新机制、剧情任务节点、等级，都是被设计好的。都是策划设计好宏观的难度曲线后，一层一层向下设计出的东西。
- 只是我们之前没有从宏观的角度出发，分析难度调控设计。今天回过头来一看，恍然大悟。
# 4.下一步计划
- 调研拆解
- 学习数据模拟验证的方法
- 数据模拟的本质是代入自己定义的测试数据进行计算，得到结果进行对比
- 推进数值拆解和关卡拆解，后续主要推进以下内容
- 继续调研拆解宏观难度调控设计
- 从微观设计反推出宏观设计，总结出二合游戏的关键认知
- 优化
- 优化美术资源
- 优化功能
- 修复bug
# 5.项目规划
参考：
https://jasminehuang477-cmd.github.io/share_hyper_casual_game_design_guide/#s10
https://merge2iaa-selectionanalysis.netlify.app/
- 开发计划：
- **任务详情看第二个文档的十、两周开发建议节奏**
- **非开发计划中的内容，不优先开发**
- 拆解调研任务
**目标**
**核心任务**
**完成情况**
完成《浪漫餐厅》关卡/数值相关设计拆解分析，说明从中收获了哪些二合类游戏设计的关键认知，输出拆解分析报告并进行内部分享
- ok——写拆解分析报告大纲
- 对《浪漫餐厅》关卡/数值相关设计进行拆解分析
- 实机记录数据（完成后才方便做下面的内容）
- 需要反思如何改进
- 学习数值拆解调研的方法
- 研究AI建模分析的方法
- ok—在网上学习数值调研拆解相关的方法
- ok—向楚真日报学习
- 问刘鹏
- **学习积累二合类的数值设计基础知识（对于数值调研拆解，基础数值设计知识很重要）**
- 从微观反推宏观内容：研究对具体设计组合的抽象、理解、演化方向预判
- 数值拆解方向
- （核心）订单数值
- 棋盘关卡
- 需要结合订单刷新机制
- 总结《浪漫餐厅》关卡/数值相关设计的规律
- 总结二合类游戏设计的关键认知
- 整理以上2点内容，进行内部分享
- 使用自动化批量关卡生成方案+分析的关卡和数值设计规律+订单刷新机制，铺量关卡。目标是铺至少40单的游戏内容量（大概1个小时左右的游玩流程）
### 80%
- 上线前要完成的任务
**目标**
**核心任务**
**完成情况**
关卡和数值设计铺量
- 对《浪漫餐厅》关卡/数值相关设计进行拆解分析
- 需要跟之前的订单刷新机制结合起来
- 总结《浪漫餐厅》关卡/数值相关设计的规律
- 用AI生成并配置好类似规律的关卡和数值
### 30%
基础功能
- 文本提示信息框——完成
- 购买弹窗——暂时搁置
- 边缘系统
### 80%
商业化
- 上架微信小游戏
- UI适配（已经跑通流程，只需要再操作一遍）
- 打包优化（已经跑通流程，只需要再操作一遍）
### 30%
更换新主题的美术资源
- 持续优化美术资源生成管线
- 目前还差
- 个人信息界面
- ok——剧情任务面板
- 思考问题
- 继续解决美术风格的饱和度问题和AI味道问题
- 物品链和生成器链考虑优化美术资源
- 将笔刷、毛刷等物品加入，弥补目前物品链物品过于相似的问题
### 99%
优化
- 手感调优
- 上线前测试找bug
### 40%
- 风险注意：https://merge2iaa-selectionanalysis.netlify.app/的六、产品风险分析很有价值，开发时需要注意
- **空间压力设计失误**
- **订单节奏不合理**
- **合成反馈不够满足**
- **美术风格不统一**