同步方案實(shí)踐)
1. 項(xiàng)目概述從零構(gòu)建一個可落地的多人同步方案最近在做一個休閑小游戲核心需求就是讓幾個朋友能在同一個房間里實(shí)時看到彼此的角色移動。市面上成熟的解決方案不少像 Photon、Colyseus 這些后端服務(wù)或者 Mirror、Fish-Net 這類 Unity 的框架功能強(qiáng)大但要么需要付費(fèi)要么學(xué)習(xí)成本不低對于想快速驗(yàn)證玩法、或者像我一樣想深入理解底層同步邏輯的開發(fā)者來說總感覺隔了一層。于是我把目光投向了 Cocos Creator 和 Tsrpc 這個組合。Cocos Creator 做 2D/3D 內(nèi)容開發(fā)足夠輕快Tsrpc 則是一個基于 TypeScript 的全棧 RPC 框架前后端共享類型定義開發(fā)體驗(yàn)非常流暢。最關(guān)鍵的是它足夠輕量、透明讓你能完全掌控網(wǎng)絡(luò)同步的每一個環(huán)節(jié)。這個項(xiàng)目就是我用 Cocos Creator 3.x 和 Tsrpc 搭建的一套房間制多人在線狀態(tài)同步的完整解決方案。它不追求大而全的 MMORPG 功能而是聚焦于最核心的“狀態(tài)同步”問題如何讓一個房間內(nèi)的所有玩家實(shí)時、平滑地看到其他玩家的移動和狀態(tài)變化。如果你正在尋找一個輕量級、可完全自托管、代碼清晰且易于二次開發(fā)的多人聯(lián)機(jī)原型方案特別是對于回合制、休閑競技、棋牌或者簡單的社交應(yīng)用場景這套方案會是一個非常好的起點(diǎn)。它幫你解決了網(wǎng)絡(luò)連接、房間管理、狀態(tài)廣播這些臟活累活讓你能更專注于游戲玩法本身的實(shí)現(xiàn)。2. 技術(shù)選型與架構(gòu)設(shè)計思路為什么是 Cocos Creator Tsrpc這個組合背后是一套非常務(wù)實(shí)的全棧 JavaScript/TypeScript 開發(fā)思路。2.1 為什么選擇 Tsrpc 作為網(wǎng)絡(luò)層首先看后端。對于中小型項(xiàng)目尤其是原型階段我們往往希望后端足夠簡單、快速迭代。Node.js 生態(tài)在這方面有天然優(yōu)勢。Tsrpc 的核心價值在于“類型安全”和“開發(fā)效率”。傳統(tǒng)的 WebSocket 開發(fā)前后端需要手動約定數(shù)據(jù)格式寫一堆 JSON 解析和校驗(yàn)代碼很容易出錯。Tsrpc 通過共享 TypeScript 類型定義讓前后端像調(diào)用本地函數(shù)一樣進(jìn)行網(wǎng)絡(luò)通信。你在后端定義好一個協(xié)議比如PtlJoinTsrpc 會自動生成前端的調(diào)用代碼包括完整的類型提示。這意味著如果你在后端修改了某個字段的類型前端 TypeScript 編譯時會直接報錯將運(yùn)行時錯誤提前到編譯時極大地提升了聯(lián)調(diào)效率和代碼健壯性。此外Tsrpc 內(nèi)置了 HTTP 和 WebSocket 雙協(xié)議支持對于狀態(tài)同步這種需要長連接、高頻數(shù)據(jù)交換的場景WebSocket 是更自然的選擇。它避免了 HTTP 輪詢帶來的延遲和性能開銷。注意Tsrpc 的“全?！碧匦砸馕吨阈枰獙⑶昂蠖斯蚕淼念愋投xProtocols放在一個獨(dú)立的目錄或npm包中。在項(xiàng)目結(jié)構(gòu)上我采用了shared文件夾來存放這些協(xié)議定義前后端都通過相對路徑或npm link引用確保類型定義唯一源。2.2 Cocos Creator 客戶端的考量Cocos Creator 3.x 對 TypeScript 的支持已經(jīng)非常完善其組件化開發(fā)模式與前端開發(fā)習(xí)慣一脈相承。選擇它一方面是看中其跨平臺發(fā)布能力Web、iOS、Android、小游戲等另一方面是其活躍的社區(qū)和相對溫和的學(xué)習(xí)曲線。對于多人游戲客戶端核心挑戰(zhàn)在于網(wǎng)絡(luò)狀態(tài)的渲染與本地操作的響應(yīng)。我們需要將接收到的網(wǎng)絡(luò)狀態(tài)其他玩家的位置平滑地呈現(xiàn)在畫面上同時又要將本地的操作搖桿輸入及時發(fā)送給服務(wù)器。這就要求客戶端有一個清晰的分層架構(gòu)網(wǎng)絡(luò)管理層、狀態(tài)同步層、實(shí)體表現(xiàn)層玩家角色需要解耦。2.3 整體架構(gòu)設(shè)計整個項(xiàng)目的架構(gòu)可以概括為“客戶端-服務(wù)器-客戶端”的星型拓?fù)?。服?wù)器作為權(quán)威狀態(tài)源和消息中轉(zhuǎn)站。客戶端 (Cocos Creator)網(wǎng)絡(luò)管理器 (NetworkManager)單例負(fù)責(zé) WebSocket 連接的建立、維護(hù)以及 API 調(diào)用和消息監(jiān)聽。游戲控制器 (GameController)場景的總控負(fù)責(zé)房間的加入/離開、創(chuàng)建/銷毀玩家實(shí)體、分發(fā)網(wǎng)絡(luò)狀態(tài)到具體的玩家控制器。玩家控制器 (PlayerController)每個玩家實(shí)體包括自己和其他玩家的控制器負(fù)責(zé)接收移動指令本地?fù)u桿或網(wǎng)絡(luò)同步的位置并驅(qū)動 Spine 動畫、更新位置。輸入模塊 (VirtualJoystick)虛擬搖桿將屏幕觸摸輸入轉(zhuǎn)換為標(biāo)準(zhǔn)化方向向量。服務(wù)器 (Node.js Tsrpc)房間管理器 (Room)核心類。管理所有房間Mapstring, RoomState處理玩家加入/離開維護(hù)每個房間內(nèi)所有玩家的狀態(tài)位置、縮放、名稱等。狀態(tài)廣播當(dāng)任一玩家的狀態(tài)發(fā)生變化如移動服務(wù)器會將該玩家所在房間的完整狀態(tài)快照廣播給房間內(nèi)所有其他連接。輸入監(jiān)聽監(jiān)聽每個客戶端發(fā)來的移動輸入指令更新服務(wù)器端該玩家的權(quán)威狀態(tài)然后觸發(fā)廣播。共享協(xié)議 (Shared Protocols)定義了前后端通信的所有數(shù)據(jù)結(jié)構(gòu)如ReqJoin加入房間請求、ResJoin加入響應(yīng)、MsgRoomState房間狀態(tài)消息、PlayerInput玩家輸入、RoomState房間狀態(tài)等。這是保證前后端一致性的基石。這種架構(gòu)的優(yōu)勢在于邏輯清晰服務(wù)器擁有最終決定權(quán)可以有效防止客戶端作弊雖然本項(xiàng)目原型階段未做嚴(yán)格校驗(yàn)。缺點(diǎn)是服務(wù)器壓力隨房間內(nèi)玩家數(shù)量增加而線性增長因?yàn)槊看螤顟B(tài)變化都需要廣播全量狀態(tài)。對于小房間如2-8人的休閑游戲這完全在可接受范圍內(nèi)。3. 核心實(shí)現(xiàn)細(xì)節(jié)拆解理解了整體架構(gòu)我們深入到代碼層面看看幾個最關(guān)鍵的環(huán)節(jié)是如何實(shí)現(xiàn)的。3.1 共享類型與協(xié)議定義這是 Tsrpc 項(xiàng)目的起點(diǎn)也是保證類型安全的關(guān)鍵。在shared/protocols/目錄下我們定義所有類型。GameState.ts- 核心狀態(tài)定義// 玩家輸入指令 export interface PlayerInput { playerId: string; scale: number; // 角色朝向通過縮放實(shí)現(xiàn)1為右-1為左 pos: { x: number, y: number }; } // 單個玩家的狀態(tài) export interface PlayerState { x: number; y: number; scale: number; name: string; } // 整個房間的狀態(tài)一個房間ID對應(yīng)一個RoomState export interface RoomState { players: { [playerId: string]: PlayerState; }; } // 當(dāng)前玩家信息 export interface CurrentPlayer { roomId: string; playerId: string; playerName: string; }這里定義了數(shù)據(jù)傳輸?shù)摹靶螤睢?。PlayerInput是客戶端發(fā)送給服務(wù)器的操作指令只包含必要信息誰往哪走。RoomState是服務(wù)器廣播給所有客戶端的權(quán)威狀態(tài)包含了房間里所有玩家的完整信息。PtlJoin.ts- 加入房間協(xié)議定義export interface ReqJoin { roomId: string; playerId: string; } export interface ResJoin { success: boolean; players: RoomState; roomId: string; currentPlayerId: string; currentPlayerName?: string; // 可選的用于顯示名稱 }Tsrpc 會根據(jù)這個文件在后端啟動時自動生成對應(yīng)的服務(wù)端處理代碼樁在前端生成強(qiáng)類型的 API 調(diào)用客戶端代碼ApiJoin.ts。你不需要手動寫任何序列化/反序列化代碼。3.2 服務(wù)器端房間管理與狀態(tài)同步服務(wù)器端的核心是Room類它管理著房間的生命周期和狀態(tài)同步。Room.ts- 房間業(yè)務(wù)邏輯import { WsConnection } from tsrpc; import { ServiceType } from ./shared/protocols/serviceProto; // Tsrpc生成的服務(wù)類型 export class Room { // 內(nèi)存存儲所有房間狀態(tài) private rooms: { [roomId: string]: RoomState } {}; // 存儲所有活躍連接 private conns: WsConnectionServiceType[] []; async joinRoom(request: ReqJoin, conn: WsConnectionServiceType): PromiseResJoin { const { roomId, playerId } request; // 1. 房間不存在則創(chuàng)建 if (!this.rooms[roomId]) { this.rooms[roomId] { players: {} }; } // 2. 在連接對象上標(biāo)記玩家和房間信息非常重要 conn.playerId playerId; conn.roomId roomId; this.conns.push(conn); // 3. 初始化新玩家狀態(tài)例如出生在隨機(jī)位置 const initX Math.random() * 10; const initY Math.random() * 10; this.rooms[roomId].players[playerId] { x: initX, y: initY, scale: 1, // 默認(rèn)朝右 name: Player_${playerId.substr(0, 4)} // 簡單生成個名字 }; // 4. 創(chuàng)建當(dāng)前玩家信息對象用于響應(yīng)客戶端 const currentPlayer: CurrentPlayer { roomId, playerId, playerName: this.rooms[roomId].players[playerId].name }; // 5. 廣播“有新人加入”的狀態(tài)給房間內(nèi)所有人包括自己 await this.broadcastGameState(roomId, RoomStateType.JOIN_STATE, currentPlayer); // 6. 監(jiān)聽這個連接的輸入消息 this.onMessageInput(conn); // 7. 返回成功響應(yīng)并附上當(dāng)前房間內(nèi)所有玩家信息 return { success: true, players: this.rooms[roomId], roomId, currentPlayerId: playerId, currentPlayerName: currentPlayer.playerName }; } }joinRoom方法做了幾件關(guān)鍵事房間管理、連接綁定、狀態(tài)初始化、廣播通知。其中將playerId和roomId綁定到conn對象上是后續(xù)定向廣播的關(guān)鍵。狀態(tài)廣播與輸入處理private async broadcastGameState(roomId: string, type: RoomStateType, data: any) { const msg: MsgRoomState { type, data }; // 找到該房間內(nèi)的所有連接 const roomConns this.conns.filter(conn conn.roomId roomId); // 并行發(fā)送提高效率 await Promise.all(roomConns.map(conn conn.sendMsg(room/RoomState, msg))); } private onMessageInput(conn: WsConnectionServiceType) { conn.listenMsg(player/Input, (msg: MsgInput) { const { roomId, playerId } conn; // 從連接中取出之前綁定的信息 if (!roomId || !playerId || !this.rooms[roomId]?.players[playerId]) { return; } // 1. 更新服務(wù)器權(quán)威狀態(tài) const playerState this.rooms[roomId].players[playerId]; playerState.x msg.input.pos.x; playerState.y msg.input.pos.y; playerState.scale msg.input.scale; // 2. 廣播更新后的整個房間狀態(tài)給所有人除了輸入者自己這里廣播給了所有人包括自己 // 廣播給自己可以實(shí)現(xiàn)“客戶端預(yù)測服務(wù)器回滾”中的權(quán)威狀態(tài)校正但本項(xiàng)目簡化處理統(tǒng)一廣播。 this.broadcastGameState(roomId, RoomStateType.INPUT_STATE, this.rooms[roomId]); }); }broadcastGameState是同步的發(fā)動機(jī)。每當(dāng)房間狀態(tài)變化它就打包成MsgRoomState消息發(fā)送給房間內(nèi)所有客戶端。onMessageInput監(jiān)聽每個玩家的輸入先更新服務(wù)器狀態(tài)再觸發(fā)廣播。這里采用了一種簡單的“狀態(tài)同步”模式服務(wù)器定期或事件觸發(fā)時將完整狀態(tài)快照發(fā)送給所有客戶端?？蛻舳擞眠@個快照來覆蓋本地其他玩家的狀態(tài)。實(shí)操心得連接管理this.conns數(shù)組存儲了所有連接。在實(shí)際項(xiàng)目中一定要實(shí)現(xiàn)leaveRoom邏輯在連接關(guān)閉onClose時從conns中移除該連接并從對應(yīng)的rooms狀態(tài)中移除玩家并廣播LEAVE_STATE消息。否則會導(dǎo)致內(nèi)存泄漏和狀態(tài)混亂。原示例代碼中提到了離開房間的方法這是必須完善的。3.3 客戶端網(wǎng)絡(luò)狀態(tài)接收與渲染客戶端的關(guān)鍵在于如何將接收到的網(wǎng)絡(luò)狀態(tài)平滑、正確地渲染到屏幕上。GameController.ts- 游戲總控與狀態(tài)分發(fā)客戶端的GameController是大腦它負(fù)責(zé)連接服務(wù)器、加入房間并監(jiān)聽服務(wù)器廣播的狀態(tài)消息。// 加入房間 joinRoom() { this.playerId this.generatePlayerId(); // 生成一個唯一ID network.ws.callApi(room/Join, { roomId: 99999999, playerId: this.playerId }).then(res { if (!res.isSucc) return; // 1. 創(chuàng)建房間內(nèi)已存在的其他玩家 const existingPlayers res.res.players.players; for (let id in existingPlayers) { if (id this.playerId) continue; // 跳過自己 this.createPlayerEntity(id, existingPlayers[id], false); // false表示是其他玩家 } // 2. 創(chuàng)建自己控制的玩家實(shí)體 this.createPlayerEntity(this.playerId, res.res.currentPlayerInfo, true); // true表示是自己 // 3. 開始監(jiān)聽房間狀態(tài)變化 this.startListeningRoomState(); }); } // 監(jiān)聽房間狀態(tài)消息 startListeningRoomState() { network.ws.listenMsg(room/RoomState, (msg: MsgRoomState) { switch (msg.type) { case RoomStateType.JOIN_STATE: this.onPlayerJoined(msg.data as CurrentPlayer); break; case RoomStateType.LEAVE_STATE: this.onPlayerLeft(msg.data as CurrentPlayer); break; case RoomStateType.INPUT_STATE: this.onRoomStateUpdated(msg.data as RoomState); // 處理移動同步 break; } }); }joinRoom成功后服務(wù)器會返回當(dāng)前房間內(nèi)所有玩家的信息?？蛻舳诵枰獡?jù)此實(shí)例化出其他玩家的角色。然后通過listenMsg持續(xù)監(jiān)聽三種狀態(tài)消息加入、離開、狀態(tài)更新。onRoomStateUpdated- 狀態(tài)同步的核心這是實(shí)現(xiàn)平滑同步的關(guān)鍵函數(shù)。當(dāng)收到服務(wù)器廣播的完整RoomState后需要更新本地所有其他玩家實(shí)體的位置。onRoomStateUpdated(roomState: RoomState) { for (let playerId in roomState.players) { // 跳過自己自己的位置由本地輸入和服務(wù)器校正決定本項(xiàng)目簡化自己也會收到廣播 if (playerId this.playerId) { // 這里可以添加客戶端預(yù)測與服務(wù)器回滾的邏輯 continue; } const serverPlayerState roomState.players[playerId]; const playerNode this.findPlayerNode(playerId); if (playerNode) { const playerCtrl playerNode.getComponent(PlayerController); this.syncPlayerPosition(playerCtrl, serverPlayerState); } } this.updateRenderOrder(); // 根據(jù)Y軸更新渲染層級 }syncPlayerPosition- 平滑插值與動畫處理直接設(shè)置node.position會顯得很生硬。我們需要使用 Cocos Creator 的 Tween 系統(tǒng)進(jìn)行插值實(shí)現(xiàn)平滑移動。syncPlayerPosition(playerCtrl: PlayerController, targetState: PlayerState) { const playerNode playerCtrl.node; const currentPos playerNode.position; const targetPos new Vec3(targetState.x, targetState.y, 0); // 1. 判斷是否需要移動避免微小抖動 if (Vec3.distance(currentPos, targetPos) 0.01) { return; } // 2. 停止該角色可能正在進(jìn)行的舊動畫 this.stopPreviousTween(playerCtrl); // 3. 更新朝向通過scale.x的正負(fù)實(shí)現(xiàn) playerCtrl.setScaleX(targetState.scale); // 4. 播放移動動畫如果當(dāng)前不是移動動畫 if (!playerCtrl.isPlayingWalkAnimation()) { playerCtrl.playAnimation(PlayerAnimState.WALK); } // 5. 使用Tween進(jìn)行位置插值 const tweenInstance tween(playerNode) .to(0.1, { position: targetPos }) // 0.1秒內(nèi)移動到目標(biāo)位置 .call(() { // 移動結(jié)束后播放待機(jī)動畫 playerCtrl.playAnimation(PlayerAnimState.IDLE); // 清理tween引用 this.removeTween(playerCtrl); }) .start(); // 6. 記錄tween實(shí)例以便后續(xù)中斷 this.saveTween(playerCtrl, tweenInstance); }這里有幾個關(guān)鍵點(diǎn)距離閾值避免因網(wǎng)絡(luò)浮點(diǎn)數(shù)誤差導(dǎo)致的微小抖動而頻繁播放動畫。動畫狀態(tài)管理移動時播放 Walk 動畫到達(dá)后播放 Idle 動畫。這需要與你的 Spine 或 Animation 組件狀態(tài)機(jī)配合。Tween 管理必須保存 Tween 實(shí)例的引用。因?yàn)榫W(wǎng)絡(luò)幀率比如每秒10-20次廣播可能高于 Tween 動畫的持續(xù)時間0.1秒。如果新的目標(biāo)位置到來時舊的移動動畫還沒播完需要先停止舊的 Tween再開始新的否則會出現(xiàn)“抽搐”現(xiàn)象。渲染層級在 2D 游戲中通常需要根據(jù)角色的 Y 坐標(biāo)動態(tài)調(diào)整渲染層級zIndex 或 siblingIndex讓后面的角色被前面的角色遮擋。updateRenderOrder方法就是遍歷所有玩家節(jié)點(diǎn)按 Y 坐標(biāo)從大到小排序并設(shè)置setSiblingIndex。3.4 本地輸入采集與發(fā)送本地玩家角色的移動由虛擬搖桿控制。輸入需要立即在本地得到響應(yīng)立即反饋同時發(fā)送給服務(wù)器。PlayerController.ts(本地玩家)update(deltaTime: number) { if (!this.isLocalPlayer) return; // 只有本地玩家才處理輸入 // 1. 從虛擬搖桿獲取輸入向量 const inputVec this.virtualJoystick ? this.virtualJoystick.getDirection() : Vec2.ZERO; // 2. 本地預(yù)測立即更新位置和動畫 if (!inputVec.equals(Vec2.ZERO)) { const moveSpeed 200; const deltaPos new Vec3(inputVec.x, inputVec.y, 0).multiplyScalar(moveSpeed * deltaTime); this.node.position this.node.position.add(deltaPos); // 更新朝向 this.spine.node.scaleX inputVec.x 0 ? 1 : -1; // 播放移動動畫 this.playAnimation(PlayerAnimState.WALK); // 3. 發(fā)送輸入給服務(wù)器 this.sendInputToServer(inputVec); } else { // 無輸入播放待機(jī)動畫 this.playAnimation(PlayerAnimState.IDLE); } } sendInputToServer(inputVec: Vec2) { const input: PlayerInput { playerId: this.playerId, scale: this.spine.node.scale.x, // 傳遞朝向 pos: { x: this.node.position.x, y: this.node.position.y } // 傳遞當(dāng)前位置 }; network.ws.sendMsg(player/Input, { input }); }這里實(shí)現(xiàn)的是最簡單的“客戶端預(yù)測”形式本地先移動再把結(jié)果告訴服務(wù)器。服務(wù)器收到后會用自己的權(quán)威狀態(tài)進(jìn)行廣播客戶端在收到廣播后會用服務(wù)器的權(quán)威位置來覆蓋本地其他玩家的位置。對于本地玩家本項(xiàng)目簡化處理也直接使用了服務(wù)器廣播的位置這會導(dǎo)致輕微的延遲感。更高級的做法是采用客戶端預(yù)測服務(wù)器權(quán)威回滾與調(diào)和但這套方案復(fù)雜度高得多本項(xiàng)目作為入門方案暫不涉及。注意事項(xiàng)發(fā)送頻率優(yōu)化在update中每幀發(fā)送輸入消息是不可取的會造成巨大的網(wǎng)絡(luò)流量。通常有兩種優(yōu)化方式1)節(jié)流每隔固定時間如50ms發(fā)送一次。2)狀態(tài)變化才發(fā)送記錄上一幀的輸入向量只有發(fā)生變化時才發(fā)送。推薦使用節(jié)流方式代碼更簡單網(wǎng)絡(luò)流量也可控。4. 項(xiàng)目部署與聯(lián)調(diào)實(shí)戰(zhàn)代碼寫完了如何讓它跑起來并讓多個客戶端真正連在一起這里涉及到本地開發(fā)調(diào)試和簡單的部署。4.1 環(huán)境準(zhǔn)備與項(xiàng)目啟動Node.js 環(huán)境確保安裝了 Node.js (建議 LTS 版本) 和 npm。創(chuàng)建 Tsrpc 后端項(xiàng)目npx create-tsrpc-applatest my-game-server cd my-game-server npm install選擇WebSocket和API功能。項(xiàng)目創(chuàng)建后將我們之前寫的shared協(xié)議目錄、Room.ts等業(yè)務(wù)代碼放入src目錄下相應(yīng)的位置。Cocos Creator 項(xiàng)目創(chuàng)建一個新的 3.x 項(xiàng)目。將客戶端腳本GameController,PlayerController等、UI 預(yù)制體搖桿準(zhǔn)備好。同樣需要將shared協(xié)議目錄鏈接或復(fù)制到客戶端項(xiàng)目中確保類型一致。共享協(xié)議的處理為了前后端共享類型最佳實(shí)踐是將shared目錄發(fā)布為一個私有 npm 包或者使用npm link在本地鏈接。對于快速原型也可以直接復(fù)制一份但務(wù)必保持同步。4.2 服務(wù)器啟動與配置在后端項(xiàng)目根目錄npm run devTsrpc 會啟動開發(fā)服務(wù)器默認(rèn)可能在http://localhost:3000。它會自動監(jiān)聽src目錄下協(xié)議文件Ptl*.ts的變化并實(shí)時生成前端的Api*.ts調(diào)用代碼。關(guān)鍵配置在src/index.ts或tsrpc.config.ts中// 創(chuàng)建WebSocket服務(wù)器 export const server new WsServer(serviceProto, { port: 3001, // WebSocket 端口避免與HTTP端口沖突 // ... 其他配置如JSON序列化、日志等級等 });確保 WebSocket 服務(wù)器的端口如 3001與客戶端連接地址一致。4.3 客戶端連接與測試在 Cocos Creator 的NetworkManager中配置服務(wù)器的 WebSocket 地址// NetworkManager.ts export class NetworkManager { public ws: HttpClient | null null; init() { const client new WsClient(serviceProto, { server: ws://localhost:3001, // 本地開發(fā)地址 // server: ws://你的服務(wù)器公網(wǎng)IP:3001, // 部署后地址 logger: console }); this.ws client; client.connect(); // 建立連接 } }本地多開測試Cocos Creator 編輯器運(yùn)行一個客戶端實(shí)例。然后使用瀏覽器的“無痕窗口”或不同的瀏覽器Chrome, Firefox, Edge再次打開游戲網(wǎng)頁這樣就可以模擬多個玩家同時在線。觀察控制臺日志和游戲畫面檢查角色是否都能正確創(chuàng)建、移動同步是否平滑。4.4 簡單的公網(wǎng)部署用于朋友間測試要讓外網(wǎng)的朋友也能連接你需要一臺有公網(wǎng) IP 的服務(wù)器云服務(wù)器如阿里云 ECS、騰訊云 CVM 等。服務(wù)器環(huán)境在服務(wù)器上安裝 Node.js。上傳代碼將后端項(xiàng)目代碼my-game-server上傳到服務(wù)器。安裝依賴并啟動cd my-game-server npm install --production npm run build # 編譯TypeScript npm start # 或使用 pm2 守護(hù)進(jìn)程pm2 start npm --name game-server -- run start安全組/防火墻在云服務(wù)器控制臺放行你配置的 WebSocket 端口如 3001 的 TCP 協(xié)議。客戶端修改連接地址將客戶端代碼中的server地址改為你的服務(wù)器公網(wǎng) IP 或域名例如ws://123.123.123.123:3001。構(gòu)建與分發(fā)在 Cocos Creator 中構(gòu)建 Web Mobile 或 Web Desktop 版本將構(gòu)建出的build目錄下的文件部署到任何一個靜態(tài)網(wǎng)站托管服務(wù)如 GitHub Pages, Vercel, Netlify 或你自己的 Nginx 服務(wù)器。你的朋友通過訪問這個網(wǎng)頁就能連接到你的游戲服務(wù)器了。重要提示這種部署方式僅適用于原型測試或極小規(guī)模的熟人社交。對于正式上線的產(chǎn)品你需要考慮1)使用 HTTPS/WSS現(xiàn)代瀏覽器要求安全上下文下才能使用 WebSocket。你需要為域名配置 SSL 證書。2)使用反向代理通常用 Nginx 將wss://yourdomain.com/game代理到本地的ws://localhost:3001并處理 SSL。3)進(jìn)程守護(hù)使用pm2或systemd確保 Node.js 進(jìn)程崩潰后自動重啟。4)負(fù)載均衡與水平擴(kuò)展單個 Node.js 進(jìn)程有連接數(shù)上限。當(dāng)用戶量增長時需要設(shè)計更復(fù)雜的架構(gòu)如分房間到不同進(jìn)程/機(jī)器并引入 Redis 等進(jìn)行狀態(tài)共享和消息廣播。5. 常見問題、優(yōu)化與擴(kuò)展方向在實(shí)際開發(fā)和測試中你肯定會遇到各種問題。這里總結(jié)一些典型問題和我踩過的坑。5.1 網(wǎng)絡(luò)延遲與同步抖動這是多人游戲永恒的主題。在本項(xiàng)目的簡單狀態(tài)同步模型下你會明顯感覺到其他玩家的移動有延遲并且在停止時可能會“回彈”一下。問題根源網(wǎng)絡(luò)傳輸需要時間RTT。從你發(fā)送輸入到服務(wù)器處理并廣播再到其他客戶端接收至少有1.5個 RTT 的延遲。如果網(wǎng)絡(luò)不穩(wěn)定還會出現(xiàn)丟包和亂序。優(yōu)化方案1插值與外推我們已經(jīng)使用了 Tween 插值讓移動平滑。還可以嘗試“外推”Extrapolation即根據(jù)其他玩家上一幀的速度和方向預(yù)測他當(dāng)前幀的位置等收到新的權(quán)威狀態(tài)后再糾正。這能減少“停頓感”但預(yù)測錯誤時會產(chǎn)生更明顯的“拉扯”。優(yōu)化方案2提高廣播頻率在服務(wù)器端可以不用每次收到輸入都廣播。而是設(shè)置一個固定的“心跳”間隔如每秒15-20次定時廣播房間狀態(tài)。這能穩(wěn)定網(wǎng)絡(luò)流量但會增加同步延遲。優(yōu)化方案3減少數(shù)據(jù)量廣播完整的RoomState在玩家多時會很大?？梢愿臑閺V播增量狀態(tài)Delta Update只發(fā)送發(fā)生變化的部分。PlayerInput也可以只發(fā)送方向向量由服務(wù)器計算最終位置。5.2 斷線重連與狀態(tài)恢復(fù)玩家網(wǎng)絡(luò)波動斷開后如何重新加入并恢復(fù)到斷線前的狀態(tài)服務(wù)器端在Room類中不能只在joinRoom時創(chuàng)建新狀態(tài)。需要實(shí)現(xiàn)一個reconnect協(xié)議。當(dāng)客戶端重連時發(fā)送舊的playerId和roomId服務(wù)器檢查該玩家狀態(tài)是否還存在可以設(shè)置一個“離線超時”時間比如30秒如果存在則將其綁定的conn更新為新的連接并下發(fā)當(dāng)前完整的房間狀態(tài)。客戶端網(wǎng)絡(luò)層NetworkManager需要監(jiān)聽連接斷開事件并嘗試自動重連。重連成功后調(diào)用reconnectAPI 而不是joinRoom。5.3 渲染層級Z-Order閃爍在updatePlayerLayers中我們根據(jù) Y 坐標(biāo)動態(tài)設(shè)置setSiblingIndex。如果多個玩家的 Y 坐標(biāo)非常接近或者在同一幀內(nèi)多個玩家的位置更新順序?qū)е屡判蚪Y(jié)果波動就可能出現(xiàn)層級閃爍。解決方案可以引入一個“層級容差”或“穩(wěn)定化”策略。例如只有當(dāng)兩個玩家的 Y 坐標(biāo)差值大于某個閾值如0.5時才調(diào)整它們之間的順序?；蛘呖梢悦?N 幀而不是每幀更新一次層級減少變化頻率。5.4 擴(kuò)展方向這個基礎(chǔ)框架可以像樂高一樣擴(kuò)展出很多功能房間列表與匹配實(shí)現(xiàn)一個大廳服務(wù)器管理所有房間信息房間號、人數(shù)、模式等?？蛻舳讼冗B接大廳獲取房間列表或進(jìn)行自動匹配再由大廳分配一個游戲服務(wù)器地址給客戶端連接。幀同步 vs 狀態(tài)同步本項(xiàng)目是典型的狀態(tài)同步快照同步。對于需要高度確定性、操作嚴(yán)格的游戲如 RTS、MOBA可以研究幀同步Lockstep。Tsrpc 同樣可以支持核心是服務(wù)器轉(zhuǎn)發(fā)所有客戶端的輸入指令每個客戶端根據(jù)相同的指令序列獨(dú)立計算游戲邏輯。更復(fù)雜的游戲狀態(tài)目前只同步了位置和朝向。你可以輕松擴(kuò)展PlayerState和RoomState加入血量、分?jǐn)?shù)、裝備、技能冷卻等屬性并在廣播邏輯中處理這些狀態(tài)的同步。輸入緩沖與指令排隊為了應(yīng)對網(wǎng)絡(luò)抖動可以在客戶端實(shí)現(xiàn)一個輸入緩沖隊列按服務(wù)器時間戳順序處理移動指令使同步更平滑。使用 Protobuf 替代 JSONTsrpc 支持 Protobuf 作為二進(jìn)制傳輸協(xié)議能顯著減少數(shù)據(jù)包大小提升傳輸效率適合移動網(wǎng)絡(luò)或更復(fù)雜的游戲狀態(tài)。這套 Cocos Creator Tsrpc 的方案最大的優(yōu)勢就是透明和可控。你能清楚地知道每一個數(shù)據(jù)包從哪里來、到哪里去出了問題可以快速定位。它可能不是性能最高、功能最全的解決方案但絕對是理解多人游戲網(wǎng)絡(luò)同步原理、并快速構(gòu)建出可玩原型的絕佳路徑。當(dāng)你吃透了這套流程再去使用那些成熟的商業(yè)框架時你會更加得心應(yīng)手因?yàn)槟阋呀?jīng)理解了它們背后在解決什么問題。 基于Cocos Creator與TsrPC的輕量級多人游戲狀態(tài)同步方案實(shí)踐
1. 項(xiàng)目概述從零構(gòu)建一個可落地的多人同步方案最近在做一個休閑小游戲核心需求就是讓幾個朋友能在同一個房間里實(shí)時看到彼此的角色移動。市面上成熟的解決方案不少像 Photon、Colyseus 這些后端服務(wù)或者 Mirror、Fish-Net 這類 Unity 的框架功能強(qiáng)大但要么需要付費(fèi)要么學(xué)習(xí)成本不低對于想快速驗(yàn)證玩法、或者像我一樣想深入理解底層同步邏輯的開發(fā)者來說總感覺隔了一層。于是我把目光投向了 Cocos Creator 和 Tsrpc 這個組合。Cocos Creator 做 2D/3D 內(nèi)容開發(fā)足夠輕快Tsrpc 則是一個基于 TypeScript 的全棧 RPC 框架前后端共享類型定義開發(fā)體驗(yàn)非常流暢。最關(guān)鍵的是它足夠輕量、透明讓你能完全掌控網(wǎng)絡(luò)同步的每一個環(huán)節(jié)。這個項(xiàng)目就是我用 Cocos Creator 3.x 和 Tsrpc 搭建的一套房間制多人在線狀態(tài)同步的完整解決方案。它不追求大而全的 MMORPG 功能而是聚焦于最核心的“狀態(tài)同步”問題如何讓一個房間內(nèi)的所有玩家實(shí)時、平滑地看到其他玩家的移動和狀態(tài)變化。如果你正在尋找一個輕量級、可完全自托管、代碼清晰且易于二次開發(fā)的多人聯(lián)機(jī)原型方案特別是對于回合制、休閑競技、棋牌或者簡單的社交應(yīng)用場景這套方案會是一個非常好的起點(diǎn)。它幫你解決了網(wǎng)絡(luò)連接、房間管理、狀態(tài)廣播這些臟活累活讓你能更專注于游戲玩法本身的實(shí)現(xiàn)。2. 技術(shù)選型與架構(gòu)設(shè)計思路為什么是 Cocos Creator Tsrpc這個組合背后是一套非常務(wù)實(shí)的全棧 JavaScript/TypeScript 開發(fā)思路。2.1 為什么選擇 Tsrpc 作為網(wǎng)絡(luò)層首先看后端。對于中小型項(xiàng)目尤其是原型階段我們往往希望后端足夠簡單、快速迭代。Node.js 生態(tài)在這方面有天然優(yōu)勢。Tsrpc 的核心價值在于“類型安全”和“開發(fā)效率”。傳統(tǒng)的 WebSocket 開發(fā)前后端需要手動約定數(shù)據(jù)格式寫一堆 JSON 解析和校驗(yàn)代碼很容易出錯。Tsrpc 通過共享 TypeScript 類型定義讓前后端像調(diào)用本地函數(shù)一樣進(jìn)行網(wǎng)絡(luò)通信。你在后端定義好一個協(xié)議比如PtlJoinTsrpc 會自動生成前端的調(diào)用代碼包括完整的類型提示。這意味著如果你在后端修改了某個字段的類型前端 TypeScript 編譯時會直接報錯將運(yùn)行時錯誤提前到編譯時極大地提升了聯(lián)調(diào)效率和代碼健壯性。此外Tsrpc 內(nèi)置了 HTTP 和 WebSocket 雙協(xié)議支持對于狀態(tài)同步這種需要長連接、高頻數(shù)據(jù)交換的場景WebSocket 是更自然的選擇。它避免了 HTTP 輪詢帶來的延遲和性能開銷。注意Tsrpc 的“全?！碧匦砸馕吨阈枰獙⑶昂蠖斯蚕淼念愋投xProtocols放在一個獨(dú)立的目錄或npm包中。在項(xiàng)目結(jié)構(gòu)上我采用了shared文件夾來存放這些協(xié)議定義前后端都通過相對路徑或npm link引用確保類型定義唯一源。2.2 Cocos Creator 客戶端的考量Cocos Creator 3.x 對 TypeScript 的支持已經(jīng)非常完善其組件化開發(fā)模式與前端開發(fā)習(xí)慣一脈相承。選擇它一方面是看中其跨平臺發(fā)布能力Web、iOS、Android、小游戲等另一方面是其活躍的社區(qū)和相對溫和的學(xué)習(xí)曲線。對于多人游戲客戶端核心挑戰(zhàn)在于網(wǎng)絡(luò)狀態(tài)的渲染與本地操作的響應(yīng)。我們需要將接收到的網(wǎng)絡(luò)狀態(tài)其他玩家的位置平滑地呈現(xiàn)在畫面上同時又要將本地的操作搖桿輸入及時發(fā)送給服務(wù)器。這就要求客戶端有一個清晰的分層架構(gòu)網(wǎng)絡(luò)管理層、狀態(tài)同步層、實(shí)體表現(xiàn)層玩家角色需要解耦。2.3 整體架構(gòu)設(shè)計整個項(xiàng)目的架構(gòu)可以概括為“客戶端-服務(wù)器-客戶端”的星型拓?fù)?。服?wù)器作為權(quán)威狀態(tài)源和消息中轉(zhuǎn)站。客戶端 (Cocos Creator)網(wǎng)絡(luò)管理器 (NetworkManager)單例負(fù)責(zé) WebSocket 連接的建立、維護(hù)以及 API 調(diào)用和消息監(jiān)聽。游戲控制器 (GameController)場景的總控負(fù)責(zé)房間的加入/離開、創(chuàng)建/銷毀玩家實(shí)體、分發(fā)網(wǎng)絡(luò)狀態(tài)到具體的玩家控制器。玩家控制器 (PlayerController)每個玩家實(shí)體包括自己和其他玩家的控制器負(fù)責(zé)接收移動指令本地?fù)u桿或網(wǎng)絡(luò)同步的位置并驅(qū)動 Spine 動畫、更新位置。輸入模塊 (VirtualJoystick)虛擬搖桿將屏幕觸摸輸入轉(zhuǎn)換為標(biāo)準(zhǔn)化方向向量。服務(wù)器 (Node.js Tsrpc)房間管理器 (Room)核心類。管理所有房間Mapstring, RoomState處理玩家加入/離開維護(hù)每個房間內(nèi)所有玩家的狀態(tài)位置、縮放、名稱等。狀態(tài)廣播當(dāng)任一玩家的狀態(tài)發(fā)生變化如移動服務(wù)器會將該玩家所在房間的完整狀態(tài)快照廣播給房間內(nèi)所有其他連接。輸入監(jiān)聽監(jiān)聽每個客戶端發(fā)來的移動輸入指令更新服務(wù)器端該玩家的權(quán)威狀態(tài)然后觸發(fā)廣播。共享協(xié)議 (Shared Protocols)定義了前后端通信的所有數(shù)據(jù)結(jié)構(gòu)如ReqJoin加入房間請求、ResJoin加入響應(yīng)、MsgRoomState房間狀態(tài)消息、PlayerInput玩家輸入、RoomState房間狀態(tài)等。這是保證前后端一致性的基石。這種架構(gòu)的優(yōu)勢在于邏輯清晰服務(wù)器擁有最終決定權(quán)可以有效防止客戶端作弊雖然本項(xiàng)目原型階段未做嚴(yán)格校驗(yàn)。缺點(diǎn)是服務(wù)器壓力隨房間內(nèi)玩家數(shù)量增加而線性增長因?yàn)槊看螤顟B(tài)變化都需要廣播全量狀態(tài)。對于小房間如2-8人的休閑游戲這完全在可接受范圍內(nèi)。3. 核心實(shí)現(xiàn)細(xì)節(jié)拆解理解了整體架構(gòu)我們深入到代碼層面看看幾個最關(guān)鍵的環(huán)節(jié)是如何實(shí)現(xiàn)的。3.1 共享類型與協(xié)議定義這是 Tsrpc 項(xiàng)目的起點(diǎn)也是保證類型安全的關(guān)鍵。在shared/protocols/目錄下我們定義所有類型。GameState.ts- 核心狀態(tài)定義// 玩家輸入指令 export interface PlayerInput { playerId: string; scale: number; // 角色朝向通過縮放實(shí)現(xiàn)1為右-1為左 pos: { x: number, y: number }; } // 單個玩家的狀態(tài) export interface PlayerState { x: number; y: number; scale: number; name: string; } // 整個房間的狀態(tài)一個房間ID對應(yīng)一個RoomState export interface RoomState { players: { [playerId: string]: PlayerState; }; } // 當(dāng)前玩家信息 export interface CurrentPlayer { roomId: string; playerId: string; playerName: string; }這里定義了數(shù)據(jù)傳輸?shù)摹靶螤睢?。PlayerInput是客戶端發(fā)送給服務(wù)器的操作指令只包含必要信息誰往哪走。RoomState是服務(wù)器廣播給所有客戶端的權(quán)威狀態(tài)包含了房間里所有玩家的完整信息。PtlJoin.ts- 加入房間協(xié)議定義export interface ReqJoin { roomId: string; playerId: string; } export interface ResJoin { success: boolean; players: RoomState; roomId: string; currentPlayerId: string; currentPlayerName?: string; // 可選的用于顯示名稱 }Tsrpc 會根據(jù)這個文件在后端啟動時自動生成對應(yīng)的服務(wù)端處理代碼樁在前端生成強(qiáng)類型的 API 調(diào)用客戶端代碼ApiJoin.ts。你不需要手動寫任何序列化/反序列化代碼。3.2 服務(wù)器端房間管理與狀態(tài)同步服務(wù)器端的核心是Room類它管理著房間的生命周期和狀態(tài)同步。Room.ts- 房間業(yè)務(wù)邏輯import { WsConnection } from tsrpc; import { ServiceType } from ./shared/protocols/serviceProto; // Tsrpc生成的服務(wù)類型 export class Room { // 內(nèi)存存儲所有房間狀態(tài) private rooms: { [roomId: string]: RoomState } {}; // 存儲所有活躍連接 private conns: WsConnectionServiceType[] []; async joinRoom(request: ReqJoin, conn: WsConnectionServiceType): PromiseResJoin { const { roomId, playerId } request; // 1. 房間不存在則創(chuàng)建 if (!this.rooms[roomId]) { this.rooms[roomId] { players: {} }; } // 2. 在連接對象上標(biāo)記玩家和房間信息非常重要 conn.playerId playerId; conn.roomId roomId; this.conns.push(conn); // 3. 初始化新玩家狀態(tài)例如出生在隨機(jī)位置 const initX Math.random() * 10; const initY Math.random() * 10; this.rooms[roomId].players[playerId] { x: initX, y: initY, scale: 1, // 默認(rèn)朝右 name: Player_${playerId.substr(0, 4)} // 簡單生成個名字 }; // 4. 創(chuàng)建當(dāng)前玩家信息對象用于響應(yīng)客戶端 const currentPlayer: CurrentPlayer { roomId, playerId, playerName: this.rooms[roomId].players[playerId].name }; // 5. 廣播“有新人加入”的狀態(tài)給房間內(nèi)所有人包括自己 await this.broadcastGameState(roomId, RoomStateType.JOIN_STATE, currentPlayer); // 6. 監(jiān)聽這個連接的輸入消息 this.onMessageInput(conn); // 7. 返回成功響應(yīng)并附上當(dāng)前房間內(nèi)所有玩家信息 return { success: true, players: this.rooms[roomId], roomId, currentPlayerId: playerId, currentPlayerName: currentPlayer.playerName }; } }joinRoom方法做了幾件關(guān)鍵事房間管理、連接綁定、狀態(tài)初始化、廣播通知。其中將playerId和roomId綁定到conn對象上是后續(xù)定向廣播的關(guān)鍵。狀態(tài)廣播與輸入處理private async broadcastGameState(roomId: string, type: RoomStateType, data: any) { const msg: MsgRoomState { type, data }; // 找到該房間內(nèi)的所有連接 const roomConns this.conns.filter(conn conn.roomId roomId); // 并行發(fā)送提高效率 await Promise.all(roomConns.map(conn conn.sendMsg(room/RoomState, msg))); } private onMessageInput(conn: WsConnectionServiceType) { conn.listenMsg(player/Input, (msg: MsgInput) { const { roomId, playerId } conn; // 從連接中取出之前綁定的信息 if (!roomId || !playerId || !this.rooms[roomId]?.players[playerId]) { return; } // 1. 更新服務(wù)器權(quán)威狀態(tài) const playerState this.rooms[roomId].players[playerId]; playerState.x msg.input.pos.x; playerState.y msg.input.pos.y; playerState.scale msg.input.scale; // 2. 廣播更新后的整個房間狀態(tài)給所有人除了輸入者自己這里廣播給了所有人包括自己 // 廣播給自己可以實(shí)現(xiàn)“客戶端預(yù)測服務(wù)器回滾”中的權(quán)威狀態(tài)校正但本項(xiàng)目簡化處理統(tǒng)一廣播。 this.broadcastGameState(roomId, RoomStateType.INPUT_STATE, this.rooms[roomId]); }); }broadcastGameState是同步的發(fā)動機(jī)。每當(dāng)房間狀態(tài)變化它就打包成MsgRoomState消息發(fā)送給房間內(nèi)所有客戶端。onMessageInput監(jiān)聽每個玩家的輸入先更新服務(wù)器狀態(tài)再觸發(fā)廣播。這里采用了一種簡單的“狀態(tài)同步”模式服務(wù)器定期或事件觸發(fā)時將完整狀態(tài)快照發(fā)送給所有客戶端?？蛻舳擞眠@個快照來覆蓋本地其他玩家的狀態(tài)。實(shí)操心得連接管理this.conns數(shù)組存儲了所有連接。在實(shí)際項(xiàng)目中一定要實(shí)現(xiàn)leaveRoom邏輯在連接關(guān)閉onClose時從conns中移除該連接并從對應(yīng)的rooms狀態(tài)中移除玩家并廣播LEAVE_STATE消息。否則會導(dǎo)致內(nèi)存泄漏和狀態(tài)混亂。原示例代碼中提到了離開房間的方法這是必須完善的。3.3 客戶端網(wǎng)絡(luò)狀態(tài)接收與渲染客戶端的關(guān)鍵在于如何將接收到的網(wǎng)絡(luò)狀態(tài)平滑、正確地渲染到屏幕上。GameController.ts- 游戲總控與狀態(tài)分發(fā)客戶端的GameController是大腦它負(fù)責(zé)連接服務(wù)器、加入房間并監(jiān)聽服務(wù)器廣播的狀態(tài)消息。// 加入房間 joinRoom() { this.playerId this.generatePlayerId(); // 生成一個唯一ID network.ws.callApi(room/Join, { roomId: 99999999, playerId: this.playerId }).then(res { if (!res.isSucc) return; // 1. 創(chuàng)建房間內(nèi)已存在的其他玩家 const existingPlayers res.res.players.players; for (let id in existingPlayers) { if (id this.playerId) continue; // 跳過自己 this.createPlayerEntity(id, existingPlayers[id], false); // false表示是其他玩家 } // 2. 創(chuàng)建自己控制的玩家實(shí)體 this.createPlayerEntity(this.playerId, res.res.currentPlayerInfo, true); // true表示是自己 // 3. 開始監(jiān)聽房間狀態(tài)變化 this.startListeningRoomState(); }); } // 監(jiān)聽房間狀態(tài)消息 startListeningRoomState() { network.ws.listenMsg(room/RoomState, (msg: MsgRoomState) { switch (msg.type) { case RoomStateType.JOIN_STATE: this.onPlayerJoined(msg.data as CurrentPlayer); break; case RoomStateType.LEAVE_STATE: this.onPlayerLeft(msg.data as CurrentPlayer); break; case RoomStateType.INPUT_STATE: this.onRoomStateUpdated(msg.data as RoomState); // 處理移動同步 break; } }); }joinRoom成功后服務(wù)器會返回當(dāng)前房間內(nèi)所有玩家的信息?？蛻舳诵枰獡?jù)此實(shí)例化出其他玩家的角色。然后通過listenMsg持續(xù)監(jiān)聽三種狀態(tài)消息加入、離開、狀態(tài)更新。onRoomStateUpdated- 狀態(tài)同步的核心這是實(shí)現(xiàn)平滑同步的關(guān)鍵函數(shù)。當(dāng)收到服務(wù)器廣播的完整RoomState后需要更新本地所有其他玩家實(shí)體的位置。onRoomStateUpdated(roomState: RoomState) { for (let playerId in roomState.players) { // 跳過自己自己的位置由本地輸入和服務(wù)器校正決定本項(xiàng)目簡化自己也會收到廣播 if (playerId this.playerId) { // 這里可以添加客戶端預(yù)測與服務(wù)器回滾的邏輯 continue; } const serverPlayerState roomState.players[playerId]; const playerNode this.findPlayerNode(playerId); if (playerNode) { const playerCtrl playerNode.getComponent(PlayerController); this.syncPlayerPosition(playerCtrl, serverPlayerState); } } this.updateRenderOrder(); // 根據(jù)Y軸更新渲染層級 }syncPlayerPosition- 平滑插值與動畫處理直接設(shè)置node.position會顯得很生硬。我們需要使用 Cocos Creator 的 Tween 系統(tǒng)進(jìn)行插值實(shí)現(xiàn)平滑移動。syncPlayerPosition(playerCtrl: PlayerController, targetState: PlayerState) { const playerNode playerCtrl.node; const currentPos playerNode.position; const targetPos new Vec3(targetState.x, targetState.y, 0); // 1. 判斷是否需要移動避免微小抖動 if (Vec3.distance(currentPos, targetPos) 0.01) { return; } // 2. 停止該角色可能正在進(jìn)行的舊動畫 this.stopPreviousTween(playerCtrl); // 3. 更新朝向通過scale.x的正負(fù)實(shí)現(xiàn) playerCtrl.setScaleX(targetState.scale); // 4. 播放移動動畫如果當(dāng)前不是移動動畫 if (!playerCtrl.isPlayingWalkAnimation()) { playerCtrl.playAnimation(PlayerAnimState.WALK); } // 5. 使用Tween進(jìn)行位置插值 const tweenInstance tween(playerNode) .to(0.1, { position: targetPos }) // 0.1秒內(nèi)移動到目標(biāo)位置 .call(() { // 移動結(jié)束后播放待機(jī)動畫 playerCtrl.playAnimation(PlayerAnimState.IDLE); // 清理tween引用 this.removeTween(playerCtrl); }) .start(); // 6. 記錄tween實(shí)例以便后續(xù)中斷 this.saveTween(playerCtrl, tweenInstance); }這里有幾個關(guān)鍵點(diǎn)距離閾值避免因網(wǎng)絡(luò)浮點(diǎn)數(shù)誤差導(dǎo)致的微小抖動而頻繁播放動畫。動畫狀態(tài)管理移動時播放 Walk 動畫到達(dá)后播放 Idle 動畫。這需要與你的 Spine 或 Animation 組件狀態(tài)機(jī)配合。Tween 管理必須保存 Tween 實(shí)例的引用。因?yàn)榫W(wǎng)絡(luò)幀率比如每秒10-20次廣播可能高于 Tween 動畫的持續(xù)時間0.1秒。如果新的目標(biāo)位置到來時舊的移動動畫還沒播完需要先停止舊的 Tween再開始新的否則會出現(xiàn)“抽搐”現(xiàn)象。渲染層級在 2D 游戲中通常需要根據(jù)角色的 Y 坐標(biāo)動態(tài)調(diào)整渲染層級zIndex 或 siblingIndex讓后面的角色被前面的角色遮擋。updateRenderOrder方法就是遍歷所有玩家節(jié)點(diǎn)按 Y 坐標(biāo)從大到小排序并設(shè)置setSiblingIndex。3.4 本地輸入采集與發(fā)送本地玩家角色的移動由虛擬搖桿控制。輸入需要立即在本地得到響應(yīng)立即反饋同時發(fā)送給服務(wù)器。PlayerController.ts(本地玩家)update(deltaTime: number) { if (!this.isLocalPlayer) return; // 只有本地玩家才處理輸入 // 1. 從虛擬搖桿獲取輸入向量 const inputVec this.virtualJoystick ? this.virtualJoystick.getDirection() : Vec2.ZERO; // 2. 本地預(yù)測立即更新位置和動畫 if (!inputVec.equals(Vec2.ZERO)) { const moveSpeed 200; const deltaPos new Vec3(inputVec.x, inputVec.y, 0).multiplyScalar(moveSpeed * deltaTime); this.node.position this.node.position.add(deltaPos); // 更新朝向 this.spine.node.scaleX inputVec.x 0 ? 1 : -1; // 播放移動動畫 this.playAnimation(PlayerAnimState.WALK); // 3. 發(fā)送輸入給服務(wù)器 this.sendInputToServer(inputVec); } else { // 無輸入播放待機(jī)動畫 this.playAnimation(PlayerAnimState.IDLE); } } sendInputToServer(inputVec: Vec2) { const input: PlayerInput { playerId: this.playerId, scale: this.spine.node.scale.x, // 傳遞朝向 pos: { x: this.node.position.x, y: this.node.position.y } // 傳遞當(dāng)前位置 }; network.ws.sendMsg(player/Input, { input }); }這里實(shí)現(xiàn)的是最簡單的“客戶端預(yù)測”形式本地先移動再把結(jié)果告訴服務(wù)器。服務(wù)器收到后會用自己的權(quán)威狀態(tài)進(jìn)行廣播客戶端在收到廣播后會用服務(wù)器的權(quán)威位置來覆蓋本地其他玩家的位置。對于本地玩家本項(xiàng)目簡化處理也直接使用了服務(wù)器廣播的位置這會導(dǎo)致輕微的延遲感。更高級的做法是采用客戶端預(yù)測服務(wù)器權(quán)威回滾與調(diào)和但這套方案復(fù)雜度高得多本項(xiàng)目作為入門方案暫不涉及。注意事項(xiàng)發(fā)送頻率優(yōu)化在update中每幀發(fā)送輸入消息是不可取的會造成巨大的網(wǎng)絡(luò)流量。通常有兩種優(yōu)化方式1)節(jié)流每隔固定時間如50ms發(fā)送一次。2)狀態(tài)變化才發(fā)送記錄上一幀的輸入向量只有發(fā)生變化時才發(fā)送。推薦使用節(jié)流方式代碼更簡單網(wǎng)絡(luò)流量也可控。4. 項(xiàng)目部署與聯(lián)調(diào)實(shí)戰(zhàn)代碼寫完了如何讓它跑起來并讓多個客戶端真正連在一起這里涉及到本地開發(fā)調(diào)試和簡單的部署。4.1 環(huán)境準(zhǔn)備與項(xiàng)目啟動Node.js 環(huán)境確保安裝了 Node.js (建議 LTS 版本) 和 npm。創(chuàng)建 Tsrpc 后端項(xiàng)目npx create-tsrpc-applatest my-game-server cd my-game-server npm install選擇WebSocket和API功能。項(xiàng)目創(chuàng)建后將我們之前寫的shared協(xié)議目錄、Room.ts等業(yè)務(wù)代碼放入src目錄下相應(yīng)的位置。Cocos Creator 項(xiàng)目創(chuàng)建一個新的 3.x 項(xiàng)目。將客戶端腳本GameController,PlayerController等、UI 預(yù)制體搖桿準(zhǔn)備好。同樣需要將shared協(xié)議目錄鏈接或復(fù)制到客戶端項(xiàng)目中確保類型一致。共享協(xié)議的處理為了前后端共享類型最佳實(shí)踐是將shared目錄發(fā)布為一個私有 npm 包或者使用npm link在本地鏈接。對于快速原型也可以直接復(fù)制一份但務(wù)必保持同步。4.2 服務(wù)器啟動與配置在后端項(xiàng)目根目錄npm run devTsrpc 會啟動開發(fā)服務(wù)器默認(rèn)可能在http://localhost:3000。它會自動監(jiān)聽src目錄下協(xié)議文件Ptl*.ts的變化并實(shí)時生成前端的Api*.ts調(diào)用代碼。關(guān)鍵配置在src/index.ts或tsrpc.config.ts中// 創(chuàng)建WebSocket服務(wù)器 export const server new WsServer(serviceProto, { port: 3001, // WebSocket 端口避免與HTTP端口沖突 // ... 其他配置如JSON序列化、日志等級等 });確保 WebSocket 服務(wù)器的端口如 3001與客戶端連接地址一致。4.3 客戶端連接與測試在 Cocos Creator 的NetworkManager中配置服務(wù)器的 WebSocket 地址// NetworkManager.ts export class NetworkManager { public ws: HttpClient | null null; init() { const client new WsClient(serviceProto, { server: ws://localhost:3001, // 本地開發(fā)地址 // server: ws://你的服務(wù)器公網(wǎng)IP:3001, // 部署后地址 logger: console }); this.ws client; client.connect(); // 建立連接 } }本地多開測試Cocos Creator 編輯器運(yùn)行一個客戶端實(shí)例。然后使用瀏覽器的“無痕窗口”或不同的瀏覽器Chrome, Firefox, Edge再次打開游戲網(wǎng)頁這樣就可以模擬多個玩家同時在線。觀察控制臺日志和游戲畫面檢查角色是否都能正確創(chuàng)建、移動同步是否平滑。4.4 簡單的公網(wǎng)部署用于朋友間測試要讓外網(wǎng)的朋友也能連接你需要一臺有公網(wǎng) IP 的服務(wù)器云服務(wù)器如阿里云 ECS、騰訊云 CVM 等。服務(wù)器環(huán)境在服務(wù)器上安裝 Node.js。上傳代碼將后端項(xiàng)目代碼my-game-server上傳到服務(wù)器。安裝依賴并啟動cd my-game-server npm install --production npm run build # 編譯TypeScript npm start # 或使用 pm2 守護(hù)進(jìn)程pm2 start npm --name game-server -- run start安全組/防火墻在云服務(wù)器控制臺放行你配置的 WebSocket 端口如 3001 的 TCP 協(xié)議。客戶端修改連接地址將客戶端代碼中的server地址改為你的服務(wù)器公網(wǎng) IP 或域名例如ws://123.123.123.123:3001。構(gòu)建與分發(fā)在 Cocos Creator 中構(gòu)建 Web Mobile 或 Web Desktop 版本將構(gòu)建出的build目錄下的文件部署到任何一個靜態(tài)網(wǎng)站托管服務(wù)如 GitHub Pages, Vercel, Netlify 或你自己的 Nginx 服務(wù)器。你的朋友通過訪問這個網(wǎng)頁就能連接到你的游戲服務(wù)器了。重要提示這種部署方式僅適用于原型測試或極小規(guī)模的熟人社交。對于正式上線的產(chǎn)品你需要考慮1)使用 HTTPS/WSS現(xiàn)代瀏覽器要求安全上下文下才能使用 WebSocket。你需要為域名配置 SSL 證書。2)使用反向代理通常用 Nginx 將wss://yourdomain.com/game代理到本地的ws://localhost:3001并處理 SSL。3)進(jìn)程守護(hù)使用pm2或systemd確保 Node.js 進(jìn)程崩潰后自動重啟。4)負(fù)載均衡與水平擴(kuò)展單個 Node.js 進(jìn)程有連接數(shù)上限。當(dāng)用戶量增長時需要設(shè)計更復(fù)雜的架構(gòu)如分房間到不同進(jìn)程/機(jī)器并引入 Redis 等進(jìn)行狀態(tài)共享和消息廣播。5. 常見問題、優(yōu)化與擴(kuò)展方向在實(shí)際開發(fā)和測試中你肯定會遇到各種問題。這里總結(jié)一些典型問題和我踩過的坑。5.1 網(wǎng)絡(luò)延遲與同步抖動這是多人游戲永恒的主題。在本項(xiàng)目的簡單狀態(tài)同步模型下你會明顯感覺到其他玩家的移動有延遲并且在停止時可能會“回彈”一下。問題根源網(wǎng)絡(luò)傳輸需要時間RTT。從你發(fā)送輸入到服務(wù)器處理并廣播再到其他客戶端接收至少有1.5個 RTT 的延遲。如果網(wǎng)絡(luò)不穩(wěn)定還會出現(xiàn)丟包和亂序。優(yōu)化方案1插值與外推我們已經(jīng)使用了 Tween 插值讓移動平滑。還可以嘗試“外推”Extrapolation即根據(jù)其他玩家上一幀的速度和方向預(yù)測他當(dāng)前幀的位置等收到新的權(quán)威狀態(tài)后再糾正。這能減少“停頓感”但預(yù)測錯誤時會產(chǎn)生更明顯的“拉扯”。優(yōu)化方案2提高廣播頻率在服務(wù)器端可以不用每次收到輸入都廣播。而是設(shè)置一個固定的“心跳”間隔如每秒15-20次定時廣播房間狀態(tài)。這能穩(wěn)定網(wǎng)絡(luò)流量但會增加同步延遲。優(yōu)化方案3減少數(shù)據(jù)量廣播完整的RoomState在玩家多時會很大?？梢愿臑閺V播增量狀態(tài)Delta Update只發(fā)送發(fā)生變化的部分。PlayerInput也可以只發(fā)送方向向量由服務(wù)器計算最終位置。5.2 斷線重連與狀態(tài)恢復(fù)玩家網(wǎng)絡(luò)波動斷開后如何重新加入并恢復(fù)到斷線前的狀態(tài)服務(wù)器端在Room類中不能只在joinRoom時創(chuàng)建新狀態(tài)。需要實(shí)現(xiàn)一個reconnect協(xié)議。當(dāng)客戶端重連時發(fā)送舊的playerId和roomId服務(wù)器檢查該玩家狀態(tài)是否還存在可以設(shè)置一個“離線超時”時間比如30秒如果存在則將其綁定的conn更新為新的連接并下發(fā)當(dāng)前完整的房間狀態(tài)。客戶端網(wǎng)絡(luò)層NetworkManager需要監(jiān)聽連接斷開事件并嘗試自動重連。重連成功后調(diào)用reconnectAPI 而不是joinRoom。5.3 渲染層級Z-Order閃爍在updatePlayerLayers中我們根據(jù) Y 坐標(biāo)動態(tài)設(shè)置setSiblingIndex。如果多個玩家的 Y 坐標(biāo)非常接近或者在同一幀內(nèi)多個玩家的位置更新順序?qū)е屡判蚪Y(jié)果波動就可能出現(xiàn)層級閃爍。解決方案可以引入一個“層級容差”或“穩(wěn)定化”策略。例如只有當(dāng)兩個玩家的 Y 坐標(biāo)差值大于某個閾值如0.5時才調(diào)整它們之間的順序?；蛘呖梢悦?N 幀而不是每幀更新一次層級減少變化頻率。5.4 擴(kuò)展方向這個基礎(chǔ)框架可以像樂高一樣擴(kuò)展出很多功能房間列表與匹配實(shí)現(xiàn)一個大廳服務(wù)器管理所有房間信息房間號、人數(shù)、模式等?？蛻舳讼冗B接大廳獲取房間列表或進(jìn)行自動匹配再由大廳分配一個游戲服務(wù)器地址給客戶端連接。幀同步 vs 狀態(tài)同步本項(xiàng)目是典型的狀態(tài)同步快照同步。對于需要高度確定性、操作嚴(yán)格的游戲如 RTS、MOBA可以研究幀同步Lockstep。Tsrpc 同樣可以支持核心是服務(wù)器轉(zhuǎn)發(fā)所有客戶端的輸入指令每個客戶端根據(jù)相同的指令序列獨(dú)立計算游戲邏輯。更復(fù)雜的游戲狀態(tài)目前只同步了位置和朝向。你可以輕松擴(kuò)展PlayerState和RoomState加入血量、分?jǐn)?shù)、裝備、技能冷卻等屬性并在廣播邏輯中處理這些狀態(tài)的同步。輸入緩沖與指令排隊為了應(yīng)對網(wǎng)絡(luò)抖動可以在客戶端實(shí)現(xiàn)一個輸入緩沖隊列按服務(wù)器時間戳順序處理移動指令使同步更平滑。使用 Protobuf 替代 JSONTsrpc 支持 Protobuf 作為二進(jìn)制傳輸協(xié)議能顯著減少數(shù)據(jù)包大小提升傳輸效率適合移動網(wǎng)絡(luò)或更復(fù)雜的游戲狀態(tài)。這套 Cocos Creator Tsrpc 的方案最大的優(yōu)勢就是透明和可控。你能清楚地知道每一個數(shù)據(jù)包從哪里來、到哪里去出了問題可以快速定位。它可能不是性能最高、功能最全的解決方案但絕對是理解多人游戲網(wǎng)絡(luò)同步原理、并快速構(gòu)建出可玩原型的絕佳路徑。當(dāng)你吃透了這套流程再去使用那些成熟的商業(yè)框架時你會更加得心應(yīng)手因?yàn)槟阋呀?jīng)理解了它們背后在解決什么問題。