技能模組的防外掛程式機制和同步機制優化

2022-03-14 20:51:36 字數 2935 閱讀 8969

遊戲在真實的環境中,有些特殊情況需要處理,本文介紹技能模組是如何處理人為作弊和現實中的網路導致的一些問題。

主要介紹四個部分:

防外掛程式網路延遲問題解決

網路卡頓和抖動

流量優化

注意,本文預設介紹的是玩家的技能處理,也就是技能的控制端在玩家的客戶端。對於控制端在伺服器的小怪,基本沒有前三個問題。

1.防外掛程式 

由於技能是客戶端先行,因此技能模組很多邏輯是放在客戶端的,由客戶端控制技能流程並且通知伺服器執行相應的功能。由此可見,技能是由客戶端發起的,服務端必須對收到的技能執行命令進行驗證以保證技能確實是可用的,防止玩家通過外掛程式重**送技能釋放訊息無限次釋放技能。

每個遊戲技能系統實現不同,可能對應的邏輯也不太一樣。基本原則是:

服務端儲存技能釋放可用性的相關資訊,比如技能cd、技能藍量等。

技能結算在服務端執行,客戶端管理技能執行流程。

服務端每次真正的釋放技能之前,對技能進行判斷是否可用。

服務端收到的技能執行訊息後,根據實現系統的規則進行相應驗證。

下面,以我們的技能系統為例,介紹我們是如何實現防外掛程式的。

在我們系統中,技能同步包括三類同步訊息:

服務端會接受到客戶端發來的這三種技能訊息,其中,服務端收到rootenter和actionenter訊息後,需要對訊息的真實性進行驗證,root_exit表示技能結束,和防外掛程式沒有關係,無需驗證。

由於技能的資訊都是以rootenter來控制的,比如技能cd、技能耗藍和沉默/暈眩等導致的技能是否可用,因此,當服務端收到rootenter的時候,首先要判斷這個技能是否真的可以釋放,判斷後進入相關邏輯。

actionenter是技能真正的執行訊息,技能模組並沒有方法判斷乙個執行節點(技能樹葉子節點)是否可用,因此,當收到actionenter的訊息時,只能根據root節點的資訊進行判斷。我們進行了兩種判斷:

基於以上機制,可以保證服務端收到的技能訊息只有合法的訊息才可以執行。

戰鬥模組的防外掛程式主要包括技能模組移動模組,把這兩塊解決外掛程式問題,戰鬥模組基本就能解決外掛程式問題了。

2.網路延遲 

在真實的網路環境中,網路延遲是難免的。造成的結果是,服務端執行邏輯一直晚於客戶端。這種網路延遲並不會造成錯誤,但是在網路延遲大的時候會造成表現和結算不能對應上。為了解決著這個問題,一般採取的方式是基於網路延遲時間讓服務端加快執行速度,去追趕客戶端。

以技能結算為例,當server端收到action_enter訊息後,根據當前時間和客戶端開始時間可以計算出網路延遲,將服務端的前搖時間減少兩個網路延遲,當客戶端收到技能結算訊息時,正好是客戶端的技能結算時間。

3.網路波動和卡頓 

對於手機遊戲來說,網路波動和卡頓也是難免的,這種情況造成的結果就是,原本按一定的順序以一定的時間間隔到達伺服器/客戶端的訊息,可能同時到達了伺服器/客戶端,或者時間間隔忽大忽小。

一般來說,當伺服器由於網路卡頓同時接收到多個技能開始執行的訊息時,可以通過兩種方式進行處理。

接到技能執行訊息後馬上執行,這樣導致的問題時可能在同一幀收到多條技能執行訊息,並且在同一幀執行多個技能。這個策略的好處是處理方式比較簡單,而且能讓伺服器盡快的跟客戶端同步。但是為了防止玩家使用外掛程式同時傳送多個技能執行請求,這個策略是不可行的。

當接收到多條技能執行訊息時,按序依次執行技能,每個技能的執行時間結束後,才執行下一條技能。這種策略的問題是,若伺服器的延遲與客戶端較大,如果玩家一直在不停的放技能,會導致伺服器與客戶端的延遲越來越大。

