引言
对缘是一款相亲类直播产品,主要的业务形态是基于红娘+男女嘉宾三人视频连麦的方式的进行在线互动,让男女双方增进了解;但是三人间模式对于用户来说还是偏单调,也缺少用户付费场景,为了丰富用户体验、提升产品粘性,为了给用户提供更多的直播玩法选择,所以会有多人直播的形式,例如7人间、7人游戏、7人玩法,但是早期的多人间设计上也是固定房间麦位,固定房间类型,如果想在直播中途切换其他玩法,就需要关闭房间重新开启新的直播间,这对于已经在直播间内的用户来说,体验并不太好,所以产品在调研其他产品之后,并且为了便于后期玩法的快速扩展以及配合运营对分成策略的调整,以及支持直播过程中切换玩法不影响房间在线用户,用不同玩法吸引用户,所以便诞生了玩法房间,以便于主播可以在房间内自由切换玩法,切换直播形式
在详细的介绍玩法之前,先得介绍下直播产品的关键概念,“直播间“,基本上所有的业务开展都离不开直播间这个载体,怎么去理解直播间的概念呢,我这里给大家打个比方,大家的业余生活中都或多或少听说过剧本杀,剧本杀就是大家在一个房间内,扮演角色代入不同的身份,推进剧情,这里的店家可以理解为我们直播产品中的主播,剧本杀的场地房间就是主播创建的房间;那怎么去理解玩法呢,店家租了一个房间,肯定不能只玩一个剧本,除了用户会乏,用户觉得无趣了,店家的效益就会差,所以在这个房间店家可以提供不同的剧本选择,根据不同的剧本配置不同的道具,用户凑齐了就可以开始剧本,那在移动端,我们的玩法就是给用户提供在房间选择不同玩法的能力
通过梳理玩法和房间承接的业务逻辑,决定把房间抽象为基础服务,提供给所有玩法服务依赖,抽象具体的直播形式、直播内容为玩法,在架构层级上房间服务和玩法服务为同级,交互上房间基础相关的和房间服务直接交互,玩法相关的和玩法进行交互
在之前的三人间设计、七人间房间设计中,房间和玩法没有严格的区分,房间就是玩法,这也导致了玩法的拓展性较差,为了更好的扩展玩法,所以需要对房间服务进行新的定义,房间集成基础能力,玩法承接业务房间服务抽象基础功能:所有房间类型都会有的一些基础功能
房间的开启、关闭:房间的开启、关闭状态维护
房间基础信息维护:房间的唯一标识、背景图片、房间公告、房间内用户列表
房间关系管理:有人的地方就有纷争,用户游戏之间难免有冲突,这个时候就需要对这些冲突有些处理措施:禁言、踢出房间、拉黑
房间权限校验:不同的房间有不同的权限,在我们的生态,主播也就是红娘,是会有不同的等级,不同的等级能开的房间有些区别
房间进出:维护用户加入、离开房间、维护房间列表,投递进房离房事件,维护在房状态
连麦申请流程:用户申请、发送申请消息;红娘同意、拒绝申请;红娘邀请上麦的交互逻辑
连麦数据维护:记录用户的连麦数据,开始时间、结束时间、流id等,用于业务统计使用
连麦状态维护:用户的在麦状态,包含房主信息、直播间id、用户个人信息(年龄、性别、所在地等),连麦状态数据应用广泛,像踩麦跟随,在麦用户推荐,直播间列表推荐等
音视频推拉流:监听推拉流回调,通过回调监听用户连麦、下麦事件,根据事件做业务逻辑
玩法的内容多样,例如:ktv玩法,大家一起点歌唱歌;心愿玩法:拍卖自己的一件物品、一种关系都可以;闲聊玩法:设定一个话题,大家相互讨论;可以看出,玩法更多的是关于游戏方式、游戏规则的一些内容
玩法角色管理:不同的玩法,每个人扮演的身份角色不尽相同
玩法配置信息:房主的个人关于玩法的一些设置信息
玩法的数据维护:玩法的基础信息,主要玩法的当前各种实时状态信息
玩法的进程管理:游戏肯定有开始、结束、暂定等相关的功能,我们需要在这个过程中保留一些信息
// 玩法实体接口 |
为了统一管理、统一接口,在api设计上,我们通过采用了工厂模式,通过不同的玩法类型实例化不同的玩法实例,使得不同的玩法之间相互隔离,减少相关的干扰
玩法信息变动较为频繁,为了保证玩法内各个用户看的信息一致性,时效性,同步性,如果只是通过客户端定时刷新的机制,很难保证用户体验,也会出现很多负面的体验更新不及时,前后端数据不一致等,而且玩法内用户同时拉取数据对服务本身的性能也是个考验,所以我们对前后端的数据交互采取了推拉结合的方式
其中推模式下,又细分了全量和增量的方式,例如:
全量:当房间玩法切换的时候,需要全量同步一次玩法的所有数据到客户端,又或者用户首次进房,全量拉一次玩法的所有信息
增量:当用户在放房间内,玩法的一些信息变动,例如:角色变动,玩法的轮次切换、玩法的状态变化等通过增量的消息去同步
玩法的管理器,管理不同的玩法之间的切换逻辑、玩法的维护逻辑
玩法服务和房间服务以及客户端之间交互逻辑
心愿玩法类似线下的拍卖行为,竞拍人申请上麦,设定自己的拍品,主持人开始吆喝,底下观众就可以通过送指定礼物竞拍,由系统记录实时的排名变化,最终无人竞拍,主持人或者房主落锤,即本轮拍卖结束,可以由下一位拍卖人上麦,然后周而复始。
主持人:落槌的场控
贵宾:特邀嘉宾,可以直接上麦,通常是房主和主持人在app熟识用户,或者长期关注房间的用户
心动位:所有参数竞拍的人(房间内任意人都可以竞拍)取前六名,并且前六名的用户会自动上麦
被拍卖者:所有用户都可以上麦,拍卖自己的某件物品或者虚拟关系
观众:吃瓜群众
{ |
心愿玩法 |
---|
玩法这套架构之后,对于我们拓展新的玩法,提供了非常好的基础,充分总结了之前的房间设计的经验,以及之前的一些痛点,例如:
1、之前的用户的在不在房间是客户端自己维护,服务端通过zego的回调来维护服务的麦位数据,导致前后端数据不一致,后续只能通过各种补漏机制来矫正数据,本次做了大胆的尝试
通过完全在服务端来控制房间内连麦的人,通过消息去做数据的同步,客户端只负责推拉流的动作
2、房间的数据,榜单变动等都是通过用户去拉取接口,有时候会出现瞬间的流量提升,本次通过消息推的方式,只有新进入房间的用户通过接口获取,大大减轻了服务的负担
3、从代码结构上,通过引入设计模式,代码层次更加清晰、拓展性更强,不同的玩法之前互不干扰,公用一套基础房间业务
4、从产品上,玩法和房间分离,用户可以自由切换,不需要关闭房间额外开新的玩法房间,重新在浪费时间去召集用户进房