html5遊戲開發設計技術解析Egret篇

    近日，因為遊戲熱門而引起業内對遊戲引擎Egret(白鹭)倍加關注。Egret是一款适用于HTML5開發的遊戲引擎，也可以用在安卓、IOS、WP原生平台等。目前業界對于Egret的前景處于半喜半憂狀态，喜的是其高效的網遊轉手遊性能，憂的是H5遊戲狀況的不清晰。

    以下内容整理自Egret(白鹭)創始人相關解答：單就Egret本身而言，給出我關于以下幾個問題的想法。

    1.Egret為何用TypeScript？為何不用Dart,AtScript或者其他？

    TypeScript(TS)是一個嚴格意義上JavaScript超集，而且它目前的1.4版本的語言設計更接近于ES6，如果隻是單純認為TypeScript是微軟出的一個開源語言的，請認真去網站深入了解一下這個開源項目，了解以下微軟的首席架構師為何會針對JavaScript做了這麼個玩意。

    那麼為何Egret會選用TS呢？

    首先，我們認為Dart的形式針對很多會使用JS或AS3的開發者而言(尤其是初學者這個最大的群體)，學習的成本曲線較陡，而谷歌又是一個在技術上“太過”創新的公司，跟随一個有可能“朝令夕改”的技術去制作一款産品，而且将整個Egret的工具和服務的體系都懸于它之上，實在有些讓我坐卧難寝。谷歌的AtScript的目标又過于宏大，瞄準了ES7，但是就目前的H5的技術推進而言，下一個JS的标準是看齊ES6。我們想做一款創新好用的産品，但是首先我考慮的是先要創作一個能用的産品。

   回到TS，它目前版本是1.4，即将在2015出現2.0，語言的結構設計無限趨近與ES6的标準，有了module，有了Proxy，還會有很多更類似于ActionScript3.0的文法。微軟還提供了一個TS的編譯器，可以在編譯時為開發者提供很多幫助，而且我相信以微軟的實力，做個編譯器的水準還是很高的。目前的JavaScript恰恰有很多設計層面和開發層面的缺陷，TS都能或多或少的彌補這些問題。選用TS這個開源項目，能再現階段很好的幫助JS開發者創作更有規模，更成熟，更有品質的遊戲項目。

    其次，我們可以用TS基于Canvas來封裝跟Flash ActionScript3.0的API結構設計，而且，我們僅僅封裝對于遊戲有幫助的部分。我在Adobe的10多年，全部鋪在了Flash産品和技術上，Flash是個龐然大物，當初Flash團隊之是以放棄AS3到AS4，AVM2到AVM3的項目，很大程度上是Core的部分太複雜了，經曆了幾代架構師和開發的調整，更新重構的成本已經無法估量。簡單的說，就是當時沒人改的了，是以，我們也不可能投入研發去自己做一個complier或者virtual machine去讓AS3交叉編譯為JS。(君不見Adobe曾經宣布的AS3到JS的Falcon交叉編譯項目，3年了都沒動靜，最後随同Flex一起捐給了Apache基金會)。

    Egret的API設計隻是借鑒模仿了Flash AS3裡跟遊戲有關的API部分，做了減法，因為Egret Engine的定位不是想讓開發者拿去既可以做廣告，又可以做minisite，又可以做Video，又可以做遊戲。我們隻想在core上保持精簡，如果開發者對不同的遊戲類型有需求，比如狀态機，實體，粒子等等，都做到了core之外的game library裡。我2014年初離開Adobe時候，中國還有接近30萬的Flash開發者，其中90%是遊戲相關，這是一個寶貴的開發者社群群體，他們對于Web頁遊的開發和了解遠遠超過了任何使用其他web前端技術做網頁遊戲的群體。Egret使用TS，一方面是為了讓JS遊戲開發人員更舒服些，另一方面是考慮到Flash AS3這個開發群體，不争取的話，慢慢都流失掉了，很可惜。

    第三，我們使用TS，還有一個想法。将來的JS也是遲早會跟ES6看齊的，等将來所有浏覽器都統一支援下一代JS的時候，現在使用Egret的開發者都已經熟悉了ES6那套做法，而Egret幾乎可以0成本的直接将TS換為下一代JS的代碼，平滑過渡所有開發者，比JS現有體系過渡到下一代的體系成本都低，更順滑，何樂而不為？

   2.我們2014年一口氣做了一堆工具，而沒有一上來就做個內建的開發環境呢？

   我在這裡要回答的有2點。在技術和産品的進化上，第一條真理是：天下武功，唯快不破；第二條是，長鞭理論無處不在；第三條是：工作流是工作效率提升的根本。以上三條重要性依次降低，當一個CTO和CIO做了産品形态和研發的決策時，請倒推。

   說一說Egret的做法，Egret裡我帶的這幫人以前是做Flash Pro，Flash Builder，Flex GUI和衆多工具及架構的技術，很有經驗。但是經驗不能完全當做生産力，經驗不能當飯吃。經驗告訴我們的是，要想在市場立足，在最短時間内做出來的産品的“核”也就是中心思想很重要。它不必拘泥于是否先要有個IDE來承載這種形态，市場需要的是最有效率的工作流，其次才是一招打遍天下的IDE內建開發環境，工作流的形态可以先出現在最初的若幹款産品裡，他們之間獨立，小巧且專注，之間的資料通用且可以協作，對于研發而言，成本和風險均可控制。

   而IDE，功能強大且齊全，開發者需要的功能都具備，但是研發成本高，風險大，周期長。按照Egret Engine的雙周疊代速度，團隊潛心于一上來就要打造一個IDE的節奏是不對的。就好像你希望快走，但是又總有一條腿邁不出去的情況一樣，這個節奏的結果就是容易扯着蛋。但是2015年，我們也會做出一個第一版的IDE，叫Egret Builder。

   3.說了引擎和工具，Egret想怎樣商業化？

   商業化的問題其實在這裡我不想說太多，我隻想說，我們除了引擎，工具，我還讓團隊做了個運作時。也就是将來Egret的技術體系就是三位一體，Engine，Tools，Runtime。關于Runtime的細節，我也不想多談，大家可以去看看Egret Runtime的産品介紹頁，就明白我們為啥要針對H5做個Runtime。很多明眼人一看就會說，這不就是個Flash Player麼？！答案是Yes，也是No。

   Yes的部分是我們的團隊原來都是做Flash的，受Flash影響頗深。Flash Player裡具備很多優秀的Web遊戲設計思想都是很贊的，我們就想我們可以用C/C++和OpenGL圍繞着這些設計思想，再做一個取代webview的遊戲加速器，讓開發者基于Egret引擎開發的H5遊戲，可以直接通過這個Runtime加速。No的部分是Flash Player是to C的，要讓使用者去裝，而Egret Runtime是to B的，內建到平台app裡，作為一個庫，當使用者在平台裡玩遊戲時候激活，玩家是不知道Egret Runtime存在的，我們也不打算對玩家去刷什麼存在感。Egret Runtime是為了解決H5遊戲性能，适配，系統底層調用和碎片化的問題而生的一個産品。

   在Egret Runtime上，我們跟各大平台的合作關系也很融洽，為什麼？因為我們就是他們平台内部的一個元件，生命周期受平台app的控管，你激活我，我就幹活，你移除了我，我就進入sleep模式，絲毫不影響人家平台業務，還能提高H5遊戲的使用者體驗，也不騷擾使用者，何樂而不為？尤其在Android上，一個activity級别的控件是讓平台恐懼的，而一個view模式下的控件，平台是喜歡的。

   4.Egret現在就是個2D的，木有競争力啊！

   近一年内，Egret Engine的确是2D的，但是大夥不都是以進步的眼光看待事物麼？Egret也一樣，秉着天下武功，唯快不破的思路，我們規劃了一下2015年的Egret Next，我們也在預研3D的部分，code name是HummingBird(請原諒我們團隊就是喜歡鳥)，更細節一點的計劃圖在這裡：

   5.說了半天，你們的套路到底是啥？

   說H5移動遊戲也好，說Web移動遊戲也好，說用腳本開發native也好，工作流齊全了，這些還算是問題麼？

   作為Egret的技術管理人，在我10多年的職業生涯裡，信奉這麼幾句話：

   1. 永遠不要基于現在去假設未來。

   2. 永遠不要嘗試用一個成功打敗另一個成功。

   3. 預測未來的最好方式就是創造未來。

   4. 就是幹！

    以上就是關于遊戲引擎Egret(白鹭)的最新資訊，結合了該引擎的技術背景、商業模式、發展前景等方面進行了诠釋，希望能夠對你有所幫助。更多遊戲設計資訊www.hxsd.com