游戲機制設計3:技能系統(tǒng)的設計思考過程

寫在前面

正式復工之后工作繁重,平日里幾乎沒精力考慮工作以外的東西,只能抓緊周末的時間來寫文章、做視頻。
印象中已經(jīng)有一段時間沒有寫游戲策劃內(nèi)容的文章了,我原打算寫一篇關于“隨機生成算法”相關的關卡設計文章。可惜涉及到的知識點頗多,有點兒難產(chǎn)。
翻閱之前的文章,發(fā)現(xiàn)我去年寫過兩篇講述設計思考過程的文章:

游戲機制設計1:掉落機制的設計思考過程
游戲機制設計2:道具系統(tǒng)的設計思考過程

這個系列還是很有意思的,恰巧我這段時間正在研究Unreal的GameplayAbilitySystem插件(官方提供的一套技能系統(tǒng)插件),所以這篇文章就和小伙伴們一起聊一聊關于游戲技能系統(tǒng)的設計思考過程吧。

行業(yè)現(xiàn)狀

行業(yè)現(xiàn)狀

在正是講解技能系統(tǒng)之前,我們先聊聊我所知的行業(yè)現(xiàn)狀,完全是我主觀的理解,可能有說的不對的,歡迎指正。

在過去幾年,手游被清一色的卡牌、MMO充斥,同質(zhì)化十分嚴重。在這種情況下,從無到有設計一款游戲的技能系統(tǒng)是幾乎不可能的,沒有必要、大部分情況是在已有的技能系統(tǒng)下進行擴展、微調(diào)。而游戲中的技能設計、則更多是由數(shù)值策劃完成的。

但近年來因為手機市場基本飽和,智能手機新用戶明顯減少,手機游戲的營銷策略也逐漸從換皮買量變?yōu)樽呔仿肪€。市場上也開始涌現(xiàn)一些以技能設計、戰(zhàn)斗系統(tǒng)作為賣點的ACT游戲和MOBA游戲。就如同PC網(wǎng)絡游戲所經(jīng)歷的過程一樣。

很多大型團隊,特別是動作作為核心賣點的游戲,則會增設“戰(zhàn)斗策劃”這個職位來滿足日益繁重的核心戰(zhàn)斗系統(tǒng)工作量。通常,戰(zhàn)斗策劃由數(shù)值策劃進化而來。因為要設計好的戰(zhàn)斗體驗,通常要足夠了解各種屬性的含義、傷害公式的差異等等??梢哉f,不懂數(shù)值的戰(zhàn)斗策劃路子一定走不遠。

關于戰(zhàn)斗策劃的職能,之后我們會專門用一篇文章來做介紹,這里就不展開來講了。

之所以在正是講解文章前,我們會介紹一下行業(yè)現(xiàn)狀,也是跟大家(特別是一些經(jīng)驗尚欠的小伙伴)分享一下。類似技能系統(tǒng)這種涉及到游戲核心玩法、又十分底層、獨立的系統(tǒng),通常是沒機會重新設計的。而我們更多要做的就是總結一套技能系統(tǒng)的通用規(guī)則,舉一反三,在之后的項目中知道哪些是優(yōu)秀的設計,還缺少什么。然后在現(xiàn)有系統(tǒng)的基礎上去優(yōu)化調(diào)整。

數(shù)據(jù)驅動

數(shù)據(jù)驅動

也許我本人是數(shù)值策劃的原因,所以在設計一個功能的時候,優(yōu)先想到的就是“數(shù)據(jù)驅動”。
所謂數(shù)據(jù)驅動,就是將可能變化的因素全部抽象為可通過數(shù)據(jù)表修改的配置項。這樣做的好處顯而易見,

就是在之后的業(yè)務擴展中,可以在盡可能不折騰程序員的前提下,通過配表實現(xiàn)更多的技能效果。
但是我這里也要特別說明一下,特別是對于一些系統(tǒng)設計者來說,千萬不能“迷信”數(shù)據(jù)驅動。

對于系統(tǒng)設計者來說,將關鍵信息設計為“可配置項”似乎并不困難。難點在于怎樣判斷一些關鍵數(shù)值的價值。換句話說,不清楚系統(tǒng)的設計目的,在系統(tǒng)設計過程中缺乏主見,一味地要求數(shù)據(jù)驅動,系統(tǒng)的可擴展。反而會造成系統(tǒng)的開發(fā)更困難,BUG更多。而這種問題則更容易被開發(fā)者忽略。

回到技能系統(tǒng)的數(shù)據(jù)表結構設計上來說,首先就是考慮將邏輯和表現(xiàn)分離。

首先就是對于技能Ability和技能效果Effect的分離。
一個技能Ability應該是若干效果的集合。
通常,技能還包括技能消耗、CD時間、前后搖動作(技能生效時刻的前后動作)等
此外,技能通常會選擇一個目標,這個目標可以是游戲中“單位”(自身角色、敵方角色、友方角色,可以設根據(jù)游戲設計一個枚舉系統(tǒng))、某個點或者是以某個點為中心的一個形狀(扇形、圓形或者方形)范圍內(nèi)。
最后,在RPG游戲中技能通常是有等級的、等級伴隨著屬性成長。
而效果effect顧名思義就是真正產(chǎn)生的各種游戲效果。這種效果包含屬性和狀態(tài)兩方面的修改。
為什么說一個技能是由多個效果組合而成的,為了技能系統(tǒng)更加的靈活可拓展,通常一些我們耳熟能詳?shù)募寄苄Ч鋵嵤嵌喾N效果的組合,比如:

