虛幻4隨筆7 未知的將來

虛幻都免費了，再不說句話彷佛就有點過度了。

在此首先向一直關注的諸位網友道個歉，這幾個月筆者稍微遇到點事兒，首先是當爸爸了，因此佔了很大的精力。

而後，對於將來的選擇和定位、職業發展方向上，筆者這幾個月也是頗爲糾結的。去年末，最終決定要離職了，要從當前的生活模式和狀態中暫時地退出來，去折騰一下本身所但願的將來。因此心思多少也不在研究上了，並且，既然作出了這樣的決定，就須要把手頭自己計劃作到今年中旬的業務，集中壓縮在離職前作完，因此這段時間也是蠻折騰的。

最後就是，這幾個月本身研究方面的東西乏善可陳……一個3D宇宙的解決方案遇到一系列的坎兒，一個Noise編輯器也是越弄越崩潰，原本計劃的對Task Graph的研究、對Kinect的集成也始終沒有完成。確實沒有什麼太多能拿得出手來的東西能跟你們分享，因此，千言萬語，到最後仍是很抱歉的。

其實最近一直有關注論壇和Q羣，不開心的時候，看看Q羣裏一幫堅持着理想的戰友各自都有很大的進步，就會以爲本身這小九九簡直就不叫事兒。不管如何，接下來應該是能夠慢慢把虛幻再撿起來了，一塊兒努力吧，爲了每一個人本身的夢想。

虛幻其實學習應該不能算困難的，發現的不少問題，其實都是官網文檔庫和Content Examples裏都有的，建議想接觸的朋友必定要先把Content Examples看完，看Example的時候，參考相應的文檔庫文檔。而後再看看官方其餘的示例，好比ShooterGame之類的。最後是多看看論壇、wiki，裏面有不少人討論一些問題的製做方法。這麼一套下來，基本應該是差很少能開始作東西了，剩下的問題就是作的過程當中遇到問題，查問題，問問題之類的了。

 

正如一開頭所說，虛幻引擎免月租費了，以前是每月6碗拉麪錢，如今連這6碗拉麪都給省了，興奮的我決定接下來連吃一週蘭州拉麪。固然，抽成仍是要的，以爲本身能賺不少的項目，也有支持更好的商業買斷的版本。虛幻引擎在國內一直是一個不算很大衆的引擎，它的前身UDK，在中國也不溫不火，遠不如在國外的熱度。而最難逃開的問題，全部UE羣都必然爆發過的，就是"真理的大討論"——UE與Unity的PK。

說實話，我的感受，這倆PK就跟XBO跟PS4去PK似的，其實沒啥必要。引擎歸結到底也就是個工具，作什麼遊戲用什麼工具——若是要作經典FPS，那首推UE四、CE；若是要作手遊，首推Unity、Cocos；若是要作英雄聯盟——那就啥都同樣了，由於最大的製做成本是發生在設計AI上……固然這麼說就太簡化了，挑選引擎有時候也沒那麼多講究，多數人每每是有權挑項目，無權挑引擎的。到如今爲止，筆者都是參與項目以前就有人幫我訂好了引擎，從未能本身去挑選引擎。其實，這種程序人員在遊戲項目中的尷尬地位，比起究竟是UE好仍是Unity好要更深入地傷害着咱們這個遊戲行業。更可怕的是，引擎優秀與否的標準居然是隻看圖形效果是否牛掰……因此常常感受Unity的火爆其實從各個方面都是一種好事——最重要的是應該會讓那些依然關注圖形的人們好好想一想，究竟什麼對於引擎纔是最重要的？

每一個引擎，都有本身的特質。Unity 4是無法自定義Mesh Stream結構的（5沒有來得及跟），這就會限制不少高級效果的引入；而UE在手機上的優化須要作的工做太多，追求短平快的也不是個好的選擇。對於項目而言，悲劇的是拿了水果刀去切豬骨，或者拿剁骨刀去削蘋果皮……工具的追求上，都瞭解瞭解會比較好。固然，若是隻是爲了找工做拿好點的工資，頁遊火那陣一開始作網頁的不少人都賺了，可是那會兒開始着急忙慌學網頁開發的有多少找到好工做了？能作到別人作不到的，天然就有人來找你，作不到別人能作到的，天然也就只能給人打工，祝好運吧。

其實說實話，Unity和UE4在上層部分的構架沒有那麼大的不一樣。記得最有意思的一個例子，就是有網友說，他的前輩告訴他，虛幻無法作RTS那種在地上放建築的系統——然而正好兩週前筆者作了一個相似的系統，並且是徹底用藍圖，一行代碼沒寫……UE目前"作不了"的東西確實是有，好比資源的全面動態加載，這個咱們項目以前針對UE3作了一套解決方案，可是先後折騰了很長時間。但上層部分……筆者我的是沒想到。引擎只是工具，策劃的需求如何用工具去表達出來，這是程序的功底和價值。我遇到過太多"這個作不了，那個很麻煩"的程序，這種遇到事情先放棄的心態，只怕比選擇什麼引擎帶來的問題更加可怕吧……

 

