Unity中實(shí)現(xiàn)仿主機(jī)游戲的UI動(dòng)畫效果,unity3d中實(shí)現(xiàn)ui界面

Unity中實(shí)現(xiàn)仿主機(jī)游戲的UI動(dòng)畫效果

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

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

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

雖然肯定會(huì)有人說自己就是不喜歡UI動(dòng)畫，因?yàn)槔速M(fèi)時(shí)間，但游戲里什么元素不浪費(fèi)時(shí)間呢而且蘋果的成功，也證實(shí)了一般人在娛樂產(chǎn)品里其實(shí)是更傾向于有UI動(dòng)畫存在的。

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

這本來就是該做的事。

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

使用Animator而非DoTween

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

此外，因?yàn)樵诓簧儆螒蚶铮ū热绱炭托艞l奧德賽），它們都采取了滾動(dòng)時(shí)列表項(xiàng)漸顯的做法，就像下面這種：

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

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

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

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

用動(dòng)畫來掩飾加載延遲

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

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

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

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

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

動(dòng)畫的功能性

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

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

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

好在APP那邊已經(jīng)完成了攻城略地，多半不會(huì)再有人去爭論UI動(dòng)畫存在的必要性，而且資料也滿多的。我因?yàn)橐郧笆亲錾缃黄脚_(tái)應(yīng)用的，那邊的風(fēng)氣都是要將UI動(dòng)畫做到極致，所以在我眼里這一直都是理所當(dāng)然的事，當(dāng)時(shí)IPhone都還在娘胎里。

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

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

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

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

動(dòng)畫的時(shí)長

為了不讓動(dòng)畫招致反感，動(dòng)畫的時(shí)長必須要短。

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

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

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

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

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

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

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

3D方面

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

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

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

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

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

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

實(shí)現(xiàn)上的困難

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

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

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

但是并不會(huì)做的。因?yàn)橐郧皼]有這樣做，現(xiàn)在也不會(huì)這樣做。因?yàn)橐郧岸际浅绦蚱唇缑?，所以現(xiàn)在也是程序拼界面，即使現(xiàn)在從任何一個(gè)角度都找不到一丁點(diǎn)這樣安排的合理性。

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

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

所以問題就兩個(gè)：

1.沒有會(huì)做UI動(dòng)畫的人。

2.即使有，因?yàn)榱鞒掏耆e(cuò)誤，耗時(shí)多，效果差。

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

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

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

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

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

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