[Unity3D]U3D開發項目總結
從2月份到現在第一個U3D項目也基本收工，雖然項目結局不是太好，但總算也是成功賣掉並上線，總結將近10個月的時間大家從端遊轉到手遊或從COCOS2轉到U3D的整個開發過程。
1.資源
無疑這是整個項目我覺得做的最差的地方，也是前期最爲忽略的地方，猶豫U3D組件式架構的原因和本身資源打包加載的一個限制，導致後期項目資源異步加載以及動態更新很難實現。
起初猶豫是項目玩法參考《印第安大冒險》，在導出它的包查看了它的結構以及部分實現的代碼後，發現基本也未作任何資源管理，資源基本上一個關卡一個場景的方式組織，所以也就按他的方式，只是簡單的按場景、特效、UI等進行了簡單的劃分。
但是隨着關卡的複雜性的增加，遊戲複雜性的增加，問題也隨之而來。
項目問題以及方案：
(1) 場景加載慢，無法異步加載
因爲沒用AB管理資源，所以很難實現異步加載，但是場景已經完成到了某種程度，也很難重新設計資源加載方式，所以臨時找了另一種方案。、
a.先將原始資源移動到Resources目錄先，這樣的原因是爲了在加載場景是預加載紋理、模型等資源，隨之而來的問題便是Resources下的目錄中不能保留不需要的資源，否則會一起導入安裝包，導致安裝包龐大，最後寫了一個編輯器擴展腳本在打包時候清理掉所有遊戲未引用的資源。方法是找到所有場景以及與之的依賴資源並記錄，找到所有資源在一處記錄的資源，剩餘資源統一刪除。
b.擴展一個編輯器腳本生成當前場景所有依賴資源列表，生成預加載文件，在加載文件時讀取並通過Resource.Load加載並保存，切換時候在釋放。爲了實現模擬異步加載的效果，加載時在一個新的協程中加載，加載兩個返回一幀。
(2) 運行時怪物創建卡頓
同樣這個也是由於這個原因造成的，解決方案相對取巧，由於怪物是有觸發器創建，所有在加載場景時候會預先創建所有怪物並隱藏，知道觸發後在顯示出來。
(3) 特效、技能等預製資源卡頓
1.資源
無疑這是整個項目我覺得做的最差的地方，也是前期最爲忽略的地方，猶豫U3D組件式架構的原因和本身資源打包加載的一個限制，導致後期項目資源異步加載以及動態更新很難實現。
起初猶豫是項目玩法參考《印第安大冒險》，在導出它的包查看了它的結構以及部分實現的代碼後，發現基本也未作任何資源管理，資源基本上一個關卡一個場景的方式組織，所以也就按他的方式，只是簡單的按場景、特效、UI等進行了簡單的劃分。
但是隨着關卡的複雜性的增加，遊戲複雜性的增加，問題也隨之而來。
項目問題以及方案：
(1) 場景加載慢，無法異步加載
因爲沒用AB管理資源，所以很難實現異步加載，但是場景已經完成到了某種程度，也很難重新設計資源加載方式，所以臨時找了另一種方案。、
a.先將原始資源移動到Resources目錄先，這樣的原因是爲了在加載場景是預加載紋理、模型等資源，隨之而來的問題便是Resources下的目錄中不能保留不需要的資源，否則會一起導入安裝包，導致安裝包龐大，最後寫了一個編輯器擴展腳本在打包時候清理掉所有遊戲未引用的資源。方法是找到所有場景以及與之的依賴資源並記錄，找到所有資源在一處記錄的資源，剩餘資源統一刪除。
b.擴展一個編輯器腳本生成當前場景所有依賴資源列表，生成預加載文件，在加載文件時讀取並通過Resource.Load加載並保存，切換時候在釋放。爲了實現模擬異步加載的效果，加載時在一個新的協程中加載，加載兩個返回一幀。
(2) 運行時怪物創建卡頓
同樣這個也是由於這個原因造成的，解決方案相對取巧，由於怪物是有觸發器創建，所有在加載場景時候會預先創建所有怪物並隱藏，知道觸發後在顯示出來。
(3) 特效、技能等預製資源卡頓
同樣這個也是由於這個原因造成的，解決方案，這個比較傳統，增加了一個預製緩存池，創建場景時候會對指定配置的特效做緩存，創建時候從緩存中取出，用完還回去就可以了。
(4) 資源更新
這個暫時只能妥協，只做了配置文件的更新
理想解決方案：
(a) 以Prefab爲基本打包力度，爲特效、UI節點、角色等等保存爲Prefab。
(b) 將所有代碼、Shader、等等公用基礎資源打包到Common.ab。
(c) Push:Common.ab的基礎上打包UI/Audio/Effect/Actor...等分支下的Common_*.ab。
(d) Push:Common_*.ab的基礎上打包UI/Audio/Effect/Actor...下的預製到 *.ab。
(e) 加載加載Common.ab，在加載分支支援時候先加載相應的Common_*.ab後在加載特定的ab。
(f) 加載可以採用異步加載形式，場景創建時候可以先創建空節點，等異步加載完成後在創建並掛接到該節點上。
(g) 關於Level，打包時候打包基本場景以及關照貼圖，加載後在動態加載響應節點數據並掛接上去
2.特效
首先這邊的特效基本是有端遊轉過來的，而前期對特效沒有做一些規範性的限制，導致一些特效複雜度相當高，以及裏面包含大量Animator(這個損耗相當大)。
其次特效未作統一的管理，而僅僅是簡單的做成一個Prefab。造成後期特效不是太好優化。
理想解決方案：
(a) 提供一個特效編輯器，組織特效，發佈的時候檢查並提示出一些必要的警告方便特效人員修改，同時未特效預製加入自動管理腳本。
(b) 或採用一些比較好的插件 FX Maker 等。
3.場景
場景最大的問題同樣是沒有好的規範，導致前期場景模型用了大量的多維材質，比如一個石頭可能有 表面/中部/底部/邊緣 等四個材質等等。
理想解決方案：
(a) 儘量只使用一中材質，當然有些工具比如Mesh Banker 可以拿來優化。
(b) 地表裝飾無盡量將貼圖合併到一張Atlas公用，減少批次，比較特殊的情況比如 Repeat Mode的貼圖可不處理。
(c) Static Batch 雖然能夠做一定的優化，但是會大大的增加Level暫用的硬盤空間，所以可以根據實際場景視角等來確定是否開啓以便減少生成包的大小。
4.動作
操控相對簡單，雖然Animator很強大，單可控性卻不是很高，所以選擇使用Animation，通過Layer進行狀態融合處理。AddMixTransform 可以進行上下半身或者特殊部分動作混合。
附帶：關於Animator性能，場景中Animator過多會造成CPU消耗過高，而Aniamtion有可見在更新的狀態選項可以進行控制，Animator卻不行，因爲是統一管理，所以需要注意。
5.NGUI
NGUI確實很強大，有自己的批渲染，這類也不需要多說，其中有兩個可以分享的地方
(a) 特效與NGUI層級，實際上NGUI/Panel/DrawCall會有一個RenderQuene，爲了層級正確我們應帶改變特效material.renderququne = DrawCall.RenderQuene + 1，這樣特效就可以在正確的面板上顯示與遮擋。
(b) DrawCall優化，可以利用 Panel:ShowDrawCall工具手動調整Panel中空間的order來減少DrawCall。
6.代碼加密
代碼加密相對麻煩，因爲其實整個過程中也通過ISpy查看過不少遊戲的代碼，基本很少做加密的，少量做了混淆。
理想解決方案：
(a) GitHub 上下載 Unity 官方 Mono庫
(b) 找到 image.c ： mono_image_open_from_data_with_name 函數：
增加代碼：(簡單的混淆DLL)
if (NULL != strstr(name, "Assembly-CSharp.dll"))
{
for (; i < data_len;)
{
data[i] = ~data[i];
i += k;
k += 1;
}
}
後編譯生成 libmono.dll/so 到相應平臺
(c)將Assembly-CSharp.dll反向混淆
7. 紋理壓縮
用disunity導出U3D打包後的資源法線android下紋理實際上是經歷過一次轉換的：
帶Alpha通道貼圖-> TGA 未壓縮格式 / 除非設置 通常都帶Mipmap
不帶Alpha通道貼圖-> KTX （ETC1 android) 不帶Mipmap
顯然爲了減少紋理對GPU芯片帶寬的浪費以及對內存的浪費android下應當使用ETC1，而且ETC壓縮失真不算嚴重，驗證可接受。
那麼對於帶Alpha通道的貼圖應該如何處理？解決方案1.提取Alpha爲單獨的Alpha通道貼圖 2.提取Alpha爲灰度圖在保存爲ETC1（默認會轉換）。
這樣有效提高程序性能同時也相應的會減少壓縮後包的大小。因爲TAG不然縮與ETC壓縮後在ZIP壓縮還是有一定的空間大小差距。
8.其他一些特效
shadow_gun 中有很多不錯的 shader 可以用用 比如EnvCube可以支持帶lingthingmap的Cube反射材質，做冰柱等效果非常好。
water 等可以簡單的用一張nosiy貼圖加Cube反射模擬，效果也可以接受。
unity / image effect/ MothionBlur 可以做Boss死亡特效 配合 Time.timeScale K幀。
等等 暫時只回想起這麼多，希望對大家有幫助，有問題可以探討。
今天項目組換老大了，希望換人後上線能順利，畢竟也花費了不少精力，週五也得離開了，想想也挺傷感的，遊戲行業真不好混。
(4) 資源更新
這個暫時只能妥協，只做了配置文件的更新
理想解決方案：
(a) 以Prefab爲基本打包力度，爲特效、UI節點、角色等等保存爲Prefab。
(b) 將所有代碼、Shader、等等公用基礎資源打包到Common.ab。
(c) Push:Common.ab的基礎上打包UI/Audio/Effect/Actor...等分支下的Common_*.ab。
(d) Push:Common_*.ab的基礎上打包UI/Audio/Effect/Actor...下的預製到 *.ab。
(e) 加載加載Common.ab，在加載分支支援時候先加載相應的Common_*.ab後在加載特定的ab。
(f) 加載可以採用異步加載形式，場景創建時候可以先創建空節點，等異步加載完成後在創建並掛接到該節點上。
(g) 關於Level，打包時候打包基本場景以及關照貼圖，加載後在動態加載響應節點數據並掛接上去
2.特效
首先這邊的特效基本是有端遊轉過來的，而前期對特效沒有做一些規範性的限制，導致一些特效複雜度相當高，以及裏面包含大量Animator(這個損耗相當大)。
其次特效未作統一的管理，而僅僅是簡單的做成一個Prefab。造成後期特效不是太好優化。
理想解決方案：
(a) 提供一個特效編輯器，組織特效，發佈的時候檢查並提示出一些必要的警告方便特效人員修改，同時未特效預製加入自動管理腳本。
(b) 或採用一些比較好的插件 FX Maker 等。
3.場景
場景最大的問題同樣是沒有好的規範，導致前期場景模型用了大量的多維材質，比如一個石頭可能有 表面/中部/底部/邊緣 等四個材質等等。
理想解決方案：
(a) 儘量只使用一中材質，當然有些工具比如Mesh Banker 可以拿來優化。
(b) 地表裝飾無盡量將貼圖合併到一張Atlas公用，減少批次，比較特殊的情況比如 Repeat Mode的貼圖可不處理。
(c) Static Batch 雖然能夠做一定的優化，但是會大大的增加Level暫用的硬盤空間，所以可以根據實際場景視角等來確定是否開啓以便減少生成包的大小。
4.動作
操控相對簡單，雖然Animator很強大，單可控性卻不是很高，所以選擇使用Animation，通過Layer進行狀態融合處理。AddMixTransform 可以進行上下半身或者特殊部分動作混合。
附帶：關於Animator性能，場景中Animator過多會造成CPU消耗過高，而Aniamtion有可見在更新的狀態選項可以進行控制，Animator卻不行，因爲是統一管理，所以需要注意。
5.NGUI
NGUI確實很強大，有自己的批渲染，這類也不需要多說，其中有兩個可以分享的地方
(a) 特效與NGUI層級，實際上NGUI/Panel/DrawCall會有一個RenderQuene，爲了層級正確我們應帶改變特效material.renderququne = DrawCall.RenderQuene + 1，這樣特效就可以在正確的面板上顯示與遮擋。
(b) DrawCall優化，可以利用 Panel:ShowDrawCall工具手動調整Panel中空間的order來減少DrawCall。
6.代碼加密
代碼加密相對麻煩，因爲其實整個過程中也通過ISpy查看過不少遊戲的代碼，基本很少做加密的，少量做了混淆。
理想解決方案：
(a) GitHub 上下載 Unity 官方 Mono庫
(b) 找到 image.c ： mono_image_open_from_data_with_name 函數：
增加代碼：(簡單的混淆DLL)
if (NULL != strstr(name, "Assembly-CSharp.dll"))
{
for (; i < data_len;)
{
data[i] = ~data[i];
i += k;
k += 1;
}
}
後編譯生成 libmono.dll/so 到相應平臺
(c)將Assembly-CSharp.dll反向混淆
7. 紋理壓縮
用disunity導出U3D打包後的資源法線android下紋理實際上是經歷過一次轉換的：
帶Alpha通道貼圖-> TGA 未壓縮格式 / 除非設置 通常都帶Mipmap
不帶Alpha通道貼圖-> KTX （ETC1 android) 不帶Mipmap
顯然爲了減少紋理對GPU芯片帶寬的浪費以及對內存的浪費android下應當使用ETC1，而且ETC壓縮失真不算嚴重，驗證可接受。
那麼對於帶Alpha通道的貼圖應該如何處理？解決方案1.提取Alpha爲單獨的Alpha通道貼圖 2.提取Alpha爲灰度圖在保存爲ETC1（默認會轉換）。
這樣有效提高程序性能同時也相應的會減少壓縮後包的大小。因爲TAG不然縮與ETC壓縮後在ZIP壓縮還是有一定的空間大小差距。
8.其他一些特效
shadow_gun 中有很多不錯的 shader 可以用用 比如EnvCube可以支持帶lingthingmap的Cube反射材質，做冰柱等效果非常好。
water 等可以簡單的用一張nosiy貼圖加Cube反射模擬，效果也可以接受。
unity / image effect/ MothionBlur 可以做Boss死亡特效 配合 Time.timeScale K幀。
等等 暫時只回想起這麼多，希望對大家有幫助，有問題可以探討。
今天項目組換老大了，希望換人後上線能順利，畢竟也花費了不少精力，週五也得離開了，想想也挺傷感的，遊戲行業真不好混。