unity3D現(xiàn)在已經(jīng)成為了眾多團隊的首選3D引擎。 并且，隨著Unity3D 4.3的發(fā)布，原生的2D支持也讓人大開眼界。雖然Unity3d的原生2D功能還有很長的路要走，但也阻擋不了它稱霸當(dāng)下。

　　2011年中，公司的引擎項目停止之后，我的目光便轉(zhuǎn)到了U3D的身上，經(jīng)過幾番掙扎后，終于對基于組件式的對象模型有了新的認(rèn)識。 而如今，這種模式，成為了我最推崇的模式。 因為它能解決我在設(shè)計引擎對象時的糾結(jié)。 而這些糾結(jié)，是我在先前的引擎開發(fā)中，一直不能優(yōu)雅地解決的。

　　首先，我們來說說U3D培訓(xùn)的好處。可能總結(jié)得不夠完善，如果有不足的地方，就表示我自己沒有體驗到。

　　一、可定制的IDE環(huán)境

　　U3D這種ALL IN ONE的設(shè)計思路，我在一個叫神咒的代碼中見到過。 集所有編輯器于一身。 雖然神咒的編輯器不能自由擴展，但由于是公司內(nèi)部的引擎，所以，它的使用，也很方便。 比如，在場景中突然想要對一個模型的材質(zhì)進行編輯，則選中此模型，右鍵，彈出材質(zhì)編輯器即可。  U3D的組件式思路，將這種關(guān)系變得更加緊密。 你都感覺不到自己在使用一個材質(zhì)編輯器。 你會覺得，你是在操作這個模型本身。 它的材質(zhì)，它的碰撞器，它的對象結(jié)構(gòu)等等。

　　回想一開始進入游戲行業(yè)的時候，天天啃著代碼。 當(dāng)時覺得代碼就是一切，各種認(rèn)為很牛X的代碼，都忍不住讀上一番。 而隨著時間的推移，特別是經(jīng)過項目的洗禮后。 突然發(fā)現(xiàn)編輯器是多么的重要。 就我做的第一個頁游來說，起手前兩個星期，我們就做了動畫編輯器，場景編輯器。而最終證明，因為這兩個簡陋的編輯器，使我們后面的工作變得更加容易。

　　因此，一個好的引擎，必定得先有一個功能完備的編輯器。

　　二、基于Mono的開發(fā)腳本

　　C/C++無疑是圖形界的寵兒，也沒有人想過用另一種語言來替代它。即使是U3D，亦是如此。 但是，早期使用C/C++編寫的引擎，都理所當(dāng)然地使用C/C++來作為上層邏輯的開發(fā)。 又有一些，采用了純腳本的模式。比如Python,LUA。 腳本的好處在于更低的編碼成本（經(jīng)過仔細(xì)研究，我發(fā)現(xiàn)，這是由于寫腳本語言的心態(tài)和寫C++的心態(tài)導(dǎo)致的。 寫C++的時候，總是想著代碼的復(fù)用度，而在腳本的時候，很多時間會認(rèn)為，這個腳本，就是為這個對象服務(wù)的，那我就按照策劃需求來寫就可以了。 我想，這也是許多時候，腳本語言存在的意義。特別是早期引擎中，使用腳本來處理一些關(guān)鍵的事件響應(yīng)）。  而大家熟知的虛幻引擎以及有一個名不見經(jīng)轉(zhuǎn)的Torque，則自己整了一套開發(fā)語言。 我想，它們的目的，就是為了使大家能夠以一種更安全的方式來編程， C++一不小心，則會帶來內(nèi)存和效率問題。 它的使用成本，人員成本其實是高于其它語言的。  Mono C# JS,BOO的出現(xiàn)，再一次讓大家的眼睛一亮，原來，引擎可以這樣整。

　　Mono的橋接，使得高效的C++圖形引擎與帶GC的內(nèi)存安全語言進行結(jié)合。不僅減少了安全隱患，也使得大家編寫跨平臺代碼時更佳容易。 同時，這類語言的反射機制，更適合做編輯器。而比起先前的一些DIY語言和像LUA這樣的小巧型語言，Mono使腳本編程可以進行DEBUG，而不單純的靠PRINT輸出。

　　這里就順帶說一下三個語言的區(qū)別

　　C# 這是我見過的大型項目中使用得最多的語言，也是我比較喜歡的語言。 因為它和C++很像，同時嚴(yán)格的類型和語法檢查。

　　JS 在幫一些朋友做小東西的時候，使用過這個語言，由于mono自帶的提示功能，寫起來還是挺順手。 但總給我一種摸不著頭腦的感覺。 并且U3D給的JS，不是嚴(yán)格的JS，有些語法不支持，而有些語法又很特別。

　　BOO 完全沒有使用過，貌似也很少有人使用。

　　三、基于組件的對象系統(tǒng)

　　這是一個我最喜歡的系統(tǒng)，我也使用irrlicht引擎山寨過，山寨的過程中，幾乎看完了它的組件參考手冊，使我對U3D引擎的組件系統(tǒng)又有了新的認(rèn)識。 同時，目前公司自主研發(fā)的引擎，也是這樣的思想。 不管我是在工作中，還是業(yè)余搗鼓都受組件系統(tǒng)的影響。 慢慢的，喜歡上了這種對象模式。

