如何設計一個易擴展的遊戲技能系統？

01-01

PC端如Dota、LOL、夢幻西遊等等。
手游端如刀塔傳奇。
可以很好的應對後續不斷添加的需求。

或者有哪些開源的可以學習的。

我個人對這個問題非常感興趣，因為我花了至少5年在設計和實踐（我自己經歷了大小7個項目，雖然大多最後因為其他原因都沒上）這樣一套機制並且可以說基本解決了這個問題！我並不想藏著他，我也和很多朋友分享了，同時也感謝他們提出了很多意見，包括細節和優化等方面，正因為互相之間的借鑒和交流，我到今天已經把這套機制歸納的非常好了，還是想把它分享給更多想做好遊戲的人，希望大家能進一步交流，把它更完善化，以形成一種規範，這套機制適用於任何類型的遊戲開發，因為他是一個很棒的思路。

首先分析一下可擴展性：我從一個設計師的角度來看，所謂的可擴展性是——你並不知道策划下一個設計的是什麼，但是你需要在儘可能不改動核心代碼的基礎上去把它實現了，並且在調試的時候（甚至是上線之後要做調整的時候），你可以並不傷筋動骨的去修改它。這裡除了你要有好的代碼規範外，還需要抽象一套機制來實現它。

最早開始想這套機制的動力是因為我在起凡工作，看了代碼之後我感覺是完全無擴展性的，當我想要設計一個新的英雄的時候，要去修改代碼已經幾乎是不可能的了，於是我便思考，如果我要做一套WoW的技能、buff系統，應該是怎樣的呢？於是我總結、歸納、抽象了這樣一套東西，並且最早在三國爭霸2項目中投入實際使用。

2年前我在GameRes發過相關的帖子：

[技術交流] Buff機制及其實際運用

AOE機制的DSL及其實際運用

[技術交流]不要用海量表項壓垮「技能流程」

實際上，好的策劃的腦洞是非常大的，你真不知道他會設計出什麼樣的技能，但你並不能說一些設計因為無法實現就理所應當被埋沒了，（我對策劃設計Dota類遊戲的思路要求是開放的，發揮想像力的：[設計思想] 遊戲系統設計思路的牢籠一味追求實用性）因此我想了這樣一個機制，他們的核心在於：

1，明確區別了AOEBuff和技能3塊，策劃應該從這個角度出發思考問題。

2，這既然是一套機制，你可以把它用在任何遊戲的框架當中。比如我要做一個Dota傳奇的卡牌遊戲，一樣可以用這套機制，但是核心在於——你的策劃要有能力歸納出遊戲中的回調點。

當然我們在使用這套機制的時候，邏輯上實現並沒有任何問題，但是我們一樣會遇到一些從邏輯變成動畫的困難，尤其是當我們的戰鬥在伺服器上一瞬間完成了，但是要把結果告訴客戶端嗎，並且有客戶端重新驗算一遍的時候，因此我在之後有總結了一套作法，來完成這個事情：

[技術交流]手游回合制遊戲戰鬥機制歸納式設計

這個解決的是，當你有各種有趣的buff，但是又想不大改客戶端的時候，你應該這樣去建立這個框架。你可以想像如果你做一個MT類型的遊戲，戰鬥是伺服器一瞬間的，但你又要客戶端重演，我們舉個例子：

比如我門設計了在MT類型遊戲中加入地形因素：可以有火海，火海每回合開始的時候對所有場上敵我英雄造成火焰傷害。

然後有個英雄是一隻鳳凰，鳳凰有2個被動效果：

1，受到火焰傷害的時候變成治療自己相當於傷害值的血量。

2，戰鬥中第一次死亡可以復活，回復最大生命值50%，如果在火海中則回復100%。

這樣一個英雄和地形，我們如何實現呢？如果你看了我上面的幾套機制，並且理解了，那基本沒有難度，你根本不需要硬編碼。但這裡有個問題，我如何讓客戶端重現？這就是上面這篇說的關鍵了。

希望以上這些我多年的經驗總結能夠對遊戲人有所幫助！

