威狐小編:，2020年11月16日至20日，中國統(tǒng)一在線技術(shù)大會現(xiàn)場舉行，為開發(fā)者帶來了一場分享尖端技術(shù)和優(yōu)秀案例的在線活動。在19日的比賽中，鷹角網(wǎng)絡(luò)首席執(zhí)行官黃一峰和副總裁海茂出席了Eagle Corner網(wǎng)絡(luò)明星產(chǎn)品明日Ark的開發(fā)過程，以及3D和2D在產(chǎn)品開發(fā)過程中的結(jié)合。

以下為致辭全文：

大家好！我是明天方舟制作一個人海貓情結(jié)。黃一峰也會被要求和我談?wù)勥@個分享。

今天我們要討論的主題是創(chuàng)業(yè)團隊的曲折發(fā)展，它將主要與明天方舟的3D和2D解決方案一起分享。讓我做一些前面對最早概念的介紹，由黃一鳳介紹在我們的3D和2D組合方案中遇到的具體問題和具體解決方案。

首先，我是一個海貓復(fù)合體，我是明日方舟的制作人，我也是上海鷹角網(wǎng)絡(luò)的聯(lián)合創(chuàng)始人。我將主要負(fù)責(zé)UI和游戲的一些部分。

明天方舟簡介。明天方舟是2017年推出鷹角網(wǎng)絡(luò)的第一款游戲，當(dāng)時我們也進入了正式開發(fā)階段。從2017年12月到2019年3月，我們共進行了三次測試，最終于2019年5月1日迎來了整個平臺的公開測試。目前，明日方舟是鷹角網(wǎng)絡(luò)的唯一工作，也是我們第一項創(chuàng)業(yè)的工作。

這部作品相對側(cè)重于獨特的風(fēng)格和視覺表現(xiàn)。由于我們的游戲游戲和視覺表現(xiàn)都有很強的自我風(fēng)格和高質(zhì)量，所以當(dāng)我們上線時，我們也得到了應(yīng)用商店的特別推薦。

這款游戲具體的玩法可以從圖中看到，它是一個由策略、塔防、RPG相結(jié)合的玩法，是采用Unity開發(fā)的，同時也是考慮到技術(shù)的實現(xiàn)，我們采用了一個2D和3D相結(jié)合的表現(xiàn)形式。在角色上我們是采用了日式的一個二次元的表達(dá)手法，但是不同于大部分的二次元游戲，我們的角色的一部分元素表達(dá)和故事世界觀以及場景概念設(shè)計上的風(fēng)格都是偏向于寫實的。

可以看一下我們最早原先設(shè)置的時候是左邊一張圖，這張圖是我們當(dāng)時用Unity開發(fā)的原型，可以看到與右邊目前我們游戲的實際畫面是有較大差距的。也是借助與Unity相對的便利性，我們能夠在早期進行一個原型的實現(xiàn)，我們采用了一些臨時的素材將我們的很多想法付諸現(xiàn)實。

考慮到了一個問題，為什么我們當(dāng)初最早開發(fā)的時候會使用Unity？除了我們自身的經(jīng)驗之外，我們當(dāng)時也會有一些現(xiàn)實的原因和一些設(shè)想，讓我們選擇了Unity這款引擎。

2016年的時候我和我們的主創(chuàng)黃一峰在家里構(gòu)思作品，當(dāng)時我們需要盡快一個大致的共識，為了《明日方舟》的具體風(fēng)格而定下早期基調(diào)。我當(dāng)時發(fā)給了他一張圖，就是我們最早奠定世界觀的一張圖，在這張圖之后，我就說我已經(jīng)準(zhǔn)備好開始了，黃一峰當(dāng)時也回答我說好，那么立刻開始把我們的作品進行具體的實現(xiàn)。

當(dāng)時剛開始肯定會遇到很多的困境，對于我們來說，當(dāng)時我們的困境非常之多，尤其是我們很多是大學(xué)剛畢業(yè)，有些是從業(yè)只進行了一個項目，所以人數(shù)非常少。面對我們一些具體的情況，我們也做了一些具體的分析。對當(dāng)時的我們來說有一些點是非常明顯的，比如我們團隊較小，因為我們的狀態(tài)是一個應(yīng)屆畢業(yè)和從業(yè)時間不長的狀態(tài)，我們當(dāng)時創(chuàng)業(yè)團隊人數(shù)也非常少，只有4到6人，至今的情況也不多，并沒有像一些創(chuàng)業(yè)團隊那樣可能帶了大量的資金或者是大量的團隊來，同時，我們自己也是平時接觸的作品非常之多，所以對于第一款創(chuàng)業(yè)的作品也是提出了很高的質(zhì)量的要求。

