# 1. 关系型表格设计

数据拆分为两张核心表：
FoodItems 管理 “事物是什么”，CombineRecipes 管理 “事物间发生什么反应”。（请先完成前面的）

# 1.1 表 1：FoodItems (物品基础大表)

这张表是整个厨房的 “物料字典”。每一行只描述一个独立物品本身的物理法则，绝对不要在这里写合成逻辑。

ID (主键)	中文名	生图名 / 熟图名	能否进锅	能否切	耗时	熟食产出数据	熟食产出实体	能否单放
Dumpling_Raw	生饺子	img_dumpling_raw	TRUE	FALSE	8.0	Dumpling_Cooked	Prefab_Cooked	TRUE
Meat_Stuffing	肉馅	img_meat	FALSE	FALSE	0			FALSE

💡 填表逻辑与字段全解析：

• ID (主键)：【最重要】物品的唯一英文代号。程序全靠这个检索数据，绝对不能重名、不能包含空格（如 Dumpling_Raw ）。

• 中文名：游戏内展示给玩家看的名字。顾客点单时的头顶气泡也会直接读取并显示这个词（如 生饺子 ）。

• 生图名 / 熟图名：（没有先不填）填入该物品 UI 图标的文件名称。注意不要填完整路径或 .png 等扩展名。如果不涉及生熟变化（如空碗），熟图一栏留空即可。

• 能否进锅 / 能否切：核心防呆开关。填 TRUE 允许放入对应的加工设备；填 FALSE 则表示玩家强行操作时会被系统直接拦截并退回。

• 耗时：在设备上加工所需的真实读条时间（单位：秒）。不需要加工的物品直接填 0 。（如果有物体有多种加工时间 请新加一列区分 比如煮耗时 切耗时等）

• 熟食产出数据：（自己取名 英文）物品加工读条结束后，灵魂变成什么？填入加工后产物在表 1 中的 ID（例如生饺子煮熟后，这里填入熟饺子的 ID Dumpling_Cooked ）。

• 熟食产出实体：（自己取名 英文）加工完成后，换上什么新外壳？填入对应 3D 模型或 UI 预制件的文件名称（如 Prefab_Cooked ）。底层代码会利用它在场景中凭空 “3D 打印” 出成品实体。

• 能否单放：（重要）

  • 填 TRUE ：表示允许直接丢在闲置的空桌面上暂存（如：盘子、一盘热饺子）。
  • 填 FALSE ：表示不能弄脏桌子，强制要求必须装入特定的容器中（如：生肉馅、面条、切好的葱花）。

• 扩充：如果你要定义新的操作 比如揉面等 请加一列 “是否能 XX” 再填写 如果是切的预制件产出数据和实体 请新建一列

# 1.2 表 2：CombineRecipes (合成配方表)

这张表是厨房的 “化学方程式”。专门定义两件物品碰在一起会变成什么。

配方说明 (备忘)	目标物品 (Target)	交互物品 (Active)	产出数据 (Result Data)	产出实体 (Result Prefab)
包饺子	Dough_Wrapper	Meat_Stuffing	Dumpling_Raw	Prefab_DumplingRaw

• 目标物品 (Target)：停在桌子上的那个 “容器” 或 “底座” 的 ID。
• 交互物品 (Active)：玩家拿在手里，砸向底座的那个物品的 ID。
• 顺序：顺序不用管。

# 1.3 进阶实战案例：经典牛肉汉堡流水线

为了让大家更直观地理解表格之间的联动配合，我们再拆解一个 “经典牛肉汉堡” 的配置案例。汉堡的制作不仅涉及设备加工（生熟转换），还涉及多物品的组合逻辑。

表 1：FoodItems (配置汉堡物料)

ID (主键)	中文名	生图名 / 熟图名	能否进锅	能否切	耗时	熟食产出数据	熟食产出实体	能否单放
Patty_Raw	生牛肉饼	img_patty_raw	TRUE	FALSE	5.0	Patty_Cooked	Prefab_PattyCooked	FALSE
Patty_Cooked	熟牛肉饼	img_patty_cooked	FALSE	FALSE	0			FALSE
Burger_Bun	汉堡底托	img_burger_bun	FALSE	FALSE	0			TRUE
Burger_Full	经典汉堡	img_burger_full	FALSE	FALSE	0			TRUE

