Unity2D格鬥遊戲開發問題？

01-03

第一次接手2D格鬥遊戲，需要用Unity開發，想問問大家都是什麼思路？
主要是角色攻擊，技能，防禦等狀態判定，雙方攻擊的先後順序，連招釋放等等，還有碰撞盒怎麼加？
可以以拳皇街霸之類的舉個例子就最好了~

謝邀。

//============================突然興起寫了個關於移動的=====================

提示信息 - GameRes遊資網

這裡所說的橫版動作遊戲，包含且不限於2D橫版動作遊戲、橫版跑酷遊戲、橫版格鬥遊戲，只要邏輯層是橫板的，且對於判定需要及高精度的（比如在動作遊戲中就是拳頭命中身體才算中，而不是WoW中，雖然近戰攻擊有時候看起來還有點距離，但是伺服器計算命中就算命中了）就屬於「橫版動作遊戲」範疇。

1，邏輯的世界

在一個橫版動作遊戲中，我們就討論這個移動問題，把世界拆散成三個，他們互相之間是並行的，由這些並行的世界，組成了玩家最後看到的遊戲，事實上不同的遊戲中並行的世界可能會有更多個。

在這篇里，我主要說的就是移動世界，一個邏輯世界。在開發遊戲的時候，當開發者處於這個世界時，會拋開一切攻防判定世界和貼圖世界的信息。

2，地形

地形的定義我就不作出解釋了，僅僅要說明的，地形並不僅僅是踩在腳下的。在橫版動作遊戲中，地形可以有以下一些信息：

1）坐標點

地形在這個世界上的點位置，一切地形相關的控制由這個點的變化來決定他的位置，坐標點不是一個2維的x,y，它還包含了一維inWorld，我們暫且這麼稱呼，表示他是否在世界上存在。坐標點(x,y)的作用大家肯定第一時間可以抽象的出來——就是在一些橫版動作遊戲中，有些會移動的島嶼，FC的冒險島、超級馬里奧開始就有。

這個很熟悉吧，屏幕中間那兩根會帶著你往上或者往下走的地形，有時候角色踩上去還會自動往下掉。這就是(x,y)坐標在這裡的作用。而會消失的地形，其實很多橫版動作遊戲也是有的，你接觸的第一個這樣的遊戲可能就是……

FC的經典大作魂斗羅，我們這一代遊戲人都是玩這個長大的，不少人人生第一個遊戲就是他，在剛開場沒多久，你就能遇到一座橋，走過去的時候會爆炸，原本可以踩的地形inWorld變成false了，當然對於這個橋，更高效的處理是去掉這個地形信息，但是在另外一些動作遊戲中，他會出現那種若隱若現的地形，出現的時候可以踩，但是消失了就會掉下去

FC的赤影戰士裡面有很多這樣的地形，另外也有成龍之龍等都會有這樣的地形。

2）天花板、充實體、牆壁

這兩個都是可選屬性，且都是boolean的，天花板的概念很好理解，就是當角色起跳的時候，會因為頂到天花板而終止跳躍開始下落，這是最常見的，天花板其實還是限制版子邊緣的東西，也就是角色無法往上走了。

最古老的天花板之一：

超級馬里奧開始的時候那些問號、磚頭、頂掉問號後的鐵塊，都是天花板=true的，而魂斗羅中，大多地形天花板都是False的，因此角色可以自下而上的跳躍。

充實體則是角色往下跳的障礙，這個真不好找圖（因為無法說明問題），但是相信每個人的遊戲經歷裡面都會遇到：

充實體=false的時候，角色按下和跳是會往下跳一層的。

充實體=true的時候，角色按下跳，要麼就是蹲著，要麼就是原地跳起（根據遊戲設定的按鍵反饋不同）。

至於牆壁，就太好理解了，通常版子邊緣，或者一些橫向不讓走過去的都是Wall=true的，比如上圖瑪麗奧裡面的綠色水管就是個典型。

3）體型

這是地形最重要的屬性，這決定了這塊地形的大小。