眩暈:限制移動、限制釋放技能、播放眩暈動畫、播放眩暈特效

對于屬性的修改則更為簡單、直觀,比如:

生命值-20

但是咱們上文中說道,技能通常是有等級的,而這個等級會被效果繼承。并對效果的數(shù)值產(chǎn)生影響,同樣的一個技能,因為等級不同威力也有所不同:

等級 效果
1 生命值-20
2 生命值-30
3 生命值-40

一些技能系統(tǒng)會將效果中這種對數(shù)值的修改抽象出來,比如我上文中提到的unreal的GAS插件,就有modifier
所謂修改器,就是對游戲中的數(shù)值進行修改的時候可以讀取一個和等級相關的數(shù)據(jù)表。
而一個效果Effect則可以包含多個修改器Modifier。

至此,一個最簡單的技能系統(tǒng)的分表結構就梳理清楚了。
但是,我們似乎忘記了游戲中最常見的一類技能效果——BUFF

我見過一些極端一點兒的技能系統(tǒng)會將所有的Effect看作是BUFF,換句話說,當我對敵人造成傷害時,我其實是給對方釋放了一個獲取瞬間就會釋放的BUFF。
如果這么說不太好理解的話,其實我們可以換一種思路。考慮一下Effect的觸發(fā)時機。
上文中我們其實是默認Effect是在技能釋放的一瞬間就觸發(fā)的。但其實我們完全可以添加一段邏輯來左右Effect的觸發(fā)時機。
最常見的觸發(fā)時機就是根據(jù)時間:立刻、周期執(zhí)行、計時結束時執(zhí)行。
此外,一些和玩法緊密相關的觸發(fā)機制也很常見:目標死亡時執(zhí)行、目標被攻擊時執(zhí)行等等
觸發(fā)時機通常是在項目開發(fā)過程中逐漸豐富的,在設計系統(tǒng)是不需要(也不可能)想出全部的可能性。
主要搞清楚觸發(fā)時機這個概念,其實我們的Effect就可以作為Buff使用了。

當然,除此以外,Buff還包括覆蓋關系、顯示圖標等其他邏輯,本文也不展開說了。

標簽系統(tǒng)

標簽系統(tǒng)

在一些以技能系統(tǒng)作為核心玩法的游戲中,比如MOBA類游戲中,技能之間相互影響、干涉,比如:

造成20點傷害,對于被眩暈的目標,傷害+20

這種技能效果,不同的技能系統(tǒng)給出了不同的解決方案。而對于GAS而言,則是通過標簽系統(tǒng)來解決類似問題。

標簽系統(tǒng)是Unreal引擎提供的另一個十分實用的系統(tǒng),旨在通過標簽篩選出我們感興趣的目標。這種思想有些類似ECS中的Component,只包含數(shù)據(jù)不包含邏輯。而標簽更純粹的只是描述某種狀態(tài)。

技能效果通常可以給目標或釋放技能的單位添加某個標簽或者移除某個標簽,并且在技能效果生效前根據(jù)標簽進行相應的篩選。

回到上文中舉例的技能效果,在加入標簽系統(tǒng)之后就很簡單了,只需要在釋放眩暈效果的技能時,順便給目標貼上“眩暈標簽”。然后,這個技能只需要包括兩個效果,其中一個效果就是常規(guī)的生命值-20的修改器,而另一個效果則是判斷當目標有“眩暈標簽”時才生效的生命值-20的修改器。

腳本擴展

腳本擴展

正如我上文中說的,不要過分癡迷于“數(shù)據(jù)驅動”。當一些通過配置難以實現(xiàn)的技能效果確實存在時,如果過分要求數(shù)據(jù)配置的可能性,可能導致的結果就是代碼和表結構的易用性都變差。這是得不償失的。因此我們可以在配置表中留出一列,供給程序回調(diào)表格中指向的代碼(通常是使用Lua編寫)

一些小伙伴可能會糾結游戲策劃究竟需不要會編程語言。事實上思想比具體實現(xiàn)更重要,上文中的這套技能系統(tǒng)其實已經(jīng)需要一定的編程思想才能駕馭。但如果你的工作內(nèi)容是戰(zhàn)斗策劃,那么你通常需要掌握一門腳本語言。如果你的項目是使用Unreal的話,那么你大概率也需要掌握Blueprint。

但是對于腳本的使用應該相當克制。作為設計者我們應該清楚其中的原因。
在一個技能需求確立之后,我們首先考慮使用現(xiàn)有數(shù)據(jù)表結構能否配置完成需求。
如果不能,則要考慮這種需求的通用性,對于通用性較高的技能效果,應該向程序員提出需求,及時的拓展枚舉或改變表結構。
只有在以上條件排除的前提下,才需要我們策劃自己動手編寫一些擴展效果的代碼,并且在編寫的過程中也要注意邏輯和數(shù)據(jù)的分離,盡量不要講數(shù)值藏在腳本中,這樣在后期的維護中會很可怕。

最后

《游戲機制設計》這個系列,我會盡量將游戲中一些偏底層的、獨立的模塊的設計思考過程整理成文章和大家分享。

之所以只是介紹思考過程,一方面是因為正如我上文中說的,這些底層系統(tǒng)通常沒什么游戲策劃可發(fā)揮的,更重要的是,我們在加入一個項目時可以更快的適應項目的工作流,所以講述思想比具體實現(xiàn)更可貴,畢竟:

授人以魚不如授人以漁

我是老李,一個游戲人
除了游戲不會別的
我們下篇文章再見!

?著作權歸作者所有,轉載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。

相關閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容