遊戲科學：這項技術讓《黑神話：悟空》解決了很多動作難題

3月27日， Epic Games在深圳舉行虛幻引擎Unreal Circle線下技術沙龍活動。會上，遊戲科學的客戶端技術負責人招文勇帶來了關於《黑神話：悟空》在動作技術實現方面的主題演講。

《黑神話：悟空》的角色數量非常龐大，而且對動作遊戲而言，角色也需要非常細緻的動作品質，這導致團隊在品質和數量這兩個維度上都面臨非常多的技術挑戰。本次演講招文勇分享了他們在《黑神話：悟空》中所運用到的Motion Matching等動作技術，以及他們如何充分利用技術解決動作難題。


以下為演講原文（有節選）：

大家好，我是《黑神話：悟空》的招文勇，來自遊戲科學。2010年我參加了《鬥戰神》專案，後來就跟尤卡、楊奇出來創立了遊戲科學，然後就一直做到現在。


很多人都知道，其實我們的動作技術是用了Motion Matching，那為什麼我們要用這個東西呢，今天我們也專門來講這個事情。


產能和質量，讓我們選擇了Motion Matching

首先我們會面臨一些挑戰。這個專案裡面我們會有很多的怪物，而這麼多的怪物，我們又要保證很高的動作產能，這樣才能滿足我們這麼多怪物的動作量，而我們又是一個3D動作遊戲，3D動作遊戲意味著一個角色它需要的動作量是非常多的，比方說做locomotion，locomotion要做得好的話，是要處理各種加減速、折返跑，原地轉身等等這些動作。

動作的製作量大，就意味著我們要搞出一個足夠簡單的管線，可以讓外包來幫我們做這個事情。然後我們還有很豐富的角色種類，比方說最簡單的人形，人形就有雙正足，雙反足（像野獸一樣，足膝蓋是往後的，而不是往前的）。還有什麼四足獸、昆蟲、蛇形等等。這些複雜又大量的動作需求，我們怎麼應對呢？


我們剛剛開始做遊戲的時候，剛好Paragon出來了。然後我們參考了一下，做了一波反推，發現這個系統非常龐大，角色的整個運動是非常流暢的，看起來也非常自然，但是為什麼我們最後沒有用？


第一個原因是它對動畫分拆的要求非常高，動畫師要理解分拆是很困難的。舉個例子，以前我們讓動畫師做一個讓角色原地轉身的動作。就這麼一個簡單的東西，但是動畫師會有自己的想法，他可能會在裡面加上一些他想表達的東西，比方說他很想讓這個角色看起來很驚恐，很快速的這種反應。


但最後這個東西進到了遊戲之後，我只要稍微走兩步，這個角色就開始原地跳舞。其實並不是動畫師的問題，動畫師有這樣的想法是合理的。但是因為他並不理解這個東西在程式層面是怎麼拼裝的，而程式又沒有辦法用一個很簡單的思路把動畫師的想法完美的套入到我們的框架裡面，所以就會產生這種製作上的矛盾。

第二個，動畫要標註的資料非常多，具體我就不細講。然後還有它是基於動畫圖的，就是Anim Graph製作的各種動畫狀態機，還有各種各樣的動畫藍圖的邏輯，是非常複雜的系統，我們花了大概一個月的時間反推，然後製作，發現維護起來非常地不容易。

所以基於這麼多的考慮，最後我們剛好遇到了一個新的東西：Motion Matching。其實這個東西是育碧的動畫方案，最早在《榮耀戰魂》這款遊戲裡面用到了，它的原理是通過窮舉你在遊戲裡會用到的所有動作，比方說跑步、轉向、啟停，窮舉所有可能用到的動畫幀。


程式可以搜尋每一幀，看哪一幀最合適。然後它會根據當前和未來狀態計算一個所謂的叫cost的東西，選擇cost最小的一幀。比方說我往前走，並且想著要向左轉，而cost最小的一幀，就是它會盡量的去用向左走的動畫來作為你的下一幀。

那麼我們選擇Motion Matching的原因就是，第一，它的工作流非常簡潔，不需要讓一個動畫師去理解這個動作是怎麼拆的；

第二，因為它整個搜尋過程都是在程式這邊就做完了，你下一步要什麼動畫，程式就會幫你搜出來。然後這也讓我們可以把各種人行運動的動畫外包出去，極大地提高我們的產能；

第三，在動畫的質量上面，它的演示是比較精良的，而且還支援各種locomotion的需求，包括各種轉向折返，還有加減速等等。然後像剛才動畫師想做一些演繹，結果出現問題的這種情況，Motion Matching也能很好地應對上，因為它會根據各種條件搜出最合適的動作，然後動作演員會在錄製的過程中更加容易地做出更多的細節演繹。而且這個是經過產品驗證的，其可控性我們在用過之後發現也還不錯，整個事情都是可以執行下來的。


