cocos2d-x進化為2.5D的一些想法

標籤：style   os   使用   ar   檔案   資料   div   art   sp   



        首先我得說Unity3D已經做的很好了，搞這些東西意義真心不大。具體Unity3D有什麼優勢我之前也寫過兩篇文章來闡述自己的想法。
        如果我的下一份工作是U3D的話，估計我就不會有這些想法或者研究了。不過誰讓我又重新轉回cocos2d了呢。我的新的工作大概就是寫一個cocos2d-x的2.5D遊戲。如果按照我自己的想法，那肯定是U3D來做，不過我在技術上從來不是剛愎自用的人。而且很多時候做遊戲圖形學和演算法都沒那麼重要，說白了就是拿什麼都能做，這裡面更多的可能是個人對引擎的熟悉程度或者喜好程度。
       這篇文章不會有什麼技術性質的東西，更多的可能是吐槽或者是臆想。首先會分析下U3D的劣勢（好話之前已經說的很多了），然後會分析下cocos2d-x做2.5D的優勢，最後會分析下3D的可行性。

一、U3D的癥結所在：
      使用U3D開發3D遊戲幾乎是唯一正確的選擇。如果是次世代遊戲的話還可以考慮UE3或者UE4，但是就手遊而言，靠次世代畫面成功的遊戲幾乎沒有。U3D幾乎已經代表了畫面的巔峰。而且很多時候一個遊戲的畫面不是引擎決定的，而是美術決定的。再優秀的引擎也會被渣美術給耽誤。
      使用U3D可以方便的跨平台，有靈活可擴充的編輯器，完善的粒子系統，豐富的資源和擴充，簡單而系統架構體系。好處很多就不一一列舉了。
      這裡分析下缺點，其中有些缺點是無關緊要的，有些是可以繞過去的，有些則是真正噁心的。這次去網易面試，主程也說，相比Unity，他們更習慣使用自研3D引擎，同樣有完善的編輯器和工作流程，但是可以避免Unity的一些問題。
      當然，只有網易這樣的大公司而且是技術向的大公司會有這樣的實力，小團隊就安安穩穩的使用Unity就OK了。畢竟畫面效果、遊戲是否賺錢、開發進度都是跟團隊水準相關的，跟引擎沒有太大關係。不是說開發慢了或者畫面渣了或者最佳化差了就是引擎不好，而是自身水平問題。
      U3D一切都很美好，但是某些細節或者流程確實很噁心，兩種情況下可能會考慮放棄U3D。一種是大公司自己研發引擎，現在開始重新研發意義不是很大，但是老牌的遊戲公司都是有很深厚的技術積累的，研發引擎真心不是多麼困難的事情，尤其是為手遊服務的引擎。  第二種是，我的需求很簡單，比如我只想渲染3D模型然後能播放動畫就OK了，這種情況下不使用U3D也是OK的。
      我個人感覺U3D在網遊開發流程上並沒有多麼漂亮的實現，更多的是為獨立遊戲這樣的小團隊模式服務的。雖然成功的MMO手遊非常多，但是牛x的團隊繞過了坑，或者填平了坑並不能說明坑不存在。
      1、資源管理方面。U3D資源是自動打包並且由引擎統一維護，你不需要（也很難）去以檔案的形式控制一個資源。這很多時候讓我感到束手束腳。雖然考慮到預製和情境中資源的載入和維護，由引擎統一管理資源是可以接受的，並且我也沒有想到更加簡單直白的方式。但是不爽終歸是不爽。資源（如紋理、模型）的細節被隱藏在U3D的資源系統之後了，如何保證資源合理的釋放，如何保證AssetBundle的資源依存關係都是值得單獨寫一篇文章的東西。這就是黑暗細節。
      2、AssetBundle。因為Unity資源有一套內部的資料聯絡（比如指令碼綁定、材質屬性等等），所以Unity提供了獨立於程式包的檔案系統，這個也是頁遊和手遊的自動更新策略的基礎。它一方面可以完成自動更新的功能，另一方面也可以實現多人開發的資料維護工作。但是如何正確的打包保證資源的最優並不是一件容易的事情。而且資源打包到AssetBundle後，在編輯器開發會有一定限制，比如Animator就無法查看動畫狀態機器了。
      3、多人開發的資源管理。我現在唯一能想到的就是讓美術也習慣用Unity，然後統一使用AssetBundle來進行資源維護，程式只需要關心Bundle就可以了。但是這要求資源就只是資源，如果程式還需要對資源進行一定的處理，比如綁定指令碼、添加碰撞檢測等，就需要額外的工作流程修改。而如果所有人共用一個svn（或git），那工程專案檔夾可能會有N個G（我的一個ARPG的專案檔夾就超過10G了）。而且Unity用meta檔案來儲存資訊也有些噁心，有些資訊是有用的，比如動畫資訊、紋理切分資訊等等，但是很多是無用的，而一個大一些的網遊零碎檔案可能很多，meta檔案體積就很恐怖了。 而且資源修改的時候可能會因為誤操作導致綁定的指令碼丟失等問題。這隻能說簡單的情況很簡單，噁心的情況很噁心。
       4、指令碼。老實說，我並沒有找到更好的解決方案。但是將指令碼綁定到物件對象上並不是多麼完美的方法。因為指令碼和資源已經綁定在一起了，那意味著代碼和資源必須放在一起管理，使用傳統的方式來維護代碼和資源不再可行。而且項目的正確程度也依賴於資源的資料配置，或者說程式員很大一部分工作需要配置資源資料。在svn或者git上面維護整個工程是一件非常痛苦的事情。我原本想開源之前停掉的那個項目，但是把2G的資源上傳到github上是不可能的事情，而如果只上傳代碼又沒有任何意義。如果是其他的項目的話，則可以只需要管理代碼即可，資源的話在網盤裡面維護一份最終的資源配置即可。
       5、很多功能可用但是並不好用。這個主要是從MMO開發便利程度上來說。比如MecAnim，動畫重新導向非常美好，狀態機器的編輯方式也算方便，動畫融合編輯尤其便利。但是就開發MMO來說這並不是很好的選擇，至少很多公司依然使用老的動畫系統。既有的架構（或者開發經驗）都是基於老的動畫系統來做的，而且完全滿足所有功能（對於公司來說，重新導向與否並不是核心考慮因素），沒有必要嘗鮮（雖然已經出來一兩年了）。關於如何讓開發上相對方便的使用MecAnim，我還寫過一篇文章，不過即便如此也不能說多麼完美的解決方案，只不過是由不可能變成可以開發而已。我認為MecAnim最大的坑就是沒有相容老的動畫系統，在使用上新舊動畫系統最大的改變是添加了狀態機器的編輯方式，但是連線、編輯狀態轉移參數的方式操作起來非常蛋疼，而直接播放動畫的介面又可能對某些功能造成影響（或者說不知道有沒有什麼負作用，不開源的話能知其然而又知其所以然並不容易）。而最完美的情況應該是編輯器、動畫重新導向、動作融合編輯功能上相對獨立，這樣開發人員可以根據自己的喜好定製動畫系統。
       6、2D功能方便但是雞肋。這個是上一條的延伸。Unity4.3推出了2D功能，並且在4.5進一步完善，但是如果我想不做修改就拿它來開發一個2D的手遊比如大掌門、刀塔傳奇之類的，依然是非常痛苦的一件事。某種程度上說，cocos2dx更加順手。倒並不是說一定要使用cocos的代碼形式或者結構，我認為Unity的基於編輯器的開發流程還是很不錯的。但是一些基礎功能的缺失，或者說沒有很方便直接的提供，讓二次開發非常必要。我之前想寫（改進）一個2D外掛程式，已經完成70%了，但是由於後面要轉回cocos，所以估計這個要延期了。Unity本身的Native只是提供了方便的顯示圖片和建立動畫功能，但是圖片打包功能非常薄弱（不支援圖片旋轉，不支援Trim，操作方式彆扭，無法與TexturePacker相比），動畫無法編輯以及精細控制（比如某一幀位移控制、時間控制），同時沒有既有的多解析度解決方案（攝像機的解析度控制）。而這些都是開發遊戲所必須的功能。

