第 30 章与第 20 章是一组对照。第 20 章的社交大厅是「一个平台内多房间漫游」，本章的平台大厅与游戏中心是「一个平台内多游戏接入」——前者切换的是房间，后者切换的是游戏，路由粒度与身份边界都不同。它同样属于第 3 层概念原型，不追求实现细节，而是把单点登录与游戏实例路由这两件事的架构轮廓画清楚：网关如何统一接入、身份如何跨游戏复用、请求如何被路由到正确的实例。
本章定位
- 全集位置：第 30 章，属「内容与扩展」层，与第 29 章并列构成第 3 层概念原型的开篇两章。
- 难度梯度：概念设计阶段，偏架构与选型。读者应关注模块划分与接口约定，而非具体实现。
- 前置章节：第 20 章社交大厅（统一身份、会话与房间目录的既有设计），本章把其扩展到多游戏场景。
- 后续衔接：第 39 章跨平台对战与第 48 章平台经济系统分别从设备侧与商业侧延展平台能力。
核心验证目标
- 单点登录：玩家在平台完成一次认证后即可进入任意接入的游戏，身份与令牌在游戏间可信传递。
- 游戏实例路由：平台网关根据游戏标识、区服与负载把请求路由到正确的游戏实例，实例启停不影响其他游戏。
- 多游戏接入模型：以服务化方式接入新游戏，接入协议与生命周期管理标准化，降低新游戏上线成本。
- 架构维度：构建最小可运行的多游戏接入系统，核心逻辑与网络层解耦，便于测试与替换。
- 性能与扩展：支撑目标并发量下的延迟与吞吐，通过模块化设计与热更新能力支撑后续迭代。
- 安全维度：以服务端权威与输入校验防止数据篡改与作弊，跨游戏的身份与权限边界清晰。
技术栈建议
| 层次 | 推荐选型 | 说明 |
|---|---|---|
| 服务端 | Go、Rust 或 Python | 概念阶段可多栈并行验证 |
| 客户端 | 概念原型未限定 | 需支持游戏列表与启动入口 |
| 协议 | WebSocket over HTTPS 加 gRPC | 实时连接与服务间调用 |
| 架构 | 网关加服务加状态管理加事件总线 | 通过消息总线解耦各子系统 |
| 持久化 | 持久化层加回放日志 | 账号数据与行为追溯 |
本章文章
| 文章 | 核心内容 |
|---|---|
| 在线联机原型全集：第 30 章 平台大厅与游戏中心（Platform Hub & Game Center） | 多游戏接入型原型，核心验证单点登录与游戏实例路由，给出架构设计、技术选型与接口定义蓝图 |
与相邻章节的关系
- 上一章：第 29 章 UGC 内容创作与分享 同属第 3 层概念原型，聚焦内容生态而非平台接入。
- 下一章：第 31 章 世界事件与动态天气 重新回到具体玩法实现，是概念原型段落之后的第一次落地。
- 同题对照：第 20 章 社交大厅 是单平台多房间，本章是多游戏接入，两者共同定义平台层的能力边界。