Why Unreal?
2019/09/10閱讀時間約 9 分鐘
動搖
最近，反Unreal的聲音一直在我耳邊出現。
他們的聲音不外乎是，沒有人在意App的穩定度啦，遊戲不需要那麼炫的效果和效能啦，找Unity的人很好找啦，授權太貴了啊等等。講到我真的是都有點動搖了。是啊，真有什麼「非用不可」的理由嗎？如果大家什麼都不在意，不在意穩定度，不在意視效，不在意製程靈活度，什麼都不在意了，那我又在堅持什麼？
可真的大家都不在意嗎？我看到的「大家」，是真的在實作的工程師們，他們都是Unity的好手，瞭解Unity的優點和缺點，他們希望能有人能出來開出另一條路，讓公司的產品能有能變得更好的可能性，而不是只能做出跟大家沒什麼差別的作品。
這次去CGDC，我看到更多的「大家」。有從大公司脫離出來做獨立遊戲人的，有抱著夢想做出自己認為的好遊戲的能人，有一直堅守著好引擎，發揮其優勢做出好遊戲的，這些人都選擇了Unreal。那些大廠呢？像大宇就用上了Unreal繼續他們的「仙劍奇俠傳」，像NVIDIA的RTX，AMD的CAS演算法，他們有什麼新的技術，第一優先也是在Unreal上開發，驗證及整合。這些人我想都不是時間太多，更不只是對新技術有狂熱才去使用Unreal的，而是他們打從心裡相信：
Unreal就是那個在遊戲業界創作了一款款好作品的專業引擎，現在開源了，我們要站在它的肩膀上，創作屬於我們自己的作品。
那些反對的聲音，每個都是對的，我不否認。因為近一點看，確確實實都是對的。
但若是認為自己應該有那份使命，要做出偉大產品的那份使命，那就應該要看遠一點。你以為「偉大產品」一定是3A作品嗎？那為什麼Epic Game Store有那麼多獨立開發者，用Unreal開發著一些8bit像素的遊戲，或是一些核心玩法很簡單的小遊戲，許多遊戲視效都不怎麼樣，絕對不是3A(根本是0.3A)遊戲，但我相信那些都是「偉大產品」，為什麼呢？
這就像是料理漫畫或卡通常表達的那個理念一樣，用心的料理才會打動人心，也就是：
你和你的廚具互相認同，合作出來一道量身打造的料理，讓吃了的人產生無比的愉悅感。
類比到遊戲開發，即便是Unity，若能讓開發者覺得認同，能好好協作出好作品，那也是很好的。但在公司，我一次次看到專案的開發人員，在自己寫shader code以省去多餘的效能消耗，在為釐清是Unity的問題還是自己遊戲碼的問題加班驗證，在想辦法繞過Unity一些很奇怪的bug而把既有的實作改了再改，在為了產品不穩定亂崩潰而努力的優化時，我一點都不覺得，這哪叫「大家用得好好的」？這哪叫「不在意穩定度」？這哪叫「不在意效果/效能」呢？我看到的是大家都在意自己產品的完美，但在扯後腿的都是Unity？
Why Unreal ?
剛剛說的偏激了。Unity確實把許多事情處理的很好，也很好上手，沒有它我們其實會更寸步難行。那回頭再看，Unity有其極限，那為什麼不是去找別的開源引擎，而是Unreal？一而再，再而三的這樣詢問自己，我每次都得到同樣的一些答案。我想，是時候做個記錄了，才不會再花腦袋去被別人影響而動搖。
效果及效能
我自己確實還沒有好好的啃過源碼，瞭解它的好效果及效能來自於哪裡，而且效果及效能的比較本就實屬不易，難以公評，這邊就不講技術，只看趨勢。如果3A大廠到獨立開發者都使用了這個引擎，而且趨勢持續往這個方向在靠攏，那我想就算實際上Unreal沒有真的比Unity好多少，但至少一定不會更糟，對吧？
關於插件(Plugin)
雖然Unity近年來一直在加強引擎的本體功能(雖然都是吞別人做好的，但合理)，但這都一直在說明同一件事：Unity自身的功能真的不足，才會有那麼多的插件來解決專案實作上的需求。和Unreal少有Editor插件在解決製程上的需求這個狀況比起來，差別在什麼地方呢？就是穩定度和相容性。
Unity的用戶面對升版這件事，是出了名的困擾。因為Unity自身功能不足，有些需求都是靠外掛解決的，但升版後往往就會造成插件的不相容。那不是官方要解決的問題，是你們用戶和外掛的作者要解決的問題。那可以不要用插件嗎？那規格缺口是誰要補上？那繼續用嗎？編不過的問題又是誰要解決？
另一個問題是外掛可能直接造成你產品的品質不良。為什麼呢？外掛的作者想得到的狀況，能做的測試，就是一個人的能力。官方有專屬的人力，自動化大規模的測試，那絕對不是同一個量級的。所以你用了外掛，有問題的話只得祈禱作者願意，也有那個心力會去解決，沒有是正常的。
引擎自身
這就是你選擇Unreal的最後一道防線了：引擎源碼。
引擎本身的設計是通用型的，不會根據你專案的規格量身打造。比如說，今天你是在做一款格鬥遊戲，你希望在調整招式的數值時，馬上可以在Editor裡面試試看是否OK。在Unity是否做得到，得看它開出來的接口是否都能滿足你的需求，可能可以，可能不行。但若是真的不行，你就得放棄或是繞路，就是規格及開發時程的損失。但在Unreal？你就直接來了啊，引擎有的接口你就接，引擎沒提供的你就自己開，引擎是你的，你當然有權力去把它改成你要的樣子。
引擎也是人寫出來的，人寫出來的就是會有bug。當你的產品被發現有記憶體洩漏的時候，你一定非常驚訝吧？Unity不是號稱它有自動記憶體管理系統嗎？為什麼還會有記憶體洩漏呢？是我的寫法有問題，還是引擎的實作有問題呢？怎麼確認及驗證呢？當你的產品不定時機率性的崩潰時，它努力的告訴你call stack，但你也只能看著call stack來瞎猜一番。運氣好會被你猜中，運氣不好的話你就有得找了，因為Unity就是個黑盒子。在Unreal的世界，簡單一點你下下log就看得出來了，複雜一點就接debugger來跑了，不用猜，證據說話。
巨人的肩膀
我常跟身邊的人說，世界上目前只剩下三種遊戲引擎。一個叫Unity，一個叫Unreal，另一種叫「Others」。
最近5年，許多新的主機照慣例被發表了出來，許多新技術更是突然給砰了出來：Vulkan, VR, AR, XR, Machine Learning, RayTracing等。許多平台更是之前沒有過的：H5, Streaming(Google Stadia), Apple Arcade, In-Car Playing, 微信小程序等。以前的遊戲產業算是涇渭分明，差異極大。但隨著新技術的爆發，不要說市場是全球化了，連「新科技」和「目標平台」都是全球化的了。一樣是一個轉輪遊戲，你不加入個新技術就沒有亮點了，沒有社群分享機制就沒有影響力了，不支援到全平台就少掉多少市場了…很多不是我們中小企業玩得起的規模了。任何一個新技術你要從無到有，想要靠自研來取得優勢嗎？任何一個新技術，要等你自研到能投入到產品成為feature，都不是你玩的起的。
從我們自己fork出cocos2d-x來維護的經驗，到現在我們想把Unreal導入公司使用，我們都深刻的體會到一件事：「遊戲引擎」不是引擎，而是「巨人」。你看到那個巨大的身影了嗎？那後面是多少的研發結晶匯集出來的呀！絕對不要有「我們只需要xx的功能而已」，或是「我們可以改一下就能符合公司需求」這樣天真的想法，因為現在不會再有「小遊戲」了，任何一個小遊戲都要有面臨多平台，多裝置，多技術亮點等各式各樣的需求，我們唯一能做的是，小心的站在巨人的肩膀上，跟上趨勢，別跌下來了。
看深遠一點，打好馬步吧
最令我動搖的，莫過於「我看不出有任何理由，用戶非用Unreal不可？」。可是大家在看的商管書籍，成功學，那一個不是叫你要看遠一點，想深一點？當我靜下心來好好思考後，突然意識到這種狀況就跟「控制狂又怎樣」提到的果然是一模一樣，人們會很習慣性的往平庸的方向去思考，因為這樣很安全。
就我自己的「投資」經驗來說，也往往都是這樣子。在三、四年前，身邊的人還在用C寫專案，用zip做版控(很多是根本就沒有)，一定要用Visual Studio，面對新技術的第一個念頭就是「我現在這樣不是好好的？」的時候，那時候我的生活比較單純，沒那麼多雜事，也就很單純的相信自己的角度，靜心下來把C++, git, make, vim這些看來一點都不討喜的基礎。當時也就一個想法：
我看到的世界，這些「基礎」非但沒有消失在日新月異的技術演化，還反而解決了一個又一個問題，成為許多偉大作品的基石，不學這個我要學什麼？
當時也沒馬上有什麼偉大的進展，在學習的過程遇到問題，找書看資料，克服問題，繼續前進。與其說是這叫「相信自己」，我更相信的是我看到的世界。後來確定我打下的基礎，在日後都陸續派上用場時，當然會覺得很值得。但當時其實沒有人會鼓勵你打這些基礎，甚至有人還會覺得浪費時間，有人覺得方向不對，要”務實”一點等。當然這就是「賭」，既然你都知道不進則退，沒人可以「早知道」，那為何不相信自己看到的世界呢？
瞄準月亮，至少射中老鷹。看得深遠，打好馬步，又何需怕浪費時間，血本無歸？當你在覺得「現在這樣不是好好的？」的時候，你就是在不進則退。
為什麼會看到廣告
33會員
63內容數
留言0
查看全部
