Unity3D使用經驗總結 缺點篇

不管是從官方手冊，仍是各類第三方教程，幾乎涉及到的，都是講如何使用U3D，以及U3D的優勢。

雖然我是用的一個讓步語氣，但請不要否定U3D的這些優勢，它們的確存在。 但對於一個引擎的特性來講，優勢與缺點老是共存的。

你能夠從網上了解到全部優勢，可是，你很難真正體會到U3D的缺點，除非你本身被坑過。 今天，我就來細數一下U3D的缺點。 這些缺點，僅針對大中型項目。 小型項目，U3D的優勢能夠充分利用。

 

是否是猛的一看，全是缺點。 不要怕，想看優勢的朋友，走這裏  Unity3D使用經驗總結 優勢篇

 

1、環境

U3D的環境能夠說是很是OK的。一體式的感覺，讓全部工做都無縫地進行。 真要說它有什麼缺點，還很難找到。 但有幾個地方，不得不說。

一、U3D默認不支持多項目，每次打開場景，則會關掉當前場景，再打開下一個場景。 而雙擊U3D的啓動圖標，又會自動打開最近一個項目。 想要解決這個也還好辦  在快捷方式後面加上 --project便可。 加上後，每次編譯時會有一個提示，這個可有可無。

再試試雙擊U3D的快捷方式，是否是會讓你選擇項目啦。

 

二、多個U3D版本不易共存，網上也有人提供瞭解決方案。可是，這始終不是太爽的一件事。

三、編輯器未和執行環境分離，若要DEBUG，必須啓動U3D編輯器。 而不少時候，對於程序員來講，是不須要的。 它們只是想改改代碼，而後編譯，執行。 或許，U3D能夠經過命令行提供一個較輕量的啓動環境。

四、若是代碼中出現了死循環，那就只有強行結束U3D，而後再開。 中間若是忘了保存，那剛剛作的場景編輯工做，就洗白了。

 

2、開銷

基於Mono的運行環境，致使引擎起步價就比別人高。初始化時間過長。 這對於中高端機來講，是感受不到的。但低端機，相比之下，就顯得尷尬了。 而這一狀況，對3D的影響還好。但對於一個小型的2D遊戲來講，就會被人誤認爲，遊戲作得不夠好。

U3D雖然提供了原生的2D支持，可是其本質僅僅是在運行期鎖定了相機，集成了BOX2D物理和2D碰撞生成器等東西。 運行時期的起步價開銷，與3D是等同的。

 

3、代碼驅動的開發模式

不論是官方示例，仍是一些入門教程，都是以代碼驅動的方式來引導你們熟悉U3D。 固然，代碼驅動方式也確實很方便，同時更能章顯U3D的強大。

對於一個小項目來講，代碼驅動無疑是最便捷的操做方式。

可是，對於一個大型項目來講，代碼驅動的結果則是BUG頻繁，且很難逐一解決。 同時，對策劃要求較高，策劃須要知道不一樣對象應該掛什麼樣的腳本。 而對於代碼驅動的開發方式來講，編碼的人，最好就是策劃。爲不一樣的對象，使用腳本定製特定的功能。

所以，使用U3D作大型項目的話，仍是得須要退回到經典的數據驅動模式。 數據驅動模式則正好沒有代碼驅動模式面臨的問題。同時，數據驅動才能更好地作出網絡遊戲。

關於這個問題，我想等有時間了，專門弄一篇文章，向你們表達一下我心中所想。

在這裏，簡單地提一下腳本掛接須要注意的地方

 

U3D的組件思路是要一直沿用的，若是腳本不掛在對象上，那就失去了這個NB的特性，如今，咱們要決定怎麼樣掛。個人思路是，對於一個對象來講，若是是對其能力進行擴展的，那就能夠將這樣的特性掛在對象身上。 反之，若是是決定遊戲流程的，那這就應該是普普統統的代碼，不能掛到對象身上。

下面，舉一個簡單的例子。  玩家走到一個觸發器上，觸發器觸發，而後，玩家移到新地圖。

