4月8日消息，在多人參與的MMO類大型游戲中，需要考慮到技能系統(tǒng)的同步問題。當一個玩家釋放角色技能時，其他玩家也會釋放其他或相同的技能，這時候如何協(xié)調好技能流程控制就非常關鍵，這回影響到玩家的游戲體驗感。下面我們就來探討這一問題的解決方案。

　　此篇文章基于之前文章介紹的技能系統(tǒng)，主要介紹了如何實現MMO中的技能系統(tǒng)的同步。

　　這里所說的技能系統(tǒng)包括：技能流程和技能創(chuàng)生體(法術場、彈道和buff)。

　　首先介紹authority和proxy的概念，這兩個概念是基于單位unit的基礎上進行的區(qū)分。

　　authority表示單位的主控端，即此單位是由客戶端和還是服務端控制。對于玩家avatar，玩家本地的客戶端就是主控端。而對于怪物，他們的行為由服務端控制，主控端就是服務端。

　　proxy表示代理端，表示被主控端控制。如對于怪物來說，所有的客戶端都是proxy;對于玩家A來說，服務端和其他玩家的客戶端都是proxy。

　　0 技能同步的原則

　　1.客戶端先行

　　對于玩家控制的單位來說，玩家點擊按鈕釋放一個技能，客戶端首先響應，單位播放動作以及相應的技能特效。

　≥我了解，有的已上線游戲并沒有做客戶端先行，而是所有的技能執(zhí)行請求都發(fā)給服務端，然后由服務端發(fā)起。

　　這種模式技能流程控制會比較簡單，但是在網絡環(huán)境差的情況下，體驗可能差一些。但是，目測也是可以接受的。

　　2.技能流程以authority為發(fā)起端

　　玩家單位技能發(fā)起是由她的客戶端，怪物的技能發(fā)起是由AI也就是服務端。

　　3.技能結算在服務端發(fā)起。

　　技能真正的結算，比如法術場檢測、buff結算、傷害計算以及扣血等，統(tǒng)一在服務端處理。

　　1 技能執(zhí)行流程的同步

　　這里所說的技能執(zhí)行流程指的是技能樹的一個執(zhí)行節(jié)點的流程。

　　技能流程負責動作、特效以及技能結算，其中技能結算包括：釋放法術場、彈道或buff。

　　一個技能執(zhí)行節(jié)點的執(zhí)行流程中，需要同步的有兩個時間點：

　　技能開始：技能開始播放動作

　　技能結算：前搖結束，即能進入結算邏輯。這類同步消息往往并不是由技能本身去同步，而是技能生成了法術場、彈道等，他們去做相應的同步。

　　以玩家點擊技能按鈕開始釋放技能為例介紹技能同步流程，如圖所示：

　　1.主控端點擊技能按鈕，技能開始播放動作，主控端告訴服務端技能開始。

　　2.服務端廣播給所有的客戶端(多玩家嘲)，告知其他所有的客戶端此玩家開始執(zhí)行技能。其他客戶端收到指令后可是播放技能表現。

　　3.服務端延遲一段時間后，服務端開始進行技能結算，并且將結算結果通知客戶端。

　　延遲時間=技能前搖時間-上行-下行，下行一半不能確定，所以默認為上行=下行

　　另一種中庸的計算方式是：延遲時間=技能前搖時間-上行，防止要求技能前搖時間過長

　　使用此同步流程的表現為：

　　1.要求技能前搖時間>2*網絡延遲，若前搖時間短，則延遲時間=0，效果可能差一些

　　2.authority客戶端表現完美。

　　3.proxy client表現一般，即玩家A看玩家B的效果為：玩家B剛開始執(zhí)行技能動作，沒到前搖時間就進行了技能結算。但是因為玩家一般也不會過分關注其他玩家的動作，所以是可以接受的。

　　2 技能樹的同步

　　我上篇文章 一個MMORPG的常規(guī)技能系統(tǒng) 已經介紹，我們游戲使用的是技能樹來管理技能流程。那么就面臨一個問題，技能樹如何同步。

　　最簡單最暴力的方式，是客戶端和服務端同時管理技能樹，并且將其狀態(tài)同步。這樣，客戶端和服務端的技能樹狀態(tài)統(tǒng)一、完備。

　　后來發(fā)現，對于proxy端，并不需要完備的技能樹信息，最節(jié)省的方式是proxy根本不接受技能樹同步信息，只是接受播放動作、技能結算等信息。但這樣需要告訴其他proxy播放什么動作、特效等。

