基于多人语音房的游戏直播方法、介质及计算机设备与流程

本发明涉及移动端直播间内互动小游戏领域，具体而言，本发明涉及一种基于多人语音房的游戏直播方法、介质及计算机设备。

背景技术：

小游戏常指一些上手很快，无须长时间进行，可以随时停止的游戏，同时要求有较高的娱乐性。基本实现方式为h5实现。多人语音房是直播间类型的一种，用户可以在同一直播间内进行多人语音聊天。目前，随着直播技术的发展，各种直播玩法层出不穷。虽然多人语音房可以实现多人聊天，然而玩法单一。另外，现有的技术也存在不少直播游戏的玩法，然而现有的游戏直播方案中至少存在以下缺陷：

1，现有小游戏多采取client-server(客户端-服务器)模式。在直播环境下，会有大量的游戏房间产生，每个房间有大量观众。如果观众直接作为客户端连入服务器会对服务器造成较大压力影响游戏体验。

2，现有小游戏多数没有语音功能，没有围观的功能。

技术实现要素：

本发明提供一种基于多人语音房的游戏直播方法及相应的装置，其主要实现了将小游戏引入多人语音房，丰富了语音房的玩法，提高了直播间游戏玩法的时效性、以及增强主播与观众的互动性，提升用户体验。

本发明还提供一种用于执行本发明的基于多人语音房的游戏直播方法的计算机设备及可读存储介质。

为解决上述问题，本发明采用如下各方面的技术方案：

第一方面，本发明提供一种基于多人语音房的游戏直播方法，包括：

获取进入直播间的指定的观众端作为嘉宾端，将所述嘉宾端加入直播间中的游戏应用；

把所述直播间中游戏应用的状态数据作为直播数据，通过所述直播间发送所述直播数据至观众端；

当接收到其中一个游戏终端发送的所述游戏应用的游戏增量数据时，将所述游戏增量数据转发至其他游戏终端；

当接收到主播端发送的所述游戏应用的游戏全量数据时，将所述游戏全量数据转发至所述嘉宾端。

具体的，还包括：

接收所述主播端实时上传的所述直播间中游戏应用的状态数据，所述状态数据用于展示于各个观众端。

具体的，所述当接收到其中一个游戏终端发送的所述游戏应用的游戏增量数据时，将所述游戏增量数据转发至其他游戏终端，包括：

将所述游戏全量数据强制推送至嘉宾端；

或者，在接收到所述嘉宾端发送的获取游戏全量数据的请求时，将所述游戏全量数据推送至所述嘉宾端。

具体的，所述游戏增量数据包括用户id以及增量数据序列号，所述游戏全量数据包括用户id以及全量数据序列号，所述在接收到所述嘉宾端发送的获取游戏全量数据的请求时，将所述游戏全量数据推送至所述嘉宾端，包括：

接收嘉宾端在判断缓存的所述增量数据序列号是否沿最大的全量数据序列号连续递增之后发送的获取从不连续的增量数据序列号到最新的增量数据序列号对应的所有游戏增量数据的请求；

向所述嘉宾端发送从不连续的增量数据序列号到最新的增量数据序列号对应的所有游戏增量数据。

优选的，所述获取进入直播间的指定的观众端作为嘉宾端，将所述嘉宾端加入直播间中的游戏应用，包括：

接收主播端提交的邀请进入直播间的游戏终端中指定的观众端加入游戏的请求，向所述指定的观众端发送是否同意加入游戏的请求；

在接收到所述指定的观众端反馈的同意加入游戏的应答消息后，为所述指定的观众端分配用户id，将所述嘉宾端加入直播间中的游戏应用。

具体的，所述获取进入直播间的指定的观众端作为嘉宾端，将所述嘉宾端加入直播间中的游戏应用，包括：

接收进入直播间的游戏终端中指定的观众端提交的申请加入游戏的请求，向所述主播端发送是否允许新玩家加入的确认请求；

在接收到所述主播端反馈的同意新玩家加入的应答消息后，为所述指定的观众端分配用户id，将所述嘉宾端加入直播间中的游戏应用。

