web斗地主游戏实现指北

前后端通信

作为一个即时多人游戏，不论是即时聊天还是更新玩家状态，都需要服务端有主动推送功能，或者客户端轮询。轮询的时间间隔可能导致游玩体验差，因为不即时更新，而且请求数量太多可能会打崩服务器。

建议在cs间建立websocket连接，其实就是建立一个更占资源的连接，但是可以长期维持这个连接通道，两端都可以收发消息。

对于服务端需要额外的配置，如spring这种已成体系的大框架就不原生支持ws，需要额外的依赖。

ws不支持SSL，有个wss就是ws+SSL

通信模型就是一个server作为ws服务器，可以与不同client建立连接并相互发送信息。注意在开发中，是服务端这边会对每一个client新建一个连接对象并保存在内存中(HashSet<Connect>)。往往服务端推送是广播，遍历这个HashSet，对所有客户端发同一个消息。

房间隔离

作为游戏有房间的需求，某些更新只需广播给某个房间里的玩家，而不是全体玩家。而最基本的ws不支持房间号这些，倒是socketio这种有专门支持，但是socketio需要专门的服务端依赖和客户端依赖。如果需要自己基于ws实现的话，可以在上面那个HashSet的基础上再套一层，即HashMap<RoomID,Connect>。由于clien请求中会提及是哪个房间发来的请求，我们找到对应房间的几个连接，只对这几个玩家发送消息。

匹配机制

这个更像是产品方案设计而不是技术设计，可以参考LOL等游戏的排名分机制。

我的一个思路是，假设我的当前rank分是k，从现在开始经过的时间为t，我会搜索rank分在[ k-t, k+t ]区间的、也正在匹配队列中的其他玩家，即这个区间随时间不断扩大。这个方案较为简单，适用于课设、毕设这种玩家数量过少、需要一定算法辅助匹配的情况。

考虑到斗地主在等待环节退出游戏的功能，匹配不止是几个人匹配上就马上开一局这种类似LOL的情况。对于已经进入房间、还在准备阶段、但某人又退出的情况，我们需要重新设计：

如果在几秒内没有找到房间，则自己开一个房间。否则进入一个匹配上的房间。
匹配算法是，玩家去匹配房间，房间的rank分为当前房间内玩家的平均rank分，在之前提到的区间范围内即被匹配上，玩家进入该房间。
还未满人的房间存在匹配队列中，供玩家定时轮询匹配。
记得在最后一个玩家退出房间后，从匹配队列中移除该房间。

建立房间

除了自由匹配，我们还要实现几个熟人组一局的需求。我们除了"自由匹配"按钮外，还要提供一个额外的"建立房间"按钮，这种房间不能被加入匹配队列中。除此之外要提供一个房间号，可以用uuid或者雪花算法等生成，并提供复制房间号和根据房间号查询的功能。

游戏

游戏状态

由于状态改变频繁，我是用redis做分布式缓存，保证一个后端节点宕机后，另一个节点也能继续使用redis中的状态。
但其实这种还是慢了，而且开发起来很麻烦，读写要反复做序列化反序列化，深层状态也不能直接hset和hget。建议还是用本地HashMap保存游戏状态。通过多节点、负载均衡，每个节点管理部分牌局。
对于游戏里的对象，构建Card、Room、Player等对象，将这些对象保存在内存中，即保存游戏状态。
Room需要记录当前出牌玩家、上一次的出牌、倍率、倒计时、地主牌等信息。
牌要记录花色、大小。

准备

开始前，各自都有个准备按钮，点击后进入准备中。如果房间满人且全部准备，则生成随机牌，除了3张地主牌，其他的直接发给各个玩家，房间进入叫分阶段。

倒计时

考虑到玩家会刷新界面，倒计时沙漏不能放在前端，由后端统一管理，每秒减一并发送给各个玩家以更新。倒计时为0时触发对应事件。

叫分

按照某种顺序，开始逐个叫分，超时的则不叫。具体规则自行设计。选上地主的玩家获得地主牌，并从他开始出牌。房间进入正式开始阶段。

提示出牌

如果上家出了牌，则查询我的手牌中是否有比他大的。我这里只是简单写下，这里的牌型判断和大小比较最好封装为函数，因为除了提示除外，直接出牌时也要比较，如果不行要给用户对应显示。

permutation:List<List<Card>> = 全排列枚举手牌中所有可能，2^n，最大不超过2^20，只在客户端计算
hint = None
for cards in permutation:
	if cards 不合法:
		continue
	if cards 是炸弹:
		...
	if cards 是王炸:
		...
	if 相同牌型且大于:
		...
if hint == None:
	...
else:
	...