新編輯器Cocos Creator發佈：對不起我來晚了！

1月19日，由Cocos創始人王哲親手撰寫的一篇Cocos Creator新品發佈稿件在朋友圈被行業人士瘋狂轉載，短短數小時閱讀量突破五位數。Cocos Creator被譽爲「註定將揭開Cocos開發世界中全新的一頁」，究竟它有什麼魅力?下面讓咱們來細細閱讀這篇文章。

如下爲全文：

上週我在廈門的「哎喲，2016」酒會上，宣佈了今年會發布一款新的編輯器。是的，今天我來了：

Cocos Creator在經歷了一年多的低調研發以後，今天終於發佈了第一個正式對外的公測版，你們能夠從 cocos.com/creator 下載。

那麼相比Cocos家族以前的編輯器產品，Creator有哪些不一樣呢?我們先看一段視頻，引擎開發團隊全體出鏡哦：

【產品定位】

若是今天讓我從新設計一次遊戲引擎，只考慮用戶體驗和開發效率，那麼我但願這個引擎能：

• 腳本化，我但願GC自動回收和手動回收都要有，這樣易用性、性能保證兩手抓兩手都要硬。我不再想看到噁心的retain / release了。C++是門好語言，可是考慮到開發效率，我更傾向於純腳本;

• 組件化，而不是面向對象繼承的擴展方式。各位讀者誰曾經直接在Node，甚至Object裏面增長函數的請舉手?不敢舉手是吧，必定怕被大家CTO拍死?這就對了。之後請嚴格用組件化思路來擴展引擎，習慣後你就會以爲渾身每一個毛孔都很爽，由於告別了噁心的hack代碼;

• 高效工做流，策劃和美術可以經過引擎編輯器獨立生產和調試，讓程序員減輕資源管理更新上的負擔，專一於功能開發，而不是參與「無盡」的調數值、調UI;

• 高度可擴展，引擎框架和編輯器都須要靈活擴展，而且但願能經過統一的編輯環境整合各類自定義工做流和擴展工具。其實組件化和數據驅動都是爲高度可擴展服務的;

• 純粹，專一，我但願僅用一門編程語言就能夠完成全部工做。我說的「全部工做」包括遊戲邏輯編碼、引擎擴展、編輯器擴展。我討厭的現狀是：須要用C++擴展引擎框架、用Lua編寫遊戲邏輯、用C#擴展編輯器，不少端遊時代過來的公司都是這麼幹的，可是成本過高了。咱們須要僅一門編程語言就能夠完成全部工做!

• 廣義多平臺，不只僅是原生的多平臺。我但願能夠一次開發後，將遊戲一鍵發佈到iOS, Android, Windows, HTML5以及Cocos Play平臺，也就是兼容Native, HTML5, Runtime三種技術形態，哪裏有用戶，我就能夠把遊戲發佈到哪裏，最大化流量獲取。

Cocos Creator就是這樣的一個產品，實現了個人全部但願與抱負。在Cocos Creator裏，咱們結合了以數據驅動和組件化爲核心的遊戲開發方式，並在此基礎上無縫融合了Cocos引擎成熟的JavaScript API體系，一方面可以適應Cocos系列引擎開發者用戶習慣，另外一方面也爲美術和策劃人員提供史無前例的內容創做生產和即時預覽測試環境。

若是讓我用一句話描述：

Cocos Creator是之內容創做爲核心的遊戲開發工具，在Cocos2d-x的基礎上實現了完全腳本化、組件化和數據驅動等特色。

嗯，上面這句話你在將來的幾個月會聽到耳朵長繭，由於這就是我和引擎團隊對Cocos Creator產品的定位描述。

來張靚照吧

因此，若是您正在考慮這些問題：

• 但願能用更低成本、更高效率地開發出來一個基於cocos2d-x的遊戲。特別是有cocos2d-js的使用經驗;

• 但願一次開發，能夠把遊戲同時發佈到iOS和Android，以及新興HTML5手機頁遊平臺;

• 但願程序和策劃、美術的工做進行解耦，讓策劃和美術能夠獨立生產和調試;

