人物同步

今天週末了,難得的雙休,終於有點時間來BB點事情了,嘿嘿,happy中。。 廢話少說讓我們進入正題吧~~

客戶端地圖格子的相關知識

在2.5D的MMO遊戲裏,角色是通過3D的方式渲染,2D的地圖是通過2D的方式顯示,所以在客戶端一般會有三個座標系:

a) 3D座標系:所有需要3D渲染的角色和光效,都以3D座標系中定位。
b) 2D座標系:用來定位和繪製固定的2D地圖元素,比如草皮、馬路等。
c) 3D座標裏的格子座標系:用來實現打掩碼、自動尋路和進行一些座標配置(比如NPC和怪物初始的位置)。使用格子座標,一是爲了方便打掩碼和進行自動尋路的計算(經典的A*尋路),二是爲了更方便查找座標的具體位置。

端遊使用的格子大小一般爲(64, 32),手遊的精確度要求低一些,可以用(100, 50),即3D座標系里長爲100寬爲50的矩形,即是格子座標系裏的一個座標。示例圖如下:

在這裏插入圖片描述

服務器同步大格子:9宮格

MMO遊戲裏,玩家要能看到地圖上所有角色的行爲,這就需要將其它玩家的動作都通過網絡數據同步過來。同步一般使用9宮格來確定,哪些玩家的數據要同步過來,然後自己的行爲要同步給哪些玩家。

服務器大格子的大小,以3*3的格子要總比客戶端顯示範圍要大一點爲原則。比客戶端大一點,是爲了預留資源加載的時間。

如下圖所示,綠色表示手機客戶端的顯示區域,當角色A在格子6中時,他可以看到1,2,3,5,6,7,9,10,11這9個格子裏的內容,那麼當他的狀態發生變化時,就需要同步給在這9個格子裏的所有玩家;同樣,當這9個格子裏的有玩家或者怪物的狀態改變時,也需要都同步給角色A。

在這裏插入圖片描述

當角色A移動到角色B所在的格子(7),則他將不再看到1,5,9這三個格子裏的內容(玩家和怪物),同時他將新看到4,8,12這三個格子裏的地圖內容。所以這個過程中,服務器要下發消息,刪除角色A所在的客戶端裏的1,5,9這三個格子裏的地圖內容,同時下發消息新增4,8,12這三個格子裏的地圖內容(類型一)。

推薦大格子具體的大小,按客戶端iPhone4S的960640分辨來制定,取屏幕長寬的1/2大一些,可以定爲640360。

角色的移動同步

地圖上角色的同步可以分爲位移的同步和行爲(比如放技能)的同步。這裏主要討論位移的同步方式。

位移同步的目的是爲了將自己的位置變化發給服務器,然後由服務器通過9宮格的方式轉發給周圍的其他玩家。

有的端遊是以客戶端格子的基本單位進行同步,當玩家從一個格子移動到了另一個格子時,就發消息通知給服務器。這種方式的缺點就是:

一、同步的延遲。玩家從一個格子開始移動,移動到另一個格子後,才發消息給服務器,服務器再轉發給其它客戶端,那其它客戶端的玩家位置,總會有一點延後。
二、當網絡不穩定的時候,很容易看到其它玩家不是均速的移動,比如玩家位置沒動,然後一下子瞬移到了下一個格子。

我們採用的方式,是同步狀態的變化,然後由客戶端來觸發服務器對大格子跨越的判斷:

d) 當玩家點擊地圖上某個地方,或者改變了搖桿方向,玩家的運行狀態就變化了,即向某個座標點移動。狀態變化的時候,客戶端就立即給服務器發消息,然後服務器進行轉發。這樣如果忽略了網絡的延遲,那這個角色在所有客戶端上,幾乎是同時開始移動。-優點

如果移動過程中沒有其它變化,則整個移動過程中只有一次消息同步。這裏需要處理一個問題,就是服務器需要知道這個角色什麼時候跨越了服務器的同步大格子,當角色跨越了同步大格子時,服務器就需要進行第二節裏(類型一)的操作。

e) 如何判斷角色的移動過程中跨越了同步大格子?,有的遊戲裏採用服務器判斷的方式,即根據角色的移動速度和方向,計算出跨越的時刻,然後使用一個Timer來觸發。同時如果服務器要取這個角色的當前位置,則需要通過運動公式來進行計算。這個方案相對精確一些,但比較複雜,服務器也需要爲每一個移動的角色設定一個Timer,對服務器的性能有所影響。

我們採用的方式,是由客戶端判斷角色每移動一小段距離,然後發消息通知服務器,服務器不對這個消息進行轉發,而只是判斷是否跨越了大格子,同時記錄下這個座標,作爲角色的當前位置。這一小段距離可以取100左右,值取得越大時,消息發送頻率越小,但服務器的同步大格子跨越判斷和角色當前位置就越不精確。

因爲是直接同步的運行狀態,所以客戶端發給服務器的座標單位是3D座標系裏單位,而不是3D座標系格子的座標單位。這樣就更加精確,一點點距離的移動,都能準確同步。

f) 同步運動狀態的一個問題是,如果玩家操作很頻繁,比如快死了逃跑時,瘋狂地點地圖,這時運動狀態變化的非常快,如果每個狀態的變化都同步給服務器,再加上廣播,那消息量是很大的。【壓力防護】

所以需要設置一個狀態同步的最短時間,當運動狀態變化很快時,則將狀態變化的消息緩存在客戶端,同時加一個Timer跟蹤。當馬上有新的狀態變化消息出來時,則進行替換,同時更新Timer。當沒有狀態變化的消息出來時,Timer到時間了就會觸發,將緩存的狀態變化的消息,發給服務器。

這樣通過消息緩存加上Timer的處理,既實現了運行狀態同步的最短時間限制,也保證了最後有效的運行狀態會稍晚一點點發送給服務器。

附錄: 其他遊戲的同步方案參考

  • 幀同步:絕大多數MOBA FPS賽車等強交互性遊戲如王者榮耀一般搭配UDP

在這裏插入圖片描述

  • 狀態同步:純服務器廣播模式的狀態同步,絕大多數MMORPG一般搭配TCP

在這裏插入圖片描述

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章