老式的遊戲中，採用二維數組作為地圖，依然是Tile Based，如超級馬里奧系列，所以都是正方形。但是隨著遊戲精度要求越來越高，也出現了多邊形的地形，並且世界不再是tile based。

早在MD時代，索尼克已經採用了特殊形狀的地形（可憐國游的跑酷還做不出來）。體型的作用是什麼我這裡就不多說了，核心在於不是矩形的體型與點的碰撞演算法，是要數學功底的，這裡我就不提供演算法了，自己百度很容易搜到，都是初中、高中教程了。

體型當然不是一個簡單的polygon就了事而得，他還有一個offset坐標，這個坐標的x,y是與坐標屬性的x,y產生關係的，已決定這個地形出現在哪兒。我們剛說了移動地形。

4）強制位移、溜滑、彈性。

嚴格的來說，溜滑、彈性是強制位移的一種，但是概念上來說還是要把它們分開。

強制位移，是指當角色處於這個地形的時候，會收到一個外力(forceMoveX, forceMoveY)，這些外力會導致角色的移動在x,y方向上受到力的作用：

最常見到的是傳送帶，但是松鼠大戰中著名的強制移動地形不僅僅是傳送帶，還有電風扇。核心在於你往一個方向走會很慢，但是往另一個方向走卻會很快。這裡要特別注意的是，一些遊戲中實現Y方向的強制移動可能是增加角色的重力或者跳躍力。

溜滑屬性（通常是float）他的作用是讓角色在停止移動的時候，還會逐漸保持一個減速的ForceMoveX效果：

早在FC的冒險島1代，我們就遇到過這種溜滑的地形。

而彈跳屬性（通常也是float），則是給角色強加一個jump的力度，最常見的是：

注意到屏幕中間那個彈簧了么，就是他！

5）位移軌跡node，可攜帶性。

一些地形有自移動的能力，他們通常會跟隨一定的軌跡移動，而這些地形通常也會需要設定一個可攜帶性，可攜帶性決定了角色在地形上是否會跟隨地形的位移而位移。而地形位移的信息，除了坐標的移動軌跡、每兩個軌跡間的tick長度外（這時候inWorld屬性也就起作用了，你可以設計一個地形移動到一個地方突然沒有了），還要設定一個可攜帶性，因為並不是所有的地形都要帶著上面的角色走的（這個自開腦洞吧）。

松鼠大戰裡面的小板車是「最不標準」的位移地形（可攜帶）。當可攜帶為true的時候，我這個地形這一幀的位移，也會成為ForceMove傳遞給角色（所以通常循環裡面地形的位移在前，別問我為啥這麼不嚴謹，因為大家都喜歡偷懶）。

6）其他屬性。

之所以歸納為其他屬性，是因為根據遊戲的不同，你還可以給地形帶上一些其他的屬性來豐富他，但是這些屬性通常與現在正在討論的位移這件事情沒什麼大關係。比如你給地形帶來一個燒傷力，角色走上去會受傷，並且受到吹飛力等影響，的確這個吹飛力會影響到角色的移動，但這個邏輯並不屬於這一層，而是屬於攻防判斷層帶來的影響。

比如洛克人的釘板就會讓角色直接掛了（至於圖裡面為啥沒掛，你懂得）

3，角色

在位移這件事情上，角色又有哪些屬性呢？

1）坐標與體型

早期的遊戲中，也包括現在很多比較粗糙的遊戲中，角色移動是一個矩形，通過這個矩形與地形（通常也都是矩形，既然這麼做了肯定是效率優先，自然都用矩形）之間的關係來實現位移的每一個細節。

而好一點的遊戲，卻採用了點陣和法線：

一個角色通常有若干個點來組成，這是在地形（位移）判定的時候用的，而不是攻擊框，這些點共同組成了一個多邊形，這個多邊形，決定了角色與地形的碰撞關係，而在角色中心會有一條法線（視覺上也是這個，但別跟法線貼圖搞混了，完全沒任何關係的），這跟法線是在角色ScaleX（左右反轉）的時候使用的，讓這些邏輯點的坐標也發生Scale，通常法線只是一個概念（並不存在實體數據），因為我們在設定角色的每一個動作的點陣（這個點陣是跟動作而非動作的每一幀的，有些遊戲是跟角色的，都不分佈道動作）的每一個點的坐標的時候，會把發現當做Y軸。而作為角色坐標的那個點，通常也是腳下那個X=0的點。

