桌游、房间类的游戏设计与开发实现（三），netty 分布式网络游戏服务器框架，netty 集群网络游戏服务器框架。

提示

当前系列是基于 ioGame 网络游戏服务器框架开发。

相关系列：

1. 桌游、房间类的游戏设计与开发实现（一）
2. 桌游、房间类的游戏设计与开发实现（二）

ioGame 简单介绍

• ioGame 网络游戏服务器框架 (yuque.com)

ioGame 是一个轻量级的网络编程框架，适用于网络游戏服务器、物联网、内部系统及各种需要长连接的场景；
ioGame 是基于 java netty 的高性能游戏服务器框架，是一款真.轻量级的网络编程框架。
ioGame 源码完全开放、最新文档阅读完全开放；使用完全自由、免费（遵守开源协议）。

你是否想要开发一个高性能、稳定、易用、自带负载均衡、避免类爆炸设计、可跨进程跨机器通信、集群无中心节点、集群自动化、有状态多进程的分布式的网络编程服务器呢？如果是的话，这里向你推荐一个由 java 语言编写的网络编程框架 ioGame。下面将会从多个方面来对框架做一些简单的介绍。

特点：

• 无锁异步化、事件驱动的架构设计；轻量级，无需依赖任何第三方中间件或数据库就能支持集群、分布式
• 通过 ioGame 可以很容易的搭建出一个集群无中心节点、集群自动化、多进程的分布式游戏服务器
• 包体小、启动快、内存占用少、更加的节约、无需配置文件、提供了优雅的路由访问权限控制
• 可同时支持多种连接方式：WS、UDP、TCP…等；框架已支持全链路调用日志跟踪特性
• 让开发者用一套业务代码，能轻松切换和扩展不同的通信协议：Protobuf、JSON
• 近原生的性能；业务框架在单线程中平均每秒可以执行 1152 万次业务逻辑
• 代码即联调文档、JSR380验证、断言 + 异常机制 = 更少的维护成本
• 框架具备智能的同进程亲和性；开发中，业务代码可定位与跳转
• 架构部署灵活性与多样性：既可相互独立，又可相互融合
• 可同时与同类型的多个游戏逻辑服通信并得到数据
• 逻辑服之间可相互跨进程、跨机器进行通信
• 支持玩家对游戏逻辑服进行动态绑定
• 能与任何其他框架做融合共存
• 对 webMVC 开发者友好
• 无 spring 强依赖
• 零学习成本

系列描述

本系列将介绍网络游戏开发中，桌游、房间类的游戏设计及实现流程。使用通用的模型来扩展桌游、房间类游戏的实现。

桌游、房间类的游戏通常指的是，如炉石传说、三国杀、斗地主、麻将 …等类似的桌游。或者说只要是房间类的游戏，该模型都适用。比如，CS、泡泡堂、飞行棋、坦克大战 …等。

桌游、房间类的游戏设计描述

light-game-room 房间，是 ioGame 提供的一个轻量小部件 - 可按需选择的模块。

light-game-room + 领域事件 + 内置 Kit = 轻松搞定桌游类游戏

该模块是桌游类、房间类游戏的解决方案。比较适合桌游类、房间类的游戏基础搭建，基于该模型可以做一些如，炉石传说、三国杀、斗地主、麻将 …等类似的桌游。或者说只要是房间类的游戏，该模型都适用。比如，CS、泡泡堂、飞行棋、坦克大战 …等。

如果你计划做一些桌游类的游戏，那么推荐你基于该模块做扩展。该模块遵循面向对象的设计原则，没有强耦合，可扩展性强。且帮助开发者屏蔽了很多重复性的工作，并可为项目中的功能模块结构、开发流程等进行清晰的组织定义，减少了后续的项目维护成本。

---

概念 - 房间管理、游戏流程、玩法操作

房间管理相关的、开始游戏流程相关的、玩法操作相关的是该模块主要解决的问题。框架为此 3 大类做了接口化的抽象。对应关系如下

1. 房间管理相关的 RoomService
2. 开始游戏流程相关的 GameFlowService
3. 玩法操作相关的 OperationService

GameRoomService 接口则继承了上述 3 个接口，起到一个聚合的作用。如果你的游戏有开始游戏流程，又有玩法操作的，那么直接实现 GameRoomService 接口即可。

或许有开发者会有疑问，为什么不设计成一个接口，这样在理解上就简单多了。

面向对象编程的一个重要概念就是“接口隔离原则”，即一个类只需依赖它需要的接口，而不需要依赖其它接口。这使得程序更具有可扩展性和可维护性。接口既可以提高系统的可维护性，也可以使系统的扩展性更加灵活。同时，接口还可以提高代码的可读性，降低代码的耦合度。

上面这段话或许有些抽象，这里用一个小案例来说明为什么要这么设计。某些游戏中，会有一些地图的概念，只有在相同的地图玩家才是可见的。

这个需求使用 room 模块来实现是简单的，只需要实现 RoomService 接口即可（房间管理相关的）。现在，房间就能表示一张地图。在玩家进入地图时，只需要将玩家添加到房间里面即可，当玩家离开时，只需要从房间移除这名玩家就行。当玩家发送一个表情时，只有该地图（房间）内的其他玩家才可以收到（利用房间广播）。

那么你会发现，地图用不上 GameFlowService 、OperationService 接口，也就是说这两个接口的能力在地图业务中是用不上的。现在，接口细化的优势就体现出来了。同时，这也能让各自的职责更清晰。

这里简单的介绍了一下房间管理相关的、开始游戏流程相关的、玩法操作相关的及其对应的接口设计原则。后续小节中，会对每个接口做详细的说明。

房间管理 - 相关

RoomService 房间管理相关的。管理着所有的房间、房间的添加、房间的删除、房间与玩家之间的关联、房间查找（通过 roomId 查找、通过 userId 查找）。

自定义扩展

开发者只需要实现该接口就能具备上述功能。

如果你使用了 lombok，推荐这种方式，只需要在扩展类中写两行代码就能具备上述所介绍的功能了。

@Getter
@FieldDefaults(level = AccessLevel.PRIVATE)
public class MyRoomService implements RoomService {
    /** 房间 map */
    final Map<Long, Room> roomMap = new ConcurrentHashMap<>();
    /** 玩家对应的房间 map */
    final Map<Long, Long> userRoomMap = new ConcurrentHashMap<>();
}

默认的实现

框架为 RoomService 接口内置了一个默认实现，如果你只想使用房间的管理相关的功能，且没有扩展的打算，那么可以使用框架提供的默认实现。

// 创建一个 RoomService 对象实例（框架内置的默认实现）
RoomService roomService = RoomService.of();

使用示例

RoomService roomService = ...;

Room room = ...;
Player player = ...;

roomService.addRoom(room);
roomService.removeRoom(room);

roomService.addPlayer(room, player);
roomService.removelayer(room, player);

roomService.getRoomByUserId(userId); // 通过 userId 查找房间

小结

可以看出，房间管理相关（RoomService）在扩展上是简单的。

本期先介绍到这，后续将介绍【开始游戏流程 - 相关】相关内容。