但是很明顯面對高要求，我們又沒有較好的技術(shù)積累去實現(xiàn)心目中非常理想的游戲作品，缺少一些開發(fā)經(jīng)驗，所以，我們當(dāng)時還需要面對的是缺少經(jīng)驗，又對自己的要求高，那么應(yīng)該怎么實現(xiàn)？還有一個隱性的條件就是當(dāng)時的游戲市場變幻莫測，即使是現(xiàn)在也是變幻莫測，但是當(dāng)時對我們來說沒有更多的技術(shù)積累，所以會更加不清楚自己應(yīng)該往哪個方向發(fā)展。

我們對這方面也是進行了一些思考，具體看一下當(dāng)時的情況。我們當(dāng)時也是非常拮據(jù)的，在一個小的公寓內(nèi)進行開發(fā)，大家有種田園牧歌的狀態(tài)。人員比較少的時候我們也發(fā)現(xiàn)團隊中沒有相對來說成功3D項目經(jīng)驗隊，我們在這個基礎(chǔ)條件下最初不會考慮3D開發(fā)的部分，但是很明顯我們又想去做那方面，所以我們當(dāng)時做了一些妥協(xié)。比如我們將我們的地圖分成了3D。

第二個是我們對質(zhì)量要求比較高。從現(xiàn)在來看《明日方舟》整個作品的調(diào)性中包含了許多我們想要追求的點。

比如從這張圖上可以看到根據(jù)這個圈的大小涵蓋范圍也可以知道我們許多點是相輔相成的，可能缺一不可，尤其是以日系角色美術(shù)為核心，寫實風(fēng)格設(shè)計輔助的一個基本美術(shù)框架，之外還有一個世界觀故事的設(shè)置。

我們自己追求另外一個重要的點是有樂趣和深度的game play的部分。除此之外還有我們的品牌形象、游戲運營和自媒體的風(fēng)格，我們非常想在作品中實現(xiàn)這些點。

從現(xiàn)在來看，《明日方舟》的整體項目有比較多的點上是往寫實方向走。我們當(dāng)時是采用了自己能夠?qū)崿F(xiàn)的方式去完成我們的作品。比如剛剛提到了一點，我們通過相對偏日系一些的二次元的風(fēng)格實現(xiàn)我們角色的表現(xiàn)，但是我們想更多地追求一些寫實風(fēng)格的東西，我們在整個故事的框架設(shè)計之外向外推導(dǎo)往寫實的方向走。

所以我們那些活動有一些設(shè)計，讓它顯得更加自恰，能夠符合世界觀，也能更加符合現(xiàn)代設(shè)計。從角色到故事，再從故事到世界觀，有一個風(fēng)格的推演，越來越寫實，越來越偏向我們想要追逐美術(shù)的寫實性表達(dá)。

因為我們過去活躍在同人圈，一些創(chuàng)作圈中也嘗試去創(chuàng)作過一些同人游戲，所以對自己，不是說簡單做一個作品就結(jié)束了，我們還是希望能夠?qū)崿F(xiàn)一些對自己的超越。很明顯的在這些方面都對自己有了比較高的要求。但是，過去因為同人游戲或同人本的載體相對來說還沒有面向那么多的用戶，沒有影響多那么多的讀者或玩家，自然要求會變低。但是，我們現(xiàn)在接觸的領(lǐng)域更大，所以我們對自己的要求也會變高。

在種種情況之下，我們自己心中想做的作品確實如圖上所說的一些，就像《賽博朋克2077》，我們未來是想嘗試往3A做，但很明顯的自己知道當(dāng)時的能力水平是沒有到這個程度的，是做不到這種程度的，我們現(xiàn)在需要找到更加現(xiàn)實的方法完成這一系列。

后來通過我們的創(chuàng)作對這個項目進行了一些早期的規(guī)劃，包括在圖中能夠看到，就以及我們最早對概念的構(gòu)想，也得益于我們當(dāng)時的概念構(gòu)想形成得比較快，后面就對自己的風(fēng)格把握得比較牢固。

在此基礎(chǔ)上，另外一條線也能順利地鋪開，對玩法進行探究。其實可以看到當(dāng)時的情況，我們幾位成員，還有其他的核心成員這邊沒有列出來。我們列舉了一些在公共場合露過面以及大家可能比較熟悉的成員。

我們每個人都會發(fā)現(xiàn)對自己熟悉的領(lǐng)域都有較高的要求。比如我自己需要追求一個比較優(yōu)秀的視覺設(shè)計風(fēng)格，而黃一峰會要求需要技術(shù)選型、品質(zhì)穩(wěn)定、可擴展，他對于程序方面有較高的要求，而RUA負(fù)責(zé)我們的玩法策劃，關(guān)卡策劃，他對自己的玩法深度要求也會非常高，而負(fù)責(zé)美術(shù)總監(jiān)的唯老師對美術(shù)品質(zhì)自然是有非常高的要求。還有其他的成員也有其他的要求。在這些要求的結(jié)合之下，對于當(dāng)時的團隊情況來說其實是非常艱巨的，如何在一個我們自己都不太清楚的該是怎么樣的項目中實現(xiàn)這些要求，就會遇到很多的問題。