如今的時代，共享已經成爲了主流，這也是符合社會化大生產進一步進化的要求的。生產更加社會化，就致使每一個人所需關注的點少了。曾經制做遊戲的人，一個程序每每須要把從圖形到狀態機到AI到聲音的全部步驟都能給Hold住，那個時代對咱們而言，就像是在聽希臘神話裏那些神祗的故事同樣。可是隨着遊戲項目規模幾何級數的增長，到如今爲止，就算有一我的可以把從引擎到客戶端到服務器整套東西都能作出來，他也沒有時間把這些都作出來，由於時間徹底是沒法承受的重量。因此這個時代，最重要的技能是去Github和stackoverflow裏面尋找各類巨人的肩膀，從一個巨人的肩膀上跳到另外一個巨人的肩膀上。一樣，本身作的東西也能夠扔到上面去，共享給別人，讓別人看，讓別人給你調錯，給你找Bug，發現你的問題，讓你提升，同時把你的東西越改越好——因此你看，Unity商店、插件的機制，從小到大，但他選擇的這條路正好是符合這個時代的特徵的。時代的變遷，生產力的進化，完成了它的必然性的構成，而Unity自己中庸而全面的特性，完成了它偶然性的構成，結果就是今天Unity的地位。其實同時代的國內有很多自研引擎也走到了這一步的門檻，可是封閉讓咱們錯失了這個機會。特別是虛幻開放以後，才發現開放這招非但沒有對本身形成不良的後果，反而全世界的開發者幫你查Bug，挑問題，基於你的系統來作第三方接入，慢慢構建起一套生態系統。……開源，真的一點都沒有吃虧啊！

時代已經變了，如今，已經沒有一家公司可以徹底地掌握全部先進的東西。共享、合做、分擔、共同進步……雖然在國內不常能感受到，可是它們確實是在發生而且影響着咱們的。用Unity卻從未下過插件，啥東西都是本身搞出來的，有幾個呢？雖然咱們可能覺得這是天經地義的，但它畢竟脫胎於那個不是那麼天經地義的時代。

新的時代來臨了，各自都要作出應對，而Epic的應對，就是UE4——一個在UE3之上，全面加強模塊化和擴展性的解決方案。

其實UE應該很早就意識到這個問題了，UE3的集成度和擴展度其實一直是很高水平的，基於反射體系構建編輯器、自動序列化，Actor/Component構型，07年的時候我就從UE中學到了，那一批看UE的國內程序同事們應該不少人都寫過相似的文字。在整合第三方庫方面，UE也仍是蠻簡單的——相對於同時代的其它引擎而言。Beast、Scaleform……咱們本身隨便搞搞，也能往裏面很方便的就把本身的服務器框架什麼的整合進去。UE3商業受權的話，也可以拿到其它項目的示例，戰爭機器、劍靈、Atlas……仍是很讓人受益不淺的。UDK在國外的討論也是一直很火（國內可能不少人不是很清楚，Unreal的MOD社羣在國外一直是一個比較大的社羣，虛幻競技場在歐美的活躍程度是很高的，歐美引擎很是注重養MOD社羣的，歐美的玩家也更具備海洋民族的開拓精神）。

可是，UE3體量太過龐大，結構中一些死結仍是不少的。並且，雖然UE3好擴展，可是再好擴展也要各類修改C++代碼，想辦法在虛幻的結構之間打上各類各樣的眼兒，把本身的代碼注入其中——這都會在後面的升級和維護中形成一系列不可預估的後果。

首先，模塊化。UE4這套插件體系，在UE3中就是不可想象的。UE4作第三方集成，比VS工程作集成還簡單，模塊結構分的瑣碎也使得它必須去設計一系列模塊間進行交互的接口，使得作插件的時候能夠直接去訪問這些交互接口，在插件裏寫出引擎的範兒，也絲絕不用擔憂本身會破壞引擎的結構。而UE3裏，則須要各類找對應處理的地方，往裏面加入本身所需的代碼。引擎一旦升級，就各類須要從新集成，平均每次升級基本上一個月的功夫就沒了。而UE4的升級，只要接口不變（一個引擎數十上百個接口，並且接口自己就高度抽象，再大的升級也不可能全部地方都變啊），基本上放那裏無論就行。目前來看，最短一天，最長一週，就基本能夠完成項目的新舊版本遷移。至少如今是勇於去作這件事情了，以前的UE3項目，作一次升級那個困難啊……不到實在忍受不了的時候，誰也不肯意去開個頭。

