virtheart
e783e6e533
- 添加游戏核心系统：战斗、任务、日志、随机数生成等 - 实现前端主界面、HUD、底部导航和各类卡片组件 - 添加用户认证系统与游戏存档持久化 - 配置项目基础架构与开发环境 - 补充文档说明与Docker部署支持
300 lines
7.2 KiB
Markdown
300 lines
7.2 KiB
Markdown
# 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`。
|
|
|
|
### 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. 把 `engine.ts` 继续拆成子模块：
|
|
- `time-system`
|
|
- `inventory-system`
|
|
- `combat-system`
|
|
- `event-system`
|
|
- `quest-system`
|
|
- `view-projection`
|
|
2. 为状态阈值、背包容量、战斗结算分别补单元测试
|
|
3. 引入基地仓库与背包转移逻辑
|
|
4. 为背包、任务、蓝图面板补筛选与分类
|
|
5. 为状态系统引入更明确的阶段化惩罚定义
|
|
|
|
## 13.12 结论
|
|
|
|
真正像游戏的关键，不是把更多信息摆上屏，而是：
|
|
|
|
- 明确主循环
|
|
- 明确系统边界
|
|
- 明确高频与低频交互分层
|
|
- 明确权威状态和表现层职责
|
|
|
|
这也是本轮把背包、任务、蓝图、日志转成系统弹窗的原因。主 HUD 应该负责“让玩家立刻决定下一步”，而完整系统面板负责“深入管理和规划”。
|