本人很懶牧牢，文章排版有問題纸兔，請勿吐槽疮蹦。

正文：

webGL這個js API诸迟，可以呈現(xiàn)交互式的2D或3D圖形。

表現(xiàn)效果一流愕乎，支持的瀏覽器豐富亮蒋。

目前支持 WebGL 的瀏覽器有：Firefox4+,Google Chrome9+,Opera12+,Safari5.1+ 和Internet Explorer11+；然而, WebGL一些特性也需要用戶的硬件設備支持妆毕。

如此犀利的技術，加上剛?cè)胗螒蛐袠I(yè)這個坑贮尖，再加上公司用U3D做的東西慢如狗笛粘。因此我自己經(jīng)過一番調(diào)查，總結(jié)出一個游戲開發(fā)思路湿硝，望各位指正：

1：后端采用熟悉的技術薪前，本人擅長java（大約做了7-8年），servlet3.0后支持websocket关斜，加上web端的良好支持示括，各種頁游層出不窮，因此選擇java左右后臺開發(fā)的主流技術沒有任何問題痢畜《庀ィ基本框架是：

spring-websocket
spring-message
jdk1.8

核心就是這兩個支持websocket的spring官方模塊，對于websocket的支持非常好丁稀，從效率上講吼拥，易上手，花了一天時間做了個websocket的demo线衫。并且實現(xiàn)了發(fā)布/訂閱的機制凿可。從交互協(xié)議上講，個人感覺不存在多大問題授账。其中開啟了stomp協(xié)議之后枯跑，不僅實現(xiàn)了訂閱消息的機制惨驶，而且配合websocket的雙工能力，從協(xié)議上將已經(jīng)不會是技術瓶頸敛助。

spring官方出品的sock.js向下降級兼容各大瀏覽器粗卜，數(shù)據(jù)支持byteArray,json等輕量級數(shù)據(jù)，因為本身要實現(xiàn)的是棋牌產(chǎn)品辜腺，從交互數(shù)據(jù)的大小上講算很小的了休建。退一萬步講，如果真的存在數(shù)據(jù)包過大评疗，換成protobuf后也能縮小1/3到1/5测砂。這塊，不成問題百匆。

數(shù)據(jù)庫方面砌些，根據(jù)項目需要，暫定為mysql做數(shù)據(jù)持久化加匈，項目的特點是持久化的頻率不高存璃，結(jié)合redis在內(nèi)存中做業(yè)務數(shù)據(jù)的存儲和數(shù)據(jù)傳遞，結(jié)算后做數(shù)據(jù)持久化雕拼。理論上還是能滿足基本需要纵东。

用戶認證：

說到用戶認證，其實有很多種做法啥寇，首先從游戲場景講：玩家進入游戲肯定是經(jīng)過認證的用戶偎球。不支持陌生用戶玩這個游戲，通常會走注冊->登錄流程辑甜。如果采用社交化登錄的話衰絮。通過掃碼登錄（微信或者qq等）然后實現(xiàn)用戶認證是比較常見的。登錄后磷醋，后端給前端一個會話token猫牡，后面的數(shù)據(jù)交互，都會帶上這個token（包括websocket協(xié)議中的數(shù)據(jù)交互）邓线。redis根據(jù)token去做用戶信息的key淌友，value就是用戶信息，從socketsession中獲取到的id褂痰，作為第二個用戶信息的key亩进，value就是token。這樣當用戶掉線缩歪，重新登錄時归薛，可以更新用戶的服務器狀態(tài)。

反向代理

為什么需要反向代理：游戲除了websocket協(xié)議，還會涉及到一些外圍的模塊主籍，還會牽扯到網(wǎng)頁的獲取习贫，活動的更新等，內(nèi)容承載肯定通過jetty或者tomcat等web容器來進行返回內(nèi)容千元。包括一些rest的api苫昌，json的數(shù)據(jù)交互等。所以上nginx還是有必要的幸海。首先是它解決了http的反向代理祟身，將用戶的請求反向代理給web容器。另外一個直接利用nginx做負債均衡物独⊥嗔颍可以很方便快捷的解決除了websocket以外的其他數(shù)據(jù)交互。其次nginx本身也支持tcp的upstream挡篓，所以也可以做到websocket的反向代理婉陷，服務如果多機部署，數(shù)據(jù)見做共享官研，那么業(yè)務數(shù)據(jù)的壓力的就可以直接通過nginx來做分發(fā)秽澳。從而減輕單擊壓力。

高可用戏羽，本來考慮上HA担神，但覺得沒必要始花，成本上去了杏瞻，一切都是卵的。本身和程序設計沒有多大必然聯(lián)系衙荐。以后再說浮创。