總結(jié)下來，我們當(dāng)時面臨的一些困難具體的情況，小團隊只有4到6人，資金也比較少，沒有足夠的資金去招人或鋪開外包，或者是招募更多人加入設(shè)計，對質(zhì)量尤其是對美術(shù)有著較高的要求，這樣我們在3D、2D方面也會產(chǎn)生一些沖突。更關(guān)鍵的是，雖然我們有過成功的項目經(jīng)驗，但是大家都很年輕，尤其是3D開發(fā)相關(guān)的一些經(jīng)驗非常不足。

當(dāng)時對于3D和2D來說有明確沖突，那我們究竟該怎么做呢？作為一個日式畫風(fēng)，以角色為主具有高美術(shù)要求的作品來說，3D項目的方向可能對我們來說非常不現(xiàn)實。因為3D項目通常需要更多的美術(shù)資源、人手和資金，而通常也需要大量的時間，還需要大量的投入。我們在沒有這些技術(shù)的情況下很明顯是沒有辦法實現(xiàn)這些。但是，未來也希望向3D做一些鋪墊，所以當(dāng)時沒有完全放棄3D方面的探索，大家在圖中能看到，我們在關(guān)卡方面是采用了一些3D，想做一些技術(shù)積累，讓我們未來能夠更好地接觸3D方面的開發(fā)。

我們也會看一下早期的圖，我們當(dāng)時在自己的案板上對游戲最早的風(fēng)格、玩法進行了很多的探索。左邊是一張非常不太清楚的圖，從圖上能看到網(wǎng)格化這個設(shè)計最早就提出了，大家可以看到中間有一塊菱形的場地，這是我們最早關(guān)于網(wǎng)格和地圖的設(shè)置，我們也遇到了一個問題就是45度角和90度角該如何排布的問題。后面我們嘗試做了概念設(shè)計，通過一些快速的素材堆積和簡單的探索把我們想要的游戲的感覺嘗試做了出來，而這圖中有些臨時素材與最后的成品是有差距，可以不用管它。從這張圖中可以看到我們最早想要實現(xiàn)的感覺，在這張圖中得到了探索，并且一定程度上影響了我們后續(xù)游戲的制作風(fēng)格。

當(dāng)時在這個情況下，90度角的網(wǎng)格化的設(shè)計已經(jīng)有雛形。當(dāng)時也想通過這個更好地探索我們的游戲，在這種情況下Unity的優(yōu)勢就會發(fā)揮出來。我們當(dāng)時確定了游戲以什么形式發(fā)布，我們當(dāng)時瞄準(zhǔn)的是手游這塊，很明顯跨平臺讓開發(fā)的可能性變得更加多樣，這是Unity的一大亮點。

當(dāng)時的情況是Unity的社區(qū)相對完善，它能夠讓我們在一個非常初創(chuàng)的缺乏經(jīng)驗的團隊里找到比較好的解決方案，讓很多的開發(fā)困難迎刃而解。同時，以Unity，3D開發(fā)的游戲項目，哪怕是軟件方面成功案例是相當(dāng)之多，能讓我們找到一些技術(shù)參照，我們該采用什么樣的方式開發(fā)我們的作品，或者說我們未來能夠做到什么樣的程度。同時，優(yōu)秀技術(shù)支持也讓我們想實現(xiàn)的新的東西有更多的可能性。還有一個最關(guān)鍵的就是有很多的小型項目在Unity的幫助下能較好地完成。U3D對于小項目的開發(fā)友好性我們認(rèn)為非常強，這也是讓我們選擇Unity的一個大原因。它作為一款成熟的跨平臺商業(yè)引擎對我們來說是當(dāng)時最好的選擇。

在選擇完采用的方式進行開發(fā)后，整個過程仍然有許多困難，可以用曲折前行這個詞來形容。我們當(dāng)時用Unity進行了一些快速的原型開發(fā)，除了剛才說的版本以外，還有一些別的版本。

我們最早出現(xiàn)了兩種原型，一種是我們目前采用的，左邊這種，和現(xiàn)在《明日方舟》游戲玩法較為接近，我們叫做5×5的模型，它和傳統(tǒng)塔防不太一樣的是場地非常之小，采用的角色數(shù)量可能較少，并且對于方向和網(wǎng)格的差異性設(shè)置要求相對之高。

右邊我們也采取了一個模型，有點類似目前常見的傳統(tǒng)塔防，地圖相對之大，它的角色目前我們是沒有放上去的，但是我們這個模型中角色的攻擊范圍沒有像現(xiàn)在的《明日方舟》網(wǎng)格化差異是如此大。它也有一些特點，比如恢復(fù)cost是通過地圖上的一些機關(guān)來完成，但是它總體來說有兩個問題是造成我們最終沒有選擇它的原因。一個是它的范圍設(shè)計不符合我們自己想要做的創(chuàng)新，就是對于網(wǎng)格的差異性讓我們每個角色有不同的使用感受。這點是我們選擇它的原因之一。

