雲計算後，Go 的下一個戰場：遊戲產業

Go 自誕生以來，因其簡單高效的處理效率和對於併發的出色支持，獲得開發人員的關注和實踐。並在 2013 年隨着重磅項目 Docker 的誕生和發展，逐步在雲計算領域造成燎原之勢。在佔領了雲計算後，Go 的下一個發力點將會在何方？

在 ECUG Con 十週年盛會上，七牛雲 CEO、Go 首席佈道師許式偉給出了他心中的答案：遊戲行業。

如下是對他這次演講的內容記錄

做爲一個技術型 CEO，我認爲技術人員都是很純粹的，以數據爲導向，理性判斷趨勢，因此今天我會站在理性角度分析，來聊聊將來 Go 的趨勢，重點是在遊戲行業。

使用 Go 作遊戲開發

圖1

由圖 1 咱們能夠看出 Go 在 Mobile 的發展時間軸，從 12 年初開始，實際上最開始它的關注度並不高，直到 14 年中旬其活躍程度纔有顯著的增長。



圖 2

圖 2 則顯示，儘管 Go 官方對 Mobile 的支持力度大於 Web，可是 gopher 們對 Web 前端的支持度遠遠高出 Mobile。Gopherjs 在社區的活躍度從 13 年 8 月開始一直很高，從圖中咱們能夠看出，Gopher 們也有着和 JavaScript 程序員們共同的夢想，使用一種語言統一先後端。

經過上面兩張圖的對比，得出一個很重要的結論，就是 Go 在桌面側的發展，即便用 Go 語言來寫桌面程序，固然目前也有不少人在嘗試，包含兩個流派：通用 UI 和垂直行業（遊戲行業）。Go 團隊官方給出的回答更加側重後者，關注垂直行業——遊戲產業。

爲何會是遊戲行業呢？能夠從如下兩點來看一下可行性：

1. 市場緣由 遊戲市場空間巨大；
2. 技術緣由 遊戲行業相對其餘行業，桌面 OS 的標準控件常常被棄用，因此需求相對收斂，更加容易知足。

接下來探討一下使用 Go 寫遊戲的可行性，對於 GUI 來講，基礎支撐是 OpenGL，它自己支持 PC（Windows/Mac/Linux/FreeBSD），Mobile (Android/iOS)以及Web (基於WebGL)。對於遊戲來講，分如下幾點：PC 端遊戲（PC）、頁遊（Web）、手遊（Mobile），這三項使用 Go也是能夠進行開發的：PC端能夠經過 OpenGL，手遊經過Go Mobile，頁遊經過GopherJS（將Go 的代碼編譯成 JavaScript）Go 頁遊是很是成熟的，使用的技術棧也是相對較少的，只須要使用 WebGL 和 GopherJS，還能夠調用JavaScript框架，諸如 

