前言
最近有些突发的事情，在飞机上写了点代码，先把它们更新上来吧。毕竟这个文章是做这个东西的一个心路历程，可能有些东西讲得并不是很明白。大家可以自己查下资料或者在下面留言。这段时间，我主要是做了一些前端的的样式以及“准备”这个功能的开发，这个功能主要是为后续的重新开始游戏等功能的准备。
思考
对于一个前端只会写js的人，其实来搞前端样式还是有困难的。但是，我们可以“借鉴”呀。
至此之前，后端只要考虑有没有这个玩家，现在我们要考虑这个玩家的状态。很明显，我们需要一个context的上下文对象来保存这个状态。在这个过程中，开发得其实很蹩脚。有这么几种关系，棋盘、规则、房间、玩家等，这部分需要去做合理地抽象，我希望未来这个后台是可以通配各种棋牌游戏的，如果我们今天想玩麻将了，我们只要写前端代码，还有写麻将的规则即可。
实现
先放一张效果图
是不是感觉比之前的好看多了，感觉就很高大上，如果是大学的毕业设计，一下子从C变成了A+，老师们都喜欢好看的...
我们来看下css的代码（后端猴子最讨厌了）
body {
font-size: 12px;
line-height: 150%;
text-align: center;
background: url(../images/bg.jpg) repeat scroll 0% 0% transparent;
margin: 0;
position: relative;
}
.game-box {
width: 640px;
margin: 0 auto;
position: relative;
}
.btn-box {
padding-left:45px;
}
.btn-box a {
background: url(../images/btn-bg1.png) center 0 no-repeat;
height: 75px;
width: 205px;
cursor: pointer;
margin:0 30px;
display:block;
font: normal 22px/70px "微软雅黑";
float:left;
color: #480e00;
text-decoration: none;
}
body是背景，game-box是画布，btn-box是下面的按钮。这里面的几个参数还是比较熟悉的，如果有哪些字段不知道什么意思，可以在w3c 上面查一查。这里面比较“神奇”的就是game-box里面的margin了，通过auto自适应，可以居中。但是随即我们就发现了一个问题，当我们发生monseDown的时候，获取的坐标是页面里面的坐标，我们如何转化为画布的坐标呢？
很明显我们需要获取
这么一个位置，这个东西纠结了好久，一直不知道怎么搞，一直找不到现成的方法（前端弱鸡）。后来阅读别人的代码中获取到这么一种思路，逐层往外递增。
function getDomXY(a) {
for (var b = a.offsetLeft,
c = a.offsetTop,
d = a.offsetParent; null !== d;) b += d.offsetLeft,
c += d.offsetTop,
d = d.offsetParent;
return {
x: b,
y: c
}
}
在前端中，offsetParent顾名思义，就是获取这个对象的父对象。
好了，添加了这些，我们其实已经把前端变得“高大上”了。这一部分都是纯粹的前端改动，后台并不需要进行任何处理。
接下来我们来考虑增加准备这么一个功能。
前端非常简单，我们只要添加一个按钮，还有对应的js代码
<div class = "btn-box"><a onclick="sendReadyMsg()">准备好了</a></div>
function sendReadyMsg(){
if (isReady == false){
webSocket.send("ready");
}
isReady = true;
}
但是对于后端，我们发现我们原来的简单后端模型支持不了。于是我们需要进行改造，首先，我们需要一个上下文对象来存用户的状态。现在我们只用来保存用户的准备状态。
public class UserContext {
private Session session;
public UserContext(Session session){
this.session = session;
}
/**
* 游戏状态
*/
private @Getter @Setter int gameStatus;
public interface GAME_STATUS {int PENDING = 0; int READY = 1; int RUNNING = 2;}
/**
* 是否准备完成
*/
public boolean isReady(){
return gameStatus == GAME_STATUS.READY;
}
}
然后以前room中存用户的set<Session>变成map<Session, UserContext>.我们来整理一下整个准备动作的流程。
简书的markdown不支持流程图真是太不方便了....
按照这个流程图，我们只要修改对应的方法即可。非常简单，就不贴代码出来了。
总结
再一次回到刚才我们提到的问题，就是用户、规则、房间等类之间的关系。这一部分是需要后面好好好好考虑的。虽然现在我也做好了一些抽象，但是可能之前没做过相关的东西，我想还是先继续添加一些功能，然后看看之前的模型是否适用。
源代码下载地址
以往没有任何做游戏的经验，如果大家有什么批评指正，欢迎大家评论指教。
