卡牌类游戏游戏大厅——下篇

阿巩

It will all be okay

我们继续昨天的上篇，在注册/登录->选择游戏区域->认证->进入大厅之后就是选择房间/创建房间，也就是进入到了大厅与游戏对接的部分。

在进入大厅创建房间或者牌桌时，需要有一系列参数在创建房间时固定下来，比如：玩家ID、房间ID、房间人数、是否有旁观者、达成的条件（低于10分不允许玩家继续比赛）、进入房间的条件（比如玩家金币不得少于1000才可以进入）。

客户端将上述数据提交到服务器，假设服务器是用Python编写的，当服务器拿到这些数据后，将数据保存下来，并且需要启一个线程进行房间的创建和等待。房间信息需要存放到内存中，在玩家登录后都能看到房间的信息，这里可以使用一个队列来满足玩家预览房间列表的需求。

考虑到Python语言的运行效率，每进入一个玩家就遍历一遍队列显然不妥，可以考虑增加一个专门的缓存或者专门做查询的Queue进程。这个进程负责管理对外的房间信息的排列和整理，其他进程负责创建房间、进入房间和接通游戏。

当玩家进入游戏后，这个Queue进程已经对玩家的内容进行了初步整理和分配，比如玩家金币不够1000，那么对于该玩家在服务器端已经做了No标记了。所以事实上客户端现在已经拿到能否进入房间的基础信息，并做出对应展示即可，如果条件满足，进入后再进行最终匹配，比如房间密码是否正确，游戏是否开始等。

对于将创建的房间分享到微信或者qq这类需求，需要使用到微信的web开发接口，也就是通过js文件取得了Token信息并且将内容正确派发到微信，当微信朋友点击链接后，使用get方法将链接后面拼上对应字符串。（如：https://www.game_server.com/share?create_id=xxx&room_id=xxx）当web服务器拿到数据之后，通知后台应用启动，如果没有应用，直接呼叫浏览器进行app下载。当玩家进入游戏后，链接Token自动失效。

在进入房间后，一般是不会直接进入游戏的，因为仍有很大的比例这个房间无法达成进入游戏的条件。那么这个阶段也是属于大厅的层面。还是以Python做服务端为例，我们可以另开一个进程来处理游戏逻辑部分，房间的进程将该房间的内容发送到游戏服务器，告诉服务器是否开始游戏，玩家有哪些，每个玩家金币数量等。服务器只会保存房间的具体信息和房间号码，等游戏全部结束后，游戏服务器才会返回给大厅服务器。最终的游戏结果也被视作游戏房间的部分。

假设现在我们已经进入了游戏中，对于判定玩家掉线的情况，因为服务端使用异步方式和客户端通信，比如我们判断有一分钟没有数据发送过来即可判定用户掉线。在掉线后一般需要由机器人接管已掉线玩家，这个逻辑如何实现呢？机器人接管后，是否允许掉线后的玩家再次回到游戏呢？

1、机器人接管后，不允许玩家进入：当玩家重新进入游戏，如果“僵尸玩家”还在上一局游戏中，游戏UI给出提示：您已掉线，请等待xxx分钟。在结束后，自动清理僵尸玩家，玩家重新获得控制权。

2、机器人接管后，允许玩家进入：当玩家重新进入游戏，机器人将控制权移交给玩家。这种方式需要服务器保存玩家目前的所有状态，由于是socket形式，在玩家退出后，这条socket的句柄已经被回收；在玩家第二次进入后要进行二次分配，插入到当前游戏中。

3、掉线后机器人不接管：如果游戏内容允许缺人，直接对掉线玩家扣除金币；不允许缺人将结束游戏，补偿剩余玩家。这种方式就相对简单粗暴了，不过在游戏开发初期，也不失为一种选择。

参考：

《游戏服务器架构与优化》 蔡能

END