Unity中實現仿主機游戲的UI動畫效果,unity3d中實現ui界面

Unity中實現仿主機游戲的UI動畫效果

在UI動畫上花費精力，最早是日本的游戲喜歡搞，歐美的游戲都非常不重視（比如暗黑2），其實我也不懂為何日本游戲這么重視這種東西，因為早期做這種東西還挺麻煩的，大概是他們對于小而美的追求吧……總之，后來的歐美游戲把日本游戲的優點全部學了去，鑄就了現在的霸主地位。

而這個問題的答案也很簡單：設備能跑，為什么不做為什么其他部分需要動畫UI就不需要，難道UI就不算美術的一部分了

要說我，國內極端不重視UI動畫，大概也是受了暗黑等一系列早期歐美游戲的影響。

雖然肯定會有人說自己就是不喜歡UI動畫，因為浪費時間，但游戲里什么元素不浪費時間呢而且蘋果的成功，也證實了一般人在娛樂產品里其實是更傾向于有UI動畫存在的。

所以我標題上雖然寫了主機游戲，指的其實是這種理所應當該有的UI動畫，用這個詞是方便大家理解，畢竟現在只要是個優秀游戲它的UI動畫都是做得很不錯的，不管在哪個平臺。

這本來就是該做的事。

更何況，實現上，也并不困難。

使用Animator而非DoTween

你我都清楚現在游戲里僅有的UI動畫是怎么做的。

但是代碼實現的動畫其實是很不方便的，它只適用于簡單的動畫，而且會導致這個工作和技術人員綁定。代替方案也簡單，就是Animator。

Animator其實創建動畫的操作也不復雜，Ctrl+6打開動畫面板然后直接創建就好了，生成的文件可以以后再改名。點擊錄制然后隨便K了就行了，默認的曲線設置大部分情況就夠用。

而且生成的動畫只要保證每條屬性的命名不變，可以在其他地方直接復用，像普通的縮放位移就可以做成通用的，倒時候把腳本復制一下就行。

Animator包含一個動畫狀態機，本身可以實現非常復雜的功能。不過大多數情況也用不上。我這為了減少工作量，就約定了兩個動畫名ShowAnimHideAnim，然后在游戲的主要UI容器類上提供了SetActive(bl)方法，創建或者顯示的時候播放容器下所有Animator的ShowAnim動畫，關閉和隱藏的時候要求調用SetActive(false)，這時候就會先播放所有Animator的HideAnim然后在播放完后隱藏界面，第一次SetActive(true)則是自動的，對技術人員而言也算隱藏的比較好。

由于界面可能分層，那Animator就可能在各層都存在一個實例。獲取容器下所有Animator就能同時啟動所有動畫（一般主動播放的都是隱藏動畫），大部分情況也可以兼容，就不用一個一個處理不同情況的動畫分支了。子界面之間的切換和父級界面之間的切換都可以用同一個動畫，處于不同狀態的界面也都可以正常退出。

大部分情況，HideAnim就是ShowAnim的倒序播放，不用重建動畫，復制ShowAnim然后將速度設為就可以，也可以適當加速。

動畫是可以在功能完成后再添加的，也可以在運行時編輯，只要操作可回溯調整起來很方便。不運行的時候也可以預覽和編輯。所以不管任何時候都是比DoTween更優越的。

缺陷是不能處理動態目標的動畫，比如游標移動。但這種情況非常少見。

設計一個通用的模板

切換動畫基本是由各個部分的顯示/消隱組成的，目地是要用動畫將不同界面連接起來。由于并不打算花費太大精力，一般的界面都遵循著通用的規律。分兩種：1.先播放前一個界面的隱藏，再播放后一個界面的出現；2.同時播放前一個界面的隱藏和后一個界面的出現。后者很簡單，就是普通的同時調用前一個界面的SetActive(false)和后一個界面的SetActive(true)，前者就需要寫個通用工具類來自動監聽事件，或者包裝在通用的視圖管理類里。

每個單獨分頁里，各級界面的關系鏈比較單一，甚至是一對一的，這時候的動畫就比較好處理，只靠顯隱控制就夠了。但是在多個分頁之間，由于每個分頁風格迥異，并且連背景圖都不同，隨便疊加很容易出現預期外的結果，所以選擇先播放前一個界面的消失，再播放下個界面的出現的方案。中間的背景過渡采用截屏的方式用一個短透明度過渡來處理。

然后再處理下列表項動畫的播放，差不多就能達到一個及格標準了。

列表項動畫僅僅實現很簡單，在重復列表項的預制上掛上Animator就可以，但列表項是需要一定間隔順序顯示的，數量也不固定，屬于動態內容，就需要用通用代碼管理。

這里就一步到位，把列表項復制的過程也和動畫一樣做了延遲，這樣復制列表項的成本就分攤到了多幀上，即使有復雜列表項也不會卡在初始化上。在一個循環列表上做這樣的處理其實是有一定困難的，尤其是在生成列表項的同時還允許滾動的前提下。所以嫌麻煩也可以選擇在這個時候鎖定輸入。

