底層搭建:踏入動作遊戲的製作階段

無良印品發表於2021-08-11
好久不見!如果不是還在持續增長的關注,我可能就意識不到還有人在關注這些知識,但總歸還是看到了對這些東西感興趣的人,我覺得還是有必要打起精神再繼續更一些乾貨,希望你們能喜歡。廢話不多說,進入正題!

新選手和忘了以往內容的的老選手,以下是往期內容傳送門:

硬直與反饋初始篇
連招系統篇
硬直系統篇

這篇文章主要講解動作遊戲的底層搭建,包括了“動作名詞的定義”和“機制的規則”和“指令(動作)層級”以及“流程判斷”,這是些稱謂我自己的習慣,現在不明所以沒有關係,一會兒就一 一解釋。

動作名詞的“定義”

上面的小標題的意思可以理解為,我們動作遊戲中每一個動作名詞必須由設計師親自定義,落實到正式的設計文件,比如:走路,跑步,衝刺,跳躍,攻擊等等;這是動作遊戲最底層最底層的框架工作。有人可能會不同意,也不明白這有什麼重要的……不要懷疑,我的一位很要好的策劃朋友就提出過“這算什麼底層”的門外漢言論,我當時給氣樂了,差點給我整不會了,不多說接下來就來看。

這個時候一定有人可能和我那個策劃朋友一樣,滿腦子問號,為啥需要在正式文件定義(描述)這些一看就知道什麼意思的名詞??

好的。

我舉個A例子:

  • 跑步:當角色走路超過3秒之後由走路切換到跑步動作;
  • 跳躍:擁有三個動作,起跳(Jump1)、持續下落(Jump2)、下落恢復(Jump_idle);起跳使用第一部分,當角色root點離“地面”Y軸距離1畫素高度的時候,處於“浮空狀態”,持續Jump2動作;離“地面”Y軸距離-1畫素的時候,播放Jump3;

光看這個例子,還不能讓大部分人理解為什麼要定義,因為這只是代表了需要解釋動作設定和製作方式,不急我們再看下一個。

再舉個B例子:

  • 跑步:僅雙擊方向鍵,角色立刻由走路切換跑步動作;
  • 跳躍:該動作使用工具或者事件幀拆分,將Jump動作劃分為三個部分,起跳使用第一部分,當角色root點離“地面”Y軸距離1畫素高度的時候,處於“浮空狀態”,持續迴圈第二部分;離“地面”Y軸距離-1畫素的時候,播放第三部分;

看了這個之後對比一下A和B,就會發現同樣的動作,可能會導致操作(觸發)方式的完全不同;不僅如此,還可能會導致製作方式的完全不同,看跳躍的“定義”就能明白,一個是拆分了做的,另一個是合起來做的。

是不是又有人會說這兩種方式對跳躍看起來區別是不是不大?其實區別大了去了,A例子中,拆分的動作可以將每一段動作的優先順序分別插入到其他動作,而B例子的動作作為一個整體,就做不到將細節的動作按需求分別插在不同的動作前後(硬要做也可以但是需要額外的定義,看製作習慣和需求)。

現在再看看,我們為什麼需要單獨定義動作遊戲裡面的每一個動作,這就是一個自己的動作遊戲的辭典,是你告訴程式這些動作是什麼,告訴動作設計這些動作該怎麼做的辭典,這能夠影響操作和設計與製作方式的定義,如果不落實在正式的設計文件,到時候出問題哪裡去找?

我們需要將每一個動作單獨定義,從而初步地建立自己對遊戲操作和實現方式的理解,但在此時此刻也不要忘記我之前文章所做的對動作遊戲的認知,這是相輔相成的。比如我曾說過將一個攻擊動作分作“攻擊動作”和“後搖動作”兩個動作,在這個“定義”的階段就可以被使用。

接下來的定義工作大家自己抽時間解決,我們們要進入下一個問題了。


機制的規則

字面上很難理解,所以需要在這裡解釋一下,假如我們需要描述一個連擊銜接怎麼運作的,就需要單獨將連擊銜接中的規則描述清楚,這個流程和“定義”類似。但為何要單獨出來,是因為這屬於玩家“操作”產生的“動作規則”。

