posts
在线联机原型第 31 章导航：世界事件与动态天气
本章是「在线联机原型全集」第 4 层（概念原型层）的开篇，把视角从「一场对局」抬升到「一个持续运行的服务器世界」。本页给出第 31 章世界事件与动态天气（World Events & Weather System）的定位、六个核心验证目标（Job Scheduler、世界参数同步、全服广播扇出、快照恢复、定时幂等、客户端插值渲染）、推荐技术栈与真实文章入口，并串起前后相邻章节与相关专题，方便已经跑通单局同步、准备进入全服世界模拟的团队按图索骥。
第 31 章处在「在线联机原型全集」第 4 层（概念原型层）的开头。前面 30 章把单局对战、匹配、经济、社交、副本这些「对局内」能力逐个跑通之后，本章开始换一个尺度提问：当游戏世界不再因为一局结束而销毁，而是 7×24 持续运行时，全服共享的状态由谁驱动、怎么广播给成千上万在线玩家、天气这种连续变化的参数又怎么在保证一致性的前提下同步到每一端。这一章适合已经把实时对战写通、正打算做「世界感」的团队，也适合想先看清全服广播成本再决定架构的服务端负责人。
本章定位
| 项目 | 内容 |
|---|
| 全集层数 | 第 4 层（概念原型层） |
| 难度梯度 | 进阶。第 115 章为入门（单局同步与玩法），第 1630 章为进阶（对局外系统），本章起进入全服级世界模拟 |
| 前置章节 | 第 10 章 mini-SLG、第 18 章城市经营、第 20 章社交大厅、第 24 章动态赛事、第 30 章平台大厅 |
| 后续章节 | 第 32 章玩家驱动经济、第 33 章社交关系、第 34 章联盟战争 |
| 原型代号 | proto-31-世界事件与动态天气 |
| 形态 | 全服状态广播型，单篇文章的完整 PRD，覆盖架构、状态机、接口与验证清单 |
本章要验证的是「全服状态广播」这件事的最小可行模型：把定时驱动、状态广播、快照恢复三件事拆开，各自用一个可测量的指标卡住，而不是一上来就做完整的 MMO 世界。
核心验证目标
| 验证点 | 要回答的问题 | 判定标准 |
|---|
| Job Scheduler | 世界事件由谁触发，集群里如何保证同一时刻只有一个节点执行 | 多副本部署下事件不重复触发、不遗漏 |
| 世界参数同步 | 天气、时间等连续变量如何下发到全服 | 玩家操作到广播端到端 P99 低于 100ms |
| 全服广播扇出 | 单节点能推多少消息、多少在线 | 单节点吞吐高于 10000 msg/s，单实例并发高于 1000 |
| 状态快照与恢复 | 进程重启或崩溃后世界状态能否续上 | 重启后世界参数与事件进度不丢、不回退 |
| 定时任务幂等 | 重复触发或重放定时任务是否产生双倍收益 | 同一事件 ID 重复执行结果一致 |
| 客户端插值渲染 | 低频广播下画面是否仍然连续 | 客户端按插值平滑渲染，服务端保持权威 |
技术栈建议
- 语言：Go、Rust、Python 三者任选，PRD 默认推荐以 Go 承载调度与网关、以 Rust 或 Python 做生成与工具链。
- 协议：WebSocket over HTTPS 承载实时广播，gRPC 承载服务间调用与批量查询。
- 存储：Redis 保存世界状态热数据并承担 Pub/Sub 扇出；PostgreSQL 保存事件定义、周期表与执行日志；时序存储保存天气与参数的长时间序列，便于回放与调参。
- 调度：单机 cron 配合分布式锁，或直接使用 Kubernetes CronJob，二选一即可，重点是锁与幂等。
- 可观测：Prometheus 采集广播延迟与队列深度，Grafana 出图，事件执行日志进入统一日志管道。
本章文章
这篇文章内部按八个部分展开，阅读时可以直接跳到关心的那一段：
| PRD 小节 | 内容 |
|---|
| 一、概述 | 全服状态广播的一句话定义与本章要验证的能力 |
| 二、核心玩法与系统目标 | 产品体验、功能目标与四类验证重点 |
| 三、系统架构设计 | Gateway、广播 Service、State Manager、Event Bus、Persistence 五层划分 |
| 四、功能模块详解 | 基础通信、状态同步、输入校验、日志与监控 |
| 五、状态机与流程图 | 世界状态机与事件生命周期的时序图 |
| 六、事件与接口定义 | WebSocket 消息类型与 REST 会话接口 |
| 七、性能指标与优化 | 延迟、并发、吞吐、内存四项目标值 |
| 八、验证清单 | 可直接当作验收用例的五条清单 |
与相邻章节的关系
相关专题