具体的，所述把所述直播间中游戏应用的状态数据作为直播数据，通过所述直播间发送所述直播数据至观众端，包括：

接收观众端提交的登录游戏房间的请求；

向所述观众端反馈包含游戏应用的状态数据的结果。

第二方面，本发明提供一种基于多人语音房的游戏直播装置，包括：

获取模块，用于获取进入直播间的指定的观众端作为嘉宾端，将所述嘉宾端加入直播间中的游戏应用；

直播模块，用于把所述直播间中游戏应用的状态数据作为直播数据，通过所述直播间发送所述直播数据至观众端；

第一同步模块，用于当接收到其中一个游戏终端发送的所述游戏应用的游戏增量数据时，将所述游戏增量数据转发至其他游戏终端；

第二同步模块，用于当接收到主播端发送的所述游戏应用的游戏全量数据时，将所述游戏全量数据转发至所述嘉宾端。

第三方面，本发明提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如第一方面中任意一项所述的基于多人语音房的游戏直播方法。

第四方面，本发明提供一种计算机设备，其特征在于，所述计算机设备包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如第一方面任意一项所述的基于多人语音房的游戏直播方法。

相对于现有技术，本发明的技术方案至少具备如下优点：

1，本发明提供一种基于多人语音房的游戏直播方法，通过获取进入直播间的指定的观众端作为嘉宾端，将所述嘉宾端加入直播间中的游戏应用；把所述直播间中游戏应用的状态数据作为直播数据，通过所述直播间发送所述直播数据至观众端；当接收到其中一个游戏终端发送的所述游戏应用的游戏增量数据时，将所述游戏增量数据转发至其他游戏终端；当接收到主播端发送的所述游戏应用的游戏全量数据时，将所述游戏全量数据转发至所述嘉宾端。本发明实现了将小游戏引入多人语音房，丰富了语音房的玩法，提高了直播间游戏玩法的时效性、以及增强主播与观众的互动性，提升用户体验。

2，本发明中所述游戏增量数据包括用户id以及增量数据序列号，所述游戏全量数据包括用户id以及全量数据序列号，本发明为了避免嘉宾端请求所述游戏全量数据期间丢失所述游戏增量数据引起再次请求所述游戏全量数据，制定如下数据同步规则：在所述嘉宾端获取到所述游戏全量数据之前，所述嘉宾端缓存接收到的所有游戏增量数据；所述嘉宾端停止向所述嘉宾端的游戏应用推送所述游戏增量数据；所述嘉宾端获取到所述游戏全量数据后，根据所述游戏全量数据中的用户id以及最大的全量数据序列号检查缓存的所述游戏增量数据的专利数据序列号是否沿所述最大的全量数据序列号连续递增；若是，则将缓存的所述游戏增量数据推送至所述嘉宾端的游戏应用，否则，所述嘉宾端向服务器发送获取从不连续的增量数据序列号到最新的增量数据序列号对应的所有游戏增量数据。

3，本发明中所述嘉宾端处理完缓存的所述游戏增量数据后，恢复向嘉宾端的游戏应用前端推送所述游戏增量数据。并且，在所述嘉宾端恢复向嘉宾端的游戏应用前端推送所述游戏增量数据之前要一直接收所述游戏增量数据并存储到缓存队列里，避免因业务逻辑耗时导致丢失所述游戏增量数据。本发明方案严谨，能够增加游戏参与者的互动性，增强游戏的社交功能，让游戏乐趣度更高。

4，本发明可以接收主播端提交的邀请进入直播间的游戏终端中指定的观众端加入游戏的请求，向所述指定的观众端发送是否同意加入游戏的请求；在接收到所述指定的观众端反馈的同意加入游戏的应答消息后，为所述指定的观众端分配用户id，将所述指定的观众端置入直播间中游戏应用的游戏席位；向所述指定的观众端发送已将其置入游戏席位的通知消息。另一种实施例中，本发明还可以接收进入直播间的游戏终端中指定的观众端提交的申请加入游戏的请求，向所述主播端发送是否允许新玩家加入的确认请求；在接收到所述主播端反馈的同意新玩家加入的应答消息后，为所述指定的观众端分配用户id，将所述指定的观众端置入游戏席位；向所述指定观众端发送已将其置入游戏席位的通知消息。本发明方案灵活性高，玩法多种多样，用户体验佳。

