技术讲解：LOL天梯匹配系统其实可以这样实现

D小游

文/农夫与射手

天梯匹配系统对于玩过LOL类游戏的玩家应该并不陌生，这是一套将玩家的实力量化，并进行实时分配组队游戏与结算的系统。旨在将单局游戏的胜率控制在50%左右。避免出现虐菜，被暴虐，单边木桶短板效应，实力悬殊的局面。以提供更好的游戏体验。

带着如上所说的目的，我们从技术角度聊聊这套系统该如何实现。

系统设计

首先说量化。量化本质上是一个利用数学公式 ax+by+cz = result求结果的过程。abc xyz 代表各种因子(如 杀人数、死亡数、助攻数、网络线路等 )，得出一个具体的分数。分数相近的人如果进行对战，他们胜负的概率将会无限接近50%，比较出名的算法有ELO。

具体的算法我们这里不再表述，回到主题，既然有一个量化的过程，那我们在设计系统的时候，需要预留两个点：

1、get量化值，对应到匹配时的分值排序；

2、set量化值，对应到结算。

即匹配时获取量化值 , 结算时更新量化值：

匹配 + 结算

再说说组队游戏。组队对战 在前端常见的表现的形式为开房 (不要想歪了)，即将多个人聚合在一起。本质上是一个链表，存有先后进入关系。第一个进入的人开房并开门，人数足够后可以关门，即关闭房间入口。不足则开门，即开放房间入口，没人了则退房。

即：

1、开房
2、退房
3、关门
4、开门

业务流程梳理

终端玩家(手机/电脑) 通过互联网接入服务器，并发送匹配请求，服务器识别用户身份。进行匹配组队，分配房间。游戏结束后，进行结算。更新匹配分数。

综上所述，我们天梯匹配梳理的整个过程如下所示：

类天梯匹配系统的实现

而想要实现类天梯匹配系统，最简单直接的办法就是利用一些第三方工具来实现。

这里我们使用的是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接口创建）的房间的列表。默认为获取指定场次的可见房间列表。可以参考详细设计里返回指定排序、指定类型列表。l 客户端可以请求获取指定房间属性的房间列表，比如游戏里创建的有3人房间、4人房间，客户端可以只获取3人房间列表。3.1.5 踢除房间成员

kickPlayer（踢除玩家）

kickPlayer(roomID,userID)

踢除玩家，开发者可以调用该接口将玩家从房间踢出。如果房间ID或者用户ID不存在，则给出对应错误信息。该接口客户端和gameServer均能使用。l在玩家创建的房间里，只有房主才能踢；MVS创建的房间不对踢除操作进行限制。

HashGet&HashSet

而上文中提到的量化，以及 JoinRoomWithProperties，那么对这个Properties，则可以由开发者自己去开发复合游戏特色的量化算法。并由自己去实现 get 和 set。也可以借助Matchvs 提供这样自定义存储 接口，持久化存储用户的Properties。

将量化算法从系统设计中剥离处理，使得Matchvs的设计不会与具体游戏强耦合 ，又允许开发者高程度的自定义，不同的系统间可以良好协作，是一个很好的设计方案。

流程图

上述接口调用的流程图如下：

当然，以上是利用Matchvs能力去实现匹配系统的基础原理讲解，而对于LOL这样的高用户量的大型游戏而言，中间还有不少技术细节难点需要攻克。

via： 游戏扶持by腾讯游戏学院

berserkerko

腾讯LOL的匹配机制现阶段是比较科学的解决方案，楼主讲述的只是开房间的环节控制，实际匹配机制会更复杂，用户将会被分为3个阶层，段位，积分，隐藏分三部分进行控制，而不是单一变量决定的。
elo算法是一种1v1基础入门级别的公平竞技算法。其特殊的数学性质并不能完全解决匹配中出现的问题，其中会有特例出现。
比如：策划在设计时会让玩家强制匹配AI进行作战（即便玩家并不愿意与AI作战的低保局及恶意挂机的惩罚局）。
再比如分区内玩家人数不足，需要从其他区间调取玩家导致对战双方战力不公。
这些都是匹配中出现的问题，而降低玩家等待时间又会产生其他问题，所以优化算法与流程需要整体进行规划，而不是采用一种第三方插件就可以解决的简单问题。
尤其是当遇到用户通量和匹配时间的的问题上的时候，匹配不平衡会更加严重。除非服务器的计算量可以达到不需要开房间，根据玩家排队时间直接从服务器抽取用户开局战斗，否则无法单纯的解决这个问题。