• 但願本身很容易對引擎的框架和編輯器進行定製、擴展;

那麼Cocos Creator是一個很是合適的選擇。

【核心理念】

高效工做流

引擎和編輯器的結合，帶來的是數據驅動和組件化的功能開發方式，以及設計和程序兩類人員的完美分工合做：

• 設計師在場景編輯器中搭建場景的圖像表現

• 程序員開發能夠掛載到場景任意物體上的功能組件

• 設計師負責爲須要展示特定行爲的物體掛載組件，並經過調試改善各項參數

• 程序員開發遊戲所須要的數據結構和資源

• 設計師經過圖形化的界面配置好各項數據和資源

就這樣從簡單到複雜，各類你能想像到的工做流程均可以實現。

以工做流爲核心的開發理念，讓策劃、美術、程序都能在工具裏快速找到最大化本身戰鬥力的切入點，並可以默契流暢地和團隊其餘成員配合。

因此，神馬調UI調數值，策劃美術能夠本身妥妥搞定，老子準時下班泡妞去了。(各位程序員朋友，此處應有掌聲)

數據驅動

這其中最實用的功能是，腳本中能夠輕鬆聲明能夠在編輯器中隨時調整的數據屬性，對參數的調整能夠由設計人員獨立完成。也就是說你代碼按照指定的格式聲明變量，而後這個變量就能夠在Cocos Creator編輯器裏面暴露出來，讓策劃人員直接在編輯器裏調整數值，直接看運行效果了。

一體化，包含代碼編輯器

Cocos Creator包含遊戲引擎、資源管理、場景編輯、遊戲預覽和發佈等遊戲開發所需的全套功能，而且將全部的功能和工具鏈都整合在了一個統一的應用程序裏。它以數據驅動和組件化做爲核心的遊戲開發方式，而且在此基礎上無縫融合了Cocos引擎成熟的JavaScript API 體系，可以一方面適應Cocos系列引擎開發者用戶習慣，另外一方面爲美術和策劃人員提供史無前例的內容創做生產和即時預覽測試環境。 編輯器在提供強大完整工具鏈的同時，提供了開放式的插件架構，開發者可以用HTML + JavaScript等前端通用技術輕鬆擴展編輯器功能，定製個性化的工做流程。

對於無數用戶反覆追問的Cocos IDE到哪裏去了?我第一次開誠佈公地說，很抱歉，不用等了，Code IDE項目已經終結了，不會再有更新。由於不管是Eclipse方案，仍是IntelliJ IDEA方案，都沒法完全和Studio或Creator融合。可是做爲一個未竟的夙願，我和引擎團隊在Cocos Creator補償了這一點：Cocos Creator帶有一個JavaScript的代碼編輯器，編輯器不只帶有你們迫切須要的函數提示、自動補完等功能，並且和Cocos Creator的場景編輯器無縫銜接——這點是Code IDE作不到的。最後是依託於Chrome瀏覽器強大的JavaScript調試功能，咱們能夠在啓動調試以後，很方便又流暢地調試腳本代碼啦!

要調試JavaScript腳本?從Cocos Creator裏面一鍵啓動Chrome馬上開始調試：

附帶一個好消息是，微軟的VS Code開源項目，和Cocos Creator用的是一樣的底層框架Electron，因此咱們正在評估考慮如何複用VS Code這個大輪子，以快速提高Creator裏的編碼體驗哦!

大幅改進的UI 系統

各位可能在上面的視頻裏面看到了新UI系統如何動態適配不一樣分辨率的狀況。是的，咱們改進了整個UI系統，也許改到你已經不太認識了，但事情的關鍵是：咱們解決了多年以來積累的許多問題和需求。Creator裏面的UI系統，支持智能畫布適配和免編程元素對齊的UI，使之能夠完美適配任意分辨率的設備屏幕。這點對於HTML5遊戲特別重要，而原生遊戲也能從中收益頗多。

在Cocos Creator裏面，UI編輯、動畫編輯都整合在這樣一個界面裏：

廣義的多平臺發佈

