Unity中實現(xiàn)仿主機游戲的UI動畫效果,unity3d中實現(xiàn)ui界面-ESG跨境

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

Unity中實現(xiàn)仿主機游戲的UI動畫效果

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

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

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

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

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

這本來就是該做的事。

更何況，實現(xiàn)上，也并不困難。

使用Animator而非DoTween

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

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

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

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

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

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

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

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

缺陷是不能處理動態(tài)目標(biāo)的動畫，比如游標(biāo)移動。但這種情況非常少見。

設(shè)計一個通用的模板

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

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

然后再處理下列表項動畫的播放，差不多就能達到一個及格標(biāo)準(zhǔn)了。

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

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

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

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

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

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

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

用動畫來掩飾加載延遲

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

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

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

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

戰(zhàn)斗結(jié)束的結(jié)算動畫也可以作為回歸初始界面的加載準(zhǔn)備。

動畫的功能性

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

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

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

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

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

以下就是比較標(biāo)準(zhǔn)的例子，如果沒有動畫，用戶甚至都無法理解自己的操作產(chǎn)生了什么樣的結(jié)果。

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

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

動畫的時長

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

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

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

我一般的設(shè)置是：長時長0.5秒，中等時長0.25秒，短時長0.1秒。當(dāng)然，要根據(jù)實際情況波動。

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

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

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

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

3D方面

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

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

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

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

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

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

實現(xiàn)上的困難

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

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

當(dāng)然，不懂也可以現(xiàn)學(xué)。初學(xué)者無非就是做的不好，但是要做到比沒有好，并不困難。

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

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

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

所以問題就兩個：

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

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

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

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

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

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

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

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