2）移動相關參數

角色本身（請一定注意「本身」）在一幀內移動相關的參數包括：

玩家期望位移(x, jump)：這個是根據操作傳過來的x,y方向的唯一，y方向的位移通常為跳躍力（一些遊戲中根據你按跳的時間長度不同，跳躍力是不同的，超級馬里奧就是一個代表，對於玩家來說甚至是一個技巧活）。一些遊戲中，角色在空中可以受到按鍵影響改變跳躍的方向，也就是因為「角色騰空後」依然接受x方向處理。

來自動作的強制位移(forceMoveX, forceMoveY, ignoreFloor)：強制位移主要是x,y方向上的，通常來說，會多一個ignoreFloor，但不會有ignoreWall或者ignoreRoof這種，當然成為ignoreFloor也不太科學，他的本意是——當我強制位移中，是否還受到正常的重力影響，典型的是侍魂中的不意打，這是一個非跳躍動作，但他有真的起跳了。還有DNF一些角色的後跳技能。

3）角色在這一幀的位置變化一審（李狗海看多了）

角色的位移，分為2個：X方向和Y方向。

X方向的位移距離=玩家期望X（通常這裡是經過buff等計算的最終X方向的速度）+自身動作forceMoveX+地形ForceMoveX+遊戲其他因素ForceMoveX。