——————————2015 08 15 更新一條 ——————————————

看來感興趣的人還是不少的，於是我發了一些關於這套機制的實際運用方式在GameRes上，主要是想說——這套東西核心還是離不開策劃的設計的，同時放開腦洞去思考，才是最重要的：

[技術交流]通用型buff機制在實戰中的運用

謝邀，不過這塊好像也沒啥可說的，這幾年主要的改變就是「表格化」了。以前一個新技能或者一個新buf都需要編寫相應的代碼，規模上去以後，修改頻繁，這樣的方法經常造成開發效率底下以及bug多的問題。雖然有些遊戲引入了局部表格化的方式，但是還是不夠徹底，更多的遊戲使用了完全「表格化」配置。一共三張表：技能表，buf表和道具表。程序只實現欄位，修改和擴充都由策劃完成。程序做一個配置檢查工具，檢查策劃的 excel寫的對不對。每個欄位不但可以寫一些具體數值，還可以寫一些小的公式和腳本，比如：DF += 3。程序讀取表格的時候，將表格轉換為 python 或者 lua 腳本，運行時 import 即可，或者每次運行載入時再翻譯也沒啥。

限於知識產權，具體表格的欄位，不方便直接提供。但其實也沒啥，自己歸納總結一下，不斷擴充即可。一般情況，一個表格有100個欄位很正常，一個技能表格上千行也很正常。不當技能表格化，道具表格化，包括任務系統，新手教學，同樣可以表格化。程序要做的就是一個強大的表格解析系統，需要擴充時擴充欄位即可，剩下的事情，讓策劃來做吧，策劃寫錯了，QC自然會給策劃提 BUG，你時不時還可以問一下策劃，你的bug到底改好沒有？

技能系統核心功能有兩個，一個是定義表現流程，一個是處理邏輯效果。所謂表現流程就是角色在什麼時候播放什麼動畫、特效、音效，什麼時候判定傷害，什麼時候發射拋射物。所謂邏輯效果就是技能給目標造成多少傷害，附加什麼buff/debuff效果。

在我設計的技能系統中，核心基礎是lua腳本，通過lua腳本處理複雜的技能邏輯。

基礎內容有這麼幾個部分：

1、Actor，這個是角色本身，它不屬於技能系統，但是它要給技能系統開放足夠的介面，比如播放動畫、播放聲音、控制位移、造成傷害、添加buff等等

2、Skill，這個就是技能本身，它在合適的時機調用腳本中的相應函數，腳本中可以在OnCreate OnHit OnDeath OnHeroDeath OnSoldierDeath等事件中寫相應代碼。由於是腳本，所以代碼非常靈活，而由於限定了只處理技能相關功能，所以代碼也不會很複雜，有經驗的策劃絕對搞的定。

3、Buff，這個是技能效果的核心。它可以是有時限的，也可以是被動無時限的。在它對應的腳本中，定義了這個Buff會影響哪些角色屬性（如血量、暴擊、攻擊力等等）或者角色狀態（如眩暈、隱身、沉默等等），同樣，buff腳本也支持事件機制，在腳本的相應事件處理其邏輯功能，可以實現非常豐富的效果。

4、Modifier，這個是一個技能修改器。技能修改器可以修改技能的流程和效果（比如技能傷害增加、火球擊中人會爆炸等等），具體可以參考風暴英雄中的技能天賦系統。技能修改器並沒有腳本與之對應，一個技能如果支持某個修改器，需要在腳本中處理相應功能。

編輯器對策劃要求比較高，如果策劃素質堪憂，盡量寫死，給一些簡單的參數配置就好。此為前言。

說了前面，那麼一個技能，基本上就和AI差的不多了。有很多成熟的行為樹編輯可以作為參考，但是還是那句話，這個東西對你們策劃要求和程序要求都要高一些，如果能力不足會容易長期填坑。

切記不要，「我什麼都想試試」。行為樹和編輯器，可以看這個實現，https://github.com/TencentOpen/behaviac