此外，因為在不少游戲里（比如刺客信條奧德賽），它們都采取了滾動時列表項漸顯的做法，就像下面這種：

這樣做可以一定程度緩解列表項邊緣區域過硬的問題，但我覺還有個作用是給列表項里的圖標預留加載時間，實際上這里的動畫是預留了幾幀完全透明的狀態的，足夠一般的圖標完成加載。

此外，咱這游戲其實只是做了最小限定的動畫內容，基本上還是怎么方便怎么來，曲線一般也都得是默認的，畢竟人力有限，也沒有這方面的競品對比壓力。但即使是復雜的動畫，也都是基于這種做法。大家可以去試圖拆分其他游戲里看到的特殊轉場，很大概率都可以拆解成不同界面的顯示/隱藏動畫連接，看起來連接著的部分其實兩個界面把同樣的元素恰好擺在同一個位置，然后在過渡的時候硬切。

具體的動畫用多層Mask和形變就可以實現，雖然性能較差，但也不在乎這點吧。而這就是一個純美術問題了。

但如果你以前做過Flash那個時代的交互動畫……其實也沒有看上去那么困難，就算是隨便試驗下也有概率出不錯的效果的，想要做到“比沒有好”還是比較容易的。

用動畫來掩飾加載延遲

正如同剛才所說的，動畫有時候不光是一種表現，同時也是一種化解卡頓感的手段。在缺乏常態動畫存在的界面里，是可以在用戶點擊后再同步加載相關內容，短暫的卡死只會被視為觸屏延時，但一旦存在循環動畫就會露餡了。

除了在空閑期后臺加載下個界面外，還有個技巧便是，你可以在上個界面的隱藏動畫開始的時候就加載下個界面，隱藏動畫雖然時間很短，但也足夠掩蓋下個界面的加載時間，畢竟這是將一幀的時長限制擴充到了原本的十幾倍。界面也可以拆分成多部分，然后各部分次序漸顯顯示，同樣也能爭取到很多時間。這樣動畫雖然浪費了時間，但有很大一部分是加載時間，也就不算虧。

這不僅僅可以用在ui加載上，同時也可以用在場景加載上。在顯示大塊內容前先用一個較長的動畫拖下時間，并在動畫時間內加載，就可以略去，或者縮短傳統的loading流程。比如一個正常的戰斗模塊加載，總時長可能也就7，8秒，你先用一個2秒的入場特效動畫拖一下，把場景加載出來，顯示場景后特效隱藏的時機里等待我方人物加載，播放人物的入場動畫，接著再用一個battle start的文字動畫拖時間，把敵方人物的資源加載完，正式開戰的時機其實和以前差不多，但是等待的焦灼感會削弱很多。實際上，玩家在意的不是等待，而是打斷。把等待時間轉變成一個動畫過程，等待過程似乎就被消除了。游戲里常見的開門側身過墻鉆洞都是這樣的設計。

戰斗入場特效最初的目的也是這個，只是不知國內廠商是不是這樣做的。如果是等全部加載完再老老實實播放個純耗時間的特效，或者播完特效再開始加載，就實在有些浪費了。

戰斗結束的結算動畫也可以作為回歸初始界面的加載準備。

動畫的功能性

UI動畫并不是個花架子，它本身也可以給予用戶額外提示，并且有輔助教學的作用。

最基本的規則是，變化的部分是動的，不變的地方是不動的。

具體動畫的代表含義，APP領域，交互設計講的夠多了。游戲UI也是UI的一部分，并不特殊。果粉整天吹噓的非線性動畫，也是其中微不足道的一項。

好在APP那邊已經完成了攻城略地，多半不會再有人去爭論UI動畫存在的必要性，而且資料也滿多的。我因為以前是做社交平臺應用的，那邊的風氣都是要將UI動畫做到極致，所以在我眼里這一直都是理所當然的事，當時IPhone都還在娘胎里。

總之，動畫大部分時候不是為了美觀，而是具有特定的功能的。沒有功能的動畫要盡量少做，和功能相悖的動畫原則上則是不能做的。

以下就是比較標準的例子，如果沒有動畫，用戶甚至都無法理解自己的操作產生了什么樣的結果。

而且動畫本身帶來的激勵效果本身也是獎勵的一部分。明明投放了收益，卻沒有讓用戶察覺，是非常蠢的。

技術人員或許會對第二張圖里的圖標歸位感興趣。這個列表雖然是個循環列表，每個數據對應的GameObject都是不固定的，但是它們所在的位置卻是固定的。所以在刪除格子前先記錄每個數據對應的位置，然后完整刷新列表重新生成所有GameObject，再根據之前記錄的位置把格子移到原本的位置，接著播放一次移動到當前位置的動畫。這樣原本不在區域內的格子也就能顯示出來了。

動畫的時長

為了不讓動畫招致反感，動畫的時長必須要短。

大部分情況下，動畫并不是目的，而是為了達成對應的功能。長時長的動畫表達重要的行為，短時長的動畫表達不重要的行為，而這個長短則是相對的。