Y方向的位移距離=-起跳力（這裡有2個做法都不能說錯，一些遊戲中先運算了起跳力-重力，而一些則是在下一步運算，這兩個都OK，看coder和designer的想法了）+本身ForceMoveY(如果是Jump變化則為-）+地形ForceMoveY+遊戲設定ForceMoveY。

4）角色的位移定案

當我們知道了角色在2個方向上的移動距離以後，我們就要進行碰撞判斷，決策是否最終能夠去到那個點。

一些老的遊戲的做法，現在可能並不是最合適，但是也是比較好用的是：直接判斷這個點是否能放角色（馬里奧做法），如果可以就過去，否則這次位移的目標點變成角色當前所在點。

更好的做法（惡魔城GBA開始的做法）則是：

我們來看圖1，好的做法（也是適合與任何角度地形的）是將角色的碰撞點當前位置與目標位置相連，並計算這些直線與阻擋的關係。我們在圖2中可以看到，藍色的阻擋橫向的如果是一個天花板，那正確的做法，角色還是應該繼續向上，頂到天花板後才開始下落，但如果採用馬里奧的做法，就會定不到天花板（正巧馬里奧是tile的，大多時候避免了這個問題）；而另一些遊戲則是角色的頭頂會超出天花板一點（其實這也完全可以接受）。但是如果做一條線段去判斷，則可以返回出頂端的點（這裡所有的具體演算法都是高中數學水平的，我就不寫了自行百度吧，或者找你家數值策划去），當然這不是唯一的好處。

我們再仔細看圖2，假如世界上有2中地行，他是橙色的線條，而且她的寬度恰好是橙色線條這麼寬，按照馬里奧的演算法，在速度夠快（移動距離夠大）的時候，我們會穿過這條線，形成「穿牆」，所以我們必須做出這樣一條射線（其實還是線段，畢竟兩頭都知道了，但我們還是需要方向的），以保證不發生這樣的bug，而不是無端的把牆壁變粗，關卡設計畢竟有她的巧妙性，而且你也沒法保證角色的速度不會這麼快對吧？尤其是跑酷遊戲。

關於角色位移，這麼小的一件事情，背後就是這麼複雜的東西，有太多需要思考的東西，太多太多了。而且要注意的是，這裡並沒有說的是，角色之間還有碰撞，當角色之間還有碰撞的時候，其他角色的碰撞框對「我」來說就是地形（牆壁為True，至於充實體和天花板就看你遊戲多麼惡搞了）。所以，真不要小看了動作遊戲裡面的角色移動，跟回合制遊戲的概念是完全不同的！

//===============================之前的回答==============================

這些問題並不是Unity才有的，所以其實問題可以去掉Unity的限制，所有2D格鬥遊戲開發思路是一樣的。

其實這個問題回答起來太長了，我之前寫過一些動作（格鬥）遊戲的相關的東西就已經很多了，但那些要幫你開發一個動作遊戲是不可能的，先給你幾個鏈接：

格鬥遊戲的招式指令判斷

[經驗心得]動作遊戲中連招的實現

[項目經驗]動作遊戲設計中極容易犯的設計錯誤

一個動作遊戲或者格鬥遊戲，每一個Tick（你必須理解他的時間單位是tick，而不是秒，其實就是計時器每一跳）會發生的事情：

1，所謂的位移信息就是當前角色正要做的動作、動作的第幾幀、這一幀動作的強制位移信息決定的，所有角色、子彈、地形在這個世界上的位移（在邏輯層，世界是方塊組成的）。

2，你需要for 攻擊框 {for 挨打框 for 防禦框}進行遍歷，並且告訴下一環節，誰碰到了誰。

3，執行碰撞的邏輯，通常傷害、改變動作等都是在這裡執行的，這裡我不的不拐開說一句——在另外一個帖子里，居然有人認為動作遊戲是可以在這一幀預判下一幀你會移動到那兒的，我就呵呵了（具有位移的技能是否應該支持被懸崖打斷？ - 遊戲）最高贊的說的頭頭是道，還有這麼多外行點了贊，我就笑了，你在這個tick的第一個事件，要去判斷下一個Tick的第一個事件的情況，首先你就要演算出這個tick後面的2步，而言算出以後，你要回到第1步之前重新決策？這種邏輯思維怎麼做遊戲呢？至於碰撞盒怎麼加，加在每一個角色-&>每一個動作-&>每一幀下面的，所以是海量的工作，比如KOF早期的10個隊伍（含boss），每隊3人就是30個角色，每個角色平均20個動作，每個動作平均10幀長度，你就要去做6000個單位的判定盒，而且每一個單位裡面都可能有攻擊、防禦、挨打3種，且每一種都可以超過1個，所以格鬥遊戲、動作遊戲，沒有積累是沒法做的。不建議新手去做。

我做過一套完整的2D格鬥遊戲的開發工具，或許可以給你一點幫助。打擊體驗要做的好，都是逐幀計算，命中、抵抗用多層碰撞盒子。會涵蓋的變數因子下面有截圖。

不好意思哈，筆者現在還不夠專業來回答這個問題，相信後面會有更多的開發者給出他們更專業的答案。不過我想給你提供一個思路：

就是MUGEN。

當然你可以直接去看這個程序的代碼。/*我並沒有看過*/

我給你的建議是，找一個Mugen的角色包，用修改工具/*比如FighterFactory*/打開，看看格鬥遊戲的數據是如何組織的。我這裡已經給你準備好了工具和一個角色包。http://pan.baidu.com/s/1bgjNFS

/*多上手玩一玩，自己也做一個角色包嘗試下，會對開發有啟發的*/

這是使用時的截圖：

題主來填坑，兩個月前在知乎發了這個問題大家的幫助，參考大家的建議後自己就在Unity里開幹了，斷斷續續做到現在要求功能已經完成，說一下大體思路吧：

直接說最核心的問題，戰鬥系統：

A.碰撞檢測：我在每個角色對象身上放了3類碰撞盒：

1.攻擊（子物體）。

2.防禦（子物體）。

3.傷害判定（自身）。

B.攻擊判定：在攻擊動畫中調整碰撞盒是否激活：例如普攻中的第一擊，其他攻擊判定類似。（某些技能還可巧用幀事件）

C.防禦判定：當播放防禦動畫的時候，防禦碰撞盒出現，注意在敵方後面攻擊時防禦無效（這個我是根據人物朝向來寫的）

D.被擊後的反應:

1.根據受到攻擊的技能播放不同的特效動畫.

2.輪流播放被擊動畫（僵直）。

3.掉血。

4.增加氣槽量（每個氣槽釋放一次大招）。

大概也就以上這些，編程方面的東西就不贅述了，主要還是思路，下面大家可以欣賞一下美術：

PS：最近也一直在忙自己的遊戲項目《靈》，是一款解謎遊戲，目前團隊5個人，雖然都不是很專業，但是大家都有十足的熱情和毅力這是非常難得的，有興趣的朋友可以關注我的

公眾微信：黑客畫家

個人網站：http://anchorart9.com

大家一起在學習交流。

原文鏈接：Unity製作格鬥遊戲核心思路總結

不請自來。

之前自己動手寫了一個2D動作遊戲，類似鬼泣，可惜要畫的東西實在太多，而我掌握不來，因此半途而廢。寫這篇答案既是總結開發過程中的種種心得，也可能給題主帶來一些並不專業的經驗。

以上是運行的時候的截圖。

在這個半成品中，我為主角畫了23幀，為怪物（也就是右邊那位斷臂屠夫）畫了10幀。在試運行的時候，我唯一的感想是，動作幀一定要多，才流暢！

我為跑步動作畫了6幀，然而根本於事無補，不調速度運行起來就跟抽風一樣，調了速度運行又有一種令人難以忍受的黏著感。

第二個攻擊動作「跨步拔刀」，我花了3+1+2幀，真正的攻擊判定幀為hero 1_27那一幀，在遊戲運行的時候，真正可謂刀如閃電……

因此，我覺得很重要的一點是：2D格鬥，美術要到位。因為2D格鬥遊戲少有60幀的流暢速率，每一幀的延遲都會在人眼中放大，因此任何一幀的偷工減料都非常的明顯。

其次，關於連招，由於我才寫了兩招，因此當時的思路並未完整寫成。

遊戲中我使用的是WASD（四方向）+JKLI（攻擊跳躍特殊攻擊使用物品）+空格鍵位（閃避），可以見鬼泣3SE對我的影響233。

這裡我寫了一個InputManager，在每一幀的Update函數中監控輸入，然後把最近的若干次輸入在Switch語句中查詢一次，若找到對應的招數列表則調用HeroAnimation.cs的函數，改變動畫狀態機的狀態，使動畫發生改變，同時再調用PhysicalPrinciple.cs的函數，確定其狀態和位置的改變。

這就是我架構的問題了，最開始寫的時候，我使用了剛體來實現【重力】，後來發現有了剛體就做不到碰撞體相交的問題，大筆一揮就寫了個PhysicalPrinciple來控制角色的位置，導致人物動作的實現被肢解成動畫和物理兩個完全單獨的方面，寫的時候很是精分不提，經常出現動畫和位置無法匹配的問題——譬如人落地了還保持空中出刀的姿勢。

因此，我得到的教訓是：動作和技能的實現最好是一體的。

第三點關於判定，我的辦法是給角色加上六個用於出招判定的碰撞體，還有六個用於被擊判定的碰撞體，全部設成trigger，對應正前方上中下盤、後方上中下盤。

每個碰撞盒上掛著hit或者behit腳本，腳本中有個enable變數控制碰撞盒是否有效。剩下的就是花大量時間針對每一幀微調碰撞盒的位置，作為動畫播放了。

至於技能和物品，由於沒寫，我也不好大放厥詞。

恩……大致就這樣，AI就寫了一個每0.1秒判定一次距離，遠則靠近，近則怒跳泰山壓頂的辣雞東西。果然很差勁啦。

題主可以去youku搜一個叫SpookMash的遊戲。如果你所說的動作遊戲是那樣的，那麼我大概知道。

逐一回答。

首先，策劃設計一個完整角色，比如怎麼攻擊，擁有幾段攻擊，有什麼技能。

然後美術根據策劃的設計再設計動作。

然後程序根據美術提供的動畫，來拆分狀態並找策劃商議。動作遊戲會經常有打斷，硬直，有效無效的切換，這需要根據Gameplay先做一個大體的初版，之後根據測試反饋調整。需要注意的是，一段攻擊或者技能，往往不止一個狀態，需要多個狀態協同工作。

狀態之間如何切換，需要策劃詳細設計，並給出文檔。然後程序來實現這個切換即可。因為需要多次修改，最好要求程序實現的靈活些比較好。

碰撞盒一般有兩種做法：

1.狀態中動態產生。及進入攻擊，臨時產生攻擊碰撞盒，進入技能，臨時產生技能碰撞盒。以此類推。

2.預先保存一個人物的所有可能的碰撞盒並讓它們失效，在需要的時候讓它們有效即可。

請根據效率和實現難度自行選擇方案。或許還有別的更好的辦法。

答得簡單，有具體製作的問題再問吧。以上。

上面的貼那麼多酷炫的圖，但我想問你們到底有沒有分析過格鬥遊戲。

格鬥遊戲的重點之一是指令輸入的處理，需要根據設計需求模糊處理指令輸入，比如236手236手可以讀成236236手，而不讀成236手或者23623手等等。這是一個重要的環節需要小心翼翼的處理。

然後就是各種動作的狀態機融合處理。用格鬥術語就是目押或者取消，一個動作未結束，在適當時機按下對應鍵位可以直接連招到另一個攻擊動作。這需要程序上處理好各種動作的狀態機融合。

這只是舉了兩個例子，還有很多細節需要處理比如有利幀，確認等等

這些都沒有，上面的你們是在格鬥遊戲還是在玩名為格鬥的過家家遊戲？

角色圖形幀的各種判定（碰撞、傷害、防禦、投技被投、飛行道具），硬直或受創動作里的幀凍結幀延遲；

不同動作互相之間的打斷、覆蓋、優先順序等等；

輸入指令的識別，包括提前預輸入；

這些東西和遊戲引擎一毛錢關係沒有，都得靠開發者反覆調校&>_&<

動作遊戲要做好更多的是整個動作系統設計好，引擎只是在畫面上能提供一定助力

飛肥斐廢是看到目前為止說的比較專業的。此外在加點補充：判定出招判定時刻和收招時刻（前搖後搖）以及受擊的物理表現（浮空，後退），擊打不同部位的不同動畫，肢體衣物破壞效果以及判定相殺，揮空取消，攻擊揮空與擊中的區別等等，如果是無雙類動作遊戲可能還會有判定幀的位移，以及浮空和combo傷害的逐漸變小，敵人倒地追擊等等。如果還有場景存在，則要考慮壁返追擊，空中追擊（參考shinobi）。另外還有一些技能可以在發動過程中改變方向如三國無雙等等。特效大概就是刀光碎屍噴血這些。如果是2d格鬥的，合體技可有可能需要考慮。

《遊戲設計的236個技巧:遊戲機制、關卡設計和鏡頭竅門》里講了很多格鬥遊戲的細節問題，看看會很有收穫

如果只是想做2D格鬥，強烈建議別用unity用cocos2dx就能滿足一切，而且效率上會有很明顯的提高。但是效果上肯定不如unity。只是建議。

———————————————————————————————————————————

進入正題：

主要是角色攻擊，技能，防禦等狀態判定，雙方攻擊的先後順序，連招釋放等等，還有碰撞盒怎麼加？
可以以拳皇街霸之類的舉個例子就最好

對於樓主的問題，我先補充一些關鍵性的對象或者說是系統吧。

首先是按鍵輸入系統：分為移動控制和技能按鍵。這裡可以解決連招釋放的問題。

其實是角色動作狀態系統：這裡需要你設計你遊戲的動作狀態。這裡可以解決攻擊、防禦、受擊、移動、站立等等。

然後是戰鬥規則：這裡就可以說你的攻擊判定了。

———————————————————————————————————————————

往細了說還有很多，大概先理順這三個模塊應該就可以做很多事了。

角色無大幅度轉身，建議用spine，u2d畢竟是嵌入在u3d中的編輯器，不專業！如角色轉身過大建議tk2dtoolkit，用幀動畫實現