最近几年接触的都是房间类游戏。
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的。
托管机器人：比较弱智的机器人。 仅仅是帮真实玩家操作，是游戏顺畅。 是一个装饰者类。装饰真人（游戏玩家）
真实玩家想要托管，相当于直接变成弱智机器人了。