游戏开发后端【免费下载链接】OpenFrontIOOnline browser-based RTS game项目地址https://gitcode.com/gh_mirrors/op/OpenFrontIO点击查看免费下载OpenFrontIO 是一款运行在浏览器中的即时战略RTS游戏其架构设计有一个核心前提游戏模拟逻辑不运行在服务器上而是每个客户端各自运行一份完全确定性的模拟。本文以仓库 docs/Architecture.md 为骨架结合src/core、src/server、src/client的源码实现完整拆解其四大组件划分、Intents→Turn→Execution 的同步机制、单 tick 的执行链路以及CDN_BASE静态资产分发方案。读完本文你将理解这套服务器只做协调、客户端各自模拟架构为什么能支撑多人实时对战以及如何配置 CDN 来部署这套系统。一、四大组件职责分离的边界整个系统被拆分为四个组件边界清晰组件职责关键实现client负责面向用户的渲染与 UI 交互src/client如 ClientGameRunner.ts 启动对局core确定性模拟纯 TypeScript/JavaScript无任何外部依赖必须完全确定性src/core核心入口 GameRunner.tsserver协调与转发 Intents/Requests即游戏服务器src/server核心为 GameServer.tsapi闭源的 Cloudflare Worker处理认证、战绩、游戏数据存储、装扮cosmetics与商业化不在本开源仓库内客户端通过 Api.ts、ServerList.ts 等与之交互值得强调的是api 是独立于开源仓库的闭源组件client 与 server 只通过 HTTP/WebSocket 与之通信这在部署时会直接影响服务器列表的获取方式参见 docs/MultiServer.md。二、模拟架构为什么每个客户端自己跑模拟传统多人游戏的权威服务器模型server-authoritative在这里被刻意放弃。文档明确指出游戏模拟逻辑不在服务器上运行。相反每个客户端运行各自的一份 core 实例这正是 core 必须确定性的原因。这套设计带来的直接收益是服务器不需要为每一份状态变更做权威裁决只需要做广播员——收集玩家的操作意图并等间隔分发给所有人。代价是确定性必须是硬约束所有客户端必须从相同的初始状态出发createGameRunner中以simpleHash(gameStart.gameID)作为 PseudoRandom 的随机种子见 GameRunner.ts保证随机数序列全局一致相同输入序列必须产生相同的状态演化因此每回合结束时客户端会上报状态哈希由服务器的 DesyncDetector.ts 比对任何不一致都会触发脱机desync处理。core 与 client 分线程运行core 与 client运行在不同线程——core 运行在Worker 线程中Worker.worker.ts 是模拟的宿主负责接收 turn、驱动executeNextTick()、把每 tick 的 GameUpdates 回传给主线程WorkerClient.ts 是主线程侧的封装通过postMessage与 Worker 通信Worker 模块以 Vite 的?workerinline形式内联为同源 Blob创建WorkerClient.ts这绕开了worker bundle 从 CDN 提供时new Worker(url)受跨域限制的问题动态 import 让约 700KB 的 base64 负载独立成 chunk只在开局时拉取不进主包。这样即使主线程被渲染、输入事件阻塞模拟依然能以稳定的节奏在后台推进。三、Intents玩家操作的统一抽象当用户执行任意操作进攻、建造、结盟、捐赠、禁运、移动军舰、快速聊天……时客户端并不直接修改任何状态而是创建一个Intent发送给服务器。Intent 的类型体系定义在 src/core/Schemas.ts 中是一个z.discriminatedUnion(type, [...])IntentSchema目前涵盖 25 种意图包括attack/cancel_attack/boat/cancel_boat进攻与撤退spawn出生点选择allianceRequest/allianceReject/breakAlliance/allianceExtension结盟与关系管理donate_troops/donate_gold/embargo/embargo_all资源与外交build_unit/upgrade_structure/delete_unit建造与基建move_warship/targetPlayer/emoji/quick_chat移动、表情与聊天mark_disconnected/toggle_pause/kick_player等会话与对局控制意图从客户端发出后服务器会为它补上来源客户端 ID形成StampedIntentIntent { clientID: ClientID }见 Schemas.ts。注意ADMIN_BOT_CLIENT_ID ADMINBOT这个占位符管理员机器人admin bot不是真实玩家但它发出的toggle_pause意图也需要合法 clientID这个值刻意选择为generateID()永不生成的字符组合以避免冲突。四、Turn服务器对意图的定时打包广播服务器不执行意图只做收集与分发。每个对局周期内服务器把收到的所有 StampedIntent 暂存在一个队列中当回合结束endTurn()由turnIntervalMs控制的定时器触发见 GameServer.ts时将当前意图队列打包成一个Turn推入服务器的 turn 历史this.turns同时清空意图队列通过type: turn的 ServerTurnMessagezbin 编码广播给所有活跃客户端。Turn 的 wire 结构定义在 TurnSchemaexport const TurnSchema z.object({ turnNumber: zb.uint(), // 回合序号 intents: StampedIntentSchema.array(), // 本回合全部带 clientID 的意图 hash: zb.float().nullable().optional(), // 回合结束时的状态哈希用于 desync 检测 });这个hash字段与 DesyncDetector.ts 配合服务器比对各客户端上报的每回合状态哈希不一致即判定脱机保证确定性约束被实际强制执行。五、完整流程从点击到渲染的 8 步链路文档给出了端到端的调用链结合源码可以完整还原每一步的实现Client 发送 Intent 到游戏服务器——客户端把用户操作编码为 Intent 经 WebSocket 发出Game server 发送 Turn 到 Client——服务器在endTurn()中打包并广播GameServer.tsClient 将 Turn 转发给 Core——主线程经 WorkerClient 把 turn 消息投递给 Worker 线程Worker 侧调用gameRunner.addTurn(turn)GameRunner.tsCore 为每个 Intent 创建 Execution——Executor.createExecs(turn)逐意图映射ExecutionManager.tsCore 调用executeNextTick()——GameRunner.ts 把本回合的 execution 注入游戏this.game.addExecution(...this.execManager.createExecs(...))再调用game.executeNextTick()所有 Executions 执行——在 src/core/execution 目录下有 50 个 Execution 实现如 AttackExecution.ts、ConstructionExecution.ts、NationExecution.ts 等tick 结束时 Core 发送 updates 给 Client——executeNextTick收尾时收集packedTileUpdates、packedMotionPlans、packedPlayerUpdates、packedAttackUpdates、nukeImpactTiles等压缩负载连同GameUpdates一起通过回调worker 场景下为game_update/game_update_batch消息发回主线程Client 渲染 updates——主线程的 GameView 接收更新并驱动 WebGL 渲染。几个值得注意的实现细节Execution 是唯一能修改游戏状态的实体。这意味着所有玩家操作、AI 行为、系统逻辑如 SpawnTimerExecution.ts、WinCheckExecution.ts、DoomsdayClockExecution.ts都必须收敛到 Execution 这条唯一的写路径上确定性才可审计、可验证无效意图也有兜底createExec在找不到对应玩家时会返回NoOpExecution而非抛错ExecutionManager.ts未知意图类型则直接抛错保证协议严格性Worker 的批量回传与让出机制Worker 在追赶catch-up时每批最多执行 4 个 tickMAX_TICKS_BEFORE_YIELD 4Worker.worker.ts避免独占任务队列、防止主线程消息洪泛快照恢复GameRunner支持snapshot()序列化当前 tick 边界的状态GameRunner.tscreateGameRunnerFromSnapshot可从快照重建模拟用于断线重连、回放见 src/core/snapshot。快照只包含已执行的 tick未执行的 turn 不会进入快照。六、静态资产与 CDNCDN_BASE的正确配置方式架构分工服务器只出壳CDN 出内容游戏服务器只负责两件事渲染index.html和提供 WebSocket。其余所有资产——Vite 的 JS/CSS bundle、图片、地图二进制文件、Worker 模块——都从CDN bucket提供docs/Architecture.md。这样做的意义是游戏服务器的带宽与算力只服务于高频的实时同步消息静态资源则享受 CDN 的全球缓存与就近分发。CDN_BASE的格式要求要求说明完整 origin如https://cdn.example.com不带路径不能写成https://cdn.example.com/assets不带尾部斜杠不能写成https://cdn.example.com/开发默认设为空字符串回退到同源same-origin在 example.env 中默认即为空CDN_BASEdeploy.sh 会透传该变量。双通道注入构建期 运行时CDN_BASE需要同时在两条路径上生效缺一不可构建期Vite build-time variable在 vite.config.ts 中读取env.CDN_BASE ?? 参与构建使产物 manifest 中直接包含绝对 URL同时构建插件会把 Vite 生成的/assets/...引用改写为cdnBaseRaw的 EJS 占位符对应 AssetUrls.ts 的rewriteAssetsForCdn只匹配src/href属性避免误伤内联脚本中的字面量运行时server runtime env var服务器通过 ServerEnv.ts 读取process.env.CDN_BASE ?? RenderHtml.ts 在请求时用cdnBaseRaw前缀 Vite 产出的/assets/...引用将 HTML 渲染为带 CDN 前缀的最终页面。CDN 前缀如何落到每一类资产上客户端侧统一的资产解析入口是 src/core/AssetUrls.tsbuildAssetUrl(path, assetManifest, baseUrl)manifest 命中时返回baseUrl directUrl去尾部斜杠拼接未命中则回退到同源路径AssetUrls.ts主线程从window.BOOTSTRAP_CONFIG.cdnBase读取Worker 线程没有window改从globalThis.__CDN_BASE__读取——该值由 Worker.worker.ts 在收到 init 消息时设置否则 Worker 内加载地图二进制等资产会静默绕过 CDNAssetUrls.ts 的注释明确说明了这一坑。地图与 Worker 模块的特殊处理地图二进制Worker 内通过FetchGameMapLoader以assetUrl(maps/${path})拉取Worker.worker.ts所以 CDN 上需要放置map-generator/assets/maps/下的全部地图文件含 100 张地图的 png 与 jsonWorker 模块虽然 Worker 代码本身也从 CDN 提供但通过?workerinline内联为 Blob 创建绕开跨域 Worker 限制见第二节。CI 配置CI 中通过vars.CDN_BASE注入到.github/workflows/{deploy,release}.yml确保每次部署的构建与运行时都使用同一套 CDN 配置。另外从 DesktopRelease.ts 的代码可以看出未设置CDN_BASE时桌面端Steam发布会收到警告——这类客户端会从应用自身 origin 拉取约 570MB 的资源而非 CDN生产中应始终配置该项。七、小结OpenFrontIO 的架构可以用一句话概括服务器负责定序与广播客户端负责确定性复算CDN 负责静态分发。四组件划分把易变的业务外挂api与必须严格确定的核心core彻底隔离Intent/Turn 机制让所有玩家的操作在同一全局顺序下进入各自的模拟配合状态哈希校验保证各端一致性而CDN_BASE的双通道配置让部署可以轻松地把所有静态负载转移到 CDN使游戏服务器专注服务于实时 WebSocket 同步。这套设计在浏览器 RTS 的约束下为零服务器权威计算 客户端一致性提供了一个完整可运行的范本其核心代码均可在本仓库src/core、src/server、src/client中逐一对照验证。赞分享游戏开发后端【免费下载链接】OpenFrontIOOnline browser-based RTS game项目地址https://gitcode.com/gh_mirrors/op/OpenFrontIO点击查看免费下载相关推荐OpenFrontIO浏览器实时战略游戏的技术架构深度解析OpenFrontIO浏览器实时战略游戏的技术架构深度解析 OpenFrontIO作为一款基于现代Web技术的实时战略游戏其技术架构展现了浏览器游戏开发的先游戏开发后端Highlight.js CDN 预构建资产包highlightjs/cdn-assets从 NPM 安装到 CDN 分发机制全解析Highlight.js CDN 预构建资产包highlightjs/cdn assets从 NPM 安装到 CDN 分发机制全解析 本指南围绕当前仓库教程文档人工智能FoundationDB 确定性模拟测试Simulation Testing内部架构深度解析FoundationDB 确定性模拟测试Simulation Testing内部架构深度解析 FoundationDB 以把分布式系统当成单进程程序来分布式数据库KV存储数据库后端上一篇Fathom Lite数据库连接池监控Prometheus下一篇CRMEB微服务链路追踪SkyWalking集成实践创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