此外，UE3的不少遊戲系統設計是很是棒的，只是一是跟FPS相性最好，其餘遊戲類型就要差點，另外一個就是不應出如今引擎的核心層裏：好比Game Mode，好比Login產生Player Controller，好比Controller變化要通知服務器廣播……諸如此類的不少不少。熟知這套系統的，天然也能遊刃有餘地在其基礎上繞出本身的玩法，可是它畢竟增長了理解成本。並且，一旦不作FPS，多多少少是要花點工做量繞一些概念的。好比要作RTS，Controller對Pawn的控制流程就會顯得雞肋。雖然對於熟悉的人而言，繞這麼幾下都不是個事兒，但畢竟這是一個不必的事情。可是，這一點，話要兩說，Unity夠自由，徹底不在遊戲系統中作限制，缺點就是前期插件來插件去，很容易搞出一個很讓人不知如何評價的遊戲系統——特別是在遊戲系統的設計層面國內鮮有人會去關注的狀況下。在項目廣泛比較接近原型開發、強調速度、策劃也願意各類放棄的手遊項目裏，還能夠接受。可是一旦項目作大一些，特別是等到開始玩"刀尖上的芭蕾"，同一個系統要經受各類預想不到、沒法假設的狀況的時候，這樣的問題就會暴露出來。因此就算是用Unity作項目的朋友，我也會常常向他們推薦UE的這套上層架構，包括過來公司參與項目，第一件事就是推行這套上層架構的概念。UE4爲了加速迭代，這套架構的不少方面在不斷弱化，而把所謂的自由更多地交給了製做者本人，因此其實BP如今能夠徹底繞開Game Mode和Player Controller，在幾乎無視他們的狀況下完成整個遊戲。但這對於系統複雜的大項目來講，極可能前期的這種設計就是後期開發團隊崩潰的根源。

最後就是對異步、並行的一系列支持。Task graph還沒跟，可是如今已經不單純是分邏輯線程和渲染線程，而是有了明確的線程池和業務的概念，將來並行這塊的進化有不少能夠期待的地方。UObject極可能會在後面的幾個版本中全面異步化，借之影響的是資源系統的全面異步加載從理論上成爲可能（甚至看Trello，UE本身就在作這方面的工做）。

咱們站在今天的角度上去批評UE當年的決策，無疑是很不公平，就如同咱們今天去批判C++爲何不早點引入C++1x這些特性同樣。我想，若是理解了UE是怎麼一步一個坑走過來的，應該也就比較容易理解UE4後續的一系列決策了吧。

因此，UE4來了。無論這一步是早是晚，無論這一步是來得及時仍是不及時，它終究是在2014年的GDC來了，並在2015年的GDC免費了。

而UE也確實沒有讓咱們失望，從一開始的4.0就可以看出來虛幻在對UE3一系列須要改代碼才能實現的功能在作各類的封裝和抽象。虛幻3只有十幾個代碼模塊，而虛幻4則抽出了數十個模塊——理論上，每一個模塊，除了依賴模塊外均可以互相獨立存在，這就必需要求在模塊之間抽象大量的接口。UE3以前不少直接調用的地方，如今都變成了接口調用，特別是編輯器方面，致使如今的編輯器擴展變得簡單許多。遊戲系統部分，也簡化了和弱化了許多虛幻3固有的一些概念，致使你不知道Player Contoller，不知道Game Mode，照樣能夠作本身的小遊戲。UE4一系列C++的實現也簡直是教科書般地優美，我如今在作一些C++ Console工程時，也已經再也不使用VS的Wizard，而是直接在UE裏建立Console工程項目了。……

這簡直就是一座寶庫，若是您的目標不只僅是開發一個簡單的手遊、不只僅是去折騰遊戲系統和數值，而是想作一些別人想都不敢想的東西，那麼，虛幻無疑是適合你的。它的代碼可讓你受益良多，亦可讓你對整個系統擁有無可爭辯的控制權，隨意地增長一些還沒有出如今這個世界上的遊戲特性。

……嗯，越寫越像傳銷了……由於我的確實是喜歡虛幻，它在強大的功能和強大的擴展性之間創建了絕妙的平衡，雖然仍然還有一些不足，可是隨着社區的擴大、第三方庫的不斷加入，相信虛幻的將來會愈來愈易用、愈來愈強大。可是，說到底，不管引擎仍是第三方的各類技術，都只是工具。Demo和產品之間橫亙着巨大的鴻溝，更遑論是製做這些Demo所需的底層技術和工具。對於項目而言，工做流、人員、資金、目標受衆、穩定的團隊、整合程度……全部這些纔是核心和關鍵的。

 

說了這麼多，其實沒有什麼乾貨。從公司離職後，應該能有更多的時間去作UE部分的研究，但願下一篇隨筆能多點乾貨。