# 2026.06.30日报-刘鹏


Source: https://feishu.cn/docx/Y06OwJVT3imN3HksAUacD4xWnM4


# 一、工作概述

拆解浪漫餐厅关卡设计框架，完成资源循环和目标控制部分拆解，为后续订单机制和资源循环框架提供设计决策支持

总结梳理已完成的数值框架汇总到总结拆解方案，方便后续检查和调整

优化顶部状态栏UI、新增头像和体力补充广告埋点

# 二、主要产出

## 2.1-浪漫餐厅关卡设计框架拆解

拆解进度文档：

### 2.1.1-关卡框架梳理

通过让AI抓取浪漫餐厅相关的拆解文章，整合各个文章的观点共识，然后人工体验验证后的审核判断，最后梳理出以下的核心设计结构：二合游戏的关卡设计核心是“资源循环+目标控制+节奏编排”

### 2.1.2-详细设计思路和方法梳理

目前完成了资源循环模块和部分目标控制模块的详细设计思路梳理，以下主要是资源循环模块的设计思路梳理

资源环节设计：

体力接管的灵活设计：

根据调研数据显示前18min新手期—>上手期中间体力体力几乎没有低于50，没有带给玩家压力，18min后进入留存循环期，开始出现透支，可以明确推断：

前期让体力隐形，保证首轮爽感和目标建立。

中期再让体力接管 session 结束点，强制玩家停止，让玩家产生戒断并保证玩家不会出现重度游戏的疲惫感。

体力承担的是留存循环期“单次游玩长度和内容消耗的控制”，不给玩家前期体验徒增障碍。

中期体力结构：

体力上限100，体力可溢出，剧情/等级、活动以及日常任务等会额外投放体力。用自然恢复、剧情/等级固定投放让没时间的玩家可以稳定获得可操作成本，同时让时间多的玩家有额外可消耗的内容。

每2分钟回复1点，溢出/回满则停止回复，3h20min可以全部回满，单次棋盘游玩的时间控制在5min左右。让玩家形成稳定回流，同时确保玩家单次时长不会太长，可以在许多碎片化场景进行。

生成器的池结构变化：

面包链生成器权重推导

咖啡链生成器权重推导

基于目前得到的生成链等级权重可得出以下结论：

以1级物品为主导
主产物 80% 仍然是面包1级，说明在前中期系统依然希望玩家从1级链条开始合成，让整体的产出可控，不会过度膨胀，1体力的产出依然近似于1个1级物品。

副链不是硬切入，而是软渗透
土豆链不是通过“突然送你一个新生成器”进入，而是通过老生成器升级后，用 14% 的副产物概率慢慢渗透进来。

高阶跳产存在，但很克制
面包2级只有 6%，它的作用不是替代合成，而是偶尔给一点“加速感”。

所综合来看生成器池的权重设计倾向于拓宽池内物品的复杂度，但又严格控制新物品的产出权重，让1体力的产出对于单链产出效率来说是缓慢提升，甚至有时是下降的（加入其他链混合的时候），确保资源产出整体稳定可控

引导玩家合成：

如何让玩家自愿去合成棋子？

棋子本身的价值随等级提升而提升，1~3级棋子不能出售，单独一个没有价值

订单不会接收1级棋子或者直接就能生成的棋子，必须通过合成才能提交

如何让玩家去合成不同的链条？

单一链条棋子等级越高收益率越低，因此低等级的混合链条收益会更高，可见设计者希望玩家追求多链并行的高策略性，而不是单冲一条高链的的低策略性。

空间资源的承接设计：

开放率：

开场 3%

5 分钟前从 3% -> 46%

18 分钟到 76%

根据调研结果说明空间设计不是平均释放，而是分两段：

前 5 分钟快速放空间，保证第一次循环顺畅

5-18 分钟放慢释放，开始让空间承担轻度决策压力

棋盘预埋棋子/生成器/奖励：

让“空间解锁”本身变成资源奖励。

把后续高阶合成成本提前埋在棋盘里，让玩家觉得自己是在“挖出价值”，而不是机械扩格子。

形成扩张壁垒，调控扩张节奏并帮玩家建立阶段性目标

订单完成触发价值重组：

《浪漫餐厅》里交单的作用至少有三层：

消耗物品，释放空间

获得金币，推进剧情

投放新订单，建立新目标

这三层的作用是对本次订单小循环的资源结算和重组，推进大循环进度并为下一次的小循环提供资源和目标条件。让大小循环有序进行。

剧情承担资源循环的阶段性改变：

剧情将多次订单小循环的金币进度转换为新阶段开启的条件，结算后解锁新的合成链开启新的订单循环和阶段目标。

## 2.2-当前数值模型总结和梳理

拆解进度文件：

以下为当前核心数值模型概括，详细见上面的拆解进度文档数值框架部分。

成本模型

模型数据参考：

生成器权重反推

