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

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

以下是對他此次演講的內容記錄

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

使用 Go 做遊戲開發

由圖 1 我們可以看出 Go 在 Mobile 的發展時間軸，從 12 年初開始，實際上最開始它的關註度並不高，直到 14 年中旬其活躍程度才有顯著的增加。

圖 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 年啟動的，活躍度也比較可觀。

使用 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 所示的圖形，雖然看似簡單，但是支持卻比較難，當然，一旦有 SVG 的支持，這個只是SVG 的一條指令。

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

實踐結果

歷經半個月實際開發，同時也由於我在教我兒子學習編程時積澱的 2 年經驗，讓我沈澱了很多素材，現在我所寫的所有 Scratch 教程基本可以正常執行，下面就是我這 2 年所積澱的一些素材舉例：

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

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

3.小遊戲
吃蛋糕：eat-cake.sb2；這個是我兒子寫的，裏面的難點在於碰撞檢測，如圖 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 等框架。

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