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

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

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

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

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

動作名詞的“定義”

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

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

好的。

我舉個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