5，本发明可以提供状态数据通道以及全增量数据通道，其中，所述状态数据通道用于传输所述直播间中游戏应用的状态数据，所述全增量数据通道用于传输游戏全量数据以及游戏增量数据。本发明中所述全增量数据通道保证数据的可靠性，状态数据通道保证数据的实时性，本发明通过发送游戏增量数据和定时同步游戏全量数据来实现整个游戏的状态同步，增强游戏体验。

附图说明

本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为本发明一个实施例的基于多人语音房的游戏直播方法的流程示意图；

图2为本发明一个具体实施例的主播端邀请观众端加入游戏的流程图；

图3为本发明一个具体实施例的观众端主动申请加入游戏的流程图；

图4为本发明一个具体实施例的游戏增量数据的同步流程图；

图5为本发明一个具体实施例的游戏全量数据的同步流程图；

图6为本发明另一个实施例的基于多人语音房的游戏直播方法的流程示意图；

图7为本发明一个具体实施例的观众端登录游戏房间的流程图；

图8为本发明一个实施例的基于多人语音房的游戏直播装置的结构框图；

图9为本发明另一个实施例的基于多人语音房的游戏直播装置的结构框图；

图10为本发明一个实施例的计算机设备的结构示意图。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。

如图1所示，在一个实施例中，一种基于多人语音房的游戏直播方法，包括：

s11、获取进入直播间的指定的观众端作为嘉宾端，将所述嘉宾端加入直播间中的游戏应用。

本发明所述基于多人语音房的游戏直播方法执行于服务器中，本发明所述方法涉及多个游戏终端，其中包括：观众端、嘉宾端以及主播端。另外，本发明还涉及嘉宾端的直播app上运行的游戏应用以及主播端的直播app上运行的游戏应用。

本发明实施例中，主播在直播间中开启小游戏后，游戏应用开始加载。当游戏应用加载成功，并成功建立游戏房间后，主播转为小游戏主播。主播在直播间中开启小游戏后，原直播间的观众自动转为小游戏观众。此时直播间画面开始加载游戏应用的数据，加载完成后，观众端的角色建立完毕。观众端可以加入游戏，即进入游戏席位。加入游戏席位的方式可以是主播端邀请，或者观众端主动申请加入，观众端加入游戏席位后则成为嘉宾端。本发明实施例中，所述游戏席位是指小游戏席位，其不完全对等于直播间麦位，所述游戏房间是指开启了小游戏，进入了小游戏模式的直播间，所述嘉宾端是指上了麦的观众端。所述观众端是指可以接收直播数据，未参与游戏的终端。

本发明实施例中，主播选择游戏并点击开始游戏。所述主播端更改ui界面为游戏状态，所述主播端加载游戏应用的数据并启动游戏环境，所述主播端回调游戏房间id，此时，游戏启动开始。所述主播端向所述服务器发送更新游戏运行状态的请求，所述服务器更新完游戏状态后向所述主播端反馈游戏状态更新完成的通知消息。所述服务器向观众端广播房间进入游戏模式的通知消息。所述观众端向所述服务器拉取游戏信息，所述游戏信息包括但不限于游戏名称、下载链接以及图标等等。所述观众端根据所述游戏信息检查当前游戏是否与app版本兼容，如果兼容，则根据游戏信息中的下载链接下载游戏资源包，下载完之后，app加载该资源包。直播间的界面切换成游戏模式，此后直播间算是正式进入游戏模式。

本发明实施例中，当主播开启游戏后，原直播间的观众即为游戏观众。进入直播间的观众端可以通过主播邀请升级为嘉宾端也可以通过主动申请成为嘉宾端。

请参考图2，图2为本发明的一种实施例中，主播端邀请观众端参与游戏的流程图。本发明实施例中，所述主播端向服务器提交邀请观众端加入游戏之前向主播端的游戏应用发送是否允许新玩家加入的请求，当主播端接收到主播端的游戏应用反馈的同意新玩家加入游戏的应答消息后，所述主播端向服务器提交邀请观众端加入游戏的请求。