二、我們需要什麼樣子的3D引擎：
      就手遊開發來說，次世代永遠不是需要考慮的。即便Unity本身那些酷炫的效果也是在手遊上“禁用”的，比如即時光照。我們一方面追求高模的表現效果，另一方面又要追求低面數的效率，本身就不可能達到所謂的“高畫質”。但是一個遊戲好不好看，炫不炫很多時候不是看是否是“顯卡危機”，而是看美術的整體風格和感覺。比如，我就感覺滿屏的光效和滿屏的飄血數字就是非常酷的遊戲了，至於毛髮是否細緻、嘴型是否匹配不在我的考慮範圍之內。
      我需要的3D引擎在功能上非常簡單，能高效率的渲染3D模型、骨骼動畫、粒子光效就足夠了。重要的不是有多麼豐富的功能，而是基礎功能是否方便且極致。由於是自己開發的引擎，我們可以把更大的精力花費在效率的最佳化上面。比如我一直想實現一個千人戰的RTS遊戲，這個我在Unity測試的效率無法滿足需求，除非把模型壓的非常慘淡。自己開發的話就可以嘗試著去最佳化和解決。
      再次重申，最先進的圖形學技術不是我所考慮的，實用才是第一要務。

三、有哪些可以參考的開源引擎：
      有很多開源的3D引擎可以學習參考，站在巨人的肩膀上面會少走很多彎路。很多公司花幾千萬幾年時間來搞3D引擎，而且有的還沒有搞成（沒有成功的遊戲代表作），在我看來就是走彎路了。這些開發人員大牛一方面鄙視OGRE之類的開源引擎認為技術上很渣，另一方面自己又沒有做出令人信服的東西。引擎開發沒有那麼容易，因為要想做出讓人信服的引擎需要編輯器、功能、效果、效率、開發流程等全盤考慮，這的確是費時費力的事情。但是同時引擎開發也沒有那麼困難，只要我們願意捨棄所有我們不關注的東西那麼可以很快做出讓自己信服的引擎。
       1、genesis-3d，搜狐暢遊搞的一套開源引擎，跟Unity非常像。屬於那種暢遊自己不用，然後推薦給別人用的東西。參考價值不大，因為它龐大而複雜。而且我個人認為它走彎路了。弄的跟Unity很像，但是跟Unity比又沒有任何亮點，反而是各種功能缺失，而且又沒有Unity的開發社區，這樣怎麼去跟Unity搶地盤？
       2、godot，又一個跟Unity很像的東西。也是編輯器向的引擎。
       3、Torque3D、Torque2D，引擎賣不出去了，乾脆開源好了。
       4、GamePlay、Panda3D、PixelLight，不算太出名，但是功能相對完善。不走編輯器路線。其中Panda3D代碼量很大。
       5、Ogre、KlayGE、WildMagic，比較出名的開源引擎了，可以看看結構設計和圖形技術。其他如鬼火之類的感覺沒什麼大亮點，跟OGRE差不多，挑一個看就完事了。

