本人很懒，文章排版有问题，请勿吐槽。
正文：
webGL这个js API，可以呈现交互式的2D或3D图形。
表现效果一流，支持的浏览器丰富。
目前支持 WebGL 的浏览器有：Firefox4+,Google Chrome9+,Opera12+,Safari5.1+ 和Internet Explorer11+；然而, WebGL一些特性也需要用户的硬件设备支持。
如此犀利的技术，加上刚入游戏行业这个坑，再加上公司用U3D做的东西慢如狗。因此我自己经过一番调查，总结出一个游戏开发思路，望各位指正：
1：后端采用熟悉的技术，本人擅长java（大约做了7-8年），servlet3.0后支持websocket，加上web端的良好支持，各种页游层出不穷，因此选择java左右后台开发的主流技术没有任何问题。基本框架是：
spring-websocket
spring-message
jdk1.8
核心就是这两个支持websocket的spring官方模块，对于websocket的支持非常好，从效率上讲，易上手，花了一天时间做了个websocket的demo。并且实现了发布/订阅的机制。从交互协议上讲，个人感觉不存在多大问题。其中开启了stomp协议之后，不仅实现了订阅消息的机制，而且配合websocket的双工能力，从协议上将已经不会是技术瓶颈。
spring官方出品的sock.js向下降级兼容各大浏览器，数据支持byteArray,json等轻量级数据，因为本身要实现的是棋牌产品，从交互数据的大小上讲算很小的了。退一万步讲，如果真的存在数据包过大，换成protobuf后也能缩小1/3到1/5。这块，不成问题。
数据库方面，根据项目需要，暂定为mysql做数据持久化，项目的特点是持久化的频率不高，结合redis在内存中做业务数据的存储和数据传递，结算后做数据持久化。理论上还是能满足基本需要。
用户认证：
说到用户认证，其实有很多种做法，首先从游戏场景讲：玩家进入游戏肯定是经过认证的用户。不支持陌生用户玩这个游戏，通常会走注册->登录流程。如果采用社交化登录的话。通过扫码登录（微信或者qq等）然后实现用户认证是比较常见的。登录后，后端给前端一个会话token，后面的数据交互，都会带上这个token（包括websocket协议中的数据交互）。redis根据token去做用户信息的key，value就是用户信息，从socketsession中获取到的id，作为第二个用户信息的key，value就是token。这样当用户掉线，重新登录时，可以更新用户的服务器状态。
反向代理
为什么需要反向代理：游戏除了websocket协议，还会涉及到一些外围的模块，还会牵扯到网页的获取，活动的更新等，内容承载肯定通过jetty或者tomcat等web容器来进行返回内容。包括一些rest的api，json的数据交互等。所以上nginx还是有必要的。首先是它解决了http的反向代理，将用户的请求反向代理给web容器。另外一个直接利用nginx做负债均衡。可以很方便快捷的解决除了websocket以外的其他数据交互。其次nginx本身也支持tcp的upstream，所以也可以做到websocket的反向代理，服务如果多机部署，数据见做共享，那么业务数据的压力的就可以直接通过nginx来做分发。从而减轻单击压力。
高可用，本来考虑上HA，但觉得没必要，成本上去了，一切都是卵的。本身和程序设计没有多大必然联系。以后再说。
服务器其他要干的事情，就剩下定义主题和接口，以及数据模型了。服务器的细节问题（并发、会话共享等），以后再讨论。
2：前端选型
先说产品的目标运行环境：
PC端：覆盖一些上了年纪的用户，下载安装，就像qq一样方便。
移动端：其实不想做移动端的。
H5：主要针对支持webGL的主流浏览器，其实大部分都支持，除了该死的IE（IE10说：什么仇，什么怨）。
从优先级来讲，是PC > H5 > APP
从前端的技术选型来讲，必须覆盖所有。
调查并且跑了一些demo之后，发现whs.js和three.js是不错的选择。whs.js也是three.js的上层封装。结合node.js完全能够做到前端的技术盲点覆盖。
选型如下：
whs.js/three.js选其一，我选whs.js
socket.io-client/reconnecting-websocket选其一。后者支持掉线重连的封装。
stompjs 结合node.js的net模块，实现overWS的websocket参数封装，一步完成消息订阅。
zepto.js 不说了，主要是轻量级，主要针对外围交互json数据多。
tween.js 动画库，备用。
es6-promise 这个不赘述咯，语法写起来就像JDK1.8一样，各种lambda写起来感觉爽。
项目架构方面：采用webpack来做构建，结合一些插件可以做很多事情。
桌面应用程序打包层面，采用electron来做打包，因此项目会集成进去，打包后会生成linux、macOS和windows的运行程序，（跨平台？），不过我只需要win32的就够了，谁TM跑linux上去玩。
项目编译后，会生成一个bundle.js的全局压缩js，全部打包到应用程序中，用户打开程序后，不会像H5打开程序一样慢悠悠的，其速度取决于用户的电脑性能和加载js运营环境（引擎等东西）的效率。总的来讲，速度非常的快。游戏体验，绝对可以媲美原生（不要小看webGL的能力）。
electron打包后其实项目可以运行了，只不过就是个白板项目，出来也有100来M，吓人，用nsis压缩打包成exe可执行文件，压缩后，几十M，放到网上供用户下载。桌面应用程序的打包过程就了结了。
H5发布：直接制作一个分支，抛开electron，剩下的无异，本身程序就是基于web开发的，但是体验上肯定不如打包后的桌面应用程序和app，资源等所有东西都要从服务器下载。
APP打包层面：没具体深入了解，不过程序在制作上肯定会针对app但是做一套页面的适配，因为游戏毕竟不像web的响应式设计那样可以适配到所有设备。但是前端的交互逻辑以及js业务层面的封装是可以复用的，所以，产生的额外工作就只剩下UI适配。
APP打包工具选择：
1. 最好的选择是，安卓和IOS都需要各自的程序员来完成，毕竟app的体验与其他的不同，拿登录来讲，如果要用微信登录，那至少要唤起微信的客户端来做授权回调，所以还是需要原生能力。
2.退而求其次，现在Hbuilder的云端打包可以支持，类似的其他平台如api cloud好像也支持。就目前调查的结果来看，还是Hbuilder配合第三方可能会比较容易一些。暂定！
PS：你要是吊得一比，你就用react-native搞啊！
app打包最麻烦的在于发布后需要先去申请一些相关平台的key和密钥。这样第三方登录才可以使用。所以，这玩意儿优先级肯定是放到最后的。
不过我会优先做一个demo出来，验证以上思路的可行性。
下一章讲项目的构建。
感谢您的阅读。