還有一點是在手機上進行實現(xiàn)的時候，這個地圖相對來說較大，體驗起來不但角色的表現(xiàn)性相對較弱，對我們美術(shù)的表達(dá)也造成了困難。所以，我們基于一些體驗和感受后決定采用了最早的5×5的方案，不過這個地圖不是5×5的，但是這是我們的統(tǒng)稱。

所以，我們決定原型之后也能借由U3D的特質(zhì)，使用我們過去的資產(chǎn)和新做的素材快速地迭代。

這是我們最早地圖的原型，能夠看到基本和我們現(xiàn)在游戲方式是比較接近的，包括角色的方向、數(shù)值、性能，還有一些地圖的基本方式，相對來說和現(xiàn)在非常接近。

我們在最后2年的跨度之中，將最早的原型，基于Unity轉(zhuǎn)化成了現(xiàn)實，是個很漫長的過程，但是利用Unity的很多便利性，能夠?qū)⑽覀兊南敕ǜ吨T現(xiàn)實。所以，最終我們認(rèn)為采用Unity是我們對內(nèi)容追求的一個最好的方式。

我們通過Unity解決了很多方面的進化，讓問題得到快速解決，也讓我們有更多的時間實現(xiàn)我們最早對于質(zhì)量方面的要求，我們能夠把精力放到內(nèi)容的制作中，最終完成《明日方舟》這樣的作品。

最終我們上線的時候人數(shù)規(guī)模差不多達(dá)到了30到40人的團隊，得益于Unity的U3D開發(fā)經(jīng)驗較為豐富的社區(qū)，我們也能快速地補充人力完成我們對游戲的開發(fā)。

我大致分享的部分就是這樣，之后會讓黃一峰介紹一下《明日方舟》具體在2D和3D開發(fā)案例中遇到的一些問題。

黃一峰：大家好！我是黃一峰，是《明日方舟》前期開發(fā)當(dāng)中的技術(shù)負(fù)責(zé)人，也是上海鷹角網(wǎng)絡(luò)的聯(lián)合創(chuàng)始人之一。剛剛我的同事海貓從他的視角講述了《明日方舟》從0到1的故事，接下來我將從我的視角，從更偏技術(shù)的角度來講述為什么我們會選擇3D和2D結(jié)合的這樣一個畫面表現(xiàn)方案，我們做出了哪些工程和技術(shù)上的取舍，我會盡量以合適的力度講解，希望能給類似選型的項目一些提示，避免重復(fù)踩坑。

接下來是一個大致的大綱。首先我會介紹我們?yōu)槭裁磿x擇3D和2D結(jié)合的方案？而這個角度可能和剛剛海貓講的不太一樣。第二，我會說一下我們方案的具體內(nèi)容，包括場景和單位兩個維度。第三，我會詳細(xì)地說明我們在開發(fā)過程中遇到的三個我們認(rèn)為比較有典型意義的問題，希望能夠給大家?guī)硪恍┨崾尽?/p>

首先，相信不是所有在座的同學(xué)都了解或玩過《明日方舟》，我會首先播放一段15秒鐘的戰(zhàn)斗視頻，這段視頻是來自我們今年夏季的活動“密林悍將歸來”。

大家可以看到整個畫面的風(fēng)格與感覺是偏于2D畫面為主，無論是角色，角色的特效、彈道以及敵人包括視角是固定的，是一個2D為主的游戲。但比較特別的是我們在場景的方案上選用了3D的一個模型和偏寫實的渲染。整個場景的建模、打光、渲染都是用偏寫實化的方式實現(xiàn)，制作和渲染都是用標(biāo)準(zhǔn)的PBR工作流。

這個結(jié)合是相對比較罕見的，也是今天我們描述的一個重點。整個戰(zhàn)斗畫面的攝像機是非正交的，就是我們傳統(tǒng)所說的透視相機，單位和場景的空間關(guān)系實際上是比較特別的，接下來我也會在遇到問題的環(huán)節(jié)詳細(xì)地進行描述，大家可以再看看這個戰(zhàn)斗畫面。

為什么我們會使用3D和2D結(jié)合這樣一個方案？剛才海貓做了一些講解。我認(rèn)為比較簡單，3D寫實風(fēng)格可以較好地匹配《明日方舟》相對嚴(yán)肅的世界觀和我們比較特別的美術(shù)風(fēng)格。而2D的Q版小人可以較好地展現(xiàn)角色的魅力，避免top-down視角的局限性。

大家可以回憶top-down的游戲，尤其是像我們這種基本是從俯視角看戰(zhàn)斗場景的游戲，角色的絕大部分都被它的頭頂給遮住，所以看到角色實際上不太能夠看到它的動畫細(xì)節(jié)以及身上的服飾細(xì)節(jié)，大部分都是個大頭。我們?yōu)榱吮苊膺@個問題，決定使用2D Q版小人。當(dāng)然最重要的問題是我們作為一個初創(chuàng)團隊，我們希望能夠盡量地降低風(fēng)險，所以我們希望能選擇相對市面上比較成熟的2D動畫方案，而去避免當(dāng)時我們認(rèn)為還沒有特別好參考的3D小人的方案。當(dāng)然，現(xiàn)在有很多友商已經(jīng)做得很好了。