如何使用Motion Matching開發動作？

• 動作設計：自由移動和鎖定
  

我們目前是把Motion Matching用在人形動畫上。很多人講我們是魂遊戲，雖然我個人不是很認同，但是像這種型別的動作遊戲，它會有兩種移動方式，第一種就是自由移動，自由移動就是我往哪邊跑，我的臉就要朝哪邊；第二種是鎖定，就是我不管往哪個方向走，我的臉都是朝著同一個方向。

然後不同的運動速度、不同的風格和姿勢都是需要單獨錄製的，比方說同一個角色，他跑和走，拿著刀，或者過會兒再舉出一個盾，這些都是需要分開錄製的。這些路線的核心邏輯是想盡辦法窮舉出所有可能用到的轉向，或者是運動速度。這裡用我們的路線圖來講一下。



先介紹下如何看路線圖。這個視訊的右邊是正面，你可以看到狼的頭部是向著右邊的，裡面有幾個標識，大家可以看到下面對這些標識都有一個說明：灰色箭頭是它臉部的朝向；藍色的雙向箭頭就代表這條路線需要來回走；白色方塊就代表要停頓一下，結合起來就像米字步，米字步就是8個方向都走一遍，但是隻有走到中間的時候是要停一下。


現在我們進入正題。

首先是自由移動。第一個，原地轉身，就是錄各種來來回回的旋轉；第二個是蛇形，就是沿著S路線跑，然後臉跟著你跑的方向；第三個，自由轉圈，跑兩個不同方向的螺旋；還有就是一個加減速。育碧認為是要錄兩個方向的，但是我們實際操作的時候一般是錄一段，感覺好像問題也不大。這種運動的目的是提供一個足夠長的加速，然後勻速再減速的這麼一個過程。


然後再看鎖定。像轉圈，就是我要繞著一箇中心點走一個螺旋路線，而螺旋的路線是要正反走兩次的，但走的過程中全程要把臉朝著一個方向，和剛才米字步類似，蛇形也是。


第四個是方塊+鑽石。這裡有具體的視訊，可以對比一下，在這個過程裡面臉都是朝著一個方向的，然後是沿著這個路線走兩遍。

• 錄製動作的9個注意事項
  

錄製的時候，演員需要注意的除了記住路線以外，主要的就是包括要不要停頓、臉部的朝向、要不要來回移動。


移動速度也是非常重要的，因為它的一個特點就是你的角色擺進遊戲裡面的移動速度是由動畫決定的，而不是由你希望的速度決定的。所以為了一開始就讓動畫最後出來的結果符合遊戲的預期，那麼這個移動速度是要估算一下的，就是說你不能差太遠。

還有一個製作動畫的經驗就是，錄這種locomotion的動畫時，武器一定要持穩。它的解決方式是你可以動手肘，但是不要輕易去動手腕。這個方式可以保證你的動畫有一定的自然晃動，但是又不會出現大幅度的旋轉。

另外我們實際在做的時候還要注意的一些點。一個就是剛才說的速度；第二個是演員的運動能力是有一定的要求的，最麻煩的是9段折返跑；演員本身的表演感也會極大地影響最終成品的品質；還有就是疲勞度的問題。這些路線數量很多，如果頻繁NG的話，其實整個過程是非常需要他有充足的體力的；錄製場地也需要比較大。

• 動作實現：結合AnimGraph，計算cost
  

講完大家都能聽懂的，現在開始講一些枯燥的。Motion Matching這個外掛目前是作為一個AnimNode來實現的。AnimNode的實現用這種方式來做的話，可以跟AnimGraph的絕大部分功能來結合，比如說需要後期加AK，或要把它放在動畫狀態機裡面，這些是完全都可以做得到的。

而且它天然地支援多執行緒。其實Motion Matching的運算壓力是非常大的，所以它如果不支援多執行緒的話，還是蠻恐怖的。

目前我們會把我們錄好的一組動畫，所謂一組是一個角色所需要的動畫，這個動畫我們是需要去算它的cost。


計算cost的話，其中一個很重要的就是要算它每一幀骨骼。Motion Matching在我們選用什麼樣的骨骼之後，它會有一個預計算的步驟，會把每一幀各種各樣的資訊算出來並儲存，方便我們後面在實際跑的過程中去算cost。

cost的計算是需要自己定義的，其公式非常重要。如果設計失誤，會極大地影響Motion Matching的品質，因為你會經常匹配到錯誤的下一幀，可能會出現各種抖動，或者你想讓它往左走，結果它走不出來，只能往前走。


而plugin提供的預設公式基本上沒有什麼實用性，就只能跑它提供的Demo，所以我們後面做了很多的優化，包括減少骨骼match，以此驅動run cycle。

