OpenFrontIO：一个基于真实地理的浏览器 RTS 游戏，它的代码比玩法更值得关注
项目速览：基于浏览器的在线 RTS 游戏。玩家在基于现实世界地理的各种地图中竞相扩展领土、建造建筑并结成战略联盟。
秒懂
- 它是什么？
- OpenFrontIO 是一个开源的在线即时战略游戏，玩家在真实世界地图上扩张领土、建造建筑、结盟对抗。它的代码结构、安装方式和许可证安排，对想研究或部署自托管 RTS 的工程师来说，比游戏本身更有嚼头。
- 适合谁用？
- OpenFrontIO 适合想研究浏览器实时战略游戏实现细节的开发者，尤其是对确定性模拟、客户端-服务器分离、以及 TypeScript 全栈架构感兴趣的人。它不适合想快速搭建一个商业游戏平台的人，因为 AGPL-3.0 要求修改后的源码必须公开，而且资产许可证是 CC BY-SA 4.0，两者叠加会让闭源部署变得困难。
- 能商用吗？
- 可以，但条件严格。AGPL-3.0 是网络 copyleft 许可证：如果别人通过网络使用你修改过的版本（例如作为托管服务），你必须以同一许可证向他们提供源代码。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
这个项目解决什么问题，谁需要它
OpenFrontIO 是一个在浏览器里运行的实时战略游戏，玩家在基于真实地理的地图上扩张领土、建造建筑、组建联盟。它解决的是两个问题：一是让玩家不用下载客户端就能玩到 RTS，二是给开发者提供一个完整的、可自托管的在线游戏参考实现。对于游戏开发者来说，这个仓库的价值在于它展示了如何用 TypeScript 写一个客户端-服务器分离的实时游戏，包括确定性模拟核心、网络同步、以及资产管线。对于普通玩家，它只是一个免费网页游戏。但如果你不是想研究代码，而是想搭一个自己的 RTS 服务，那它的许可证和部署方式会直接影响你的决策。
架构：客户端、核心、服务器三块分离
项目结构分成三个主要目录：/src/client 是前端游戏客户端，/src/core 是确定性游戏模拟，/src/server 是后端游戏服务器。这种分离是实时策略游戏的常见做法，核心模拟不依赖渲染，可以独立测试和回放。README 里提到，要回放一个生产游戏，你必须 checkout 到该游戏运行时的同一个 commit，gitCommit 值可以通过 https://api.openfront.io/game/[gameId] 查询。这个细节说明它的回放系统是建立在确定性模拟之上的，如果核心逻辑变了，旧回放就无法复现。另外，/zbin 目录是一个自包含的紧凑二进制线格式，用于 zod schema，这意味着网络传输的数据结构是用 zod 定义并序列化的。这种设计让前后端共享类型定义，减少同步错误，但也意味着如果你要改协议，必须同时改 zod schema 和 zbin 的序列化逻辑。
安装与运行：npm run inst 不是可有可无的细节
安装命令不是常见的 npm install，而是 npm run inst。README 明确警告不要用 npm install 或 npm i，因为这个脚本会执行 npm ci --ignore-scripts，它根据 package-lock.json 精确安装依赖，并且不运行任何脚本。这样做的目的是防止供应链攻击，因为 npm 安装时的生命周期脚本可能被恶意利用。这是一个值得记住的细节，尤其是你在部署到生产环境时。开发模式用 npm run dev，它会同时启动 webpack dev server 和游戏服务器，并自动打开浏览器，你可以用 SKIP_BROWSER_OPEN=true 禁用这个行为。如果只想跑客户端，用 npm run start:client，只跑服务器用 npm run start:server-dev。另外，npm run dev:staging 和 npm run dev:prod 可以连接远程 API 服务器，用于调试登录、购买或回放等场景。这些命令都写在 README 里，实际效果我没有验证过，但至少安装路径是清晰的。
开发工具链：Oxlint 和 ESLint 双管齐下
项目使用 Oxlint 和 ESLint 两个 linter，npm run lint 会同时运行它们，npm run lint:fix 会自动修复。这种双 linter 配置在 2026 年不算罕见，Oxlint 通常更快，ESLint 更成熟，两者互补。测试用 npm test，但 README 没有说明测试覆盖哪些部分，也没有给出具体的测试框架名。格式化用 npm run format，这通常意味着有 Prettier 或类似工具。对一个游戏项目来说，代码风格一致性很重要，因为核心模拟的确定性要求代码行为完全一致，任何微小的差异都可能导致不同客户端之间的状态不同步。所以，如果你要贡献代码，最好先跑一遍 npm run format 和 npm run lint，否则 CI 可能会拒绝你的合并请求。
许可证：AGPL-3.0 和 CC BY-SA 的双重约束
OpenFrontIO 的源代码采用 GNU AGPL v3.0 许可证，资产（如图像、地图）则采用 CC BY-SA 4.0。AGPL 意味着如果你修改了代码并部署为网络服务，你必须向用户提供修改后的源码。这对于想私有部署一个修改版游戏的公司来说是个硬约束。CC BY-SA 4.0 对资产也有类似要求，衍生作品必须同样以 CC BY-SA 分享。README 还要求修改版本必须保留版权声明，具体在页脚和加载屏幕上显示“© OpenFront and Contributors”。这意味着你不能简单地把这些声明删掉。如果你只是自用，不对外提供服务，AGPL 的约束会小一些，但资产许可证仍然可能限制你重新分发。这些是法律问题，我无法给出法律建议，但你必须意识到双重许可证会同时约束代码和内容，不能只考虑其中一个。
运行模式与回放：一个真实的生产调试场景
README 提供了连接生产服务器的开发模式，npm run dev:prod 可以让你在本地客户端上调试生产 API，比如登录流程或购买流程。但有一个限制：未完成的游戏不能在 localhost 上回放。这意味着如果你要调试一个正在进行的游戏，你做不到，只能等它结束。另外，回放要求本地代码版本与生产游戏运行的 commit 完全一致，否则模拟结果会不同。这种严格性说明 OpenFrontIO 的回放系统不是简单的录像，而是基于确定性模拟的重新执行。这既是优点也是缺点，优点是回放数据量小，且能精确复现逻辑，缺点是任何代码更新都可能破坏旧回放的兼容性。如果你想部署一个长期运营的服务器，你需要考虑如何管理版本迁移，或者接受旧回放无法播放的事实。
替代方案：与 WarFront.io 的关系和自建难度
OpenFrontIO 是 WarFront.io 的一个分支和重写，README 明确给出了 WarFrontIO 的 GitHub 链接。这意味着它不是从零开始的，而是继承了 WarFront 的架构和设计，然后用 TypeScript 重写了。如果你想找一个更轻量或更简单的 RTS 参考实现，可以直接看 WarFront.io，它可能更原始，代码量更少，但缺少 OpenFrontIO 的现代化工具链。另一个替代方案是自己从零写一个，但那样你需要处理网络同步、确定性模拟、资产加载等所有问题，而 OpenFrontIO 已经把这些打包好了。不过，OpenFrontIO 的规模可能很大，因为它包含了完整的游戏逻辑、地图数据、以及多语言支持（Crowdin 项目存在，说明有社区翻译流程）。如果你只需要一个简单的示例，这个项目可能显得过重。
编辑结论
OpenFrontIO 适合想研究浏览器实时战略游戏实现细节的开发者，尤其是对确定性模拟、客户端-服务器分离、以及 TypeScript 全栈架构感兴趣的人。它不适合想快速搭建一个商业游戏平台的人，因为 AGPL-3.0 要求修改后的源码必须公开，而且资产许可证是 CC BY-SA 4.0，两者叠加会让闭源部署变得困难。在决定采用之前，先确认你的部署场景是否接受 AGPL 的传染性，以及你是否愿意保留 README 中指定的版权声明。另外，安装时务必使用 npm run inst 而不是 npm install，这是项目刻意设计的供应链安全措施。如果你只是想玩一个 RTS 游戏，直接访问 openfront.io 即可，不需要碰代码。
社区笔记