181 lines
5.8 KiB
Markdown
181 lines
5.8 KiB
Markdown
下面是对 Rusted Warfare（《铁锈战争》）多人游戏中“当用户有公网 IP 创建房间，别人就能在游戏列表里看到房间名称”这一机制是怎么实现的 的详细解释（包括技术原理与背后机制）：
|
||
|
||
|
||
---
|
||
|
||
🧠 一、两种多人房间发布机制
|
||
|
||
在 Rusted Warfare 中，有 两类多人房间发布方式：
|
||
|
||
1. 官方公共服务器列表（Public Server List）
|
||
这是游戏自带的服务器列表，会显示开放给全世界玩家的房间。
|
||
当玩家开了公网可访问的房间，并且端口可达时，该房间有机会出现在这个列表里。
|
||
|
||
|
||
2. 中继服务器 + 房间码方式（Relay + Room Code）
|
||
如果房主没有公网可访问或没有设置端口映射，则可通过官方 Relay 中继服务器 创建房间，别人通过房间码加入，而不会出现在那个公共列表（或只显示在特定中继功能列表中）。
|
||
|
||
|
||
|
||
我们主要讨论第一种——当房主有公网 IP 或端口映射后，如何让其他玩家在列表里看到你创建的房间。
|
||
|
||
|
||
---
|
||
|
||
🌐 二、房间列表是集中管理的
|
||
|
||
1️⃣ 官方的“服务器列表服务”
|
||
|
||
当你在 Rusted Warfare 游戏中打开多人游戏界面时，客户端会 向官方服务器请求当前所有公开房间的列表。
|
||
游戏客户端向像 gs1.corrodinggames.com 或类似域名的中央列表服务发起 HTTP 请求拉取最新房间信息。
|
||
|
||
这个列表服务扮演了 目录中心（Directory Server） 的角色 —— 把所有已注册的公开房间汇总，并返回给玩家客户端。
|
||
|
||
|
||
---
|
||
|
||
🔄 三、房间注册流程（简化版）
|
||
|
||
当一个玩家创建房间且满足“公开可访问”的条件（比如端口已映射且对外可达）：
|
||
|
||
1. 客户端将房间元数据传给列表服务器
|
||
|
||
包含：
|
||
|
||
房间名称
|
||
|
||
房主的 IP/端口（公网 IP 或域名）
|
||
|
||
当前人数 / 最大人数
|
||
|
||
地图 /版本等信息
|
||
|
||
|
||
游戏客户端在创建房间后会 向官方列表服务发送一次注册请求。
|
||
|
||
|
||
2. 列表服务保存房间信息并返回确认
|
||
|
||
列表服务会把这个房间加入到它的数据库或内存缓存中。
|
||
|
||
|
||
3. 列表服务对外提供房间查询接口
|
||
|
||
当其他玩家打开服务器列表界面时，他们的客户端会请求这个列表（通常是 HTTP GET 接口），然后它就能看到你公开的房间。
|
||
这个 HTTP 接口返回的通常是一个JSON 或类似数据结构的数组，包含当前所有可用公开房间。
|
||
|
||
|
||
|
||
|
||
---
|
||
|
||
📌 四、为什么公网 IP / 端口映射是关键
|
||
|
||
对于列表服务和其他玩家来说：
|
||
|
||
列表服务需要知道你的房间可以从互联网上访问，
|
||
|
||
只有在别人连接你游戏服务器时能成功建立 TCP/UDP 连接时，才有意义地把这个房间展示出来。
|
||
|
||
|
||
这就是为什么：
|
||
|
||
✅ 如果你有“公网 IP + 正确端口映射”，你的房间就可能在官方列表里显示；
|
||
❌ 如果你不做端口映射、没有公网 IP、或被 NAT 屏蔽，则不会显示在那个列表里。
|
||
|
||
|
||
---
|
||
|
||
🧩 五、官方列表与中继房间的区别
|
||
|
||
方式 是否需要公网可达 是否在公共列表出现 可否不端口映射
|
||
|
||
官方公共房间 ✔️ 是 ✔️ 是 ❌ 不可
|
||
中继 + 房间码 ❌ 不一定 ❌ 不在普通列表（只有靠房间码加入） ✔️ 可
|
||
第三方服务器（如 RW-HPS） 看实现 可自己维护列表 视服务器部署
|
||
|
||
|
||
中继服务器是官方游戏从 1.14 版本开始加入的机制，用于解决 NAT/无公网 IP 的玩家联机困难，并通过房间码加入。
|
||
|
||
|
||
---
|
||
|
||
🛠 六、底层技术原理核心点总结
|
||
|
||
从技术角度，列表显示的实现背后主要依赖以下机制：
|
||
|
||
📍 1. 房间端口可达检测
|
||
|
||
只有公网可建立连接的主机才具备被列入公共房间列表的条件。
|
||
|
||
通常做法包括：
|
||
|
||
游戏客户端尝试 向中央列表服务注册自身的信息
|
||
|
||
列表服务可能会对该房间端口进行简单的可连通性检查
|
||
|
||
若能连通，就会把这个房间的信息保存起来
|
||
|
||
|
||
|
||
---
|
||
|
||
📍 2. 服务端列表 API
|
||
|
||
中央的列表服务对外开放 API，供玩家客户端定期拉取：
|
||
|
||
GET /servers/list
|
||
|
||
返回当前所有开放房间的元数据，比如：
|
||
|
||
[
|
||
{
|
||
"name": "MyRoom",
|
||
"ip": "203.0.113.99",
|
||
"port": 5123,
|
||
"players": 3,
|
||
"maxPlayers": 8,
|
||
"version": "1.15"
|
||
},
|
||
...
|
||
]
|
||
|
||
这才是游戏中看到的列表内容。
|
||
|
||
|
||
---
|
||
|
||
📍 3. 定期 Heartbeat（心跳）
|
||
|
||
为了让列表保持最新，游戏客户端通常会：
|
||
|
||
周期性发送心跳更新给列表服务
|
||
|
||
列表服务移除很久没有心跳的“死房”
|
||
|
||
|
||
这类机制在很多在线游戏中都很常见。虽然 Rusted Warfare 官方没有完全开源这个部分，但这也是一个通用实践。
|
||
|
||
|
||
---
|
||
|
||
📌 七、第三方房间列表服务器机制
|
||
|
||
像 rustlist 或 自定义列表服务（例如 GitHub 上的 Minxyzgo/rustlist）允许玩家部署自己的列表服务器。
|
||
这种第三方列表通过自身的 API 把房间信息存储下来，并以类似方式向客户端返回数据。
|
||
|
||
这说明官方的房间列表机制其实很可能是一个 中央 HTTP/REST 服务 + 客户端 Heartbeat 注册 + 房间元数据缓存/发布 的通用架构（类似很多其他游戏的匹配/目录服务）。
|
||
|
||
|
||
---
|
||
|
||
🧠 八、总结
|
||
|
||
📌 当你有公网 IP 并创建房间时游戏能把这个房间显示在列表里，是因为游戏客户端向官方的列表服务注册了你的房间元数据，列表服务缓存并对外公开这个房间信息，其他玩家通过 HTTP 请求获取并渲染列表。
|
||
|
||
📌 这个机制核心依赖于简单的 中心目录服务 + 注册/心跳 + 列表拉取 API 架构，与绝大多数在线游戏的公开房间列表机制类似。
|
||
|
||
|
||
---
|
||
|
||
如果你想，我也可以进一步解释 官方列表服务可能的具体协议（比如 HTTP API 细节、JSON 字段结构、心跳机制） 或 基于第三方服务器如何实现自己的列表系统。要不要我深入写一个模拟版接口规范？ |