同時，我們想實踐3D開發(fā)的流程，積累一些3D開發(fā)的管線和工作經(jīng)驗，所以我們最后選擇了這樣一個特殊的選型。選擇這個選型有很多現(xiàn)實因素，但是最后實踐下來我們認(rèn)為它是別具一番風(fēng)味的，相當(dāng)特別。

好，這張概念剛剛展示過，是由海貓在我們項目早期立項初期創(chuàng)作的一張圖，這張圖創(chuàng)作的時候我們一行代碼都還沒有開始寫。這張圖是為了給整個團隊的成員統(tǒng)一的認(rèn)識，我們這個游戲究竟會長成什么樣，可以從繁瑣或者抽象的策劃案中具體地落到到這樣一個視覺的概念上。

可以看到這張圖中的很多要素和我們現(xiàn)在的選型是一致的，包括3D的場景，包括2D的小人這里面模糊掉了，包括整個攝像機透視的方向，其實和我們現(xiàn)在的選型高度相似，這也是我們比較幸運的一點。

大家可以看到比較特別的是左下角有個小人是垂直站在場景上的，但是這個垂直站在場景上的行為符合場景和角色的關(guān)系，但是卻不符合我們視角的比較好看的關(guān)系，那個像紙片，這個問題也是為之后的開發(fā)埋下了一些伏筆。

這兩張圖是我們早期的一些設(shè)計和參考圖。左邊這張圖是早期的Q版小人，我們一共有8個小人，而Q版小人上我們的選型和當(dāng)時主流的身比小的主題不同，我們選擇了相對它的腿和身子會更長一些，頭身比相對更大一些，而這個方向我們?nèi)诤狭艘恍┟朗絈版小人的風(fēng)格。

右邊這張參考圖是ArtStation一位藝術(shù)家的作品，但是我們看到，我們認(rèn)為它非常符合我們對3D場景包括對寫實場景的一個審美。首先它的作畫風(fēng)格是偏風(fēng)格化的寫實，其次，整個構(gòu)圖是以網(wǎng)格為核心單元，并非是以我們最后選用的四邊形或者是正方形的往格，而是使用了正六邊形的網(wǎng)格。但是總體來說，整個這樣的視覺感覺非常符合我們預(yù)期，所以我們也把它作為我們創(chuàng)作的參考。

然后是視覺方案的詳細(xì)的描述。我們分為兩部分，第一部分是場景，場景包括3D的網(wǎng)格狀地圖，地圖周邊的那些擺件，地圖背后的遠(yuǎn)景，以及地圖上可交互或裝飾性的小物件，所有3D的模型都是使用標(biāo)準(zhǔn)的PBR工作流制作，在美術(shù)同學(xué)的雕刻上會特意做一些畫面化的風(fēng)格化的雕刻，但不會追求較低面線的方式實現(xiàn)一個卡通的效果，我們的面數(shù)相對比較高。

第二，在貼圖繪制上我們會做一些風(fēng)格化的嘗試，但總體來說我們并非做一個比較常見的日式RPG或者類似游戲的卡通化風(fēng)格，我們希望用更寫實的風(fēng)格做到一些差異化。

在Shader上，我們采用的光照模型是基于Unity Standard Shader修改得到的PBR Shader。之所以不使用Unity默認(rèn)的Standard Shader是因為我們對它進行了針對性的優(yōu)化，同時還添加了一些我們所需要的功能。

第二部分，單位。單位包括角色、敵人、第三方單位以及很多可交戶的2D物件等等。所有的2D動畫我們都是使用Spine骨骼動畫軟件進行制作。在著色上我們使用了經(jīng)過特殊處理的一個Unlit的Shader，它不會受到任何的動態(tài)光照和動態(tài)陰影的影響，之所以選擇這樣的方式，并非完全源于我們的技術(shù)限制，同時也是因為我們經(jīng)過實驗發(fā)現(xiàn)，如果我們做的更加激進一點，整個場景的角色和敵人的辨識度會變得更差，玩家在玩的時候可能不太能分辨出來哪些是他需要關(guān)注的東西。這部分也是接下來我們進一步推進這個畫面表現(xiàn)所需要處理的問題，如何平衡game play和視覺效果。

我們場景的視覺方案會由這三張圖作最直觀的展現(xiàn)。接下來三張圖都是我們實際的渲染圖。

第一張可以看到密林這樣的場景，可以看到場景細(xì)節(jié)和這個地塊，而第二個場景是一個熔巖洞窟的場景。

第三圖是我們故事發(fā)生的主要地點，龍門夜晚的場景。

大家可以看到這三張圖，在建模上面我們使用了高度抽象化的以格點為核心的構(gòu)架的方式，整體的光照細(xì)節(jié)、模型貼圖細(xì)節(jié)以及一些周邊的裝飾系，像一些建筑物和一些管道都非常寫實。