以下思考主要基於桌游、卡游、TRPG，隨評論擴展，想到哪寫到哪：

一、設定基準不超限。

基準包括三條線，指導性、上限、下限。

高低級上下限距離盡量拉開點，多躍進，少漸進，注意多少和有無的差別。低級破上限或者高級破下限，意味著禁招和廢渣。

二、嚴控相關性和維度。

MTG里，一張好像有點強但實際沒什麼卵用，加一張莫名其妙，可能等於一個超強組合。兩張的bug級combo基本上都死在設計階段，但是三張、四張的組合呢？隱蔽性就大多了。想想電壓鑰匙，別忘了備忘夾。

DD三版，5級是個坎，因為LV5開始施法者就有3級法術了。3級法術最典型的兩個例子，火球術是AOE的起點，飛行術讓戰場進入立體。單體到群殺，平面到3D，這就是維度變化。

提升相關性和維度，會讓遊戲複雜程度急劇上升。參考某卡牌遊戲「一個武將技多了個子系統」。

再舉個例子：一張同時涉及相關性和維度的牌，《武裝飛騰》，2WW，生物結界，每操控一個平原就+1/+1帶飛行，關鍵時刻一腳踹爆。當然被《送終刀鋒》就是一換二，順帶一提《送終刀鋒》也可以算維度攻擊。

三、多加減，少乘除。

+5點火焰傷害，走到底也是5點。

+5%看上去不多，這裡加點那裡加點，每次都不多，乘起來就爆炸了。

所以很多遊戲里兩個+10%等於+20%而不是+121%。

四、謹慎調整暴擊率。

關聯前一條。

傷害加成無上限，你可以搞出1300%的傷害。

暴擊率加成有上限，最多就是100%。

尤其那些跟暴擊相關的特效，一旦100%觸發就非常可怕。

還有怪物，是否跟英雄共用一套計算流程。英雄攻擊單個怪物的次數有限，怪物攻擊英雄的累計次數無限。英雄打個暴擊秒了怪物皆大歡喜，怪物暴擊秒英雄事情就大條了。

技能沒什麼框架，只是有很多欄位罷了

比如 cd 施法距離釋放動畫飛行動畫等等

其實遊戲技能不是一直不是什麼難點，畢竟根據每個屬性實現邏輯就好了

技能真正麻煩一點是其實是所謂的「效果」

因為從很久以前，遊戲設計的時候就把效果這個概念添加進來了

對於遊戲戰鬥對象主體，我們暫時叫做BattleAgent簡稱BA。

影響BA的數據有很多，比如移動速度攻擊力基礎屬性等等，影響的入口也有很多

技能

buff/被動技能

裝備

強化

寶石

魂

等等，而這些實際上從影響結果沒什麼區別

首先我們先談區別，對於這些數值影響，其實區別只有入口或者說是作用的方式

技能是BA(castor)對BA(target)釋放造成的瞬間數值影響

buff是castor對BA(target)安裝後造成的持續數值影響，分為按時觸發瞬發和持續修改數值

裝備是特定容器對BA持續修改數值

所以這裡遊戲開發者們抽象出了效果這個概念

對與效果而言，只存在2個行為

1 對BA產生數值影響

2 對BA撤銷數值影響

所以效果最終定義為

interface Effect { void cast(BattleAgent target); default void reverse(){ } }

而對於其他功能實體來說，就可以簡化為效果的容器

interface EffectContainer extends Effect{ List& getEffects(); }

這樣我們就只要定義不同效果容器就可以了

比如技能

class abstract Skill implements EffectContainer{ public void spellTo(BattleAgent target){ foreach(Effect effect in getEffects()){ effect.cast(target); } } }

對於buff

class abstract Buff implements EffectContainer{ public void update(){ foreach(Effect effect in getEffects()){ effect.cast(target); } } }

對於被動技能（其實也是buff）

class abstract BuffSkill extends Buff { public void install(){ foreach(Effect effect in getEffects()){ effect.cast(target); } }

public void unstall(){ foreach(Effect effect in getEffects()){ effect.reverse(target); } } }

