前后端通信
作为一个即时多人游戏，不论是即时聊天还是更新玩家状态，都需要服务端有主动推送功能，或者客户端轮询。轮询的时间间隔可能导致游玩体验差，因为不即时更新，而且请求数量太多可能会打崩服务器。
建议在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:
...
托管
自动根据提示的第一个方案出牌。
出牌校验
考虑到客户端可能会乱搞，所以在服务端也要对出牌再做一次校验，是否真的大于上家的牌。
出牌超时
如果出牌时超时，如果上家没出，则出最小的一张，否则直接打不起。
打不起
清空"上一次出牌"。
退出重连
退出行为能通过用户点击按钮退出的行为、或网络错误断开websocket连接触发hook，这两个捕获到。
如果退出，在服务端更新该用户为托管，并更新客户端。如果重新连接，则将他的状态改为正常，并将当前游戏状态推送给该用户。
对于逃跑需要在结算时给予惩罚。
结算
某玩家的牌出完后，先让前端放一个出牌动画，然后再让各用户展示手牌，然后再显示结算框。
自行设计规则，主要是根据叫分、炸弹飞机等数量，做加法、乘法等，对输赢玩家做金币和rank分的增减。
注意结算框是另一个推送请求，在这个请求推送后直接在服务端修改该房间状态为准备中。
点击结算框的确认的玩家，在前端还是留在房间内，显示准备中。即后端其实已经改了，但是页面转换逻辑留给前端。这样效果比较好。
人机
- 使用 RL 模型：github.com/kwai/Douzero
- 我做了一些调整，方便使用它：github.com/urlyy/DouZero_I_have_trimmed
放个图做封面图