為了解決此類問題,我們在客戶端和服務端採取不同的處理方式。

3.1 proxy服務端(主控端是玩家控制的客戶端) 

伺服器是技能真正執行的地方,需要保證技能正確的執行。因此,服務端基於第二種方式解決網路卡頓,同時增加了一些邏輯,以保證服務端不會和客戶端延遲過大。

3.1.1 訊息佇列

proxy服務端以佇列的形式儲存下來收到的技能訊息並依次執行。

當服務端收到技能同步訊息後,就將訊息存入佇列,技能執行模組就根據佇列依次執行,其中,actionenter會執行一段時間,後搖時間點到達後結束。rootenter和root_exit對技能執行狀態進行控制。

3.1.2 防止服務端延遲過大

在某些情況下,服務端可能遲於戶端較長時間。比如網路卡頓,導致客戶端多次釋放技能的訊息同時到達服務端。為了解決這種問題,我們通過兩種機制,讓服務端追趕客戶端。

3.2 proxy客戶端 (主控端是玩家控制的客戶端或者是伺服器控制的怪物) 

客戶端只是執行技能的表現,在網路條件較差的情況下,我們只要保證遊戲的正確性(不出錯誤,不影響伺服器正確執行,網路條件變好後遊戲可以正確執行)即可,至於表現和使用者體驗,盡力就可以了。

在我們遊戲中,客戶端的proxy端採用的是接到訊息後馬上執行的策略。客戶端接到既能執行資訊,那麼就把之前正在執行的技能停止掉,然後執行新的就好了。

4.流量優化 

流量的優化基本上沒有太多通用的技巧,最基本也是最重要的就是:不要同步沒有意義的訊息。

這句話是廢話,但是也是流量優化的指導方向。聽起來很簡單,但是實現起來非常難,甚至想不同步冗餘資訊是不可能的。

為什麼說這件事很難,甚至是不可能的呢?

一,只有梳理清楚了執行邏輯,才能確定哪些同步訊息是必要的,哪些是冗餘的。執行邏輯一定要清晰。

二,比如一條訊息,某些情況是不用同步的,有的情況又要同步。那麼發,還是不發。再細節一點,比如乙個引數,有的情況不需要同步,有的情況需要同步。如果對每種情況進行特殊化編寫**,**可讀性可能較差,如果傳送乙個通用的同步訊息,可能訊息量比較大。那麼,做到什麼程度?大概做到遊戲流量可以接受的成都就好了。

還有些tips可以減小流量資訊,比如:

5.其他 

本文基於底層的訊息是保證訊息順序、保證不掉包、保證訊息不被篡改、保證訊息沒有重發的。這件事,本身實現起來可能更加複雜。

open falcon的外掛程式機制

plugin可以看做是對agent功能的擴充。對於業務系統的監控指標採集,最好不要做成plugin,而是把採集指令碼放到業務程式發布包中,隨著業務 上線而上線,隨著業務 公升級而公升級,這樣會比較容易管理。1.編寫採集指令碼 用什麼語言寫沒關係,只要目標機器上有執行環境就行,指令碼本身要有可執行許可...

執行緒的同步機制

1 執行緒安全與非執行緒安全 非執行緒安全是當多個執行緒訪問同乙個物件彙總的成員變數時產生的,產生的後果就是髒讀,就是指讀到的資料是被更改過的。而執行緒安全就是對獲取成員變數的值經過同步處理,不會再出現髒讀的現象。2 執行緒不安全的產生條件 a.存在多個執行緒 b.多個執行緒共享同乙個資源 c.對共...

jQuery中的外掛程式機制

我們在很多地方都用過外掛程式,外掛程式能讓我們操作某個東西變得異常方便,jquery也不例外,為了擴充套件jquery庫函式,jquery提供了兩種方式 來看一下例子 extend 注意每個方法之間要用英文逗號隔開 max function a,b var min min 5,7 console.l...