如图2所示，所述服务器在接收到邀请指定的观众端加入游戏的请求后，向所述指定的观众端发送是否同意加入游戏的请求；在接收到所述指定的观众端反馈的同意加入游戏的应答消息后，为所述观众端分配用户id，并向所述主播端转发观众端反馈的同意加入游戏的应答消息。所述主播端接收所述应答消息后向服务器发送邀请观众端上麦的请求，所述服务器将邀请观众端上麦的请求转发至观众端，观众端上麦后向服务器反馈上麦完成的通知消息，所述服务器将所述上麦完成的通知消息转发至所述主播端。

进一步的，所述主播端接收到观众端反馈的上麦完成的通知消息后，向所述主播端的游戏应用提交将所述指定的观众端置入游戏席位的请求，所述主播端的游戏应用接收到该请求后将所述指定观众端置入游戏席位并设置基本信息，所述主播端的游戏应用向所述主播端发送已将所述指定观众端置入游戏席位的通知消息，所述主播端接收到该通知消息后向所述服务器发送更新游戏席位信息的请求，所述服务器更新完游戏席位信息后向所述主播端反馈游戏席位信息更新完成的通知消息。进一步的，所述观众端进入游戏，并传递用户id以及游戏房间号至所述主播端的游戏应用前端，最后所述观众端向主播端发送已进入游戏响应的通知消息。

请参考图3，图3为本发明的一种实施例中，观众端主动申请加入游戏的流程图。如图3所示，所述服务器可以接收进入直播间的游戏终端中指定的观众端提交的申请加入游戏的请求，向所述主播端发送是否允许新玩家加入的确认请求；在接收到所述主播端反馈的同意新玩家加入的应答消息后，为所述指定的观众端分配用户id并向观众端反馈同意新玩家加入的通知消息。进一步的，所述观众端向所述服务器提交申请上麦的请求，所述服务器将所述申请上麦的请求转发至所述主播端，所述主播端反馈同意上麦的应答消息后，所述服务器为所述观众端执行上麦。

进一步的，所述观众端上麦完成后，所述主播端向所述主播端的游戏应用发送将所述指定观众端置入游戏席位的请求，所述主播端的游戏应用将所述指定观众端置入游戏席位并设定基本信息之后向所述主播端反馈已将所述指定观众端置入游戏席位的通知消息。所述主播端接收该通知消息后向所述服务器提交更新游戏席位信息的请求，所述服务器更新完游戏席位信息后向所述主播端反馈游戏席位信息更新完成的通知消息。

进一步的，所述观众端进入游戏，并传递用户id以及游戏房间号至所述主播端的游戏应用前端，最后所述观众端向主播端发送已进入游戏响应的通知消息。

s12、把所述直播间中游戏应用的状态数据作为直播数据，通过所述直播间发送所述直播数据至观众端。

本发明实施例中，接收所述主播端实时上传的所述直播间中游戏应用的状态数据，所述状态数据用于展示于各个观众端。

本发明实施例中，所述直播数据是指包含当前整个画面的数据，以及背后所维护的数据的集合。所述主播端会定时上传所述直播数据，相应的，接收方可以单凭该直播数据，恢复整个画面及背后的状态。例如飞行棋游戏终，所述直播数据包括有玩家的数量、每个玩家的基本信息(头像以及姓名等)、每个飞机的位置以及每个玩家手中的道具等等数据的集合。

需要说明的是，所述直播状态数据是用于观众端显示游戏画面相当于主播端将游戏画面投影到观众端的手机屏幕上。

本发明实施例中，提供状态数据通道以及全增量数据通道两种数据传输通道，其中，所述状态数据通道用于传输所述直播间中游戏应用的状态数据即所述直播数据，所述全增量数据通道用于传输游戏全量数据以及游戏增量数据。

具体的，所述状态数据通道用于观众端显示游戏画面。所述主播端定时把整盘游戏的所有状态数据通过所述服务器通过原有的媒体流信道，广播给所有直播间内的其他游戏终端，并且，要求任意一状态数据能恢复对应的整盘游戏的信息，相当于一种“录像回放”功能。本发明设计所述状态数据通道主要是利用了直播间内原有的媒体广播信道来解决观众量大的情况下，游戏状态广播性能压力过高的问题。

