# 13 运行时引擎与核心系统深化设计 本文档补足“把游戏做好”所需要的核心系统设计，不只讨论 UI，而是把运行时引擎、生命周期、背包系统、生命系统、事件与在线存档串成一套完整方案。 ## 13.1 当前产品定位 TinyWaste Online 不是网页式信息展示项目，而是一款： - 服务端权威结算的在线废土生存游戏 - 以单屏 HUD 为常驻界面 - 以系统弹窗/面板处理中频与低频操作 - 以时间推进驱动状态、资源、事件和任务 这意味着架构设计要同时满足： - 决策节奏像游戏 - 数据流像在线产品 - 规则层像可测试的模拟器 ## 13.2 运行时引擎分层 建议把“引擎”理解为运行时规则框架，而不是 3D 图形引擎。 ### 13.2.1 Runtime Core 职责： - 接收玩家动作 - 推进时间 - 执行效果链 - 更新世界状态 - 产出新 `GameView` 当前仓库中主要由 `packages/game-core/src/engine.ts` 承担。 ### 13.2.2 View Model Layer 职责： - 把内部 `GameState` 投影成适合 HUD 使用的 `GameView` - 控制哪些信息常驻、哪些信息放到弹窗层 - 限制 UI 对领域状态的直接依赖 ### 13.2.3 Content Layer 职责： - 维护物品、地点、敌人、任务、配方、事件定义 - 所有玩法扩展优先靠数据增量，而不是写死分支逻辑 ### 13.2.4 Persistence Layer 职责： - 用户身份 - 云存档 - 版本迁移 - 存档校验 ## 13.3 游戏生命周期 游戏生命周期建议明确分成 7 个阶段： 1. `boot` - 客户端初始化、检查账号会话、读取配置 2. `session-ready` - 已确认账号身份，开始拉取云端存档 3. `save-ready` - 存档进入内存，HUD 可以渲染 4. `decision` - 玩家阅读信息、选择动作 5. `resolving` - 服务端执行动作、推进时间、写入日志 6. `interrupt` - 战斗、事件、死亡、胜利等强制中断态 7. `persisted` - 新状态完成落库，回到下一轮 `decision` 生命周期原则： - UI 永远不直接修改权威状态 - 所有中断态都要可恢复 - 任意动作完成后都应保证日志、时间、任务和存档状态同步 ## 13.4 HUD 生命周期 主 HUD 只保留高频信息： - 时间 - 生存状态 - 当前地点 - 行动入口 - 角色装备摘要 - 快捷栏 中频系统改用面板弹出： - 背包 / 避难所仓储 - 蓝图 - 任务 - 完整日志 设计原因： - 更像真实游戏而不是网页后台 - 减少主屏认知负担 - 保证一屏内只承载“下一步决策需要的信息” ## 13.5 动作执行生命周期 一条标准动作链应为： 1. 玩家发起动作 2. 服务端校验动作是否合法 3. 推进时间 4. 结算状态消耗 5. 结算地点资源与热度 6. 结算掉落/交易/配方结果 7. 检查事件、战斗、任务推进 8. 写入日志 9. 写入存档 10. 返回新 `GameView` 这里最重要的是顺序一致性。只要顺序稳定，玩家就能理解“为什么会掉血、为什么这里空了、为什么事件触发了”。 ## 13.6 背包系统设计 ### 13.6.1 当前正确方向 当前采用体积容量，而不是无限背包，这是对的。 原因： - 废土游戏的核心就是取舍 - 容量限制会自然驱动路线规划、补给管理和交易行为 - 比单纯格子背包更贴合生存题材 ### 13.6.2 背包分层 建议将背包拆成 3 层： - `Quick Slots` - 高频立即使用 - 水、药、近战、少量工具 - `Field Bag` - 当前随身背包 - 受体积限制 - `Shelter Storage` - 基地仓储 - 用于长线积累 当前项目已经有 `Quick Slots + Inventory` 雏形，下一步建议补 `Shelter Storage`。 当前实现进度： - 已经落地 `Field Bag + Shelter Storage` 双层库存 - 仅位于 `home / Shelter-7` 时可访问避难所仓储 - 避难所内制作会同时读取背包与仓储材料，避免资源可见却不可用 ### 13.6.3 物品状态 每个背包物品后续建议支持： - `itemId` - `count` - `durability` - `quality` - `boundFlag`（任务物品或不可丢弃） - `sourceTag`（掉落来源，便于日志和分析） ### 13.6.4 背包交互原则 - 主 HUD 只显示快捷栏和容量摘要 - 完整背包在弹窗面板中查看 - 装备/使用/整理/分类都应在背包面板完成 - 背包面板必须优先展示“对当前生存决策有帮助的信息” ## 13.7 生命系统设计 生命系统不应只是一根血条，而是一组相互耦合的生存状态。 ### 13.7.1 核心状态 - 生命 `life` - 饥饿 `hunger` - 口渴 `thirst` - 精力 `energy` - 理智 `sanity` - 辐射 `radiation` ### 13.7.2 设计原则 - 生命是最终硬失败边界 - 饥饿与口渴是持续性压力来源 - 精力限制连续行动长度 - 理智影响事件与长期稳定性 - 辐射是高风险区域的长期代价 ### 13.7.3 阈值式生命系统 建议后续把状态效果从“单纯数值显示”升级成阈值逻辑： - `safe` - `strained` - `critical` - `collapsed` 每个阶段绑定不同惩罚： - 命中修正 - 额外时间成本 - 事件风险提升 - 治疗效率下降 - 逃跑成功率下降 ### 13.7.4 生命系统与 UI 主 HUD 只显示数值和条形图还不够，应该同步显示： - 当前生存威胁 - 原因解释 - 恢复路径提示 例如： - “脱水：口渴已压缩行动余量” - “疲劳：建议短休或回避高风险搜刮” ## 13.8 战斗系统设计 战斗不应该吞掉整个游戏，而应该是风险系统的一种表现。 ### 13.8.1 当前定位是对的 当前仓库使用“距离 + 回合 + 动作选择”的轻量模式，这是合理的。 ### 13.8.2 下一步建议 - 加入更清晰的命中区间提示 - 加入武器与状态联动的解释文本 - 区分“战斗结束”和“战后结算”两个阶段 - 把战斗弹窗升级为更完整的战斗面板 ### 13.8.3 战斗生命周期 1. 遭遇初始化 2. 玩家选择动作 3. 双方结算 4. 更新距离与生命 5. 写入战斗日志 6. 判断胜负/逃跑 7. 战后掉落与任务推进 ## 13.9 事件系统设计 事件是废土题材最重要的内容增幅器。 要求： - 事件必须能解释触发原因 - 事件必须能绑定状态、物品、任务和地点条件 - 事件必须能写出可追溯日志 - 事件应该偏向“抉择”而不是“随机弹窗骚扰” ## 13.10 在线存档设计 作为账号制在线游戏，存档系统应被视为引擎的一部分。 ### 13.10.1 必须保证 - 动作完成后立即得到权威新状态 - 存档和视图状态保持一致 - 任意时刻掉线后能恢复到最近稳定节点 ### 13.10.2 建议增加 - 多存档槽 - 存档版本迁移日志 - 后端动作审计 - 非法状态回滚策略 ## 13.11 当前代码层面的下一批重点 1. 当前已拆出的运行时模块： - `inventory-system` - `place-system` - `effect-system` - `survival-system` - `quest-system` - `view-projection` 2. 下一轮继续拆出： - `combat-system` - `event-system` 3. 为状态阈值、背包容量、战斗结算分别补单元测试 4. 继续强化基地仓储：分类、批量整理、仓储专属配方 5. 为背包、任务、蓝图面板补筛选与分类 6. 为状态系统引入更明确的阶段化惩罚定义 ## 13.12 结论 真正像游戏的关键，不是把更多信息摆上屏，而是： - 明确主循环 - 明确系统边界 - 明确高频与低频交互分层 - 明确权威状态和表现层职责 这也是本轮把背包、任务、蓝图、日志转成系统弹窗的原因。主 HUD 应该负责“让玩家立刻决定下一步”，而完整系统面板负责“深入管理和规划”。