我們的整個視覺方案如下，首先我們的場景是使用Unity PBR渲染模型的，在Shader上我們采用的是略微優(yōu)化和修改后的BRDF2，在性能上進行了一些調(diào)優(yōu)，并且添加了我們可著色的陰影，在PBR Shader層面實現(xiàn)了高度物，也適配我們某些場景一些特殊的效果。

在Lightmap上面，我們在Shader里面對Lightmap的編碼和解碼進行了一些特殊處理，使它在所有平臺上能達(dá)到一致性更好的效果，這點我之后會在問題階段詳細(xì)描述它的細(xì)節(jié)。

我們每個場景都會使用Unity靜態(tài)烘焙的方案，會烘出兩張圖，一張Lightmap，一張Shadowmask，會有比較細(xì)膩的光影和陰影的表現(xiàn)。在打光方案上會有一盞混合動態(tài)光，這相當(dāng)于我們在運行時只有一盞動態(tài)光會配很多靜態(tài)烘焙光的方式來做打光方案，并且在特殊的情況下我們會添加更多的探針做一些靜態(tài)的反射，為某些場景添加一些必要的視覺效果。

除了整個模型之外，我們在場景上會添加一些Unity提供的添加方案，一些傳統(tǒng)的濾鏡特效和模型特效。大家可以看到剛剛的視頻中有一個瀑布，就是用特效實現(xiàn)，會增加一些風(fēng)味。

接下來是角色的視覺方案。我們絕大部分的角色在右邊這張圖中可以看到，我們的SPINE工程當(dāng)中實際是用了正反兩個面做每個角色的。

為什么這么做？我們參考了類似的游戲，很多2D游戲?qū)嶋H上只有正面一面，但是在動作上會刻意地避開像沖刺、穿刺這樣方向性很強的動作，而選擇畫面中德克薩斯使用的半圓的圓弧斬的方式，這樣能模糊方向性，但是這樣會極大地限制我們美術(shù)工作者對于動作的創(chuàng)作包括武器的創(chuàng)作，所以在權(quán)衡之后，我們還是選擇了把絕大部分角色做兩面，做一個動作的拆分，而其他的角色以及不太重要的第三方單位，我們就會使用單面的方式。

整個這樣一個方式可以看到在正面和反面的轉(zhuǎn)變過程中，我們是做了一個類似于紙片人轉(zhuǎn)變的動畫。這個動畫我們的靈感來自于任天堂一款著名的游戲系列《紙片馬里奧》里面一個類似的畫面，對比看一下，我們游戲的效果和這個是比較接近的。

好，接下來我會詳細(xì)地描述幾個在開發(fā)過程中遇到的問題。這些問題都是源自于我們?nèi)诤?D場景2D角色做一個結(jié)合。因為這個方案比較少見，所以遇到問題也比較少見，希望給大家?guī)硪恍┨崾尽?/p>

首先第一個是空間關(guān)系錯誤，剛剛我也已經(jīng)提到過，我們場景和攝像機，攝像機并不是垂直于場景，它實際上和場景的X、Y平面呈一個60度夾角的關(guān)系，而角色，因為我們要展現(xiàn)角色，肯定是對著場景，對著攝像機，它是垂直于場景的方向的，通過簡單的幾何關(guān)系可以得出場景的X、Y平面和角色的夾角實際上是30度，也就是說我們的角色并不是站在場景上，而是斜躺在場景上，或者說是躺在場景上。它實際上是一個斜插的東西，它的結(jié)果可能是極易穿模，這里說可能不太直觀，大家可以看一下這張圖。

最左邊的圖就是我剛剛描述的合理空間關(guān)系，但由于角色后面的地塊它的模型非常高，所以說它的頭是插在模型當(dāng)中的，形成了穿模。

為了解決這個問題，有的同學(xué)可能會說，把這個角色給調(diào)整到垂直場景不就解決問題了嗎？那么我們最右邊這張圖就是把角色調(diào)整到垂直于場景，這個時候它和場景的關(guān)系對了，深度關(guān)系也對了，但是看起來非常奇怪，像紙片人。

這種情況下，如果我們調(diào)整一下攝像機的角度，比如像中間這張圖一樣，調(diào)整到能夠正常地平視這個角色，那整個空間關(guān)系看起來是正確的，只是這樣一來我們的游戲是沒法玩的，因為攝像機只能以這個角度去看，玩家是沒法操作的。

為了解決這個問題，我們最后達(dá)到的效果是希望像左邊這樣，但是能解決穿模的問題。這其中曾經(jīng)經(jīng)歷了一個錯誤的思路，也就是我們渲染的時候關(guān)閉了一些test，同時Z-write也不大，我們把整個場景中的模型、擺件和角色都通過一個深度混排的方式，手動對它排序，類似于傳統(tǒng)2D游戲的處理方式。我們手動排序之后手動去歸置，這樣確實能達(dá)到相對比較正確的結(jié)果，但是會帶來兩個主要的問題。第一個就是我們會破壞這個合批，打破它靜態(tài)的一個batching。