💡 填表逻辑解析：

• 限制放置：生肉饼（ Patty_Raw ）和熟肉饼（ Patty_Cooked ）的 能否单放 都被设为了 FALSE 。这意味着玩家不能把油腻的肉饼直接丢在厨房桌台上，强制要求玩家必须寻找对应的容器（汉堡底托）来承载它。
• 耗时数据：生肉饼进锅后耗时 5 秒，系统会自动抹除它的存在，并读取 熟食产出数据 ，在原位置生成一个全新的 Patty_Cooked 实体。
  1. Patty_Raw (生牛肉饼) 的推理逻辑：
• 为什么 能否进锅 = TRUE ？ 毫无疑问，生肉必须经过加热才能吃，这是加工链的起点。
• 为什么 耗时 = 5.0 ？ 这是游戏节奏的把控。5 秒的烹饪时间能逼迫玩家在等待期间去干别的事（比如去拿汉堡底托），从而形成多任务并行的紧迫感。
• 为什么 能否单放 = FALSE ？ 牛肉不能直接放桌子上 多脏啊

2. Patty_Cooked (熟牛肉饼) 的推理逻辑：

• 为什么 能否进锅 = FALSE ？ 已经熟了，如果还能进锅，就会导致无限循环或者需要额外写 “烤糊了” 的逻辑。为了简化系统，熟食直接拒收。
• 为什么 能否单放 = FALSE ？ 刚出锅的肉饼滋滋冒油，同样不能直接放在桌上。这迫使玩家必须提前准备好容器（汉堡底托）或者端着盘子去锅里接，强化了流水线的先后顺序。

3. Burger_Bun (汉堡底托) 的推理逻辑：

• 为什么 能否进锅 = FALSE ？ 碗当然不能烤
• 为什么 能否单放 = TRUE ？ 它是整个配方的基底。既然熟肉饼不能单放，那桌上就必须有一个能接住它的东西。底托就像《胡闹厨房》里的盘子，可以随手放在空闲格子里暂存，等待核心食材的加入。

4. Burger_Full (经典汉堡) 的推理逻辑：

• 为什么 能否单放 = TRUE ？ 作为终极形态的产物，它是干净且完整的。玩家可以把它放在桌面上等待顾客，或者作为成品进行缓冲调度。

表 2：CombineRecipes (配置汉堡拼装配方)

配方说明 (备忘)	目标物品 (Target)	交互物品 (Active)	产出数据 (Result Data)	产出实体 (Result Prefab)
组装汉堡 (正向)	Burger_Bun	Patty_Cooked	Burger_Full	Prefab_BurgerFull
组装汉堡 (反向)	Patty_Cooked	Burger_Bun	Burger_Full	Prefab_BurgerFull

💡 填表逻辑解析：

• 这里完美演示了双向合成的容错设计。在实际游玩中，玩家的直觉是多样的：
  1. 玩家拿着熟肉饼，砸向桌上的汉堡底托（正向逻辑匹配成功）。
  2. 玩家拿着汉堡底托，去扣平底锅里的熟肉饼（反向逻辑匹配成功）。
• 只要配置了这两行，无论玩家用哪种手感操作，底层引擎都会瞬间执行销毁，并在当前位置 “无中生有” 地生成一个带有完美预制件外壳的 Burger_Full 。
• 实际填表只用填一行就可以了 程序后面会统一做脚本来反转过去

# 2. 避坑与防呆规范 (极其重要)

为了防止一键导入数据时程序崩溃，请务必遵守以下规范：

1. 精准的 ID 对应：表 2 中的 Target 、 Active 和 Result Data ，必须是表 1 中已经真实存在的 ID。如果出现拼写错误，系统会直接报错 “查无此物”。
2. 纯净的文件名：填写预制件或图片名字时，千万不要带后缀（如 .png 或 .prefab ），也不要带绝对路径。程序代码会自动去特定文件夹加上后缀匹配。