　　在我們系統(tǒng)中，技能同步包括三類同步消息:

　　技能根節(jié)點enter (root_enter): 表示一個大技能的進入。

　　技能葉子節(jié)點enter(action_enter): 表示一個技能樹的執(zhí)行節(jié)點的進入。

　　根節(jié)點exit(root_exit) ：表示大技能結束。

　　根節(jié)點保存一個完整技能的信息，需要和技能模塊外部交互，因此需要知道技能的開始和結束。

　　葉子節(jié)點的執(zhí)行代表著技能真正的執(zhí)行邏輯，也需要同步。

　　而對于其他節(jié)點，作為流程控制節(jié)點，只需要在主端確保技能流程無誤即可

　　后來這里進行了進一步的優(yōu)化，對于純根節(jié)點，主控端(玩家控制的客戶端)將信息同步給服務端，服務端不再同步給其他客戶端。有的技能樹只有一個節(jié)點，那么按照葉子節(jié)點的策略，主控端同步給服務端，服務端廣播給所有的其他客戶端。　

　　3 技能結算的同步

　　技能結算包括創(chuàng)建法術場、buff、彈道、技能直接傷害等。

　　法術場、彈道的同步

　　法術場、彈道的同步比較類似，他們都作為一個entity(網絡同步單元)在服務端創(chuàng)建，創(chuàng)建以后使用entity管理機制服務端通知客戶端他們的創(chuàng)建和銷毀。

　　以法術場為例，法術場的執(zhí)行和同步流程：

　　服務端發(fā)起創(chuàng)建一個法術場，并且通知客戶端。

　　法術場每隔一段時間結算一次，注意，法術場結算并不需要同步，每隔一段時間服務端執(zhí)行檢測邏輯，客戶端播放結算特效等。兩個邏輯互不依賴，也不要求時間一致。

　　當法術場結算時檢測到攻擊目標時，服務端計算攻擊傷害等信息，并將攻擊信息發(fā)給客戶端。

　⊥戶端收到傷害信息，客戶端播放相應的表現，如法術場受擊特效等。此處還包括屬于通用模塊的跳字等。

　　當服務端的法術場時間到了進行destroy時，使用entity的管理機制通知所有客戶端destroy法術場。

　　彈道的同步類似， 的區(qū)別就是法術場在某一位置使用攻擊盒檢測目標，而彈道是一個移動的子彈，客戶端表現是一個特效在飛，而服務端每隔一段時間根據飛行速度等使用膠囊攻擊盒去檢測目標碰撞。

　　由以上可以發(fā)現，法術場作為一個entity他的管理成本是比較高的，所以若策劃想出一些需求需要使用多個法術場實現，一般通過拓展法術場功能使用一個法術場來實現。

　　比如，策劃要做一個冰火兩重天法術場，即法術場在每次結算時使用不同的參數，第一次結算使用火焰，第二次結算是冰霜。若這種需求較少，可以使用兩個法術場，但是如果要冰火雷毒水電風魔奧術神圣*N重天，則代價太大。一般可以讓法術場支持每次使用不同的結算參數來結算即可。

　　buff同步

　　buff是附加在unit身上的東西(沒有unit就沒有buff，但是沒有unit可能有法術場)，所以不需要使用entity來同步。

　　服務端確定buff是否可以掛在unit上面。

　⊥戶端和服務端都維護一個buff管理器，掛buff的消息通知所有客戶端，客戶端負責表現，服務端負責結算即可。

　　4 傷害、屬性的同步

　　主要介紹下傷害的同步，順便附帶介紹下屬性同步。

　　對于傷害結算來說，技能、buff、法術場和彈道都可能造成傷害，當服務端發(fā)現造成傷害時，服務端首先根據技能信息計算傷害值，計算以后將傷害信息發(fā)送給所有客戶端，所有客戶端接到信息后首先播放技能傷害相關的表現，如受擊特效等，然后播放跳字等通用傷害客戶端表現。

　　也就是說，傷害值的同步其實就是簡單的rpc消息。

　　buff可能修改單位屬性，如攻擊力、攻擊速度等。這些屬性值的同步一般使用屬性同步，屬性同步的意思是當一個值改變了，底層自動把這個值同步給客戶端。

　　血量等信息值都是用屬性同步方式。

　　傷害計算和屬性模塊是一個重要且比較復雜的模塊(當然，若游戲數值非常簡單也可以很簡單)，后面我會寫文章詳細介紹這個模塊。

   投稿郵箱：chuanbeiol@163.com   詳情請訪問川北在線：http://m.sanmuled.cn/