- 用户触发活动逻辑
用户在进入斗地主主页的时候,会去校验该用户是否能够触发活动,如果在触发活动范围内,会判断疲劳度决定是否出现活动弹窗,引导用户进入残局玩法。下面展示的是当用户进入首页时,校验触发逻辑:
这里在设计的时候用了两个开关,一是总的活动开关,二是新用户触发开关;考虑当出问题的时候能够提供一键降级的能力,另外给运营提供了关闭新用户触发的入口。
- 进入游戏请求牌局
每一个用户每日十局挑战的关卡并不相同,用户点击开始挑战会进入当天的挑战进度中,此时会判断当前是否有未完成且是当日的牌局,如果有的话,直接恢复至玩家上次离开时的状态。如果发现没有一局缓存或此关卡已结束,那么利用十局缓存中的数据和进度信息初始化牌局,并写入到一局缓存中,用户开始本关卡挑战。
值得注意的是请求用户今日的十关挑战是放在每天第一次进入第一关挑战时,避免在前一步判断触发时调用算法而造成大量无用请求;为什么在这里统一请求,而不是每一关都请求算法:是为了能够分发不同的牌局策略,算法侧的同学会根据不同的策略筛选和分发牌局,例如A桶投放前5关简单,B桶投放奇数关简单等;并且会尽量将牌局打散以获得更多真实用户挑战记录,以供后期数据分析。
前文提到的如何让用户一个月内不会请求到同样的牌局,一开始想的解决方案是通过布隆过滤器实现,后来简化了一个方案,将所有牌局分成31个区,每个自然天请求不同分区内的牌局即可。
- 出牌和跳过
下方的框图展示了玩家的出牌逻辑,在调用算法接口获得AI出牌信息之前,会对用户出牌进行前置判断。由于斗地主涉及到多种异常信息,因此需要做很多对异常信息的判断和处理,哪一些异常需要透给用户,例如:牌型不符合要求(不是单张、对子、三带、顺子、炸弹等),是否能够压过上家牌,是否能跳过(对面不要时玩家不可跳过),出的牌是否是玩家手牌(防止直接刷接口) 等等。
在检验没有问题之后,会将玩家本轮出的牌、玩家剩余手牌、AI剩的牌组装,并封装请求,RPC请求算法获得AI此轮出牌,拿到AI出牌后更新牌局信息,再判断是否走到结算,如果此时有一方手牌已为空,则本关结算;否则更新牌局信息缓存,玩家继续下一轮次的出牌动作。
结算逻辑: