乙個MMORPG的常規技能系統

2022-07-16 07:39:08 字數 4417 閱讀 7470

**自:

廣義的的說,和戰鬥結算相關的內容都算技能系統,包括技能資訊管理、技能呼叫介面、技能目標查詢、技能表現、技能結算、技能創生體(buff/法術場/彈道)管理,此外還涉及的模組包括:ai模組(技能呼叫者)、動作模組、尋路/移動模組以及人物屬性和傷害數值結算等。

先說下技能模組每個部分的職責和原理:

1、技能表

首先說下實現技能的基本思路。實現技能的基本思路就是通過策劃填寫**,來配製成某些技能,在執行某個技能的時候,分別去根據這些**中的內容,確定技能如何表現。基本的邏輯是:

if skilltable.get("技能動作"):

paly 動作

if skilltable.get("特效"):

if skilltable.get("法術場"):

建立法術場

....

複製**

2、技能資訊管理

unit建立時,此模組管理unit可使用哪些技能,比如遊戲中玩家可以選擇使用哪些技能。

遊戲中技能的公升級、技能加點、技能池管理都在這個模組。

此模組還需要管理技能等級/符文/裝備等外部模組對技能引數的修改。

3、技能呼叫介面

提供技能呼叫的介面供ai或玩家操作呼叫,呼叫時可以提供乙個目標unit,也可以不提供讓技能自己查詢。

提供三個介面:

此外,當前乙個技能正在執行時新的技能呼叫啟動,此時新的技能呼叫資訊會被儲存。一般來說,並不會把所有新的技能呼叫資訊儲存下來,那樣就成了乙個技能執行的序列。我們遊戲僅儲存乙個新的技能呼叫資訊。

總的來說,技能模組提供盡量少的介面供ai/ui等上層邏輯使用,這樣可以有效的與ai和ui進行解耦。

4、技能流程管理

技能流程這裡分兩點討論:

(1)乙個技能可能由多個子技能以一定的模式組合起來。

乙個技能常常由多個子技能以一定的模式組合而成,比如三段擊、比如衝鋒斬(先衝鋒、後斬)等,甚至還存在根據不同的環境選擇執行不同的子技能。分析策劃需求發現,技能可以分成乙個樹形結構,這個樹形結構非常類似行為樹,同樣可以將節點分為控制節點和執行節點,甚至可以包括condition節點。為此,我們專案引入乙個技能樹概念來描述這種資料結構。

(2)乙個具體的技能(技能樹執行節點)也有乙個固定的執行流程。這個流程一般為:前搖過程、前搖過程結束=技能結算時間點、後搖時間點。

4.1 技能樹

技能樹參考傳統行為樹的設計,使用樹形結構控制技能的執行流程。

技能樹和行為樹在結構上比較類似,但是在執行邏輯上有很大的不同。

首先,技能樹的重點並不是根據上下文選擇乙個合適的節點執行,而是以一定的策略將技能樹從頭到尾遍歷執行一遍。

其次,技能樹沒有tick的概念,而是基於**的,比如乙個順序節點,順序節點中乙個子節點執行完畢後,馬上通知順序節點,順序節點執行下乙個子節點,直至順序節點的最後乙個子節點執行完畢,順序節點就會通知父節點(如果有)它已經執行完畢。

此外,為了完成技能的一些需求,控制節點往往儲存更多的控制資訊來控制子節點的執行流程。具體的資訊根據策劃需求設定,比如順序結點包括原子屬性和迴圈屬性。如果乙個順序節點具有原子屬性,則這個順樹節點在執行的過程中並不會被end,只有全部子節點執行結束才可以end。

以我們遊戲中戰士普攻三段擊為例:

三段擊本身是乙個順序節點,當技能開始時,此節點順序執行三個子節點。對於第乙個子節點,它依然是乙個順序節點,首先衝鋒至目標單位身前,然後對目標單位進行揮砍。但是衝鋒節點還包括了乙個condition,若和目標的距離很近,則跳過衝鋒節點,直接揮砍。

普攻是乙個迴圈技能,這個技能只要玩家點著按鈕不放開,技能就會一直執行,因此根節點(普攻)是乙個具有迴圈屬性的順序節點。而對於子技能1(控制節點),他是乙個具有原子屬性的順序技能,即當單位正在衝鋒時,玩家鬆開按鈕,單位也會執行完揮砍後才會推出技能。

!關於技能樹的使用和思考

技能樹開始的設計思路是,有些技能的執行流程和行為樹類似,比如以一定的順序執行一系列子技能,比如根據不同的上下文確定技能的執行流程。簡單的說,技能樹的引入有以下好處:1.使技能模組可以獲得部分ai的能力,從而將和技能強相關的ai邏輯放在技能模組使技能模組和ai模組降低耦合,2.可以清晰的描述技能流程,3.使用樹增加拓展性,策劃可以設計出各種各樣複雜的技能。

關於好處1,舉個例子:屠夫boss的勾子技能可以將玩家拉過來,若成功的拉過來,boss會執行乙個攻擊子技能,否則不執行。通過這樣可以將勾人和攻擊作為兩個子技能構成技能樹,攻擊子技能有乙個condition過程,即判斷上乙個子技能是否成功。

技能樹在使用後慢慢發現一些問題,首先,技能樹的同步要求每個樹節點都進行同步,增加同步負擔,其次,技能本身並不會有太複雜的控制結構。

為此,後來我們對技能樹進行了優化:

最終的技能樹基本上是只有順序/隨機兩種控制型別節點,節點擁有較輕度的condition功能。

4.2 執行節點的技能流程

技能釋放時,目標可能已經由ai傳給了技能模組,也有可能沒有乙個目標,如玩家控制單位。