WebGL (https://github.com/gopherjs/webgl)、 jQuery (https://github.com/gopherjs/jquery)、 Websocket (https://github.com/gopherjs/websocket)

整體來講，Go 對 Web 的支持算得上是很是成熟的，它的應用面也不侷限於頁遊，如圖 3 所示是一個仿 React 的一個項目「vecty」，是使用 Go 進行開發的，由圖咱們能夠看出這個項目是在 15 年啓動的，活躍度也比較可觀。



圖 3

使用 Go 作跨平臺遊戲

使用 Go 去作全平臺遊戲支持相對於 Web 而言，所能用到東西相對會收斂不少，相似 Javascript 的不少庫就不能再用。

此時我選擇的技術方案爲：使用 Go 作跨平臺的 Scratch。

首先講一下什麼是 Scratch，它是一門面向兒童編程教學的語言，能夠教兒童編寫遊戲，目前其排名已經擠進工程類語言排名的前 20。爲何要使用 Go 來重寫 Scratch 呢? 一是出於我對其的熱愛，其次是 Scratch 目前仍舊存在一些瑕疵，我但願能夠去慢慢完善。

2.X 版本（https://github.com/LLK/scratch-flash）只能基於 Flash 編寫而且只能跑在 PC 上，而基於 Google Blockly + React 編寫的 3.0 版本（https://github.com/LLK/scratch-gui）雖然已經可用，可是兼容方面仍然存在問題，好比與 2.X 不少地方不兼容，可是2.X的用戶羣體是很龐大的。所以 Scratch 還存在不少進步空間，是很是值得期待的。

目標與挑戰

正是因爲 Scratch 的不足，讓我看到了挑戰。我爲本身定了一個目標，作一個兼容 Scratch 2.X 的跨 PC、移動、Web 多終端平臺的 Scratch 腳本執行器。下面是我所面臨的多種挑戰：

1.腳本支持—Json 腳本

Scratch2.X 是 Json 腳本，從 parser 角度來看難度不大，可是從 executor 角度來看其難度與使用其餘的腳本的難度是一致的。其次，其腳本是單線程僞並行的，因爲不一樣的 Scratch 腳本之間可能會共享變量而且 Scratch 並無 mutex 語法，因此真的並行會致使系統邏輯錯亂。在Go 當中模擬一個單線程僞並行的程序相對而言仍是比較複雜的，因此這是我面臨的第一個挑戰。

2.多行文本排版與顯示

True Type 字體的支持，小型排版系統須要考慮行禁（例如：標點不能在行首，英文單詞不能分拆到兩行顯示）

3.音頻播放

須要支持常見音頻格式，而且要支持混音（能夠同時播放多個聲音，應當要有多我的同時說話的效果）

4.SVG 格式支持

Scratch 2.X 內建的精靈 (sprite) 都是矢量格式的，而且基於 SVG 格式，SVG 有着很是複雜的指令集，完整支持等價於寫一套 GDI Canvas（當前Go 社區並沒有成熟的 SVG 渲染的項目）

5.複雜圖形



圖 4

圖 4 所示的圖形，雖然看似簡單，可是支持卻比較難，固然，一旦有 SVG 的支持，這個只是SVG 的一條指令。

6.碰撞檢測

這基本上是遊戲類程序最基礎的需求：兩個精靈(sprite)的碰撞檢測

實踐結果

歷經半個月實際開發，同時也因爲我在教我兒子學習編程時積澱的 2 年經驗，讓我沉澱了不少素材，如今我所寫的全部 Scratch 教程基本能夠正常執行，下面就是我這 2 年所積澱的一些素材舉例：

1.社交類 

對話：weather-conversation.sb2；包含音頻播放，多行文本排版與顯示，也有不少複雜的圖形、背後腳本等。圖 5 所示就是。



圖 5

2.棋牌類

 五子棋：five-chess.sb2；圍棋：go-chess.sb2；國際象棋：chess.sb2，這些看起來簡單，但要作到完整要包含協程(共享全局變量的處理)、複雜腳本等比較複雜的東西。圖 6 所示是圍棋的示意圖。

圖 6

3.小遊戲

吃蛋糕：eat-cake.sb2；這個是我兒子寫的，裏面的難點在於碰撞檢測，如圖 7



圖 7                                                                                

跨平臺之爭：React Vs.Go

Scratch3.0 是使用 React 作的，而我是使用 Go 去作來進行一個全新挑戰。Scratch3.0 作了不少東西，花了一年多的時間，功能相對比較完善，可是對於我我的而言我僅僅作了一個執行器，難度不一樣，因此最後我會對二者作一個對比，比較一下他們之間的優缺點。

1.React+React Native

優點：場景比較通用，能夠基於 WebGL 也能夠開發遊戲； 劣勢：傾向於將 Web 搬到 Native（mobile）技術棧複雜，性能相對低；React 框架對開發遊戲的難度基本沒有減負。

2.Go+GopherJS

優點：技術棧極簡，上手容易，性能極好； 劣勢：較爲小衆； 場景：比較垂直，對遊戲有較完整的支持。

總結

Go 的桌面側戰場剛剛開始，但技術相對而言已經比較成熟，儘管很早期，可是因爲 Go 所帶來的研發效率的提高，必定程度上消除了因爲早期而致使的資源不足，所以，即使前端知識不足，可是通過多年發展，Go 社區的豐富資源偏偏彌補了這個不足。

建議能夠適當關注，選擇合適的時機進軍「戰場」。進軍方向能夠選擇：其一是使用 Go 寫遊戲，它能夠作到全平臺支持；其二是使用 Go 寫 Web 應用來代替 React 等框架。