首先，觸發器自己是一個對象，它會檢測是否有對象進入它，若是對象 玩家，那將會被傳送。

對於一個普通的gameobject來講，是沒有檢查對象進入和觸發能力的。 那，咱們能夠將它的COLLIDER弄成TRIGGER。 可是，一個對象的RIGGER觸發的檢測，只能是在掛在它的對象腳本里作。

按咱們上面說的原則，那當腳本里檢查觸發後，咱們就不能直接操做玩家。 而是應該將這個事件拋出，由邏輯來處理。

因而，咱們能夠寫一個事件類，這個事件類負責管理全部事件，而後感興趣的對象，能夠來對裏面的事件進行接收和處理。

咱們還須要一個TrigerDetector來作全部觸發器的掛接。 剩下的事情，就是真正的遊戲邏輯來作了。 

 

上面是單機的狀況，那網絡的狀況，又怎麼作呢。 這就是數據驅動的魅力了。

對於這個觸發器，咱們能夠掛接一個teleport的腳本，這個腳本什麼功能都沒有，只有一些變量，如目標地圖ID等。另外，咱們還須要將這個對象標記爲SERVER對象。

而後，咱們須要擴展編輯器，將場景導出。標記爲SERVER對象的，則導出到SERVER使用的數據文件，沒有標記爲SERVER的，則導出到客戶端的數據文件裏。

而後，先後兩端進行加載和操做。至於如何導出，下面有簡單說明。

 

4、所見即所得

咦，這不明明是優勢麼。爲毛又成缺點了。

其實，這確實是優勢，而缺點其實不是由於它，而是由於U3D採用二進制存儲場景文件。那多人協做的時候，SVN衝突但是一樁接着一樁的。 

解決這個的辦法也挺簡單，咱們擴展一下編輯器，將對象導出成非二進制格式不就成了麼。而後再在遊戲裏面，從新加載。

思路是這樣，要實現這個中細節，其實也挺麻煩的。咱們公司的編輯器雖然功能很少，界面不美，可是卻優雅地解決了這個問題。

這套方案也不是一兩句話能說清楚。 總之，記住，這裏是個坑。

既然提到這裏了，若是不說點具體解決辦法，可能有人說我是裝B了。 那我說一個可以必定程度上解決衝突的辦法。

一、場景中全部對象，使用prefab。 不能有非prefab出現，且不能修改prefab的任何屬性

不能修改屬性的緣由是爲了保存的時候簡單，若是你們屬性都同樣的話，那咱們只須要存它的縮放，旋轉，平移以及對應的prefab名字就能夠了。 趕上須要不一樣屬性的東西，那新建一個PREFAB

二、擴展一個編輯器功能，將場景導出爲XML或者JSON什麼的文本格式

這個文本格式，保存了全部的對象信息，每一個對象信息包含縮放，旋轉，平移以及對應的prefab名字。 固然，這不是死的，若是有其它需求，可自行添加。好比，對象的初始active狀態

三、新建一個真正的場景，裏面只有一個GameObject對象，這個對象只掛接了一個腳本，這個腳本的初始化，就是調用遊戲邏輯的初始化，這個腳本的UPDATE，就是調用邏輯的UPDATE。

這其實就是一個MAIN入口。 你的遊戲邏輯應該是與具體場景無關的。 你只須要加載你先前導出的文件，而後對全部對象進行實例化便可。

 

這個是解決SVN衝突的第一步，同時也是數據驅動實現的第一步。

 

 

關於遊戲的增量更新之類的坑，並非U3D特有的，一般只有兩個解決方案，一個是數據和代碼分離，以減小更新壓力。 另外一個是純腳本，實現全部功能，包括資源的加載什麼的。 無論採用何種方案來應對這個問題，數據驅動是必然的。

這也是我入手U3D的緣由，由於經過編輯器擴展，我找到了數據驅動的解決辦法。

 

其實，最想說的兩個問題都說了，一是數據驅動，二是SVN衝突解決。但U3D確定不僅這些坑。 但那些坑，都是很具體的，經過具體需求才能解決的。

上面講到的，是全部項目都適合的坑。但願對你們有幫助。