服務器其他要干的事情忧吟，就剩下定義主題和接口，以及數(shù)據(jù)模型了斩披。服務器的細節(jié)問題（并發(fā)溜族、會話共享等），以后再討論垦沉。

2：前端選型

先說產(chǎn)品的目標運行環(huán)境：

PC端：覆蓋一些上了年紀的用戶煌抒，下載安裝，就像qq一樣方便厕倍。
移動端：其實不想做移動端的寡壮。
H5：主要針對支持webGL的主流瀏覽器，其實大部分都支持，除了該死的IE（IE10說：什么仇况既，什么怨）这溅。

從優(yōu)先級來講，是PC > H5 > APP

從前端的技術選型來講棒仍，必須覆蓋所有悲靴。

調(diào)查并且跑了一些demo之后，發(fā)現(xiàn)whs.js和three.js是不錯的選擇莫其。whs.js也是three.js的上層封裝癞尚。結(jié)合node.js完全能夠做到前端的技術盲點覆蓋。

選型如下：

whs.js/three.js選其一乱陡，我選whs.js
socket.io-client/reconnecting-websocket選其一浇揩。后者支持掉線重連的封裝。
stompjs 結(jié)合node.js的net模塊蛋褥，實現(xiàn)overWS的websocket參數(shù)封裝临燃，一步完成消息訂閱。
zepto.js 不說了烙心，主要是輕量級膜廊，主要針對外圍交互json數(shù)據(jù)多。
tween.js 動畫庫淫茵，備用爪瓜。
es6-promise 這個不贅述咯，語法寫起來就像JDK1.8一樣匙瘪，各種lambda寫起來感覺爽铆铆。

項目架構方面：采用webpack來做構建，結(jié)合一些插件可以做很多事情丹喻。

桌面應用程序打包層面薄货，采用electron來做打包，因此項目會集成進去碍论，打包后會生成linux谅猾、macOS和windows的運行程序，（跨平臺鳍悠？）税娜，不過我只需要win32的就夠了，誰TM跑linux上去玩藏研。

項目編譯后敬矩，會生成一個bundle.js的全局壓縮js，全部打包到應用程序中蠢挡，用戶打開程序后弧岳，不會像H5打開程序一樣慢悠悠的凳忙，其速度取決于用戶的電腦性能和加載js運營環(huán)境（引擎等東西）的效率∷跎福總的來講消略，速度非常的快。游戲體驗瞎抛，絕對可以媲美原生（不要小看webGL的能力）艺演。

electron打包后其實項目可以運行了，只不過就是個白板項目桐臊，出來也有100來M胎撤，嚇人，用nsis壓縮打包成exe可執(zhí)行文件断凶，壓縮后伤提，幾十M，放到網(wǎng)上供用戶下載认烁。桌面應用程序的打包過程就了結(jié)了肿男。

H5發(fā)布：直接制作一個分支，拋開electron却嗡，剩下的無異舶沛，本身程序就是基于web開發(fā)的，但是體驗上肯定不如打包后的桌面應用程序和app窗价，資源等所有東西都要從服務器下載如庭。

APP打包層面：沒具體深入了解，不過程序在制作上肯定會針對app但是做一套頁面的適配撼港，因為游戲畢竟不像web的響應式設計那樣可以適配到所有設備坪它。但是前端的交互邏輯以及js業(yè)務層面的封裝是可以復用的，所以帝牡，產(chǎn)生的額外工作就只剩下UI適配往毡。

APP打包工具選擇：

1. 最好的選擇是，安卓和IOS都需要各自的程序員來完成靶溜，畢竟app的體驗與其他的不同卖擅，拿登錄來講，如果要用微信登錄墨技，那至少要喚起微信的客戶端來做授權回調(diào)，所以還是需要原生能力挎狸。

2.退而求其次扣汪，現(xiàn)在Hbuilder的云端打包可以支持，類似的其他平臺如api cloud好像也支持锨匆。就目前調(diào)查的結(jié)果來看崭别，還是Hbuilder配合第三方可能會比較容易一些冬筒。暫定！

PS：你要是吊得一比茅主，你就用react-native搞拔杼怠！

app打包最麻煩的在于發(fā)布后需要先去申請一些相關平臺的key和密鑰诀姚。這樣第三方登錄才可以使用响牛。所以，這玩意兒優(yōu)先級肯定是放到最后的赫段。

不過我會優(yōu)先做一個demo出來呀打，驗證以上思路的可行性。

下一章講項目的構建糯笙。

感謝您的閱讀贬丛。