成本计算

项目当前的成本模型

动态有效成本模型
系统不会只按物品等级判断订单难度，而是会结合当前生成器产出池权重，计算玩家当前真实完成成本。

公式：

Lv1EquivalentPerClick = Σ((weight_i / totalWeight) × 2^(item_level_i - 1))

effective_cost(item) = 2^(level - 1) / chain_efficiency

order_stamina = Σ(count × 2^(level - 1) / chain_efficiency)

含义：

Lv1EquivalentPerClick：这条链一次点击平均能值多少个 1 级物品

effective_cost(item)：这个目标物品在当前盘面下到底难做不难做

order_stamina：这一整单实际要花玩家多少体力/点击成本

weight_i / totalWeight 来自当前棋盘生成器 output_pool 的权重分布

chain_efficiency 表示该物品所属产线当前的 Lv1EquivalentPerClick

目的：
让订单难度随当前盘面生产力动态变化，避免只按静态等级出单导致体感失真。

订单难度体系

订单难度采用明确 stamina 区间划分：

Easy：4 - 20

Medium：21 - 45

Hard：46 - 80

Boss：100 - 128

含义：

把“订单难不难”从主观标签改成客观成本区间。

目的：

保证同一难度档内，不同物品组合的完成体感大致一致。

动态难度调节

数据推导

成本记录

AI推算

Phase 3 已实现自适应难度逻辑。

核心公式：
ratio = avg_stamina(最近5单) / stamina_target

当前配置：
stamina_target = 30

当前大致策略：

ratio > 2.0：发 [Easy, Easy, Easy]

ratio > 1.2：发 [Easy, Easy, Medium]

0.8 - 1.2：发 [Easy, Medium, Hard]

0.6 - 0.8：发 [Easy, Medium, Medium]

补充规则：

Boss 单有 5 单冷却

连续 Easy 有保护，避免长期无压力

Phase 3 前两批有柔性过渡，避免从预设单直接跳到完全随机

目的：

让玩家长期处于“略有挑战但能完成”的区间，避免卡死或无聊。

订单奖励模型

推导来源：

当前奖励设计主口径为：

reward = round(sum(reward_base[level] × count) × tier_multiplier)

难度倍率：

Easy：1.0

Medium：1.2

Hard：1.5

Boss：2.0

含义：

奖励会随着订单难度提升而增加，但整体增速低于成本增速，避免高阶订单收益膨胀。

目的：

前期给玩家明显“交单赚到了”的反馈，中后期逐步转为“需要精打细算”的体验。

补充说明：
当前工程里仍能看到 reward_base_table 和 coin_per_cost 两套口径并存的痕迹，后续仍需进一步统一。

体力系统

当前已落地配置：

最大体力：100

每 120 秒恢复 1 点

每次生成消耗：1 点体力

含义：

每次生成行为都绑定清晰成本，形成统一可量化节奏。

目的：

控制单次 session 时长

制造自然回流节奏

为订单难度和生产效率提供统一度量

售卖价格模型

当前卖价公式：

sell_price = max(0, level - 2)

对应规则：

Lv1、Lv2：不可卖

Lv3 起：线性递增

含义：

卖物品只是空间管理兜底，不是主要收益来源。

目的：

允许玩家清理低价值物品释放棋盘空间，同时不破坏“订单交付才是主收益”的核心循环。

订单系统结构

当前订单系统按三阶段推进：

Phase 1：引导单
目的：保证玩家完成首个核心闭环

Phase 2：预设订单链
目的：精确控制教学节奏、链路解锁顺序和金币回收节奏

Phase 3：动态循环订单
结构：展示槽位 + 待补充池 + 定时补单 + 自适应难度 + 离线补偿

整体设计思路：

前 10 分钟优先保证“不断单、可推进、快速兑现”

随后再逐步引入动态单、跨链单和 Boss 单，增加深度

生成器产出池设计

数据参考：

生成器产出池遵循以下规律：

总权重固定

生成器等级越高，高阶物品权重越高

低阶物品不会完全消失，而是保留长尾分布

生成器升级不是“直接产出终点物品”，而是“产出池变广，高阶概率渐增”。

目的：

维持“低级产出 -> 合成升级 -> 交订单”的核心玩法，不让生成器升级直接跳过合成过程。

## 2.3-顶部状态栏的优化

对顶部状态栏进行优化：

去掉钻石栏位，不做额外的货币系统

新增头像和等级占位，支持配置和更新

新增体力广告埋点，可看广告获取额外体力

新增体力恢复倒计时，可视化体力补充进度

# 三、收获和反思

## 3.1-收获

关卡框架设计

其中：

资源循环 负责回答：玩家靠什么生产、合成、交付、再继续推进。

目标控制 负责回答：玩家此刻看到什么、能做什么、该先做什么。

节奏编排 负责回答：这些事情以什么压力、什么顺序、什么速度发生。