目前Cocos Creator支持發佈遊戲到傳統的iOS, Android平臺，以及新興的HTML5手機頁遊平臺上，特別是支持Cocos Play的runtime加速器。因此這裏的多平臺已經比以前cocos2d-x的多平臺更廣義了：橫跨Native和HTML5。固然咱們也不須要再和各平臺的工程文件、晦澀的makefile打交道了，在純腳本的世界裏一切都變得簡單，配置開發環境的要求已經被徹底移除，在運行以後就能夠馬上開始遊戲內容創做或功能開發，是否是很簡單?這就是我下很大決心作「完全腳本化」的明顯收益之一。

完善的配套文檔和社區支持

文檔，首先固然是文檔。你能夠從cocos.com/docs/creator獲取產品的用戶手冊，而更簡單的方式是直接從Creator的菜單裏面點「文檔」打開用戶手冊的離線版，離線版，離線版哦!

在示例遊戲方面，咱們此次版本發佈就帶了4個遊戲示例。其中一個21點撲克牌遊戲仍是和騰訊遊戲合做開發的，美術資源所有由騰訊遊戲受權。反正引擎團隊這幫技術宅是畫不出這種品質的遊戲美術。再次特別感謝騰訊遊戲對Cocos Creator的幫助與加持!

除了文檔和示例遊戲以外，咱們還錄製了Cocos Creator的教學視頻，你能夠在離線文檔裏很容易找到。咱們會陸續更新更多的教學視頻放到文檔裏面。

****

【回答Cocos2d-x老用戶關心的問題】

Cocos Creator和Cocos Studio的定位區別?

我這人很誠懇，既然說到「產品定位」，那麼我必定不會只說Cocos Creator的好處，這裏我也要說說Creator不合適如下狀況：

• C++和Lua的死忠粉，但願學一門語言吃一生的程序員 —— 不適合。爲了Cocos Creator的純粹，我選擇了JavaScript做爲引擎、編輯器、遊戲邏輯的核心語言。雖然從技術角度講Creator也能夠支持Lua和C++遊戲，可是今天我仍然但願保持這個產品的「純粹、專注」。因此不論大家怎麼噴，在編程語言方面，我今天不打算妥協。別TMD和我吵，難道您不知道「PHP是全世界最好的語言」麼?嘿嘿。至於爲何在Cocos Creator裏面選擇JavaScript，下文我會詳細解釋緣由，請耐心往下看;

• 對包體積「極端」敏感人羣。以Android版的引擎runtime.so文件爲例，v3.x版本的引擎上，Lua空包體積3.6M，JavaScript空包體積5.2M，因此JavaScript會比Lua大出1.6M，主要是由於JavaScript VM的體積要大一些。咱們正在作各類包體壓縮的工做，將來空包體積會進一步下降，但Lua始終會有1M左右的優點;

• 但願用Cocos 3D的編輯器功能。目前Creator的研發進度還沒法支撐3D編輯需求，支持3D和VR的時間點待定，不會很快，有這方面需求請選擇Studio。

因此，對於有上述需求的用戶，能夠繼續使用Cocos Studio編輯器。Studio和Creator是兩條平行的產品線，我打算平行地維持很長一段時間。

爲何不Cocos Studio上實現這些功能?

多種編程語言門檻使得Cocos Studio難以擴展。雖然咱們在Studio裏推出了自定義控件的擴展功能，但實際上因爲引擎修改用C++，遊戲邏輯編碼用C++ / Lua / JavaScript三選一，編輯器擴展用C#或Lua，通常團隊須要掌握三門編程語言才能完成Studio的擴展插件。因此實際使用中極少團隊能夠可以輕鬆 Studio作擴展插件。

在Cocos Creator裏面，「僅須要」一門JavaScript語言，就能夠覆蓋遊戲邏輯編寫、引擎框架擴展、編輯器擴展三個工做量最大的區域。若是配合node.js作服務端框架，那麼只要掌握JavaScript就能夠全盤通吃了。若是再從npm上撈一點方便使用的package，這日子可就滋潤多了。

爲何拋棄C++作完全腳本化

