关于房间类游戏一下感想

最近几年接触的都是房间类游戏。

1个人房间类游戏，代表《弓箭高手》。  主要工作在客户端，服务器仅仅是配置和存储玩家关卡信息。 

2个人房间类游戏，代表《蛇与梯子》《桌球》《象棋》。 

3个人房间类游戏，代表《斗地主》

4个人房间类游戏，代表《麻将》

4人以上房间类游戏，代表《牛牛》《炸金花》 《英雄联盟》

 

有的玩法还有俱乐部。 其实俱乐部基本上就是房间类游戏管理器，管理者是群主。  

有的玩法还有比赛模式。 其实比赛模式也基本上就是房间类游戏管理器， 只不过房间之间，有横向或纵向比较。  有时间限制等。

有的游戏还有匹配模式。其实匹配模式就是一个大房间。 所有人加入的是这个大房间。 用一定匹配规则开一个房间

不管什么模式都离开基本元素-房间。

 

根据实际开发遇到的一些问题做一下总结：

基础玩家：存放数据库查到的数据。 如昵称，金币数据， 钻石数据， 头像。VIP等级。 玩家基础状态（在线，离线）

基础房间： 支持广播， 支持针对某人单独发送数据

游戏玩家： 继承基础玩家，  存放游戏逻辑实例。 存放游戏内容相关东西， 如玩家状态（游戏中，准备中，打牌中）， 再如手牌

　　　　　　行为： 打牌，看牌， 胡牌等。 

游戏逻辑： 继承基础房间。 存放房间状态。 记录所有玩家。整个游戏循环驱动者。带1结尾三个步骤的就是核心。连在一起就是1局。

房间状态：
已初始化，
等待坐人
人满状态
约定玩法
玩法准备1 - 玩法做初始化
玩法开始1
玩法结束1
解散

 

客户端外部网络输入数据，到驱动房间动作。   通过 session.uid  查房间tid。 在更具tid获得房间。 直接调用房间方法：  table['cs_'+ event](uid, msg)

以上是没有机器人开发的正常流程。没有任何难度。 

 

我在实际碰到的项目中，如果房间加入了机器人，加入了真实玩家托管， 加入了玩家超时帮忙自动操作。 代码将变得很糟糕。 凝成一坨。

这些都是比较难处理的，因为改变了原有游戏计划（流程）。必须总结一下，否则每次碰到这样的， 毫无章法，瞎写。 加班加点最后开发完成且最后测试OK，但是代码结构垃圾，代码质量垃圾。

所以这块也必须总结一下。

 

 

机器人：装饰器类。 装饰游戏玩家。 加上一些AI算法。     需要监听所有广播消息，和单独发送的消息。 对实际客户端而言有的数据仅仅是更新UI，无他用， 这样的消息可以不用监听。

this.event.on(TableMsg.OnPutCard,  AIfunc);// 收到某人打牌的消息， AIFunc里决定要不要吃和碰。   因为有游戏房间实例， 所以可以 this.table.eatAction(uid);// 直接执行吃动作

这里的真实机器人是要保证胜率的，总体来说不能让系统输钱。因为可以控制发牌，可以控制摸牌， 可以知道对手手上的牌， 通过作弊保证胜率还是比较OK的。

 

托管机器人：比较弱智的机器人。 仅仅是帮真实玩家操作，是游戏顺畅。 是一个装饰者类。装饰真人（游戏玩家）

真实玩家想要托管，相当于直接变成弱智机器人了。