對我的工作流程來說這屬於一種動作機制,而這個機制會產生一系列規則。因此單獨拎出來,防止和“定義”的概念弄混了。

我通常會將:“蓄力攻擊”、“連擊銜接”、“拼刀/一閃”等等概念當作一種機制描述,要求程式按照我的描述的規則去實現這些機制。

我舉個例子:

連擊銜接:

按一次按一次鍵釋放對應動作一次;

僅記錄兩次按鍵資訊,如果按了三次或者更多次鍵,記錄最後一次的按鍵資訊;

連續普攻動作銜接舉例:一個普攻動作(不包括動作後搖)結束前,有按鍵響應,則連續播放下一段普攻動作,一直重複該操作,直到做完最後一個序號的普攻做完,這一動作序列結束;

正常情況下,一個普攻動作(不包括動作後搖)做最後一幀後沒有按鍵響應,則連擊狀態失敗,恢復成該動作對應的待機恢復動作;atk1 → atkidle1 → idle

非正常情況,指的是我們會有表格引數控制按鍵響應時間,因此,沒有引數影響的情況下,稱為正常情況;

連續普攻動作銜接流程舉例:atk1 → atkidle1 → idle

atk1中按鍵響應則atk2 → atkidle2 → idle

atk2中按鍵響應則atk3 → atkidle3 → idle

atk3中按鍵響應則atk4 → atkidle4 → idle

這個例子應該非常清晰,不太會存在看不懂的情況,這屬於構建動作遊戲基礎的一套機制。同理如果想描述“蓄力攻擊”這種概念,也是一樣的。

再舉個例子:

蓄力動作:

當玩家按住攻擊鍵超過0.36秒,角色就會進入蓄力動作;

持續按著攻擊不放超過固定時間,比如,1.5秒後進入蓄力階段2,將會進入下階段蓄力;(可通過核心和道具加速)

在蓄力階段任何時候鬆開攻擊鍵,將會釋放蓄力攻擊;

蓄力1階段: 0.36-1.5秒;傷害100%-200%

蓄力2階段: 1.5-2.7秒;傷害200%-400%

蓄力3階段: 2.7-4秒;傷害400%-700%

大家可以按照這種模式,來描述想要的功能,每個人想要的都不一樣不一定要按照我寫的這個來。

看到這裡總結一下,如果“定義”是“積木”本身,那麼“機制”是屬於構成整個動作遊戲的“積木搭建指南”,你在告訴程式這些動作機制是怎麼出現的,怎麼銜接的,怎麼區分的,有哪些問題需要注意。

另外!如果你有人物動作工程檔案同步說明就更加好了,可以匯出Gif圖給程式加以說明,或者我之前文章裡手繪動作效果階段那樣也是可以的。文字所能描述有時候並不能達到100%的溝通效果。

指令(動作)層級

所輸入的指令的層級關係,字面意思上我們可以理解為按鍵輸入的指令,但在我構建的這套系統裡面這是不正確的,這裡的指令指的是每一個動作,因為同樣的“按鍵輸入”絕對會因為一些連招的機制形成不同的“動作”,所以“按鍵指令”是不可靠的這裡的指令代表的是“動作指令”。

其實動作層級我之前也講過,這裡不贅述。

需要分清楚單個動作與動作之間的從屬關係,以及動作之間的層級關係;因為表達的東西很複雜,所以我會用到“流程圖”和文字,因為有時候光文字是沒有辦法表述清楚的。如下圖就是從屬關係:

底層搭建:踏入動作遊戲的製作階段
【動作之間的從屬(遞進)關係圖,並非狀態機】

這張圖片作為靜態圖能表現出來的資訊有限,在給程式的時候這種圖是有動態效果的,可以通過“傳輸點”看出從屬關係,方便讓程式理解哪個動作可以遞進到哪個動作。