框架層面：咱們嘗試過在C++上實現組件式結構，結果引擎組的高手寫出來的C++代碼像極了STL庫的風格，我以爲至少有1/3的Coocs引擎團隊人員沒法一眼看懂這些C++代碼，更不用說各位用戶了。若是咱們硬要走C++這條路，最後會致使引擎框架代碼難以理解和進行調試。若是咱們非要發展示代遊戲引擎的組件式結構，那麼只能選擇腳本化了。另外，腳本化的附帶好處就是不須要處理各平臺的工程文件和makefile。

在編輯器層面，若是C++一條路走到黑的話，必然要選擇用Qt來開發編輯器。可是C++在編輯器的缺點很明顯，就是必定要經過編譯纔可以使用。這致使了兩個結果：

(1) 編輯器插件的分享者提供所有源碼，讓策劃和美術人員本身編譯去用;

(2) 編輯器插件的分享者提供windows 32bit, windwos 64bit, mac 64bit, linux 32bit, linux 64bit, ios 64bit, android 32bit, android 64bit給策劃和美術人員自行選擇下載;

上述兩種狀況，都不是策劃和美術人員能夠承受的。換成腳本就簡單了：上傳腳本(可開源、可混淆加密) -> 下載腳本 -> 解釋運行。直接跳開了編譯過程。

可是腳本化並非意味着整個引擎都用腳原本寫。Cocos Creator的框架核心仍然是你們熟悉的整個Cocos 2d-x C++引擎，引擎的主循環和絕大多數計算工做都在C++層面完成。只是利用JavaScript bindings綁定出Cocos Creator的JavaScript API。因此你們無需擔憂性能問題。

爲何在腳本里面選擇JavaScript而不是Lua

哈哈，這是個好問題，good question，pretty good!我知道必定會被國內無數的Lua程序員的口水淹死。首先聲明，Cocos Creator的架構，徹底能夠支持在上面用Lua把全部工做所有從新實現一遍。僅僅是翻譯和資源投入的問題。

可是，我不打算這麼作。

我更但願「純粹、專一」地先作好JavaScript，不承諾對Lua和C++的支持時間點。將來也許有1%的機率會改主意，可是今天我很堅定。有幾個主要緣由：

1. 無數的大公司，包括Microsoft, Google, Apple, Facebook, Intel等都在大力投入JavaScript的研發上面，但Lua則沒有這個生態。JavaScript領域，有node.js，有npm，這些Lua都沒有;有Intel的nw.js(node-webkit)，有Facebook的React，有Apple和Google鼎力支持的HTML5和WebGL，有Mozilla的asm.js，在桌面跨平臺領域有Github的Electron和Atom，有Adobe的Brackets，而咱們沒有見到上述哪家大公司投入資源大把資源在Lua上，這-是-事-實。請各位老闆深思爲何巨頭們都作出這樣的選擇，或者大家以爲本身比這些大公司的決策者更聰明也無妨。

2. JavaScript可讓遊戲跨Native, Runtime, 純HTML5三種模式，也就是我上文所說的「廣義跨平臺」，而Lua只能發佈前兩種。今天騰訊QQ瀏覽器、QQ空間、QQ遊戲大廳已經都開放手機頁遊接入了，騰訊工做室的《歡樂鬥地主》已經發布了基於Cocos Play加速器的手機頁遊版本。若是哪一天微信或手機QQ開放了 HTML5遊戲領域，那時候再來Lua轉JavaScript就已經來不及了，各位老闆只能面壁哭去了。

3. Cocos Creator底層選擇了Github公司開發的開源項目Electron。而Eletron是Github官方的代碼編輯器Atom，以及微軟開源項目VS Code所用的底層基礎。其實咱們頗有幸和國際巨頭公司作出了一樣的架構選擇。如我前文所說，固然也不排除將來和VS Code合做、快速提升Creator開發體驗的各類可能。

引用我一個好友對Cocos Creator的評論：「有了這玩意兒我還管什麼Lua啊，遊戲公司要的就是下降開發成本，管它是什麼編程語言」。恩，此人是Lua死忠粉，而且出過cocos2d-lua教程書籍。