技能在釋放法術場、彈道的時候,重要的是技能的方向而不是技能目標一般來說,技能獲得乙個目標物件以後,技能的方向就是釋法者到目標的方向。

此外,技能方向可能需要一些配置,如前搖鎖定(前搖過程中目標移動,技能方向不變),ui可控制(技能釋放過程中,玩家可以通過控制ui控制技能的釋放方向)。

6、技能表現

技能的表現包括動作、特效、shader、音效等。其中,特效比較複雜,需要配置的內容也比較多。比如,有些特效掛在模型上,有的特效掛在場景裡。對於法術場的特效,分別可以分為法術場開始、結算、結束特效,分別在法術場開始時、結算時、結束時顯示。對於buff也類似。

7、彈道、法術場和buff等技能創生體

狹義的來說,技能只是負責技能的執行流程(技能樹管理以及技能流程管理),而技能真正的結算主要是由其創生體結算的。當技能前搖結束開始生效時,技能建立相應的彈道和法術場,法術場彈道擊中敵人時又有可能產生相應的buff。

一般來說,法術場是乙個場景的某塊檢測區域,每隔一段時間法術場檢測此區域的敵人,並對其攻擊結算。

彈道是一類子彈移動路徑的抽象,建立乙個彈道就表示乙個子彈特效沿這個彈道移動並檢測路徑上的敵人。

buff就是掛在單位身上的乙個具有持續時間的狀態,狀態對單位產生一些正面或者負面的影響,並且在此段時間內,每隔一段時間進行一次傷害結算 。

對於技能、法術場、buff之間的功能界定並不是很固定,比如技能能否直接對單位造成傷害,法術場能否對單位造成傷害,甚至技能只能建立法術場,法術場只能檢測目標不能造成傷害,只能掛buff,而所有的傷害都是通過buff來結算。當然,這樣並不一定好,一般來說,技能和法術場都可以對單位造成傷害。

總之,創生體功能的界定需要根據策劃需求、效率考慮等因素調整。

7.1 buff狀態

buff就是掛在單位身上持續一定時間的有益或者有害的狀態,這裡狀態=buff。

buff模組有個需要注意的是buff之間的相互關係,如排斥(a狀態在,b狀態掛不上去),清除(a狀態掛上去同時導致b狀態消失)等。

為了實現以上功能,最簡單的方式是在狀態a中直接填寫狀態關係狀態字段,如狀態a排斥狀態b/c/d/e...,a狀態清除狀態x/y/z...。

以上的實現方式有個問題,等遊戲做到後期,我們有成千上萬個buff狀態,那麼乙個魔法免疫狀態,策劃需要填表的排斥狀態可能成千上萬。

為了解決這個問題,可以使用分類的思想解決。定義某類狀態和另一類狀態之間的規則。

基於以上思想,引入乙個叫buff原子狀態的概念,原子狀態表示一類狀態,如減速、禁魔、魔免、懸空、暈眩、變羊等等等。

在給單位掛乙個新的buff的之前,查詢此buff持有的原子狀態和單位身上已經有的原子狀態之間的關係,根據單位身上已有的原子狀態判定新的原子狀態應該使用何種行為處理。

此處的何種行為,代表的就是原子狀態之間的規則,如排斥等。這些規則可以讓策劃填乙個名字叫「原子狀態關係」的表,此表是乙個n*n的二維陣列,n為遊戲中所有的原子狀態的數量。

原子狀態的數量遠遠小於buff的數量,所以可以很容易的定義這些規則。

7.2 法術場

法術場描述對一塊區域的影響,這塊區域可以每隔一段時間進行一次檢測,檢測這塊區域內的單位並且對單位進行結算。

法術場需要注意乙個問題,就是乙個法術場每次結算可能使用不同的引數進行結算,比如乙個技能,第一次結算對每個單位進行暈眩,第二次結算對單位進行傷害。

解決這種問題比較直接的方式是技能直接建立兩個法術場,每個法術場結算一次,第二個法術場建立具有延遲時間。但是這種方式有個問題,有可能策劃需求做乙個結算十次而且每次結算的引數都不同的法術場。那麼,乙個技能以一定的時間間隔建立是個法術場,同時法術場的管理具有一定的成本,從而導致效率的降低。

為解決這個問題,我們優化了法術場結算的實現機制,增加了一種新的法術場:序列法術場。這類法術場策劃可以配置法術場每次結算之間的時間間隔以及每次結算所使用的法術場引數。

寫乙個簡單的技能編輯器(前言)

還有大叔的這篇也有參考價值 本人分享這個的初衷是經歷了一次直接強擼類arpg遊戲的痛苦,策劃直接給不確定的需求,美術不經過策劃直接給資源給程式,然後程式就是一邊要和策劃確定和執行策劃需求,一邊還要和美術對相應的美術資源,不行再返工,浪費了太多了專案時間,這就造成了中間策劃和美術的一些溝通的架空,本人...

FQ也是開發人員的乙個技能

在 技術這十年 書中看到一段文字談到,前端web開發的過程中最值得參考的一些資料時,提到了yahoo,google,facebook,這些都是引領了技術潮流的公司,其中開源的內容和技術非常的多,如 yui hadoop 等等。而這三個公司其中兩個的 基本是無法訪問的,因此如果需要了解這些知識需要fq...

老闆也是乙個工種,也是一種技能

執行力強的員工是手腳的延伸 視野開闊專業的員工是大腦的延伸 老闆的技能是養活這些人 於是老闆要能夠比這些人知道賺錢的方法,看到賺錢的機會,能夠畫出大餅,做出看似不可能或不可思議的決定。因為同樣是看一篇文,其他人看的是精彩,而老闆要看到那些是可以借鑑的,那些是有問題的,那些是可以差異化的,然後根據分析...