所以，在用戶很夠看清的前提下，動畫時長應該能短則短。

我一般的設置是：長時長0.5秒，中等時長0.25秒，短時長0.1秒。當然，要根據實際情況波動。

長時長動畫是少見的，所以大部分動畫都在0.25秒左右。而0.25秒也差不多是人類的極限反應時間，等到他們反應過來的時候動畫已經播完了，就不會嫌棄動畫阻礙他們的操作了。

然而在動畫時長如此短的情況下，如果基礎幀率只有30，那么整個動畫就只有7.5幀，考慮到前后還有加減速的過程，中間快速移動部分的將會更快，每幀移動的位置就會更大，也就會產生很強烈的畫面跳幀的感覺，也就是卡頓。所以想要使用這個數值，幀率達到60是很有必要的。或者就要重新設置動畫曲線，讓它中間的速度降低一些，但這樣一來好好的非線性動畫也就沒了。

動態模糊理論上也能解決這個問題，但是哪可能用

所以，60FPS對于UI動畫來講非常重要，可以的話還是要盡量達到，這就對其他地方的性能有了更高的要求。如果不能達到，就只能減慢動畫速度一倍，或者減少大幅度的位移來回避這個問題。

3D方面

使用3DUI可以提升畫面的縱深感，讓畫面的線條更加多樣，避免死板。

3DUI遇到的第一個問題就是邊緣鋸齒，這個問題在斜線上也同樣存在。解決方案是在貼圖外圈預留一像素透明邊，效果和傳統反鋸齒的結果很類似。所以UI不需要依賴反鋸齒功能的。

UI通常不開啟mipMap，這是因為UI通常并不會出現高倍率的圖片縮放，3D界面為了維持可用性傾角也很小。但如果確實出現了線條走樣問題，就需要開啟mipMap。

UGUI對3DUI的支持非常糟糕，它的自動更改顯示順序合批的功能在3D界面中會失效，但是相鄰的UI組件依然可以按材質合批，如果打好圖集還是能處理掉很多Pass的。一個界面通常除了圖標都處于同一個圖集里，只有文本使用不同材質，所以只要把文本和非文本分開就能解決大部分的合批失效問題。所以可以用腳本始終同步文本的位置，讓他們相對于背景移動，而不是依賴原本的父子級關系。

其他方案也不是沒有，但都很麻煩。

這可以算是UGUI一個非常嚴重的缺陷，多半是因為使用3DUI的游戲過少的原因。其他開源或者支持手動設置depth的UI系統就沒這問題。但是如果不使用UGUI，性能又不足以在界面動畫中保持幀率，會更加得不償失。至少，UGUI的問題還是可以花力氣解決的，只要保證Pass數量不要超過戰斗中的平均值，都還在可接受的范疇內。

實現上的困難

根本問題在于，國內的大部分UI設計師其實根本就不懂UI動畫。

美術也是同樣是分類別的，跨類別的時候，不懂就是不懂。所以即使硬讓他們設計也設計不出來。他們不能的話，其他人也同樣不能。簡而言之，就是公司沒有符合要求的人，公司也不認為應該招募和培養這樣的人。

當然，不懂也可以現學。初學者無非就是做的不好，但是要做到比沒有好，并不困難。

但是并不會做的。因為以前沒有這樣做，現在也不會這樣做。因為以前都是程序拼界面，所以現在也是程序拼界面，即使現在從任何一個角度都找不到一丁點這樣安排的合理性。

但這樣安排，就是做不出來。即使做出來，付出的成本和代價也很高。

UI動畫本身是非常簡單的，但是沒有專業的人來做，再簡單的東西都會變得很困難。現在常態的做法就是美術/策劃提需求，然后技術實現。但動畫本身也是美術的一種，是需要通過試錯來逼近最優解的，這樣做根本無法進行多次迭代，效果自然不會好。而提需求的成本也會導致需求量降低。

所以問題就兩個：

1.沒有會做UI動畫的人。

2.即使有，因為流程完全錯誤，耗時多，效果差。

所以我們需要先找一個會做UI動畫的人（愿意自己學著做的也行），然后教會他如何使用Animator，告訴他和功能相關的約定，并把他插入到拼界面的流程后面去。

這只能解決通用UI動畫的問題。遇到不通用的，則需要他和技術商量解決方案。

但還有一種情況是這樣也解決不了的：并不是所有的動畫都可以用Animator實現，這樣美術就很難參與到迭代流程里，需要在技術之間來回打轉耗費大量時間，難產的概率就會非常高。

這里就需要專長UI動畫的TA上場，但在TA的定義都被扭曲的不成樣子的現在，提這個似乎也沒有什么意義。

但是沒有就是做不出來，想做出來就必須有，歸根結底還是看需求的緊迫性了，國內市場顯然一點都不緊迫。

特別聲明：以上文章內容僅代表作者本人觀點，不代表ESG跨境電商觀點或立場。如有關于作品內容、版權或其它問題請于作品發表后的30日內與ESG跨境電商聯系。