什么是类Dota游戏的天梯匹配
玩过Dota或者LOL的人都知道 . 天梯匹配系统是一套将 玩家的实力 量化,并进行实时分配组队游戏 , 结算的系统. 旨在将单局游戏的胜率控制在50%左右. 避免出现虐菜,被暴虐,单边木桶短板效应, 实力悬殊的局面 . 以提供更好的游戏体验 .
带着如上所说的目的 . 我们从技术角度聊聊这套系统该如何实现 .
系统设计
首先说量化
量化本质上是一个利用数学公式 ax+by+cz = result求结果的过程 . abc xyz 代表各种因子(如 杀人数, 死亡数, 助攻数 ,网络线路等 ) ,得出一个具体的分数. 分数相近的人如果进行对战 . 他们胜负的概率将会无限接近50% . 比较出名的算法有ELO ,
具体的算法我们这里不再表述 . 回到主题, 既然有一个量化的过程 , 那我们在设计系统的时候 . 需要预留两个点:
- get量化值 , 对应到匹配时的分值排序
- set量化值 , 对应到结算
即匹配时获取量化值 , 结算 时更新量化值 :
匹配 + 结算
再说说组队游戏
组队对战 在前端常见的表现的形式为 开房 (不要想歪了) , 即将多个人聚合在一起 . 本质上是一个链表 , 存有先后进入关系 . 第一个进入的人开房 并开门, 人数足够后可以关门 , 即关闭房间入口 . 不足则开门,即开放房间入口. 没人了则 退房 .
即:
- 开房
- 退房
- 关门
- 开门
业务流程梳理
终端玩家(手机/电脑) 通过互联网接入服务器 . 并发送匹配请求 , 服务器识别用户身份 . 进行匹配组队,分配房间 . 游戏结束后 , 进行结算. 更新匹配分数 .
综上所述, 我们天梯匹配梳理的整个过程如下所示.
Matchvs的类天梯匹配系统的实现
Matchvs是如何提供这样的能力的呢? 这里就有必要谈到JoinRoomWithProperties这个接口了.
条件匹配
条件匹配JoinRoomWithProperties
JoinRoomWithProperties（roomProperty,userProfile）
roomProperty是匹配标签，让开发者可以描述“玩家想进一个什么样的房间”。提供maxPlayer（房间最大人数）,mode（游戏模式，默认为0）,can_watch（允许观战，默认不允许）固定字段。
开发者可以自定义房间属性用于精准匹配，比如：开发者获取到玩家当前积分500，于是在roomProperty里定义“range”:“400 – 600”。服务端收到请求后，将完全按照key-value进行匹配，即将携带相同的roomProperty的玩家匹配到一起。对于上述开发者自定义内容，服务端是帮该500分的玩家找到分值波动范围100的水平相近的其他玩家。
上面说到 如何 实现天梯式的匹配加入 , 没有说道这类房间如何创建 . 那么再说下Matchvs的另外两个接口.
CreateRoom
场景: 游戏中允许玩家自己创建房间并设置相应规则。比如：你画我猜。
房主可以踢出其他玩家，如果房主掉线或退房，则转移房主，房主转移规则按加入顺序进行转移。
提供创建房间的接口用于玩家创建房间，玩家主动创建的房间和系统自动创建的房间隔离。即随机匹配（条件匹配）和指定房间匹配分离，随机匹配不能匹配到玩家创建的房间里去。
CreateRoom(roomName,roomProperty,userProfile)
创建房间，roomName是房间名，password是密码，密码可以为空（此处考虑对外是分开两个接口还是只有一个）。roomProperty为房间属性，可被修改，只能被创建者修改。roomProperty设置固定字段“房间是否可见”，玩家创建房间后将该玩家加入房间。玩家创建的房间不能被随机加入，其它玩家只能通过“加入指定房间”进入。
GetRoomList
获取房间列表
getRoomList（GameID，mode，roomType，roomProperty）
获取游戏里由玩家主动创建（通过调用createRoom接口创建）的房间的列表。默认为获取指定场次的可见房间列表。可以参考详细设计里返回指定排序、指定类型列表。
客户端可以请求获取指定房间属性的房间列表，比如游戏里创建的有3人房间、4人房间，客户端可以只获取3人房间列表。
3.1.5 踢除房间成员
kickPlayer
踢除玩家
kickPlayer(roomID,userID)
踢除玩家，开发者可以调用该接口将玩家从房间踢出。如果房间ID或者用户ID不存在，则给出对应错误信息。该接口客户端和gameServer均能使用。
在玩家创建的房间里，只有房主才能踢；MVS创建的房间不对踢除操作进行限制。
HashGet&HashSet
而上文中提到的量化 ,以及 JoinRoomWithProperties ,那么对这个Properties, 则可以由开发者自己去开发复合游戏特色的 量化 算法.并由自己去实现 get 和 set . 也可以借助Matchvs 提供这样自定义存储 接口 , 持久化存储用户的Properties.
将量化算法从系统设计中剥离处理 , 使得Matchvs的设计不会与具体游戏强耦合 , 又允许开发者高程度的自定义 , 不同的系统间可以良好协作 , 是一个很好的设计方案 .
流程图
上述接口调用的流程图如下:
