實時聯網遊戲後臺服務技術選型和挑戰(房間匹配與數據同步篇)

在此前的《網絡接入篇》中咱們介紹了實時聯網遊戲網絡接入相關內容,網絡接入層開發考驗的是開發者高性能網絡編程的功底,即解決C10K甚至C10M的能力。本文開始介紹遊戲邏輯層,因爲不一樣遊戲玩法千奇百怪,本文不涉及遊戲具體的業務邏輯,只探討在邏輯層實現中常常遇到的房間匹配和數據同步問題。算法

基於「房間」模式的聯網對戰遊戲,遊戲流程可分爲匹配(matchmaking)和 對戰(gameplay)兩個階段。匹配是指將在線」玩家中知足必定條件或要求的玩家「撮合」到一塊兒進行遊戲。對戰是指匹配到同一房間的客戶端(玩家)彼此創建通信信道(通常是經過鏈接到指定房間服務器,並經過房間服務提供的接口)來同步玩家操做、遊戲狀態等數據以支持同一房間內玩家對戰和互動。編程

房間匹配安全

通常來講房間匹配服務架構以下圖所示,其中和房間匹配相關的通信數據稱之爲「控制流」,房間內遊戲對戰通信數據稱之爲「數據流」,顯然兩種不一樣類型的流對帶寬、延時等指標容忍度不一樣,實際開發中應分別由不一樣服務器來承擔。 服務器

不一樣遊戲的匹配策略可能不太一致,例如常見的基於場次、基於等級、隨機匹配等。若是在房間建立時給房間打上必定數量的標籤,咱們即可以借鑑搜索引擎的倒排索引的思路來實現房間匹配算法。例如待加入的房間有: R1: [T1,T2,T3],R2:[T3],R3:[T1,T3],Rn:[T1,T2],這些房間不只會存在與全局匹配列表中,同時還會存在每一個標籤索引中。
假如Tag1表示「競技場」,要匹配「競技場」房間只需在Tag1索引隊列中匹配,同時爲了增長靈活性,匹配還應該支持由AND、OR、NOT、括號操做符組成的邏輯表達式,例如 T1 AND T2 的匹配候選集= INTERSEC(Tag1隊列, Tag2隊列),(T1 AND (NOT T2))的匹配候選集=DIFF(Tag1隊列, Tag2隊列)。

遊戲同步網絡

在《網絡接入篇》中介紹過網遊三種常見的網絡架構:C/S架構,P2P架構,還有一種C/M架構,分別以下圖所示。 架構

網絡遊戲中經過同步機制來保證各個客戶端遊戲世界的一致性,主流的同步機制有兩種:1 狀態同步; 2幀同步。狀態同步是指:由客戶端負責將玩家的操做發往中心節點 (服務器或master客戶端),由中心節點來負責遊戲邏輯計算並將計算結果廣播給客戶端,再由客戶端負責渲染遊戲結果。而幀同步的理論基礎是:遊戲邏輯由操做指令驅動,只要操做序列一致,那麼遊戲結果就應該一致。

下表咱們簡要對比了兩種同步機制的差別 post

遊戲類型、網絡條件是同步機制選擇時的首要考慮因素,對於同步頻次低,例如休閒回合制遊戲,鑑於數據流量小同時對遊戲邏輯安全性和以及防外掛能力有較高要求,通常大都採用狀態同步的方式。但對於操做要求比較高的,例如運動、賽車類遊戲裏涉及大量的物理邏輯運算,以及MOBA類對流暢性有更高要求的遊戲,幀同步是更好的選擇。
相關文章
相關標籤/搜索