參與小游戲首發計劃，也正試著做一些別的小游戲，不總結點什么好像不大好，但一總結又發現好多內容，只好通過“2W1H”的方式來拋磚引玉一下（以下為科普內容）：

（高清版請識別圖片中小程序碼）

W.小游戲是什么？

這是花叔參與開發的第一款小游戲，也是首發17款小游戲中的一個。

那具體小游戲是啥呢？花叔具體能從以下角度來分析一下：

1.賬號體系

從賬號體系講，小游戲就是游戲小程序，隸屬于小程序的體系范疇。

2.技術體系

原則上不管h5還是小程序還是小游戲，都是“客戶端-服務端”的技術交互模型，只不過小程序的技術框架是微信自研的，而網頁（包括H5）是基于行業的通用的網頁技術標準。通用技術標準兼顧全行業，各種技術點都囊括進來，可能本身就比較臃腫，運行起來有所拖沓是可以理解的，而自研有個好處，用想用的技術，不相干的技術抹掉，整個形態就更輕便了，體驗快也可以隨之而來，不過也會存在一些跨平臺的限制。

總而言之，小游戲就是小程序體系下的子集，但只保留了必要的游戲特性以及微信私有功能接口。

3.差異

區別太多了，這里只說說非技術同學能理解的區別，其中紅色部分是最大的差一點，也是最特別的功能點，關系鏈數據有多大作用就不分析了，虛擬支付的話，它是一個明顯能讓小游戲變現的功能。

ps.開發成本是相對目前網頁開發的團隊的。

W.需要哪些人參與開發？

基于原有開發H5的團隊模型來總結小游戲開發所需要的人力，那么可能是這樣：

（這也是開發互聯網網頁應用的團隊能力模型）

至于專業游戲團隊需要怎樣的人力，花叔也不清楚，不是行內人不知行內事，但其實常規網頁開發團隊也是可以做小游戲。

H.怎么做？開發流程是？

說太多不如畫個圖，大致總結了一下：

補充解釋一下：

1.需求策劃

• 創意碰撞+平臺側確認，別想太復雜就是想做什么就拉會討論，然后寫寫能表達想法的文檔或ppt，不用太復雜，說清楚問題就好，但不要省去微信平臺策略或規范的校驗，然后確認好初步交互稿由誰來出。

• 技術評審，確定好方向后，要把所有開發哥拉一塊討論一下技術實現難度

• 項目排期，確定好項目推動的負責人，讓他排期，這很重要，特別對小游戲這種溝通成本很高的項目，PM很重要

• 賬號申請，賬號申請需要跑流程，搞資質，提前跑起來吧。

2.交互調整

• 拉起會議，據花叔經驗，接觸的項目基本上沒有哪個的交互是一步到位的，記得有必要時拉起交互確認的會議。

• 輸出完整交互稿，要完整的交互稿，手繪、ppt、圖片都行，別求模板了，能說表達清楚各元素表達的意義以及互跳邏輯就好。

3.視覺設計

• 可以外包，要外包分攤工作量的話，相對來說視覺這塊容易分出去一點。

• 要預想好有哪些素材，游戲和平面設計還是不大一樣，游戲需要準備很多素材，音頻視頻序列幀動畫都可能需要用到。

4.代碼研發

• 接口規范指定，需要需求方或者pm拉上前端開發、后端開發一起開會，之后協商接口規范，可以由前端給接口需求，后端按前端的需求做接口；但反過來也行，后端直接給接口規范，前端用，發現不夠用，就聯調修改。

• 前端開發，小游戲是重前端的，前端同學首先要理清所有技術點的前后端交互邏輯，例如鑒權是怎樣的？openid是怎么轉換的？敏感數據是怎么獲取的？關系鏈數據是怎么獲取的？等等，這里細節有點多。

• 后端開發游戲拍賣平臺，首先鑒權要第一時間做，因為所有其他接口是基于這個的，其次要了解微信的一些token管理機制，該不該刷緩存什么的都得搞清楚；其他的就按常規網頁后臺開發就好。另外，如果是實時對戰要用到socket，服務器資源也是更高要求，要另外做資源以及實現難度評估。ps.后端開發一般好難外包，如果用上了后續會有各種問題，例如數據風險如何評估、服務器資源如何確定等問題。

5.聯調+測試

• 常規功能測試

• 容災測試

• 服務器性能測試

• 弱網測試，這塊對于常規網頁開發的團隊來說很沒經驗，前端開發同學在開發過程中要特別注意

6.提審+發布

• 這沒啥好多的，就是內容填寫。

好了，以上說了好多，也沒有從很細的點來說，有疑問是必然的，想深究可直接找花叔~~~

總結

以上是生活随笔為你收集整理的头号小游戏玩家科普指南的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。