因為我們整個場景是一個靜態(tài)，包括它的光照貼圖和陰影貼圖，我們在渲染的時候可以用相當(dāng)?shù)偷腄rawCall做到所有的場景，絕大部分場景的DrawCall都在個位數(shù)。如果需要混排，需要打亂角色前、角色后的順序，我們會增加非常多的DrawCall。

其次，我們會有一些小擺件，比如場景上的一些樹木是跨兩個格點的，這些小擺件我們大家對它進行排序就很難知道它到底在哪一層。

最后我們解決的思路是讓角色需要看起來垂直于攝像機，但實際上垂直于場景的。這個聽起來有點抽象，待會兒我們會展示圖片。那么我們解決方案實際上是把深度進行一個調(diào)整，在Unity當(dāng)中擺位或者是在場景當(dāng)中的位置和著色，它的角色都是垂直于攝像機的，也就是躺在場景上的。而在Vertex Shader最后我們會把深度從剛剛那個空間變換到垂直于場景的空間，這樣以來對于深度測試和深度寫入來說就好像角色是垂直于場景上。

左邊這張圖就是正常的透視關(guān)系，也就是說角色是躺在場景上，會穿模的情況，實際上最后做深度測試的時候，我會把它角色的深度從剛剛左邊這個圖變換到右邊這個深度空間當(dāng)中，你可以看到整個角色現(xiàn)在是垂直于場景，并且被抽起來的，它變得更拉長了。

這張草稿能說明問題，首先這個camera是我們的攝影機方向，它和場景是有一個夾角的，角色垂直于這個camera的方向Z軸，它的夾角和場景夾角是30度，這個時候我們可以做這樣的一個三角形，而這個三角形的斜邊是我們箭頭指的方向，就是我們在深度測試的時候?qū)嶋H上所在的位置，可以發(fā)現(xiàn)這上面線上的每個點和原本角色上的每個點是一一對應(yīng)的。通過幾個簡單的關(guān)系，這是一個直角的三角體，而且是一個30度夾角的，斜邊和對邊的比例是1：2，所以說實際上這個邊的長度是它的2倍。

這里我不會深入一些處理的細(xì)節(jié)，因為我相信這個比較容易，通過大家的計算都可以得到。只需要說一點，做這個變換只需要在Vertex Shader在最后做一個深度變換可以，這需要注意的是，這個時候Vertex Shader最后的位置它實際上是處于透視除法之前騎士空間當(dāng)中的，所以此時如果要做一個Z軸的變化在騎士空間中需要考慮到第四位W參與運算，這里是個簡單的代碼。

好，那么問題解決了嗎？其實并沒有。我們在整個視覺方案當(dāng)中還遇到了很多別的問題，剛剛提到的是其中最重要的點而已。這里圖中說明的是另外一個問題，我們的干員重兵他的攻擊方式比較特別，他的攻擊方式是往下?lián)]鞭的時候縱深會特別長，所以說會直接穿到這個模型里面，如果我們把它的角色深度拉伸到垂直于場景，它依然會穿進去，所以此時我們做了一個特殊處理，當(dāng)它的高度大于等于0的部分，我們使用剛剛說的處理方式，而高度小于0的部分，我們使用另外一套處理方式，使這個鞭子被旋轉(zhuǎn)到平行于這個場景的X、Y平面，這樣才能在同樣正確并且一致的條件下正確地繪制出來。

除此之外，還有空中，它其實處理方式也是不太一樣的。所以，這里是有很多細(xì)節(jié)，如果大家感興趣，接下來我們再詳細(xì)探究。

第二個問題是Lightmap不一致的問題，而這個問題很多友商包括很多網(wǎng)友在網(wǎng)上也提到過，我也看到很多文章，他們會發(fā)現(xiàn)編輯器、在實機、在移動平臺上可能最后Lightmap的結(jié)果都不太一樣，但是我們調(diào)研得到的結(jié)果是如果拋開Unity版本談這個問題是沒什么意義的，因為每個Unity版本對于Lightmap編碼解碼的細(xì)節(jié)都有一定的調(diào)整。

所以我們這里所有的結(jié)論是在2017年的LTS版本上。這個問題的原因是因為光照貼圖存儲的并不是顏色，它和通常的紋理圖是不一樣的，它存儲的是間接光的信息，它的范圍是在0和1之外，我們無法用一個常規(guī)LDR的貼圖格式把它存下來，它原本是一些APBR的信息。所以說我們需要把它進行編碼，才能重造一些LBR的貼圖格式。那么這個編碼的方式在不同平臺上不一樣，這個原因也導(dǎo)致了最后不同平臺上的表現(xiàn)結(jié)果不一致。

大家可以看這兩張圖，可能不太容易看清，在明暗交界的地方陰影會泛藍(lán)紫，這個藍(lán)紫就是陰影的細(xì)節(jié)，在左邊這張圖是被吞掉了，這個細(xì)節(jié)是我們需要處理的。

