打通投喂→游戏玩法信道
05/031 浏览综合
以下是关于 “打通投喂→游戏玩法信道” 的架构讨论。
当前状态已有的：
- Leaderboard.lua 的投喂弹窗完整可用，但点击食物后只显示 Toast，没有后续动作
- GameState.lua 已有 RecordFoodIntake()、AddIndicator()、暗线指标系统（血糖/血脂/血钠）
- Enemy.lua 已有 Spawn() 机制，支持从 Config.EnemyTypes 查类型
- BrainDashboard.lua 已有 MONITOR-G（饮食结构分析），读取 GameState.GetIntakeHistory()
- FoodRegistry.lua 已有 MarkFedByOthers() 和完整的食物元数据框架
数据流设计方案核心链路：投喂(Leaderboard)
→ 写入"待消化食物队列"(持久化)
→ 口腔关卡读取队列，生成食物NPC(Enemy.Spawn)
→ 食物经过口腔处理(碎裂/酶解)
→ 器官传递(胃→小肠→大肠)
→ 每个环节影响暗线指标(血糖/血脂/血钠)
→ 大脑监控室实时反映变化
→ 大脑食物图鉴记录
关键设计节点1. 待消化食物队列（核心中间件）这是整条链路的枢纽。投喂产生食物，口腔消费食物，需要一个队列连接两端：pendingFoods = {
{ foodKey = "spinach", feederId = 1051336128, timestamp = os.time() },
{ foodKey = "apple", feederId = 0, timestamp = os.time() }, -- 0 = 自己投喂自己
}
存储位置有两个选择：方案存储优点缺点A. 内存队列GameState 本地变量简单、即时刷新页面丢失，只适合单机B. clientCloud云变量跨会话持久、支持多人互喂有延迟、需要轮询考虑到你当前是单机模式（.project/settings.json 的 multiplayer.enabled 是 false），方案 A（内存队列）做 MVP 最快，后续切多人时再升级为方案 B。2. 投喂动作触发（Leaderboard → GameState）点击食物卡片时：
- 把食物推入 GameState 的待消化队列
- 同时立刻记录到食物图鉴（大脑知道"吃了什么"，不需要等消化完）
- Toast 反馈
- 读取待消化队列
- 按时间顺序或按节拍（Beat）逐个生成食物 NPC
- 每个食物的 EnemyType 从 FEED_FOODS.key 映射到 Config.EnemyTypes
总结：需要新增/修改的模块模块改动工作量GameState.lua新增 pendingFoodQueue、PushFood()、PopFood()、GetPendingFoods()小Leaderboard.lua食物点击回调中调用 GameState.PushFood() + GameState.RecordFoodIntake()小Config.lua为5个食物类别定义 EnemyType 模板 + 指标影响规则中Enemy.luaSpawn() 支持从 pendingFoodQueue 取食物，叠加食物名称/图标中BeatSystem.lua节拍开始时检查 pendingFoodQueue，生成对应食物波次小BrainDashboard.lua无需改动（已有读取通道）无总体来说，核心改动集中在 GameState（队列）和 Enemy（映射+生成）两个模块，其他模块只需少量对接代码。