　　之前在做一個RTS游戲項目的時候，參考了著名開源項目 0.A.D的代碼。 當(dāng)時只是為了去尋找LOS和多單位協(xié)同尋路的方案。 但在參考其代碼的時候，發(fā)現(xiàn)了它整個系統(tǒng)，都是基于組件式的。又一次，對組件式有了好感。 而經(jīng)過仔細(xì)思索后。 回到了我一直堅持的子系統(tǒng)劃分法的游戲框架。 當(dāng)我不禁感嘆，原來，自己也一直是在組件式。 只不過，我的組件式，是MANAGER方式，MANANGER內(nèi)部進行對應(yīng)的實體管理、。 比如，背包系統(tǒng)，則只負(fù)責(zé)玩家背包數(shù)據(jù)，背包使用，背包相關(guān)的功能。 不管是數(shù)據(jù)存儲，還是與前端通信，都是背包系統(tǒng)自己在負(fù)責(zé)，其它模塊完全不需要干涉。  而U3D中的組件系統(tǒng)，則將這個粒度劃得更仔細(xì)了……。  這對于早期的像OGRE的entity系統(tǒng)。僅僅是認(rèn)為對象可以由子對象構(gòu)成，可以說是一個質(zhì)的變化。

　　早期的引擎，基本上都是繼承優(yōu)先的設(shè)計方案，更多時候考慮的是編碼的便利性，且引擎的走向都具有針對性。 而當(dāng)面對一些復(fù)雜情況的時候，繼承式的編碼是十分麻煩的。 并且，對于JAVA,C#這樣的語言，并沒有提供多繼承能力。 因此，繼承式的編程，在面對越來越廣泛的游戲需求的時候。顯得無能為力。 組件式則是一種聚合優(yōu)先的編碼方式，它的復(fù)用度和伸縮度，都遠(yuǎn)遠(yuǎn)大于繼承。 唯一讓一些C++程序員覺得不太順眼的，可能就是過多的變量和虛函數(shù)調(diào)用開銷吧。 但這些，在當(dāng)下來說，都不是問題。 影響大眾步伐的，早已不是那種語言特性本身導(dǎo)致的開銷。更多的，是如何使我們高效率，高質(zhì)量地完成一個游戲。 因此組件模式已經(jīng)成為必然。 從新版的UE4的變革，以及暢游的G3D，國外一個開源的godot引擎，就可以看出來，大家對組件模式，已經(jīng)有了深深的好感和接受度。

　　四、所見即所得

　　這可以說是許多人最喜歡的特性，這也是G3D群里，問的人最多的特性，三天兩頭就有人問，G3D能不能像U3D一樣在編輯器里預(yù)覽游戲效果呀。

　　U3D除了編輯后立即運行，還能在運行過程中時實編輯，查看效果。當(dāng)然，運行過程中編輯對象的數(shù)據(jù)，會在停止后失效。（注意，對文件屬性的修改，不會失效）

　　五、代碼驅(qū)動的開發(fā)模式

　　這種模式，可以使我們快速地構(gòu)建一個原型。 對于U3D中的MonoBehaviour來說，它扮演的，就是如何驅(qū)動它的目標(biāo)對象。 因此，你可以將你的對象的各種能力分配到不同的腳本組件中，然后根據(jù)對象的需求來掛接。

　　六、多平臺發(fā)布

　　U3D支持的平臺，無疑是當(dāng)下較為流行的平臺。 滿足絕大部分項目需求。 早期的引擎，多以PC和CONSOLE為主。 支持WINDOWS,XBOX,PS2已經(jīng)是很不錯了。 U3D便利的多平臺發(fā)布特性，也使得它成為了當(dāng)前性價比最高的引擎的原因之一。

　　也有許多公司正在自主研發(fā)引擎，或者是將先前的PC引擎修改為多平臺（IOS+ANDROID居多）。 但這也檔不了U3D的步伐。

　　七、良好的生態(tài)圈

　　在使用公司引擎的時候，我就發(fā)現(xiàn)，若我遇上一個問題，只能問公司的老員工們，或者找其它引擎TEAM尋求幫助。而U3D這種生態(tài)圈，不是一天兩天能形成的。GOOGLE,百度，各種論壇，都能很容易找到自己想要解決的問題。 而對于一些經(jīng)驗上的問題，也有不少人總結(jié)。 這使得后來者，可以快速上手引擎。

　　而AssetStore的出現(xiàn)，不僅使U3D的生態(tài)圈更加穩(wěn)固，同時也提供了許多機會。 你可以制作插件放網(wǎng)上賣，賺取一些利益，也可以購買別人的插件，作為使用或者參考也好。 有時候，購買一些插件，可以讓你快速脫離當(dāng)前的困境。 一個是解決進度問題，一個是解決思路問題。 這是之前其它引擎不具備的。
　　Unity3D培訓(xùn)入門容易，真的要精通，那是相當(dāng)難的，對unity3D感興趣的同學(xué)可以咨詢我們也可以到unity3D官網(wǎng)查看unity3D教程。