进一步的，本发明所述全增量数据通道是指该通道能提供游戏增量数据传输和游戏全量数据传输的功能，是提供给游戏应用实现用的数据通道。本发明通过发送游戏增量数据和定时同步游戏全量数据来实现整个游戏的状态同步。所述服务器会负责转发数据，还会保存所述游戏增全量数据以供游戏应用恢复游戏状态使用，例如断线重连等情况下。

本发明中所述全增量数据通道保证数据的可靠性，状态数据通道保证数据的实时性，本发明通过发送游戏增量数据和定时同步游戏全量数据来实现整个游戏的状态同步，增强游戏体验。

s13、当接收到其中一个游戏终端发送的所述游戏应用的游戏增量数据时，将所述游戏增量数据转发至其他游戏终端。

本发明实施例中，所述游戏增量数据是指某一个游戏逻辑产生的动作数据，其可以代表一次操作。例如，下棋时往上走了一步，这里产生游戏增量数据即往上走一步的操作。需要说明的是，所述游戏增量数据在数量或者顺序上是互相依赖的。例如下棋时，发生了游戏增量数据序列“上”、“下”、“左”之后，棋子到达某个位置，如果发了生了数量上的缺失或者顺序乱了，会产生完全不一样的结果，将导致最终位置不一样。而游戏全量数据不存在这种依赖性。

总而言之，由于通讯过程中无可避免地出现缺失，所以要依靠游戏全量数据和游戏增量数据共同作用达到各游戏玩家的游戏状态保持一致。

请参考图4，图4为本发明的一种实施例中所述游戏增量数据的同步流程图。如图4所示，当嘉宾端产生所述游戏增量数据后将所述游戏增量数据上传至所述服务器，所述服务器缓存所述游戏增量数据并将所述游戏增量数据转发至其他游戏终端，如主播端以及其他嘉宾端。本发明实施例中，所述游戏增量数据包括用户id以及增量数据序列号，该用户id是指发送所述游戏增量数据的用户端的id号，所述增量数据序列号是指所述游戏增量数据对应的编号。其他游戏终端接收到所述游戏增量数据后检查接收到的所述游戏增量数据的增量数据序列号是否是连续的，若发现接收到的某id的游戏增量数据的编号不是连续的，则请求不连续点的游戏增量数据到最新的游戏增量数据的所有数据。

s14、当接收到主播端发送的所述游戏应用的游戏全量数据时，将所述游戏全量数据转发至所述嘉宾端。

本发明实施例中，所述游戏全量数据包含当前整个画面的数据，以及背后所维护的数据的集合。主播端会定时上传所述游戏全量数据。所述游戏全量数据与所述直播数据的用途不同。所述游戏全量数据用于参与游戏的玩家恢复游戏用，例如断网等情况下，会拉取所述游戏全量数据恢复当前游戏状态，而所述直播数据用于观众端的展示。另外，所述游戏全量数据和所述直播数据的数据结构不一定一致，因为所述游戏全量数据用于恢复游戏状态，其包含更多的数据。所述直播状态数据用于给观众端显示，其仅包含可以正确显示的数据即可。

请参考图5，图5为本发明的一种实施例中所述游戏全量数据的同步流程图。如图5所示，本发明实施例中，所述主播端定期上传所述游戏全量数据至所述服务器，所述服务器在强制更新功能开启的情况下可以将所述游戏全量数据强制推送至嘉宾端；或者，在接收到所述嘉宾端发送的获取游戏全量数据的请求时，将所述游戏全量数据推送至所述嘉宾端。

进一步的，所述嘉宾端接收到所述游戏全量数据后同步所述游戏全量数据，将所述游戏全量数据与缓存的游戏增量数据进行整合，推送给所述嘉宾端的游戏应用前端。

具体的，所述游戏全量数据包括用户id以及全量数据序列号，该用户id是指发送所述游戏全量数据的用户端的id号，所述全量数据序列号是指所述游戏全量数据对应的编号。