然後設計公式時要注意二義性，二義性的意思就是說我去搜下一幀，發現另一幀好像也可以，那一幀好像也行，因為他們算出來的cost可能差不多，很容易會導致一個問題，就是我好好地跑著，但會突然跳到另外一個動畫去，然後就會出現抖動。

導致二義性的原因是因為預設公式只算了速度和Bone Match，維度太少了，很容易導致有兩幀可能會算出差不多的結果，但實際的匹配度中明顯會有一個高於另外一個，所以我們參考了育碧建議的一些考慮因素，增加了一些額外的維度，包括未來幾幀的位置、朝向、加速度和減速度。

像加減速度會很影響你的匹配。比方說我只考慮速度的話，或許能匹配上一個勻速運動的動作，也可能會匹配上一個正在加速到最後幾幀的動作，但這兩個動作可能是不一樣的，而加上了這些維度之後，能在兩個都能用的動畫中排除掉一個，選擇最適合的動畫，這就解決了二義性的問題。

還有設計公式時要考慮各種當前因素，比方說速度匹配、當前腳步的位置等等，接著還有未來因素。這裡需要提到一個概念叫Responsive，它是公式裡面的最後一項，未來相關的因素都要乘以Responsive，Responsive越大的時候，未來因素的權重就越大。這個引數我們是可以控制的，引數越大意味著越有希望保證操作的靈敏度。

Motion Matching仍有不足，5大問題可以解決


我們一直在說Motion Matching是動畫驅動移動，它自身也是有一些問題的，比方說他的動作很寫實，動作寫實這個事情本身就是跟操作的靈敏度有矛盾。你可以想象一下，現實中你在高速地往前跑，突然有人要讓你往後，你肯定是來不及的，要一個急剎車，然後再回去才行。如果遊戲裡面也是這樣的話，它確實會影響操作的靈敏度。所以用了Motion Matching之後，本身就要權衡這個東西。所以需要在錄製的時候也要考慮好加減速的敏捷程度，要求演員要儘可能做到敏捷，這個對演員的運動能力也是有一定的要求。

第二個是它的各種效能問題，比方說它的記憶體佔用是非常高的，動畫資料量非常大，應對策略就是可以刪除沒有實際用到的幀。其實在錄製的時候，做一些統計工具，會發現中間有很多幀，到最後成品時是沒有用到的，這些可以抽掉，抽掉之後並不會影響動畫的質量，而且又可以節省記憶體。

第三個是它的運算量非常大的，因為前面說過他理論上就是去算每一幀到底哪個更合適。所以這個問題首先可以用多執行緒來解決，第二個是由於它的搜尋其實是一個多維搜尋，所以可以用KD去變成一個樹狀的搜尋，這樣可以極大地減少它的搜尋量。優化效果非常顯著，可以節省80%左右的CPU時間。

還有我們的cost計算是需要自己設計的，我們設計的維度越多，就會導致運算量越大。所以我們可以通過砍掉不必要的維度來減少運算量。其中Bone Match數量最好降到最少，我們只用選擇一些關鍵的骨骼，比方說腳、頭、手這些東西就行，當然這個也是需要根據專案來確定的，因為他並不是一個很固定的方式。

另外我們在錄製動畫的時候，一般會錄製2～3個迴圈，但就算是這樣，其實可能偶爾還是會有重複感的。比方說你們第一次看這個視訊的時候，會注意到火頭狼會轉刀，而這個到實際上在錄Motion Matching的時候是沒有錄在裡面的，這個是通過疊加動畫的方式疊加上去的。所以我們實際製作的時候先是自動摸索Motion Matching，Motion Matching的時候只要簡單地走就好了，然後再製作一個轉刀的動畫，把轉刀的動畫用addictive的方式疊加上去，就可以把這兩個動畫合起來。而且我還可以隨機決定他什麼時候轉刀，來避免這種重複的感覺。


最後對於一個龐大的體系，如果說每一個骨骼都要做一套的話，這個是很恐怖的。我們動畫藍圖目前是可以跨骨骼複用的，這也給我們一個好處就是我們可以做非常複雜的邏輯。右邊這個圖是我們實際的動畫藍圖，其實它還有很多別的內容，但是一屏截不下來，非常複雜。


在實操中，我們可以把動畫藍圖指定到一個本來不屬於它的骨骼上面，然後通過它再來組織我們的動畫資料。這樣對美術或者策劃來說比較易於配置，而且也比較容易實現載入，因為它還可以直接作為一個streaming的載體來完成動畫的載入。



好的，謝謝大家！

來源：遊戲陀螺
原文：https://mp.weixin.qq.com/s/lyGQsjICOQemy5jIBfTJsg