自 2018 年初，首批微信小程序遊戲上線，從憑藉微信帶來的巨大流量和變現能力，小遊戲生態極速地建立了起來。截至到目前，微信小遊戲月活用戶已超 4 億，開發者高達數十萬。在現如今的遊戲市場寒冬中，擁有微信龐大的用戶量以及更好兼容性的小程序遊戲，優勢就顯得格外明顯。無疑，這將會是一個巨大的風口。
那麼，如何從 0 到 1 去實現一款微信小遊戲？微信小遊戲背後的技術本質是什麼？提供哪些能力和玩法？使用小程序·雲開發將獲得哪些獨家優勢？帶着對這些問題的解答，來自騰訊雲·雲開發團隊與微信團隊的四位講師開始了這場技術佈道。
如何入手開發一款小遊戲？
衆所周知，微信第三方開發分爲兩類，一類是基於行業通用網頁技術框架開發的微信H5與公衆號文章，另一類則是基於微信技術框架開發，包含着微信私有技術特性的普通小程序與小遊戲。
在H5、普通小程序與小遊戲之間的區別中，目前小遊戲是唯一一個真正支持關係鏈數據使用方案的。爲此，騰訊高級工程師周桂華（花叔）講解道，一個微信用戶的關係鏈數據包括兩部分，一部分爲用戶好友的用戶數據，另一部分爲該用戶所在的某個羣的羣成員用戶數據。之前爲了保護用戶關係鏈數據，微信基於技術框架會在前端做一個封閉式的子域，而主域會把信息丟給開放數據，這個開放數據也就是子域。每當子域需要暴露關係鏈的數據，如繪製排行榜等業務場景，需要將排行榜繪製到封閉式的 sharedCanvas 上，再在主域將 sharedCanvas 渲染上屏。
然而，子域不可能發出第三方請求，每個開發者的數據庫都是微信定義在託管服務器裏，你的業務數據只能跟主域做交互。但在最新一套的開放能力中，微信提供JSServer服務器與互動型託管數據。其中，互動型託管數據是把好友之間的交互數據單獨存一份的數據，而JSServer的作用則是校驗用戶數據，順便把數據存到普通的託管數據裏。
在演講中，擁有重構工程師和設計師“雙重身份”的花叔，提起自己第一次開發小遊戲，深有感觸地說道：“如果第一次做遊戲的話，你會有一種感覺，像是你在創造一個世界。其實我對第一個遊戲最大的感觸是非常開心。”
2017年，小程序誕生，爲了學習如何開發小程序，花叔嘗試做了一款關於思維導圖的小程序工具。當小遊戲出現後，花叔默默定下了獨立開發一款小遊戲的目標。在開發的過程中，花叔漸漸發現，CreateJS做遊戲有點弱，那是偏程序編碼的開發方式，雖然在做數據調用和程序邏輯方面比較靈活，但是做遊戲UI效果，CreateJS會顯得無力，因爲要一行行代碼寫，效率不高。而實際遊戲開發中，UI效果的製作工作量又不少，所以CreateJS在遊戲開發上面還是略遜一籌，可以說它只是個代碼庫，要真正做遊戲還是需要一整套開發套件才行。
那麼，偏程序開發的形式來開發遊戲太累，怎麼辦？此後花叔慢慢轉戰Coccos Creator。起初，作爲代碼流的花叔一開始挺不習慣Coccos Creator的開發流程，其開發理念是以工作流爲核心，讓不同職能的開發者能夠快速找到最大化自己作用的工作切入點，並能夠默契流暢的和團隊其他成員配合。
簡單來說，Coccos Creator就是把遊戲中可能用到的各類功能或者元素封裝成一個個組件，這些組件帶有自己的回調方法，組件在可視化開發工具裏就能通過拖拽和拼裝形成遊戲。Coccos Creator還有有一個比較好的點是：它約定了程序員可以定義一些屬性，這些屬性能暴露給其他同學去修改。這樣就可以很好地解決前端訴求，開發質量和開發效率的問題。
但是接下來又有另外一個問題，傳統服務器後端方案太龐雜，一個半前端的開發工程師，怎麼獨立並快速開發遊戲？以花叔開發的《影子的遊戲》爲例，這個遊戲也是基於Coccos Creator，後端方案跟上述所說的不太一樣，是基於雲的。而這時的技術框架很簡單，上面是小程序雲，下面是小遊戲端，而小程序·雲開發只需要一個前端開發就搞定。
而小程序·雲開發解決的問題，就是前端開發和後端開發中間的並行過程。小程序·雲開發提供了三板斧和兩封裝，三板斧指的是小程序·雲開發提供了數據庫、存儲、雲函數的能力，兩封裝則指鑑權與雲調用。其中，某些方法在調用的時候，開發者需要做服務端API AccessToken機制，抑或是小程序的登陸鑑權，但這些都不用管，小程序·雲開發把這些東西都封裝好了，開發者直接用就行了。
小程序·雲開發技術加持
自 2018 年初，首批微信小程序遊戲上線，到現在不到兩年的時間內，微信小遊戲的生態，已有數十萬的開發者，月活高達4億。其中，58%以上是30歲以上的用戶，31%是40歲以上的用戶，而之後父母輩將會成爲小遊戲的主力。
小遊戲生態的繁榮來自於過硬的基礎能力，從發佈初期的原生Canvas，到現在完成主流引擎的適配，小遊戲開發門檻在一步步下降，此外還有硬件接口暴露，分包加載等基礎能力，都在不斷擴展遊戲開發的邊界。基於微信的關係鏈，以及數據運營能力上的完善和基礎架構層面雲開發提供的便捷服務，整個生態都進入了良性的循環，開發者可以通過這些東西完善自己的小遊戲，並且從遊戲中獲得推廣和收益。
那麼，爲什麼要有云開發？衆所周知，傳統開發模式對於業務開發存在一些痛點難以解決。騰訊云云開發團隊前端工程師楊航講解道，一款生產級別應用的開發，除了業務邏輯以外， 有太多的東西需要處理。爲了保證服務的穩定， 需要龐大的周邊設施，包括負載、高可用、安全、監控等。在傳統模式下，從物理機託管，再到使用雲上的服務雲主機，最後到PaaS級別的服務，隨着服務封裝層級越來越高，暴露出開發者需要關心的細節就越少，也就釋放出更多的人力與投入成本， 但最終仍需要專業的運維人員來介入維護，不但耗費資源，人力的引入也帶來錯誤引入的風險。
除此之外，開發層面上前後端分離雖然是一種優秀的架構，但實際開發過程中前後端分離所帶來的權責不清晰，溝通時間增多，代碼調試等挑戰都使得整個開發進度趨於緩慢。
那麼，是否有一種新的開發模式，可以讓開發者可以更多地專注業務邏輯。從小程序的技術來看，小程序技術棧主要限制在了JS，與前端開發相匹配，使用Node可以在一定程度上分擔後端的業務，降低溝通成本，前後分離得更徹底，解決業務邏輯開發部分的問題。但絕大多數業務開發對於各種複雜周邊設施搭建、網絡、主機運維相關的知識也是很有限的，想要搞好，就得投入大量的時間精力來建設。
基於這樣的想法，騰訊雲總結了整個開發流程中普適性廣的基礎能力，進行更上層的封裝，運維部分被完全隱藏掉，暴露函數式調用的接口來直接操作服務，業務開發者完全不感知環境與運維。同時提供代碼運行容器解決複雜業務邏輯處理的問題，甚至是讓前端程序員可以獨自包攬整個項目，推出這種無服務的 Serverless 開發模式。
無服務是未來開發的發展趨勢，從物理機到雲上的IaaS層、主機、PaaS層的開放架構，一步一步釋放了開發者運維相關的東西，讓開發者更專注於自己業務能力的開發。而云開發正是Serverless應用服務中臺。
雲函數是Serverless的核心，也是雲開發功能中很重要的一點。在雲函數中，開發者不需要自己寫邏輯來獲取到小程序的appid、openid，雲開發通過私有協議把其置入雲函數的運行上下文，在雲函數裏可獲取，同時在雲函數前端進行了鑑權處理，所有到達雲函數的請求都是合法登錄態的請求，函數中完全不需要鑑權操作了。
其中，雲調用就是雲函數中很好用的一個功能，如果開發者經常進行小程序開發，需在服務器運行的API，通過access_token來做權限標誌。但云調用就屏蔽了這件事情，開發者在雲函數中直接調用Cloud Open API，整個調用鏈就可以直接順暢下來了。
實時推送能力落地與實踐
隨着小程序·雲開發的普及，開發者希望雲開發能提供通過後臺直接往前臺推送消息的功能。由於此前沒有這個功能，導致開發者需自己去搭 WebSocket 服務，而在搭建的過程中無法保證良好的可靠性和併發性。如果要提供良好的性能，需要的開發成本會很高。
那麼，如何在現有云開發能力下進行即時通信能力的開發呢？微信小程序研發工程師鄧坤力提出了兩個關鍵詞 —— 長連與推送。長連是所有技術通信服務，或者需要依賴於實時性的所有服務的基礎。而推送能力，是需要有一個主動同步客戶端的能力。此外，存儲、消息與文件的持久化也很重要，一是結構化文本的數據，這些文本的數據通常適用數據庫存儲，對於一些較大的數據，比如圖片、音頻、視頻，這些在聊天中會出現的內容，需要用雲存儲來承載。
那麼，從上述三個即時通信服務的要點來講，目前用雲開發能完成這一整套即時通信的服務嗎？一、對於長連來說，雲開發並不滿足，因爲雲開發是Serverless短連的服務；二、沒有主動同步客戶端的能力。因此，在這種情況下，大部分的開發者也只能通過短輪詢的方式作爲長連、推送的替代方案。而短輪詢則是每隔一段時間去請求一下數據庫，看一下數據庫是否有更新，如果有更新，再去更新客戶端的意外狀態。但短輪詢會帶來一系列包括資源浪費，維護、開發成本高等問題，甚至在安全性方面，很多開發者還會爲了貪圖方便會把不宜落在客戶端的信息傳到客戶端使用，比如 access_token 和 session_key。
爲此，雲開發數據庫新增了實時推送更新的能力，實現在小程序端、小遊戲端就可以直接對數據發起監聽的能力。開發者可以給定查詢語句進行監聽，每當查詢語句的結果發生變化時，小程序端就會收到包含更新內容的推送，並對實時數據變化做出響應。
實時數據推送的場景有很多，包括即時通信、狀態同步、實時協作等，在演講中鄧坤力舉例說道，對於小遊戲開發來講，狀態同步很常見，遊戲通常分爲狀態同步和幀同步。狀態同步的遊戲，像棋類、牌類，由服務端存儲完成狀態，像五子棋、象棋等遊戲都屬於狀態同步的類型。再比如，實時協作的場景，在線共享文檔、騰訊文檔、谷歌文檔，以及項目管理的協作工具等，這都是可以通過實時數據推送能完成的事情。
從整體架構上，實時數據推送能力分成了三個模塊：小程序的前端 SDK、中間接入層和後臺。他們分別承擔的業務爲：
-
小程序的前端 SDK：這個業務需要在前端做些邏輯去保證服務的可靠性。然後在提供一個簡單易用的接口給前端同學用。
-
中間接入層：其任務是與前端保持 WebSocket 長連接，接入層會去後臺輪詢，取到最新的消息事件後就發送給前端。
-
後臺：就是一個比較傳統的服務，在這一層監聽到最新消息就返回。
爲了保證數據的可靠性和完整性，在做模塊設計時，小程序·雲開發採用互不信任的原則，即上述三個模塊之間是互不信任的。爲此做了很多的冗餘設計，如果系統中的某一模塊沒有調用成功，小程序·雲開發會採取一些措施來彌補這個缺失。比如說小程序的 SDK，它會定期的去接入層查詢最新消息事件的版本號，如果查到與本地的版本號對不上，它就會重新拉取一下這個消息事件。這樣即使出現數據丟失或者網絡連接斷掉的異常情況時，依然能保證數據的可靠性。
爲了保證低延時，除了在接入層提供 WebSocket 接口以外，後臺所有的業務都使用了基於 TARS 框架的 RPC 通信，TARS 是一個成熟的開源框架，其性能很好。
爲了處理高併發，小程序·雲開發也在持續優化接入層，讓其儘可能的維持更多的實時連接。
此外，鄧坤力在演講的最後也介紹了雲開發近期推出的其他能力，包括已有的HTTP API，能打通雲開發的資源，在其他端也能直接使用；數據庫聚合，普通數據庫的能力無法滿足的話，開發者可以通過聚合做分組查詢、統計查詢；數據庫的高級查詢，這也是控制檯的新能力，以前控制檯只可以完成簡單的數據庫操作，加上這個能力之後，開發者可以在控制檯中用數據庫的語法進行批量的數據增刪查改。
多人聯機對戰玩法的實現
所謂聯機遊戲，是指玩家與互聯網上其他玩家一起玩的遊戲。聯機遊戲的類型有很多，比如《歡樂麻將》《歡樂鬥地主》等回合制多人遊戲，《貪吃蛇大作戰》、《極速大亂鬥》、《亂鬥英雄》等實時多人遊戲，還有火爆一時的社交小遊戲《海盜來了》。
小遊戲生長於微信、QQ等社交平臺，天然適合拉好友一起玩聯機遊戲，比如情侶、朋友、團隊等玩法。但目前的小遊戲大多是單機遊戲，原因之一是聯機遊戲背後的業務和技術邏輯很複雜，開發者要考慮的問題很多。這些聯機遊戲有什麼特徵呢？或者有什麼技術難點呢？騰訊雲高級產品經理張小華分析出以下三點：
-
第一，先把玩家組織起來，因爲它是聯機遊戲，你要在互聯網上找到一個跟你一起玩的人，相當於是要有某一種組織把互聯網上的人組織在一起，我們把這個組織就稱爲“房間”。做房間管理比較簡單，但做在線匹配，會發現當有很多人發起匹配請求的時候，一臺服務器根本撐不住，而想要多大容量的服務器才能做到全區全服，這是一個技術難點。
-
第二，玩家和玩家之間要進行網絡通信，這就涉及到很多問題，網絡通信是TCP協議，還是UDP協議？開發者花了半年去開發一款聯機遊戲，結果發現還很卡，聯機遊戲網絡波動、抖動的時候如何讓遊戲呈現出平滑的效果，這裏面的技術很有難度。
-
第三，部署和運維。對戰類的遊戲，尤其是房間類的遊戲，它是有狀態的。比如，4個人加入到這個房間，這4個人會同時到一臺服務器上戰鬥，不能分佈在多臺服務器戰鬥，如果分佈在多臺服務器戰鬥，可能會連接數據庫，降低效率。尤其是當很多人頻繁操作數據庫的時候，數據庫的性能可能會出現異常。
對戰類遊戲並不是很好做，是很困難的，而小遊戲聯機對戰引擎(MGOBE)就將聯機遊戲背後的技術和運維難點一一解決，開發者只需要調用幾個JS接口，5分鐘即可實現房間管理、在線匹配、聯網對戰等功能，無需複雜的後臺代碼。
很多開發者有疑問，房間管理也好，在線匹配也好，都是調用的API。如果我有自己的邏輯，要寫一些特殊的邏輯，怎麼辦？小遊戲聯機對戰引擎有一個房間的擴展，開發者每調用房間裏的API，引擎都會觸發自定義邏輯的腳本，開發者可以在這個腳本里面寫自己的代碼。這樣的話，一個技術棧就可以完成前後端的能力。甚至包括掉線場景，開發者都可以到自定義服務邏輯中去寫，比如，玩家掉線了，你讓他對局失敗，還是把他剔除房間，這都可以在房間擴展裏面去寫自己的一些特殊邏輯。
剛纔講的是怎麼把玩家組織起來，玩家和玩家之間怎麼進行網絡通信。這裏有三種模式：
一、客戶端直接發消息到另外一個客戶端，按需發；
二、幀同步
其中，張小華以《王者榮耀》爲例，講解幀同步的原理。在遊戲中，客戶端會把玩家的動作指令發佈給後端，但是後端不會立刻轉給其他的客戶端，而是按照一定的頻率，把所有客戶端轉給它的消息再同步給各個客戶端，每一個客戶端就都有其他客戶端的邏輯。所以這時候開發起來就會像單機遊戲一樣，服務端會有一定的渲染，如果用戶實時的同步，客戶端就會不停的在渲染。像這種定時的客戶端，客戶端渲染的頻率也是固定的，不會很亂，這樣的話，就能實現它較高的開發效率。
儘管如此，幀同步還是有一些缺點，網絡要求高，防外掛能力比較弱，並且斷線重回的時間很長。由於它的幀同步是渲染，如果渲染斷線了，會從第一幀渲到當前。如果之前遊戲玩了5分鐘，重新渲染也可能要5分鐘，當然mgobe已經解決這個問題了。另外，因爲客戶端的服務器，不管是手機也好，電腦也好，裏面有浮點數，各個電腦產生的浮點數都是不一樣的，這時候按照浮點數渲染出來的結果會導致各個客戶端不一樣。
三、狀態同步
幀同步用的遊戲不算多，主要是小戰場實時的遊戲，大部分遊戲用的是狀態同步，狀態同步的防外掛能力很強，它能勝任大事件、大戰場，像吃雞類遊戲。而狀態同步，斷線重回的時間也很短，因爲每一次都保存的是一個狀態，網絡環境相對輕鬆，但開發效率相對慢一些，因爲在服務端寫一遍，可能跟客戶端差不多的邏輯。mgobe支持狀態同步，開發者只需要寫邏輯，無需關注部署的事情。
結語
據第三方機構報告顯示，2019年小遊戲的市場規模或達250億元，其生態也不斷成熟。而小程序·雲開發將持續豐富 SDK 能力，釋放騰訊的技術價值，逐漸支持多種開發語言，讓開發更便捷。未來，新的技術層出不窮，但是要知道技術始終是爲人服務的。不解決人的問題，技術無法成長壯大。將開發者的精力解放出來，讓他們投入到業務邏輯等更具價值的工作中，從根本上賦能技術發展，纔是推動行業”車輪“不斷向前駛進的源動力。