而動作的層級關係表,則需要額外的詳細描述,你需要一個詳細的列表,寫上你的動作名稱和英文名稱(動作軟體中使用的英文名稱),以及它的層級關係;誰是最高的層級(比如死亡),誰是最低的層級(比如待機),一個個列好,不要讓人物在“死亡”的時候還能“跑”。

這塊可不是一篇文章就能完全講的清楚的,哪怕我之前搞了那麼多文章,又給了一些圖例,其實光就這個段落就能講一大篇文章,我希望的是大家能夠通過這篇文章將動作遊戲的細節理解清楚,然後自己在做專案的時候能夠少踩點坑,並且建立一個良好的概念,最後自己總結出自己的方案。

流程判斷

流程判斷指的是“傷害判斷流程”、“各種效果計算流程”、“單元(配表)模組流程”,除開前面兩個流程,“單元(配表)模組流程”這塊做過遊戲行業的策劃都知道,很多策劃的工作就是在前面的所有框架全部打好之後,只管根據要求填引數。但對這部分人來說“流程判斷”這塊應該還是很好理解的。但是,沒有接觸過遊戲策劃的人應該也是大量存在的,所以這裡我需要簡單的講述一下這塊主要是什麼。

簡單理解傷害判斷流程,就是我們需要告訴程式該怎樣生成傷害,怎樣判斷生成傷害,什麼條件下做什麼傷害判斷,有沒有什麼特殊情況。請看下面的圖例:

底層搭建:踏入動作遊戲的製作階段
(注意這些內容一定要和程式面對面溝通)

簡單理解傷害計算流程,就是傷害的計算方式,請看下面的示例,傷害計算流程(這不是傷害判斷流程!!注意):

普通傷害計算流程:

效果幀 → 是否閃避 → 物理傷害(是否暴擊) → 屬性加成百分比 → 傷害減免(包括防禦等所有減免) → 是否格擋 → 最終傷害


被閃避則跳過所有流程直接冒字"MISS"

傷害Buff流程:

效果幀 → 是否被抵抗 → 屬性加成百分比 → 最終傷害


被抵抗則跳過所有流程直接冒字“抵抗”

這裡說一句,我給出來的並不適合直接照搬,僅用作理解。

再簡單理解效果計算流程,就是將一系列(相同性質的)引數資訊定製成ID,做成一個單元(表格);通過和程式約定各個單元(表格)的作用;再通過程式按照你指定的規則呼叫各個單元的引數,通過引數與引數之間的計算獲得你想要的結果;其中每個單元負責的作用不同,你需要和程式約定由單元A到B,再由B到C和D······最後到G,並最後得到你要的結果。

請看下面的示例圖:

底層搭建:踏入動作遊戲的製作階段
(這僅代表了一部分的單元流程,別照搬,不知道引數就搬會死的很慘)

這些流程是底層框架組成的重要一部分,如果做的好,就會有很大的開發空間!你後面想要做什麼樣的效果都可以利用這套底層來完成(當然這也是有邊界的),不用額外加單元(表格),單元多了還有可能會衝突,或者造成本沒必要的工作量。

以後可能也許大概會講到表格怎樣“精簡”、“可擴充”、“易於理解”……但是最好還是不要抱希望,說那麼細,我覺得自己都可以開課了,搞點知識付費。

結語

這篇文章講完了動作遊戲底層框架的主要幾個點,把這些全部消化掉再運用到自己的策劃文件裡面就是大成功,剩下的一些細節做遊戲的時候自然會碰到然後自己解決掉的。能夠從第一篇一直看到這裡的大夥估計都是有水準的,相信大夥。

之後我如果還要準備文章的話可能不會講策劃方面的了,再講就是更具體的東西了,所以,我可能會直接過渡到遊戲動作美術表現,或者體驗設計等等方向。

過段時間再見吧,希望能夠和大家分享更多,但是我太懶了(如果你們真的需要你們可以試著催一催,反正我也不一定做),目前總共五篇文章幫助大夥在理解和搭建(2D)動作遊戲上入個門,3D我就暫時真的沒什麼辦法了,哈哈。

祝大家共同進步!


來源:機核
原文:https://www.gcores.com/articles/140154

相關文章