已有的cocos2d-html5, cocos2d-js項目能夠平滑升級到Cocos Creator嗎?

抱歉不能。畢竟繼承式和組件式是徹底不一樣的兩種設計思路，區別相似於蒸汽動力和電力時代同樣巨大。Cocos Creator裏面的框架API，和cocos2d-js API大概有80%是一致的，可是改動了其中的20%。若是您熟悉cocos2d-js api，那麼您只須要幾天的從新學習和適應，而後會發現開發速度愈來愈快。因此，沒法「無縫」移植，您須要一些移植工做量。

Cocos Creator開源嗎?

鑑於遊戲引擎領域已經有諸多競爭對手，恕我沒法將整個團隊一年多心血的Cocos Creator100%開源。可是我始終不忘cocos2d-x開源社區的初衷，因此在Cocos Creator裏面，得益於高度可擴展的架構設計，對於不涉及核心技術門檻的編輯器組件，咱們所有開源奉獻給行業。徹底開源的部分包括：

• 代碼編輯器

• Spine導入插件

• Tilemap插件

• 引擎框架部分，就是加入了entity-component結構的定製版cocos2d-x

以上部分100%開源，這個列表後續還會持續增長。今天發佈的是Cocos Creator v0.7，咱們計劃在春節後的2月份以內發佈v1.0，而後在v1.0以後新開發的插件，都講按照Cocos Creator標準插件擴展的開發方式進行，並開源。你們能夠參照這些開源的編輯器擴展的標準和範例，開發出本身的擴展插件出來用。

【來自精英團隊的有力支持】

如Cocos Creator設計師、項目負責人王楠在視頻中所說，Cocos Creator團隊其實是由兩批精英遊戲和工具開發者匯合而成，一方面保持了跨平臺原生開發領域的多年研發經驗積累，另外一方面又加入了熟悉遊戲開發各個流程和圖形界面工具開發技術的新鮮血液，算得上是目前國內遊戲工具研發領域的全明星團隊。Oh yeah，我最喜歡這樣B格滿滿的全明星團隊了。我長期的夢想就是匯聚國內的技術精英，打造出一款對世界產生影響的軟件產品來。Cocos2d-x已經實現了第一步，今天我但願用Cocos Creator更近一步。

同時，咱們幸運地得到了騰訊遊戲的承認與加持：

在Cocos Creator發佈之際，咱們和騰訊遊戲一塊兒，爲開發者們準備了一個小驚喜：《21點遊戲》所有源碼與資源，100%開源供你們學習。《21點遊戲》是Cocos Creator的示例項目之一，由騰訊遊戲和Cocos引擎團隊聯合開發。開發者們能夠藉此快速學習使用Cocos Creator開發遊戲界面和玩法等。

《21點遊戲》示例包括：

• 完整的菜單、排行榜和遊戲循環

• 大量須要經過數據動態讀取修改的圖片和字體資源

• 高質量的幀動畫特效

• 多分辨率自適應的 UI 佈局

• 外部導入的狀態機代碼庫

• 使用曲線動畫和腳本混合呈現的動效細節

《21點遊戲》示例體驗地址>>>>

《21點遊戲》示例源碼下載>>>>

特別感謝騰訊遊戲的受權與支持!

這款工具可以真正改善Cocos遊戲開發的工做流，全面提升遊戲的開發效率，進一步下降遊戲開發門檻，手遊市場還在飛速增加，競爭、挑戰、需求也愈來愈多樣化，Cocos團隊正在以更高效率爲目的爲愈來愈龐大的開發者大軍提供更直接有力的幫助和支持，讓更多的開發者能從容應對瞬息萬變的市場。

Cocos Creator下載地址：cocos.com/creator/

我是王哲，歡迎您試用Cocos Creator以後給咱們引擎團隊開噴或者點贊。我決定這幾天親自回覆這篇文章下面的全部留言，因此不論你對Cocos系列產品是愛是恨，是捧是噴，儘管留言，全部意見都是歡迎的!