进一步的，所述在接收到所述嘉宾端发送的获取游戏全量数据的请求时，将所述游戏全量数据推送至所述嘉宾端，包括：

接收嘉宾端在判断缓存的所述增量数据序列号是否沿最大的全量数据序列号连续递增之后发送的获取从不连续的增量数据序列号到最新的增量数据序列号对应的所有游戏增量数据的请求；向所述嘉宾端发送从不连续的增量数据序列号到最新的增量数据序列号对应的所有游戏增量数据。

具体而言，在所述嘉宾端请求所述游戏全量数据返回前，缓存期间收到的所有游戏增量数据。同时停止向所述嘉宾端的游戏应用推送所述游戏增量数据。缓存内容为游戏增量数据队列[<id1，seq1>，<id2，seq1>，<id1，seq2>...]，其中，id为用户id，seq为数据的编号。所述嘉宾端拿到包含用户id以及全量数据序列号的游戏全量数据之后，推给所述嘉宾端的游戏应用前端。同时根据所述游戏全量数据中的用户id以及最大的全量数据序列号检查某id的缓存的游戏增量数据的增量数据序列号是否沿最大的全量数据序列号连续递增，如果是，直接将缓存的所述游戏增量数据，推送到所述嘉宾端的游戏应用前端，否则所述嘉宾端向所述服务器请求不连续的增量数据序列号到最新的增量数据序列号对应的所有游戏增量数据。

所述嘉宾端处理完缓存的所述游戏增量数据后，恢复向嘉宾端的游戏应用前端推送游戏增量数据。其中，所述嘉宾端恢复向游戏应用前端推送游戏增量数据之前要一直接收所述游戏增量数据并压到缓存队列里，避免因业务逻辑耗时导致丢失所述游戏增量数据。

请参考图6，另一种实施例中，本发明还包括一个步骤：

s10、接收观众端提交的登录游戏房间的请求，向所述观众端反馈包含游戏应用的状态数据的结果。

请参考图7，图7为本发明一种实施例中，所述观众端登录游戏房间的流程图。如图7所示，本发明实施例中，观众端可以向所述服务器提交登录游戏房间的请求，服务器相应的反馈包含所述观众端所要登录的房间的游戏状态数据的结果。

进一步的，所述观众端登录游戏房间之后可以向所述服务器获取游戏信息，所述游戏信息具体可以包括游戏名称、游戏下载链接以及图标等等，所述观众端根据所述游戏信息检查当前游戏是否与app版本兼容，如果兼容，则根据所述游戏信息中的下载链接下载游戏资源包如游戏脚本，图片等，下载以后，app加载该资源包，更改ui界面为游戏状态，加载并启动游戏环境。

请参考图8，在另一种实施例中，本发明提供了一种基于多人语音房的游戏直播装置，包括：

获取模块11，用于获取进入直播间的指定的观众端作为嘉宾端，将所述嘉宾端加入直播间中的游戏应用；

直播模块12，用于把所述直播间中游戏应用的状态数据作为直播数据，通过所述直播间发送所述直播数据至观众端；

第一同步模块13，用于当接收到其中一个游戏终端发送的所述游戏应用的游戏增量数据时，将所述游戏增量数据转发至其他游戏终端；

第二同步模块14，用于当接收到主播端发送的所述游戏应用的游戏全量数据时，将所述游戏全量数据转发至所述嘉宾端。

优选的，所述直播模块12中包括：

接收单元，用于接收所述主播端实时上传的所述直播间中游戏应用的状态数据，所述状态数据用于展示于各个观众端。

登录单元，用于接收观众端提交的登录游戏房间的请求，向所述观众端反馈包含游戏应用的状态数据的结果。

所述第一同步模块13中包括：

推送单元，用于将所述游戏全量数据强制推送至嘉宾端；或者，在接收到所述嘉宾端发送的获取游戏全量数据的请求时，将所述游戏全量数据推送至所述嘉宾端。

所述第二同步模块14中包括：

发送单元，用于接收嘉宾端在判断缓存的所述增量数据序列号是否沿最大的全量数据序列号连续递增之后发送的获取从不连续的增量数据序列号到最新的增量数据序列号对应的所有游戏增量数据的请求，向所述嘉宾端发送从不连续的增量数据序列号到最新的增量数据序列号对应的所有游戏增量数据。