裝備同理被動技能

是不是很清晰？

而對於複雜的技能效果，因為我們已經抽象出了Effect

所以怎麼實現也就很容易了

class DamageEffect implements Effect{ private int damage = 100; public void cast(BattleAgent target){ target.hp -= damage; } }

看起來是不是很簡單，我們來寫個變羊

這個技能包括 2 個效果外形修改和屬性

1 外形變羊

class ChangSheepEffect implements Effect{

public void cast(BattleAgent target){ target.gameObject = GameManager.getAnimeObject("sheep"); } }

2 攻擊力和防禦力變0 速度變慢

class PropChangeEffect implements Effect{

public void cast(BattleAgent target){ target.atk = 0; target.def = 0; target.speed = 50; } }

就是這麼簡單，同學你明白了嗎

如果要深入一點的話，就是變羊是持續型的，到了時間會變回來

所以我們要一個可以觸發buff的效果

class TriggerBuffEffect implements Effect{ BuffSkill buff = new BuffSkill (){ public List&<&>getEffects(){ return new List().add(new ChangSheepEffect()).add(new PropChangeEffect()); } } public void cast(BattleAgent target){ int time = 3000;//3秒 target.addBuff(buff,time); } }

然後把這個TriggerBuffEffect加到技能能上就ok了，就完成了一個可以變羊3秒的技能

恩累了就這樣

2016 3- 21 更新

@王敬哲在他的答案里提到個有趣的問題，就skill和buff的邊界問題，恰好新的項目里裡面我進行了一個比較新的嘗試，就是抹除這個邊界。

在這次的項目中，因為技能需求足夠複雜，所以採用了以前一直只想沒實踐的想法，就是取消技能在邏輯中的的概念，或者說在基礎邏輯中沒有技能的設計，技能只在數據層和討論的概念中出現。

具體的描述也很簡單，所謂的技能我們都理解為施法者一組行為和數據的組合，它包含了技能的icon，類型，動作等一系列和戰鬥邏輯有直接關係但沒有本質關係的概念與數據的總和，用來在遊戲概念中定義一個技能的所有特徵。

但是在戰鬥中，真正發揮作用的是buff，在新的設計中，所有的參與戰鬥邏輯的實體都是buff。

比如如果要實現一個火球，那麼實現方式是技能數據告訴我會播放什麼樣的施法動畫，同時丟出一個彈道，而這個彈道上附著一個buff，叫做燃燒，該buff附帶特效火焰和200點的碰撞傷害（在彈道命中敵人時候）。

而這個一整個流程，在概念里，被定義為施法者釋放了一個技能，映射到現實邏輯，就是某人拿起一個石頭，點燃，然後把石頭丟出去砸到了某人。

至此，核心的技能結算邏輯里，徹底幹掉了skill這個類，技能變成了只在概念討論里才出現的辭彙。戰鬥結算中，不再存在skill的概念。

目前該設計運行良好，在策劃一段時間適應後，變得相當容易理解。不存在任何所謂 skill和buff邊界問題

更多內容請關註：水風的遊戲思考寫了多篇文章關於技能、戰鬥等。

廣義的的說，和戰鬥結算相關的內容都算技能系統，包括技能信息管理、技能調用介面、技能目標查找、技能表現、技能結算、傷害結算、buf/法術場模塊管理，此外還涉及的模塊包括：AI模塊（技能調用者）、動作模塊、尋路/移動模塊以及人物屬性和傷害結算。

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

- 技能信息管理：管理unit所擁有的技能以及技能的等級、cd等。

- 技能調用介面：AI或者UI操作觸發技能，觸發技能時可能選擇了一個目標（AI），也可能並沒有目標。

- 技能流程管理：一個技能可能由多個子技能以移動的執行模式組合而成，而每一個最終執行的技能執行過程也存在一個流程，一般包括：前搖過程-結算點-後搖過程。技能在前搖結束時進入技能真正的結算流程，結算流程可能創建子彈，也可能觸發buf或者創建法術場。

- 技能目標查找：若技能觸發時已經設置了技能目標unit，則直接將其作為目標unit，否則需要根據一定的策略選擇。此外，技能釋放的時候還需要釋放方向和釋放位置等信息，也在這個模塊獲取。

- 技能表現：技能釋放過程中，需要創建相應的特效以及執行相應的動作。

- buf/彈道/法術場管理：buf掛在unit身上，可能影響unit的一些行為和狀態；法術場一般由場景管理，影響場景中某範圍內的unit。彈道就是技能創建的一個子彈，這個子彈可能以不同的路線移動（直線／拋物線／直接命中等）

## 0技能表

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

```

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

paly 動作

if skillTable.get("特效"):

播放特效

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

創建法術場

....

```

##1 技能信息管理

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

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

此處包括處理技能升級／附文／裝備等外部模塊對技能參數的修改。

##2 技能調用介面

提供技能調用的介面供AI調用，調用時可以提供一個目標unit，也可以不提供讓技能自己查找。

提供三個介面：

- 技能開始：開始執行技能，若技能不循環進行，則技能可以自動結束。

- 技能結束：有的技能不能自己結束，比如某些循環技能。當玩家鬆開按鈕，調用技能結束介面，告訴當前技能使其結束，此時技能到達後搖點時，技能不再繼續執行。

- 技能停止：當技能被強制打斷時，如被攻擊、暈眩等，技能會被強制停止。

此外，當前一個技能正在執行時新的技能調用啟動，此時新的技能調用信息會被保存。一般來說，並不會把所有新的技能調用信息保存下來，那樣就成了一個技能執行的序列。我們遊戲僅保存一個新的技能調用信息。

##3 技能流程管理

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

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

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

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

###3.1 技能樹

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

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

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

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

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

###3.2 執行節點的技能流程

一般來說，技能的執行流程包括：

- 前搖時間：技能開始，但是技能真正的結算流程還沒開始。技能開始以後，機能相關的特效和動作就開始播放。

- 前搖時間結束：技能前搖結束時技能開始真正的釋放以及結算，等技能前搖結束以後，技能真正的釋放並結算。釋放包括創建相應的彈道／法術場和buff。

- 技能後搖點：技能播放到後搖點時間時，技能真正的結束。這時，技能對應的特效以及人物動作可能還會繼續播放，但是技能流程已經正式結束了。也就是說，下一個技能可以執行。

##4 技能目標查找

技能釋放時，目標可能已經由AI傳給了技能模塊，也有可能沒有一個目標，如玩家控制單位。

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

的向量。

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

## 5技能表現

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

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

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

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

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

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

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

功能的界定需要根據策劃需求調整。

好像都是討論遊戲結果影響方面的技能表現，有沒有討論美術表現的技能表現啊？簡而言之就是程序和美術合作方面的，而不是程序和策劃合作方面

比如說，像格鬥遊戲一樣的必殺技/大招等等，但面向多人vs多人的情況

說是設計系統,其實設計技能機制的結構

技能本身的功能是什麼?

主動技能:特定情況下可用-&>執行表現,在特定時間在對特定區域對特定敵人-&>產生特定效果-&>一段時間內產生效果/瞬間產生效果

被動技能-&>學習時獲得buff

根據這個思路,技能機制拆分成技能,子彈,buff三個大塊

ps:buff之所拆分為獨立的模塊主要是buff有很多有的特性,比如buff疊加層數,buff標記用於驅散,目標篩選,表現等等

3個大塊的各種事件都可以調用子彈集,從而對特定的目標產生效果

而子彈集本身可以調用到包括子彈在內的3個模塊(入口統一可以監控各種效果)

如此,通過各種事件調用子彈,使得技能系統可以在各種情況下讓指定的目標產生指定的效果

擴展時,主要看新東西加在哪一塊(小功能,子模塊等),或者在新的事件中調用子彈組

比如把子彈集的每個子彈擴展為子彈組,一次可以調用多個按特定規則排布的子彈

又或者增加一個觸發器類型,增加一直即時效果,本質都是在原有架構內增加小內容

舉幾個例子:

示例1:

玩家釋放技能1-&>釋放子彈1對自身加免疫buff,釋放子彈2在1秒後對身前範圍最近1個友方擊中-&>命中後對自身釋放子彈-&>命令自身對目標釋放技能2

釋放技能1後選擇對身前最近一個友方追加釋放技能2

示例2:

被動技能-&>獲得buff-&>buff觸發器每2秒在自身位置釋放單體子彈1清除buff1,aoe子彈擊中敵人-&>每命中一個敵人對自身疊加1層buff1

實際效果:周圍敵人越多自身獲得越多層buff1

示例3:

玩家釋放技能1-&>釋放子彈1對自身周圍友方和敵方擊中-&>對命中的目標釋放3個子彈:子彈1篩選敵人產生傷害,子彈2篩選友方30%血以上造成治療,子彈3篩選敵人血量大於80%命中後產生子彈4對自身添加buff

實際效果:對周圍友方殘血造成治療,對敵人造成傷害,如果擊中的敵人血量較高,自身獲得增益

示例4

玩家有被動技能獲得buff1-&>buff觸發器效果為暴擊擊中時若雙方距離&>300則對目標發射子彈1和子彈2-&>子彈1對自身添加buff,子彈2篩選有buff2的敵人

技能效果:暴擊擊中距離自身較遠的敵人使自身獲得增益,觸發時若敵人有buff2,則造成額外效果

示例5

玩家釋放主動技能-&>發射子彈使自身獲得6層buff1

buff1附帶3個觸發器

觸發器1-&>釋放技能清除所有層數buff1

觸發器2-&>受到攻擊失去1層

觸發器3-&>buff1消失時自身獲得buff2

buff2-&>觸發器每1秒對自身附近發射子彈篩選1個敵人-&>令目標對自身發射子彈添加增益

技能效果:主動隱身,受到攻擊失去1層,釋放技能後解除隱身,隱身結束後一段時間內受到傷害轉移給附近一個敵人

從架構上說,主動技能都可以拆分為釋放條件檢測-&>釋放-&>目標選擇-&>產生效果

從而拆分為如上的方式

但是裡面很多細節,比如子彈初始位置設置,做成什麼樣子組合出更多的設計形式,同時可以兼容更多的有效需求

比如一個回合制卡牌遊戲,要啥飛行子彈,區域只要相對和絕對位置2大類,然後直接填坐標就好了

就還是看一個策劃的抽象能力了...

好像以前有款Sid Meier出的星際slg遊戲，大概03年就有了，就是有星際會議，根據民主投票結果改變規則。

太陽神三國殺的設計技能主要是通過lua來實現。

易擴展指開發擴展還是玩家擴展？我覺得lua的那種數組結構比C容易擴展多了。用了LUA都不想用C。

第一種純讀表.

優點:批量處理大量技能,維護方便(前提是策劃不要腦洞太大,想出一些某名奇妙的技能).

缺點:欄位多,亢余欄位多.增加新的奇怪技能時候,心智壓力大,需要考慮與整個框架的耦合.

進化型:

技能的特殊功能只讀取info欄位,根據info的內容進行解析.甚至可以把一個樹形結構體存在info欄位,程序解析info就是了.

第二種表與腳本混合.

又有兩種分支,

分支一:主表副腳本,腳本作為欄位綁定於表裡.表的某個欄位就是技能的腳本路徑.技能的主流程,框架邏輯有表的欄位來決定.

分支二:主腳本副表,主邏輯,流程都是有腳本實現.技能的主流程由腳本實現.腳本讀表獲取數據,進行技能的操作.

優點:增加奇怪技能,很方便,直接寫腳本就可以了.

缺點:批量處理工作量大,既要改表,又要改技能.每個技能對應獨立的腳本,技能越多,腳本越多.批量處理的時候,工作量大.

第三種純腳本

優點:自由,開發速度快,適合產品原型驗證的時候使用

缺點:不宜維護....

總結,沒有標準答案,純讀表方案,只要欄位夠多,根據排列組合,理論上也能實現無窮無盡的技能,但是欄位那麼多,對於策劃和程序都是巨大的心智負擔.但是好處明顯,數據驅動,只要改表,不需要改代碼,就能製作新的技能.純腳本,實現demo原型驗證的效率實在夠快,比如製作獨立遊戲,在做玩法驗證的時候,純腳本方案,可以直接開始擼,而不用考慮對框架的耦合限制.混合型,欄位不多,腳本也不是那麼多,但是修改技能.單單改表不行,還要改腳本.

所以如果策劃牛逼,純讀表好.策劃菜比,純腳本好.其它情況?策劃說的算...

（。。。答完看了下其他答案感覺這個問的是程序問題，表示非程序無能為力。以下答案僅僅從策劃或玩家的角度考慮。）

1、感覺從現實來說沒啥好說的。技能無非是一堆數值、各種狀態（BUFF或DEBUFF）、施放條件、持續時間、CD等等的排列組合。沒做過具體的技能設計，但我想應該是一張表裡面有N多列表示不同的狀態、或者BUFF。新技能應該是在這個表裡面加多一橫，並在你想要技能有什麼效果的對應列上設定。（純個人想像，如果錯誤請大神們指出免得誤導了別人。）

2、在拓展性上我發表一下個人看法，擴展容易但必須考慮清楚。

A、首先要考慮替代性的問題，比如動作遊戲按鍵有限的情況下一個新技能意味著必須淘汰一個舊的技能。如果是淘汰就要考慮用戶之前技能以及現在技能的升級成本以及作用相關性，如果新技能效果有限或者說用戶需要付出很大的代價才能讓新技能達到替換舊技能的水平，那將會影響新技能的普及替換。如果說技能是跟RMB掛鉤比較直接的話要考慮替代的時間間隔，好不容花了很多時間、精力、金錢把技能弄好，雄霸一方才2天出個新技能回到解放前人人平等那就不對了。

B、擴展的技能主動性技能要慎重，盡量是被動或BUFF類。不用替換主動技能又達到增強效果。

C、平衡性問題

技能這部分我倒是沒有見過有開源的框架，但題主必須要糾正一個觀念，技能這部分的架構，是沒辦法做到策劃提出需求而你不用修改的，你所能做到的就是降低各個功能塊的耦合，給策劃足夠的自由度，後續添加很少的代碼即可。

比如說弓箭手的技能，你在做的時候提供子彈數量與子彈夾角，是否穿透，是否返回，再提供一個可以配置曲線的地方，這樣的話策劃基本上可以根據你提供的參數配置直線曲線散射單攻返回穿透這幾個因素組合的各種技能。

樓下有人提到buff與技能的關係，說起來各種形態的都有，主要看做這塊的程序怎麼想，有些技能結構中buff的比重很高，基本上技能就是掛各種buff，效果全由buff實現，有些技能結構中buff比重很低，僅僅用來實現一些光環類，狀態類效果，這兩者之間的界限，其實還是看個人實現，並沒有一個硬性的規則。

個人覺得不受制於技能釋放狀態的效果，都應該歸類到buff裡面，也就是說技能的動作釋放完了還存在於自身或者敵方的效果，具體如回復，持續傷害，減速，眩暈，封技，打坐等等，歸到buff裡面也可以更自由，技能只需要提供掛buff的相應配置即可。

另外，關於技能結構，最好能提供組合技能的功能，以我尚淺的資歷，到目前為止這個功能要麼是早期要麼是後期，基本上遇到的項目都要用，在實現一些比較複雜的技能時尤其有用，所謂組合技能就是可以連續釋放多個技能中途不退出技能狀態，注意這個和連續釋放無CD技能是有區別的，組合技能是用來處理類似於衝過去打幾下然後打到天上再打到地上一通踩的這種技能的，你做的時候就會發現這些技能每一段都是技能表可配置的，但組合起來就得重新寫一個新的技能，而且策劃一般會提過來好幾個這樣的炫酷技能，那麼提供技能組合無疑是比較好的方案。

其實說白了就一句話，提供各種可配置參數，把許可權交給策劃，具體要提供哪些，你自己多想想，細節很多，寫下去就沒完沒了了，就這樣吧。

作為一個玩家，也確實想過不少次一款怎樣的遊戲才是真正的遊戲，想了很多，世界背景，技能，社會框架等等。想到最後，頓時覺悟。

只做介面，然後把坑留給其他千千萬萬的玩家來填。

需求不明確……

推薦看一下Dota2的技能系統，完全的數據驅動，可以捆綁lua腳本進行複雜的邏輯操作。

數據驅動類技能 - Valve Developer Community

做好基本框架，然後實現各種interface，比如傷害，加buff，取位置，身上的buff情況，最後通過表格?lua語句，讓策劃玩起來

如果只是基礎無趣的技能，那麼直接填表就行了

什麼？你是一個略微風騷的策劃？那麼自己寫寫lua，把這些介面用起來。其實很簡單，基本會if就行了：比如判斷「灼燒」buff，如果目標身上有，那麼技能x造成額外傷害?暈眩，否則只有基礎傷害於是十分容易地山寨了一個火男～

什麼？你是一個有情懷的策劃，想要做一些真正能裝逼的技能？！只需在現有的基礎上，跪舔程序大爺，幫你增加新的介面，然後最用lua組織起來就好了！

比如，last breathe = 實現浮空介面 ? 判斷給定範圍內，是否存在浮空單位?如果存在，則技能允許釋放?技能釋放時，瞬間移動過去?取滑鼠最近且在距離內的浮空目標?延長浮空?造成傷害

每個技能都不一樣如果設計幾十個技能那欄位得加多少程序和策劃都會瘋了建議看看火炬之光的技能編輯器會很受啟發

不是內行的人都認為改下設計和實現跟用紙巾擦一下嘴角一樣簡單實際上比更改建築結構還難

由於是從事設計工作，所以在此只談設計需求方面的思路。

關於具體實施方案，如果無法將當前遊戲機制可能產生的運算關係全集完全羅列並全部編寫為底層API，那麼，表格化配置方案並不是最靈活的解決方案~在從技能描述設計到技能邏輯設計再到最終填寫配置的過程中，將會不斷的發生當前表格配置無法滿足設計需求的問題，直至完成階段規劃的全部技能設計，以內容生產商的角度考慮，這將涉及到關於項目生產時間的dead line問題~

每個技能邏輯完全通過程序代碼實現是擴展性最差的解決方案，原因很多，在這裡只講一個決定性因素就夠了，一旦版本更新出現技能邏輯方面的改動，在遊戲版本更新時很難支持熱更新。

比較有彈性的解決方案是底層API配合腳本編寫，也就是說將技能實現中基於面向對象的部分與基於面向過程的部分分拆，底層運算API部分交給前端遊戲機制實現的程序人員做，另行指派程序人員專門負責腳本編寫或將這個工作交給設計人員，不過據我個人了解，多數公司都是指派程序人員來完成這個工作，畢竟多數的中小型公司通常設計人員都比較少，有腳本編寫能力的更少，無法滿足項目在生產時間上的需求。另外，以項目流程迭代角度來考慮這個生產時間問題，這種解決方案可步進式推進項目進度~

關於技能抽象問題，需要針對當前遊戲機制主體所支持的時間序規則設計，如果機制屬於非回合制類型，確實有單次時間序技能（常規定義技能），常量時間序技能（BUFF與DEBUFF）,與條件技能（英雄光環技能，終止條件多為英雄陣亡）等概念~這是由於技能概念是建立在時間序的面向過程邏輯基礎上所導致的~如樓上一位兄台所說，技能是設計、程序及美術三方共同協作所誕生的產物，所以單談技能設計很難獲得有效設計經驗~

入行時間還不長在這方面可以總結出的階段性結論暫時只有這些，期待大神指點~

……本來寫了不少內容，結果這個差評APP把我辛苦打的文字扔了，心情不美，不說了~