四、cocos2d-x的3D現狀和進化的可行性：
      cocos2d-x-3.2版本已經加入3D模型和骨骼動畫的支援了，最新的github上面有更多的重構和改進，比如支援submesh了。當然對一個3D引擎了來說這遠遠不夠，但是很多時候對我們製作2.5D遊戲來說又綽綽有餘。
      至於為什麼要考慮cocos2d-x的3D化，而不是用上面提到的引擎，主要考慮是學習成本和開發成本。學cocos的人很多，用cocos做遊戲的人也很多。所以對應的開發人員比較好招，而跨平台遇到的坑基本上它都填平了。最最主要的是，看主程的習慣，主程的習慣可以指導技術方向，還是那句話，引擎無法決定開發效率，正確的使用引擎才是。
      現階段最主要的缺失是一個完善的粒子系統，比如OGRE的Particle Universe，粒子系統本身和編輯器缺一不可。其他的再看看武器綁點、換裝能不能搞定，如果現在就可以的話，就不需要額外的開發工作量了。
      只要開發流程是正確的，編輯器沒有那麼重要，只需要情境、UI等部分內容支援所見即所得 (WYSIWYG)的編輯就可以了。熟悉流程要比熟悉編輯器提升更多效率。

五、就算方向錯誤，浪費時間了會有什麼損失：
      好像也沒什麼損失，一方面再一次證明我對Unity的欣賞是正確的，另一方面可以學習到底層的引擎技術。這個對之後開發都很有協助。當底層技術沒有問題時，開發遊戲就是寫邏輯，條理清楚的把邏輯實現就OK了。但是當遇到新的問題時，懂得底層會協助解決問題。
    

cocos2d-x進化為2.5D的一些想法