這里我不會詳細(xì)地描述RGBM和WLDR編碼，大家如果感興趣，如果不了解的話，網(wǎng)上稍微查一查應(yīng)該比較容易了解。整體來說RGBM會將額外的信息存儲到第四個通道alpha當(dāng)中，而WLDR的方式比較暴力，它直接把RGB的原始信息除以2乘下來，所以它丟失的信息比較多。

接下來是具體的問題，當(dāng)Lightmap光照貼圖被烘焙出來之后，它的TextureType默認(rèn)是設(shè)置到Lightmap，那么這種情況下Unity就會根據(jù)當(dāng)前所選擇的平臺來編碼這個Lightmap，影響采樣的結(jié)果。如果在PC上我們把Lightmap Quality設(shè)置成為High的話，它存儲的是一個原生的HDR的信息，如果把它作為Normal Quality，它會把HDR信息通過RGBM進行編碼，存在一張LDR的貼圖里面去，如果是iOS的安卓，也就是移動平臺，它會比較暴力的把所有這樣的信息都給編碼成double LDR的方式。而double LDR的方式下，alpha通道會直接丟棄，這才是我們想通過做一些操作把信息存到alpha通道當(dāng)中，讀出來的是個常量。

接下來是我們做測試的一些細(xì)節(jié)。這些細(xì)節(jié)今天我不會展開，大家如果感興趣可以會后通過PPT的方式查看。

結(jié)論來說，如果我們繼續(xù)保持Unity的默認(rèn)選擇?TextureType ?-Lightmap，它就已經(jīng)存儲為double DR，LDR的格式了，那double DR的格式只能存儲0到2的亮度范圍，亮度2以上的范圍都被截斷和丟失了，為了我們達(dá)到更好的效果，在不同的平臺上使用RGBM編碼，我們必須采取一個default的格式。

具體的方案是我們把烘焙出來的光照貼圖的TextureType從Lightmap改為default，同時我們把RGBM的alpha通道這個信息從Lightmap當(dāng)中抽離出來，放入shadowmask的green chanel，這個原因是因為shadowmask實際上使用了它的red chanel通道，其他通道是沒有被使用的。我們?yōu)榱俗寖蓮堎N圖都可以不存alpha通道，最大化地利用包體內(nèi)存空間，我們把alpha做了一個trick的操作，這樣一來我們就可以用任意我們喜歡的壓縮格式，包括STC、ETC2和PVRTC對這兩張shadowmask和lightmap進行處理。

我們會修改GBR的shader，用RGBM來解碼這個lightmap，并使用從shadowmask中讀取的信息，也就是剛才說的green chanel的信息來輔助這個解碼。在PC上當(dāng)然也是需要相應(yīng)地修改兼容，使所有平臺上達(dá)到一致的效果。

最后這張圖就是我們經(jīng)過這樣一個處理方式之后在所有平臺上包括編輯器，包括PC、安卓、iOS都達(dá)到的細(xì)節(jié)的光照貼圖的效果。

最后一點，我們?nèi)绾稳诤?D場景2D角色的渲染表現(xiàn)？這個問題實際上是一個比較復(fù)雜的問題，我們現(xiàn)在也在探索。我們總結(jié)了幾點：

首先第一個是我們會對每個主題的場景定義一套作用于所有單位、所有角色的tint color，使其著色和場景氛圍更接近。也就是說我們每個場景里面角色的渲染其實略微有些區(qū)別，而這個區(qū)別的tint color是由我們美術(shù)工作人員做配置。第二點，通過美術(shù)處理能夠調(diào)整3D場景、2D角色，包括整個特效的整體氛圍和色調(diào)，使它更加融洽。

我們也會除了剛才的tint color之外提供一些后處理的選項，包括color grading和Bloom等等，讓美術(shù)工作人員能通過他們的努力使我們整個場景3D和2D更加協(xié)調(diào)。未來我們也會探索更多的方式融合這一特殊的畫面表現(xiàn)。

最后做一個總結(jié)，《明日方舟》3D和2D結(jié)合的方案我們首先使用了PBR的渲染和工作流去處理這個3D模型的場景。然后對于2D的角色，我們使用Spinn的骨骼化軟件，使用unlit的shader去處理。

第二點，為了解決3D場景、2D場景空間透視關(guān)系錯誤的不協(xié)調(diào)的問題，我們對shader進行修改，在深度上做了一個變換，使它看起來和實際深度當(dāng)中的表現(xiàn)是不一致的。

第三點，我們自定義了我們Lightmap的編碼和解碼流程，使其在不同的平臺上都能得到一個一致且更好的效果。

第四點，我們使用了一些定制化的tint color和一些后處理的選項，讓3D場景和2D角色能融合得更好。

最后，我們提供了這么多的選項是讓我們的美術(shù)工作人，也就是說我們的藝術(shù)家們來做最后的處理。因為我相信技術(shù)人員只是提供工具，最后的整個畫面效果肯定還是需要以更加感性的認(rèn)識去調(diào)整。

今天的分享就到此結(jié)束，謝謝大家，再見。

404461