进一步说：

前期靠强引导+单目标+紧空间 建立理解。

中期靠多链引入+目标并行+空间整理 建立复杂度。

后期靠体力瓶颈+多槽位控制 session 节奏和回流。

所以它不是单纯“订单驱动”，而是三套系统一起控体验。

资源循环设计的核心收获

《浪漫餐厅》的资源循环，不该简单理解成“体力 -> 物品 -> 交单”，更准确是：

体力/点击资格 -> 生成器产出 -> 合成转化 -> 空间承接 -> 订单回收 -> 剧情/系统再注入

这里最重要的几个认识是：

体力 前期不是卡点，而是中期 session 长度控制器。

生成器升级 不是直接送高阶，而是扩展产出池、引入副链、改变产出结构。

合成 不是让单位材料收益率越来越高，而是把资源压缩成更高阶的可交付价值。

空间 不是被动限制，而是资源循环能否成立的承接底盘。

订单回收 不是终点，而是把物品、空间、金币、剧情重新组织成下一轮目标。

剧情 不是外层包装，而是把回收出的价值再转成新链、新生成器、新订单和新阶段。

## 3.2-反思

拆解效率：目前拆解工作主要卡点还是数据量不够，其他平台文章和一些老项目源码有关具体数值的数据较少，核心数据主要靠人工体验去摘，数据可靠，但效率低数据量少，部分数值模型只能满足当前的游戏表现，不能确定后续随着游戏新内容的注入，模型会不会出错。后续考虑能不能直接解包或者通过接入SDK让AI批量记录数据。

# 四、明日计划

继续拆解完善关卡设计框架目标控制和节奏编排部分的详细设计思路和方法拆解

根据拆解的节奏完成背包解锁阶梯设计 + 配置

拆解等级经验相关的数值和数值框架，确定前期等级成长节奏。

# 五、当前进度和规划

时间

模块

交付物

交付标准

完成情况

本周任务完成进度（%）

D1

订单机制拆解和配置同步

剧情系统背景切换和旁白配置

仓库、合成动效问题优化

订单机制完整流程图和配置结构

剧情系统背景可切换，旁白可居中配置

仓库、合成动效突兀出现在其他二级

输出订单系统完整流程图，包含生成、刷新、完成、奖励发放、异常中断等关键节点，并整理对应配置字段说明。

订单相关配置可定位、可修改、可同步，形成一份配置说明文档。

剧情系统支持按节点切换背景，切换后显示正确、无错位、无丢失。

拆解浪漫餐厅订单显示和补充机制，完善整个订单刷新机制配置

剧情系统界面背景和旁白配置方案落地

仓库界面优化、合成动效UI触发逻辑优化

20%

D2

广告位 ID 替换

新手引导补全

背包解锁阶梯设计 + 配置

AdService.cs → 微信后台真实 ID

增加"合并两个 gen_craft_lv1 → gen_craft_lv2"的引导步骤

设计 4→20 格的解锁节奏，写入 BackpackUnlockConfig.json

广告位替换为真实 ID，并完成基础验证。

新增合并引导步骤，流程可正常触发。

完成 4→20 格背包解锁节奏设计并写入配置。

拆解浪漫餐厅关卡设计框架，完成资源循环和目标控制部分拆解，为后续订单机制和资源循环框架提供设计决策支持

总结梳理已完成的数值框架汇总到总结拆解方案，方便后续检查和调整

优化顶部状态栏UI、新增头像和体力补充广告埋点

15%

D3

XP 等级数值设计

XP 系统配置实现

顶部状态栏改造

等级曲线、XP 来源权重、等级奖励表

配置 reward_xp、升级判定逻辑、存档

去钻石栏、加头像框+等级、体力按钮接广告埋点

完成等级曲线、XP 来源和奖励表设计。

XP 获取、升级判定和存档逻辑可正常运行。

顶栏完成等级展示改造，体力按钮接入广告埋点。

D4

AudioManager 实现

音频资源配置

推送通知接入

BGM/SFX 播放管理器、音量控制、Settings 联动

AudioConfig.json + 接入已有的 merge_sfx_id

微信订阅消息模板、触发逻辑（体力满/订单刷新/回流）

完成 BGM/SFX 播放管理和设置联动。

音频配置可用，并接入现有音效资源。

完成体力满、订单刷新、回流等通知触发逻辑。

D5

完成新链剧情配置包含背景、旁白图片

完成人物动画制作

完整剧情配置

人物动画制作完整workflow或者skill

新链剧情背景、旁白图片等配置补齐，系统可完整跑通。

完成人物动画制作 workflow 或 skill，支持批量生成。

规划风险提醒：探索与收口失衡【最高优先级】、空间压力设计失误、订单节奏不合理、广告点打断体验、合成反馈不够满足、 美术风格不统一、 第一版系统定义过早、单人 AI 工具使用不熟