所述获取模块11中包括：

第一获取单元，用于接收主播端提交的邀请进入直播间的游戏终端中指定的观众端加入游戏的请求，向所述指定的观众端发送是否同意加入游戏的请求，在接收到所述指定的观众端反馈的同意加入游戏的应答消息后，为所述指定的观众端分配用户id，将所述嘉宾端加入直播间中的游戏应用。

第二获取单元，用于接收进入直播间的游戏终端中指定的观众端提交的申请加入游戏的请求，向所述主播端发送是否允许新玩家加入的确认请求，在接收到所述主播端反馈的同意新玩家加入的应答消息后，为所述指定的观众端分配用户id，将所述嘉宾端加入直播间中的游戏应用。

请参考图9，在另一种实施例中，所述基于多人语音房的游戏直播装置还包括：

接收模块10，用于接收观众端提交的登录游戏房间的请求，向所述观众端反馈包含游戏应用的状态数据的结果。

本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述的基于多人语音房的游戏直播方法。其中，所述存储介质包括但不限于任何类型的盘(包括软盘、硬盘、光盘、cd-rom、和磁光盘)、rom(read-onlymemory，只读存储器)、ram(randomaccessmemory，随即存储器)、eprom(erasableprogrammableread-onlymemory，可擦写可编程只读存储器)、eeprom(electricallyerasableprogrammableread-onlymemory，电可擦可编程只读存储器)、闪存、磁性卡片或光线卡片。也就是，存储介质包括由设备(例如，计算机)以能够读的形式存储或传输信息的任何介质。可以是只读存储器，磁盘或光盘等。

本申请实施例还提供一种计算机设备。如图10所示，所述计算机设备包括：

一个或多个处理器510；

存储装置520，用于存储一个或多个程序500，

当所述一个或多个程序500被所述一个或多个处理器510执行，使得所述一个或多个处理器510实现上述终端的基于多人语音房的游戏直播方法。

如图10所示为本申请计算机设备的结构示意图，包括处理器510、存储装置520、输入单元530以及显示单元540等器件。本领域技术人员可以理解，图10示出的结构器件并不构成对所有计算机设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件。存储装置520可用于存储应用程序500以及各功能模块，处理器510运行存储在存储装置520的应用程序500，从而执行设备的各种功能应用以及数据处理。存储装置520可以是内存储器或外存储器，或者包括内存储器和外存储器两者。内存储器可以包括只读存储器、可编程rom(prom)、电可编程rom(eprom)、电可擦写可编程rom(eeprom)、快闪存储器、或者随机存储器。外存储器可以包括硬盘、软盘、zip盘、u盘、磁带等。本申请所公开的存储装置包括但不限于这些类型的存储装置。本申请所公开的存储装置520只作为例子而非作为限定。

输入单元530用于接收信号的输入，以及接收用户输入的选择语音文件等相关请求。输入单元530可包括触控面板以及其它输入设备。触控面板可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板上或在触控面板附近的操作)，并根据预先设定的程序驱动相应的连接装置；其它输入设备可以包括但不限于物理键盘、功能键(比如播放控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。显示单元540可用于显示用户输入的信息或提供给用户的信息以及计算机设备的各种菜单。显示单元540可采用液晶显示器、有机发光二极管等形式。处理器510是计算机设备的控制中心，利用各种接口和线路连接整个电脑的各个部分，通过运行或执行存储在存储装置520内的软件程序和/或模块，以及调用存储在存储装置内的数据，执行各种功能和处理数据。

在一实施方式中，计算机设备包括一个或多个处理器510，以及一个或多个存储装置520，一个或多个应用程序500，其中所述一个或多个应用程序500被存储在存储装置520中并被配置为由所述一个或多个处理器510执行，所述一个或多个应用程序500配置用于执行以上实施例所述的基于多人语音房的游戏直播方法。

应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

应该理解的是，在本申请各实施例中的各功能单元可集成在一个处理模块中，也可以各个单元单独物理存在，也可以两个或两个以上单元集成于一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

以上所述仅是本申请的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。