首页> 中国专利> 远程游戏环境中的游戏可用性

远程游戏环境中的游戏可用性

摘要

本发明的实施例监视并动态管理游戏服务内的游戏实例。游戏服务提供远程游戏环境,用户在诸如因特网的广域网上连接到该远程游戏环境。例如,本发明的实施例可以预测对特定游戏标题的需求。所述需求预测用于确定当玩家加入和离开游戏会话时为满足需求需要多少备用游戏实例。具有较高需求的游戏可以拥有更多为玩家投入准备的备用游戏实例。具有较少需求的游戏可以拥有更少正在运行等候玩家投入的活动游戏实例。

著录项

法律信息

  • 法律状态公告日

    法律状态信息

    法律状态

  • 2019-04-26

    授权

    授权

  • 2016-04-27

    实质审查的生效 IPC(主分类):A63F13/358 申请日:20140519

    实质审查的生效

  • 2016-03-30

    公开

    公开

说明书

背景技术

视频游戏已变得日益流行。某些视频游戏允许多个玩家使用位于彼此远端的客户 端设备在同一游戏内进行交互。例如,在对等游戏环境中,遍及世界的多个客户端可以在网 络上连接到由所述客户端设备之一容宿的游戏。在另一示例中,服务器可以容宿多个客户 端设备在广域网上加入的游戏。

发明内容

提供本摘要用于以简化形式介绍下面在详细说明中进一步描述的概念的选择。本 摘要不旨在识别所要求保护的主题的关键特征或必要特征,其也不旨在被孤立地用作在确 定所要求保护的主题的范围时的辅助。

本发明的实施例监视、预测需求并且动态管理远程游戏服务内的游戏实例。所述 游戏服务提供用户在诸如因特网的广域网上连接到的远程游戏环境。例如,所述游戏服务 可以使用位于世界各地的一系列服务器或一系列服务器群来容宿视频游戏。玩家然后使用 多种不同客户端设备连接到所述游戏服务,所述不同客户端设备包括游戏控制台、智能电 话、平板电脑、个人电脑及其它计算设备。

本发明的实施例监视游戏玩耍的特性,以便确定游戏实例应当被添加还是从所述 游戏服务中减除。本发明的实施例可以通过游戏标题来监视游戏实例。例如,本发明的实施 例可以预测对数据中心内的特定游戏标题的需求是400个游戏实例。所述需求预测用于确 定当玩家加入和离开游戏会话时需要多少备用游戏实例来满足需求。具有较高需求的游戏 可以拥有更多为玩家投入准备的备用游戏实例。具有较少需求的游戏可以拥有更少正在运 行等候玩家投入的活动游戏实例。各种游戏的备用实例的数量可以基于特定服务器和由该 服务器为之提供服务的玩家的位置而不同。

附图说明

下面参考附图详细描述本发明的实施例,其中:

图1是适于实施本发明的实施例的示例性计算环境的框图;

图2是根据本发明的实施例的在线游戏环境的图;

图3是根据本发明的实施例的远程游戏计算环境的图;

图4是根据本发明的实施例的、示出远程游戏环境内处在不同阶段中的游戏实例的状 态图;

图5是根据本发明的实施例的、图示远程计算环境内的备用和活动游戏实例的分配的 图;

图6是根据本发明的实施例的、示出管理远程游戏服务内的游戏实例的方法的流程图;

图7是根据本发明的实施例的、示出管理远程游戏服务内的游戏实例的方法的流程图;

图8是根据本发明的实施例的、示出管理远程游戏服务内的游戏实例的方法的流程图。

具体实施方式

本发明的实施例的主题在这里用具体特性被描述以满足法定要求。然而,本说明 书自身不旨在限制本专利的范围。相反,发明人已设想,所要求保护的主题还可以结合其它 当前或未来的技术以其它方式被体现,以便包括与本文档中所描述那些类似的步骤的组合 或不同的步骤。此外,尽管术语“步骤”和/或“框”在本文中可以用于暗示所使用的方法的不 同元素,但除非并且除了当单独的步骤的顺序被明确描述时之外,否则所述术语不应当解 释为暗示在本文中公开的各种步骤之中或之间的任何特定顺序。

本发明的实施例监视、预测需求并且动态管理远程游戏服务内的游戏实例。所述 游戏服务提供用户在诸如因特网的广域网上连接到的远程游戏环境。例如,所述游戏服务 可以使用位于世界各地的一系列服务器或一系列服务器群来容宿视频游戏。玩家然后使用 多种不同客户端设备连接到所述游戏服务,所述不同客户端设备包括游戏控制台、智能电 话、平板电脑、个人电脑及其它计算设备。

本发明的实施例监视游戏玩耍的特性,以便确定游戏实例应当被添加还是从所述 游戏服务中减除。本发明的实施例可以通过游戏标题来监视游戏实例。例如,本发明的实施 例可以预测对数据中心内的特定游戏标题的需求是400个游戏实例。所述需求预测用于确 定当玩家加入和离开游戏会话时需要多少备用游戏实例来满足需求。具有较高需求的游戏 可以拥有更多为玩家投入准备的备用游戏实例。具有较少需求的游戏可以拥有更少正在运 行等候玩家投入的活动游戏实例。各种游戏的备用实例的数量可以基于特定服务器和由该 服务器为之提供服务的玩家的位置而不同。

在备用状态下,活动存储器中的游戏对象可由执行该游戏的处理设备访问和操 纵。活动存储器与辅助存储器相对,其中,游戏对象可以当其在游戏行动中不可操纵时被被 动存储在该辅助存储器中。正在活动存储器中运行的备用游戏实例不附连到玩家简档或来 自游戏客户端的I/O通道。一旦玩家请求游戏,则该玩家的玩家简档被加载到正在运行的游 戏实例中,并且I/O通道被从游戏客户端映射到该游戏实例。由此,备用游戏实例可以在没 有玩家简档或I/O通道的情况下运行。一旦一个或多个玩家被添加到备用实例,则该游戏实 例变为活动实例。

游戏服务可以容宿同一游戏标题的多个实例以及其它游戏标题的实例。游戏标题 的每个实例在游戏会话中运行。游戏会话运行视频游戏代码,所述视频游戏代码负责为用 户创建玩耍体验。游戏服务的不同部分可以被分配来运行特定游戏标题的游戏会话。资源 的监视和分配可以在游戏服务级上总体地、在逐标题基础级上对游戏服务的部分或其组合 来完成。

游戏会话运行由一个或多个玩家访问的视频游戏标题。本发明的实施例运行针对 游戏服务编写的游戏标题。针对游戏服务编写的标题不使用代码来管理服务器资源或其它 远程计算资源。作为代替,分配给游戏服务的计算资源响应于游戏服务计算特性的改变而 被动态更新。

游戏服务的各种特性可以被监视并被用于预测需求以及确定将备用的游戏实例 的最优数量。例如,针对标题运行的活动游戏会话的数量、连同对新游戏会话的请求和生成 针对该游戏标题的新游戏会话花费的时间一起被监视。这些特性可以在游戏会话的数量增 加或减少时用于计算为满足需求所需要的备用游戏会话的最优数量。

当游戏会话结束时,计算资源可以被回收利用到正在运行同一标题的备用游戏会 话。回收利用到同一标题允许机器在游戏代码不需要被重新加载到该机器上的情况下运行 游戏。当仅游戏标题的块(chunk)(诸如,级别)被加载到机器的活动存储器中时,则计算设 备可以被回收利用到正在运行同一级别的游戏会话。

进一步地,可以监视游戏会话或关联于该游戏会话的计算资源的健康。在一个实 施例中,显示诸如比预期处理时间慢这样的不健康特性的计算资源不被回收利用,并且作 为代替,将健康资源用于创建备用游戏会话。

已简要描述了本发明的实施例的概要,下面描述适于在实施本发明的实施例时使 用的示例性操作环境。

示例性操作环境

一般地参考附图,并且特别地首先参考图1,用于实施本发明的实施例的示例性操作环 境被示出并一般地指定为计算设备100。计算设备100是合适计算环境的仅一个示例,并且 不旨在对本发明的使用或功能性的范围建议任何限制。计算设备100也不应当解释为具有 与所图示的构件的任一个或组合有关的任何依赖或要求。

本发明可以在计算机代码或机器可用指令的一般上下文中进行描述,所述计算机 代码或机器可用指令包括诸如程序构件的计算机可执行指令,其由计算机或者诸如个人数 据助理或其它手持设备这样的其它机器执行。一般说来,包括例程、程序、对象、构件、数据 结构等的程序构件指执行特定任务或实施特定抽象数据类型的代码。本发明的实施例可以 以多种系统配置来实践,包括手持设备、消费电子、通用计算机、专用计算设备等。本发明的 实施例也可以在分布式计算环境中实践,其中,任务由通过通信网络链接的远程处理设备 执行。

继续参考图1,计算设备100包括直接或间接耦接以下设备的总线110:存储器112、 一个或多个处理器114、一个或多个呈现构件116、输入/输出(I/O)端口118、I/O构件120以 及说明性电源122。总线110表示可以是一条或多条总线(例如地址总线、数据总线或其组 合)的东西。尽管为清晰起见用线条示出了图1的各种框,但实际上,勾画各种构件并不如此 清晰,并且比喻地,所述线条更准确来说将是灰色和模糊的。例如,人们可以将诸如显示设 备的呈现构件看作I/O构件120。同样,处理器具有存储器。于此,发明人认识到这是本领域 的本质,并且重申图1的图仅图示了可以结合本发明的一个或多个实施例使用的示例性计 算设备。未在诸如“工作站”、“服务器”、“膝上电脑”、“手持设备”等的类别之间做出区分,因 为全部都在图1的范围内被设想,并且指“计算机”或“计算设备”。

计算设备100通常包括多种计算机可读介质。计算机可读介质可以是任何可被计 算设备100访问的可用介质,并且包括易失性和非易失性介质、可移除和非可移除介质两 者。作为示例且非限制,计算机可读介质可以包括计算机存储介质和通信介质。计算机存储 介质包括用任何用于存储信息的方法或技术实施的易失性和非易失性、可移除和非可移除 介质两者,所述信息例如是计算机可读指令、数据结构、程序模块或其它数据。

计算机存储介质包括RAM、ROM、EEPROM、闪存或其它存储器技术,CD-ROM、数字多功 能盘(DVD)或其它光盘存储装置,盒式磁带、磁带、磁盘存储装置或其它磁存储设备。计算机 存储介质不包括传播的数据信号。

通信介质通常将计算机可读指令、数据结构、程序模块或其它数据体现在诸如载 波或其它传输机制的已调制数据信号中,并且包括任何信息递送介质。术语“已调制数据信 号”指这样的信号,所述信号使其特性中的一个或多个以使得将信息编码到该信号中的方 式被设置或改变。作为示例且非限制,通信介质包括:诸如有线网络或直接连线连接的有线 介质,以及诸如声学、RF、红外和其它无线介质的无线介质。以上的任意的组合也应当包括 在计算机可读介质的范围内。

存储器112包括采用易失性和/或非易失性存储器形式的计算机存储介质。存储器 112可以是可移除的、非可移除的或其组合。示例性存储器包括固态存储器、硬盘驱动器、光 盘驱动器等。计算设备100包括一个或多个处理器114,其从诸如总线110、存储器112或I/O 构件120这样的各种实体读取数据。呈现构件116向用户或其它设备呈现数据指示。示例性 呈现构件116包括显示设备、扬声器、打印构件、振动构件等。I/O端口118允许计算设备100 被逻辑耦接到包括I/O构件120的其它设备,所述其它设备中的一些可以是内置的。说明性 I/O构件120包括麦克风、操纵杆、游戏手柄、卫星天线、扫描仪、打印机、无线设备等。

示例性在线游戏环境

现在转向图2,根据本发明的实施例示出了在线游戏环境200。在线游戏环境200包括通 过网络220连接到游戏服务230的各种游戏客户端。示例性游戏客户端包括游戏控制台210、 平板电脑212和个人计算机214。使用诸如智能电话的其它游戏客户端也是可能的。游戏控 制台210可以具有通信地耦接到其的一个或多个游戏控制器。在一个实施例中,平板电脑 212可以充当游戏控制台210或个人计算机214的输入设备。在另一实施例中,平板电脑是独 立游戏客户端。网络220可以是诸如因特网这样的广域网。

关联于游戏控制台210的控制器包括游戏手柄231、平板电脑232、头戴式耳麦236 和深度相机234。游戏控制台可以与生成富输入和基本输入这两者的控制设备关联。单独的 控制器能够生成不同种类的输入,以及单一控制器可以生成富输入和基本输入这两者。

游戏手柄231可能能够生成基本控制信号,所述基本控制信号例如是通过按钮选 择和操纵杆移动生成的那些。诸如由游戏手柄231内的加速度计和陀螺仪生成那些的移动 数据可以是富感觉数据的示例。在某些实施方案中,不将移动数据看作富感觉数据。

平板电脑232可以是游戏控制器和如先前与平板电脑212一起提到的游戏客户端 这两者。平板电脑232被示为直接耦接到游戏控制台210,但该连接可以是通过因特网或子 网而间接的。在一个实施例中,游戏服务230帮助构成平板电脑232和游戏控制台之间的连 接。平板电脑232能够生成众多输入流,并且还可以用作显示输出机制。除作为主显示器之 外,平板电脑232可以提供与示出在耦接到游戏控制台210的主显示器上的信息接近的补充 游戏信息,或简单地是控制表面。由平板电脑232生成的输入流包括视频和图片数据、音频 数据、移动数据、触摸屏数据和键盘输入数据。

头戴式耳麦236捕获来自玩家和玩家的周围环境的音频输入,并且如果其与头戴 式耳机或其它扬声器耦接则还可以充当输出设备。

深度相机234生成深度云,该深度云被用作控制输入。深度相机234可以使用红外 相机来针对每个所捕获像素确定深度或与该相机的距离。立体镜深度相机也是可能的。另 外,深度相机234可以捕获典型颜色流或图片。深度相机234可以具有几个图像收集构件。例 如,深度相机234可以具有多个相机。

游戏服务230可以包括彼此通信地耦接的多个计算设备。在一个实施例中,游戏服 务230使用一个或多个服务器群来实施。服务器群可以跨包括遍及世界的城市的各种地理 区域分散。在该场景中,游戏客户端可以连接到最近的服务器群。本发明的实施例不限于该 设置。

游戏服务230允许游戏在由游戏服务230提供的计算设备内被执行。游戏服务与游 戏客户端之间的通信会话将输入流量携带给游戏服务230,并返回所渲染的游戏图像和/或 其它游戏输出。

用于远程游戏的示例性游戏客户端和游戏服务

现在转向图3,根据本发明的实施例示出了示例性远程游戏环境300。远程游戏环境300 包括通过网络330通信地耦接到游戏服务器340的游戏客户端310。在一个实施例中,所述网 络可以是因特网。游戏客户端310连接到第一游戏输入设备312、第二游戏输入设备314和显 示器316。示例性游戏输入设备包括游戏手柄、键盘、鼠标、触摸板、触摸屏、用于接收语音命 令的麦克风、深度相机、视频相机和轨迹球。本发明的实施例不限于这些输入设备。显示器 316能够显示视频游戏内容。例如,显示器316可以是电视或计算机屏幕。在另一实施例中, 显示器316是与游戏客户端310集成到一起的触摸屏。

游戏客户端310是能够执行视频游戏的计算设备。游戏客户端310可以是平板电脑 或膝上电脑。在另一实施例中,游戏客户端310是游戏控制台,以及显示器316是通信地耦接 到该游戏控制台的远程显示器。游戏客户端310包括操作环境320、视频合成构件321、游戏 执行环境322和游戏数据储存器324。为简单起见,游戏客户端310的其它构件未被示出。

连接到游戏会话的客户端设备可以对于不同游戏扮演不同角色。在一个实施例 中,客户端设备仅向游戏会话发送控制信号。正在游戏会话中运行的游戏代码处理该控制 信号以改变游戏状态。例如,游戏内的玩家或对象可以响应于控制输入而移动。游戏实例可 以生成反映已更新的游戏状态的已渲染视频游戏图像,并将该已渲染图像传送给连接到在 该游戏会话中运行的游戏实例的一个或多个客户端。每个客户端从关联于该客户端的玩家 的角度可以接收不同的已渲染视频游戏图像。尽管从游戏服务的角度被描述为客户端,但 所述客户端可以是对于其它计算设备的服务器。例如,住宅内的计算设备可以在局域网上 向包括平板电脑或智能电话的其它计算设备提供游戏内容。

在另一实施例中,从服务器发送游戏几何结构和其它游戏信息并将其与驻留在客 户端上的图像数据组合以便在客户端设备上生成已渲染的视频游戏图像。客户端与游戏服 务之间的处理的其它划分是可能的。

操作环境320可以由管理硬件并向正在游戏客户端310上运行的应用提供服务的 操作系统提供。所述操作环境可以向作为游戏和通信功能的部分的不同应用分配客户端资 源。

游戏数据储存器324存储已下载的游戏、游戏采样和/或已部分下载的游戏。游戏 可以在可玩的框中被下载。为玩游戏,可能需要将游戏从游戏数据储存器324加载到关联于 游戏执行环境322的活动存储器中。游戏数据储存器324还可以存储玩家进度文件。

游戏执行环境322包括执行游戏的部分或游戏的实例所需的客户端310上的游戏 资源。在某些实施例中,客户端310不包括游戏执行环境或用于执行游戏的计算资源。游戏 执行环境322包括活动存储器以及计算和视频处理资源。游戏执行环境322接收游戏控制, 并使游戏根据游戏编程被操纵和进展。在一个实施例中,游戏执行环境322输出已渲染的视 频流,该已渲染的视频流被传送给显示器316。游戏执行环境322可以执行游戏的部分以生 成游戏图像,由视频合成构件321将所述游戏图像与从游戏服务器340接收的已渲染图像组 合。

视频合成构件321将从游戏服务器340接收的已渲染视频游戏图像与由客户端310 渲染的已渲染视频游戏图像合并,以便形成单一图像,该单一图像被输出给显示器316。已 渲染视频游戏图像可以指用来成功地合成服务器和客户端图像的仅单一颜色图像或者颜 色图像和深度缓存数据。视频合成构件可以执行比例换算和其它功能以生成合适的视频输 出。本发明的某些实施例不使用或包括视频合成构件321。

游戏服务器340包括连接管理器342、玩家简档数据储存器344、游戏可用性管理器 346、游戏执行环境348、游戏数据储存器350、游戏管理器352和游戏媒介354。尽管被描绘为 单一盒子,但游戏服务器340可以是包括众多机器的服务器群或甚至几个服务器群。所述服 务器的几个可以充当协调游戏体验的中央服务器的客户端。

连接管理器342在客户端310与服务器340之间建立连接。连接管理器342还可以提 供各种认证机制以确保用户被授权访问由服务器340提供的游戏服务。连接管理器可以在 服务器和虚拟机被添加到游戏会话时为服务器和虚拟机提供安全、加密和认证信息。连接 管理器342还可以分析连接内的可用带宽,并根据需要将该信息提供给构件。例如,视频游 戏图像的分辨率可以被降低以适应有限的带宽。

玩家简档数据储存器344可以结合连接管理器342工作,以便建立和存储玩家信 息。玩家简档的部分可以包括诸如玩家的名称、地址和信用卡信息这样的人口统计和金融 信息,或者其它用于支付或购买由游戏服务提供的游戏和体验的机制。

另外,玩家简档数据储存器344可以存储在单独的游戏内玩家的进度。可以存储玩 家的分数、成就和通过游戏级别的进度。进一步地,玩家简档数据储存器344可以存储诸如 语言偏好的关于单独的玩家偏好的信息。玩家可以访问来自多个客户端的游戏级别信息。 例如,玩家的进度可以从好友的游戏控制台或在玩家的移动设备上被访问。

关于玩家的游戏客户端和网络连接的速度的信息也可以存储在玩家简档数据储 存器344中,并用于优化游戏体验。例如,在一个实施例中,当地理上最近的服务器群繁忙 时,具有较高等待时间因特网连接的玩家可以优先被连接到最近的服务器群,而具有较低 等待时间连接的玩家可以连接到更远的服务器群。这样,具有能最好地处理附加等待时间 的网络连接的玩家被连接到由于他们的位置而产生附加等待时间的服务器群。

玩家简档数据储存器344还可以存储单独的玩家的使用历史。可以存储玩家的购 买游戏、采样游戏或通过不要求购买游戏的游戏服务玩游戏的历史。

游戏可用性管理器346对使用数据进行分析,以便尤其确定特定游戏标题的多少 个备用实例应当是可用的。一般说来,具有高需求的游戏将拥有更多可用的游戏的备用实 例。将游戏加载到活动存储器中以创建备用实例可能花费一两分钟;由此,具有高流失 (churnin)和产出(churnout)的游戏也可能需要更多的游戏的备用实例是可用的。还应 当考虑创建特定游戏标题的备用实例花费的时间。较快加载的游戏可能需要较少备用实 例,因为当需求改变时附加游戏实例可以被更快地生成。换句话说,具有较慢加载时间的游 戏可能需要更多可用的备用游戏。

游戏可用性管理器346还可以提供被游戏管理器352或其它构件用于向特定游戏 池分配服务器资源的信息。分配给特定游戏池的服务器资源包括执行活动游戏实例以及没 有玩家连接到的备用游戏实例所需的资源。当对各个游戏的需求随时间改变时,可以调整 资源向游戏池的分配。进一步地,历史使用数据可以用于预期改变。例如,如果第一个游戏 在10:00pm和午夜之间比第二个游戏被玩得更大量,第二个游戏在白天被玩得更大量,则对 于10:00pm到午夜时间段,可以在第二个和第一个游戏之间切换资源。

游戏可用性管理器346可以为不同数据中心提供不同的备用游戏分配,其是基于 可能由该数据中心为之提供服务的玩家的人口统计的。例如,如果特定游戏在美国西北部 流行,则该游戏标题的更多备用实例可以在位于西北部的数据中心内可用。另一方面,在东 南部更流行的游戏可以在位于东南部的数据中心内具有比较更多的备用游戏实例。

游戏可用性管理器346可以向游戏管理器352以及其它构件提供游戏需求信息。在 一个实施例中,当分配给特定游戏的资源被用尽从而玩家暂时不能玩该游戏时,游戏媒介 354被通知,并且该游戏被暂时从游戏列表中移除。这防止玩家选择游戏和在玩之前有延 迟。可用性分析基于数据中心、一天中的时间和其它事件可以非常粒状的。

游戏执行环境348包括执行游戏的实例所需的游戏资源。这些是由游戏管理器352 和其它构件管理的先前描述的资源。游戏执行环境348包括活动存储器以及计算和视频处 理。游戏执行环境348通过I/O通道接收诸如减少的控制器输入这样的游戏控制,并且使得 游戏根据其编程而被操纵和进展。在一个实施例中,游戏执行环境348输出被传送给游戏客 户端的已渲染视频流。在其它实施例中,游戏执行环境348输出游戏几何结构或其它表示, 其可以与游戏客户端上的本地对象组合以便渲染游戏视频。

游戏数据储存器350存储可用的游戏。游戏可以从该数据储存器被检索并被加载 到活动存储器中以便在游戏会话中使用。游戏数据储存器350可以被描述为被动或辅助存 储器。一般说来,游戏不可以脱离游戏数据储存器350而被玩。然而,在某些实施例中,该辅 助存储器可以用作虚拟存储器,在此情况下,游戏数据储存器350的部分也可以充当活动存 储器。这说明,活动存储器不必由特定硬件构件定义,而由游戏资源为执行游戏而活动地操 纵和访问存储器内的对象的能力定义。

游戏管理器352管理玩家与活动游戏的连接。在一个实施例中,存在针对通过游戏 服务可用的每个游戏的单独的游戏管理器。以单一游戏为例,游戏管理器将把玩家投入请 求的游戏中。在一个实施例中,玩家可以通过游戏管理器352连接到游戏。换句话说,游戏管 理器352可以充当针对单独的游戏实例之间的通信和连接的看门人。当玩家退出游戏时,指 令可以去往游戏管理器352,以便检索该玩家的进度并将其保存到玩家简档数据储存器344 内该玩家的简档中。

游戏媒介354跟踪正在进行的游戏会话,并帮助玩家找到要加入的游戏会话。游戏 媒介354可以生成界面,该界面允许准玩家搜索好友正在参与的游戏会话。媒介354可以允 许玩家搜索具有这样的玩家的活动游戏会话,所述玩家具有类似的技能级别,所述技能级 别例如由玩家等级、游戏进度或在游戏内获得的成就指示。在一个实施例中,媒介354仅返 回这样的游戏会话,所述游戏会话具有对更多玩家可用的空间。

在另一实施例中,媒介354可以返回当前已关闭的游戏会话的列表,所述已关闭的 游戏会话具有在开放可用之前玩家可以期望的估计等候。所述等候可以通过分析针对会话 的流失来计算。所述流失测量玩家离开游戏会话的速率。所述流失可以使用针对同一游戏 标题的全部游戏会话的平均来计算。所述流失可以专用于特定游戏会话。等候时间还可以 考虑等候加入的其他玩家。由此,如果四个玩家正在等候加入平均每30秒一次开放的会话, 则估计的等候时间将是两分钟。媒介354可以管理等候加入游戏的玩家的队列,并在开放变 得可用时将他们添加到该游戏。

媒介354还可以生成开放游戏会话的列表以便玩家加入。甚至在没有准玩家的输 入的情况下,该列表可以被过滤,以便仅列出具有类似级别玩家或另外适合该准玩家的会 话。例如,可以仅列出玩家有玩的许可的游戏标题。在另一实施例中,列出全部游戏,但指示 使玩家知道哪些游戏将需要购买附加的许可。玩家被给予通过界面购买用于玩游戏的许可 的机会。

媒介354可以通过操纵为新玩家加入列出的游戏会话而在杀掉其它的同时努力保 持游戏会话满。玩家以最小化总的计算资源使用的方式被导向到游戏会话。例如,代替具有 两倍之多的半满的游戏会话,可以努力保持玩家的游戏会话满。由此,如果游戏会话接近其 中计算资源可以被移除的玩家门限数量,则该游戏会话可以不被列出,除非是响应于针对 另一玩家的特定查询或对该会话唯一的其它寻找到的特性。这允许游戏会话落在门限之 下,以及允许资源被移除。另一方面,在努力保持游戏会话满时可以首先列出具有仅少量开 放的游戏会话。

由此,媒介354提供搜索工具以帮助玩家找到满足他们的需求的开放游戏会话。当 多个游戏会话满足玩家的需求时,玩家可以以最小化在给定时间运行的游戏会话总数的方 式被添加到游戏会话。

媒介354还可以为了节约网络资源和提供更好游戏体验而为玩家选择游戏会话。 媒介354可以查看玩家的本地能力的特性以便选择合适的游戏会话计算资源。作为示例,玩 家正在使用的控制台的类型或游戏的版本可以影响哪些计算资源被选择用于运行游戏会 话。进一步地,玩家的地理位置影响玩家连接到哪个数据中心以便最小化网络等待时间。媒 介354将使与正在优选数据中心中运行的游戏会话的连接优先化。一般说来,地理上更靠近 的数据中心将具有较少等待时间,但网络状况可以改变。在一个实施例中,对网络状况进行 监视,并且将玩家与在数据中心内运行的对该特定玩家来说有最少等待时间的游戏会话相 匹配。

现在转向图4,根据本发明的实施例提供了示出不同部署状态下的游戏实例的状 态图。图4中所示的状态是示例性的。实施例不限于这些状态。取决于在状态图中期望的粒 度级别,其它中间状态可以是可能的。可替换地,所示的状态可以被压缩。初始,在部署状态 412下,计算机资源在数据中心内被分配410以便创建游戏实例。计算机资源包括被游戏执 行环境使用的处理、存储器和其它硬件。

计算资源的单元可以通过物理机或虚拟机来区分。在一个实施例中,为物理机的 附加服务器被作为计算单元分配给游戏会话。在此情况下,该物理服务器与计算单元或资 源有一对一的关系。在另一实施例中,虚拟机被使用。虚拟机人为地将单一物理计算设备分 离为两个或更多个虚拟机。每个虚拟机能够实现完整服务器的能力,但与一个或多个附加 的虚拟机共享硬件设备的CPU和其它构件的能力。在一个实施例中,单一的真实或虚拟机容 宿多个游戏会话。

真实或虚拟机的能力可能不同。由此,可以将不同尺寸的物理或虚拟机指派给游 戏服务。游戏服务可以根据需要为各个游戏标题选择具有第一能力或第二能力的计算资 源。针对第一游戏标题的游戏会话可以在具有第一能力的服务器上运行,以及针对第二游 戏标题的游戏会话可以在具有第二能力的服务器上运行。在一个实施例中,游戏会话使用 几个虚拟机。在另一实施例中,单一虚拟机运行多个游戏会话。

在正在初始化状态416下,将内容安装在计算机资源上,并且计算机资源被配置用 于玩游戏。所述配置过程可以包括调整关于已分配计算机资源的设置以用于最优地玩特定 游戏标题。针对游戏标题的最优设置可以从表中被检索。

从正在初始化状态416,游戏实例被置入备用状态420下。在备用状态420下,游戏 实例不连接到特定游戏会话或玩家。当存在对新活动会话的需求时,备用状态420下的游戏 实例被置入已指派状态424下。在已指派状态424下,发生附加的配置,游戏实例被指派422 以游戏会话,并且玩家被连接到该游戏实例。在已指派状态424下,玩家偏好和特性可以被 添加到游戏,以便在玩家最后离开游戏的地方开始游戏。当玩家加入游戏实例时,可以反映 玩家成就和力量。在玩游戏持续期间,游戏保持在活动状态426下。

一旦玩游戏结束,则游戏实例转移到正在终止状态428。在正在终止状态428下,可 以存储进度记录以及用于在维持游戏进度的同时允许玩家稍后重新加入游戏的其它游戏 特征。从正在终止状态428,游戏实例移动到已终止状态430。在已终止状态下,可以完成各 种测试以确定游戏代码是否完好并且可被再用。如果在游戏代码或其它配置中检测出错 误,则游戏实例可以转移到隔离状态436。游戏实例可以在对游戏实例检测出错误或其它问 题的任何时间点处转移到隔离状态436。

在一个实施例中,到达已终止状态的全部健康游戏实例被重新开始并移动到正在 初始化状态以及然后备用状态。在一个实施例中,仅备用池中的游戏实例的当前数量被监 视并用于预测最优需求和确定附加实例是否应当被创建。可替换地,当游戏实例到达已终 止状态430时,可以做出是否再用该已终止游戏实例的确定。如果需求指示出已终止的游戏 实例应当被再用,则该游戏实例在返回到备用状态420下的游戏实例的池之前可以转移到 正在初始化状态416。需求计算将在随后被详细描述。当已确定将超过备用游戏实例时,可 以实施池减少过程421以销毁游戏实例。分配来销毁游戏实例的计算机资源然后可以根据 需要跨数据中心进行重新分配。

现在转向图5,根据本发明的实施例图示了备用游戏实例的池。远程游戏环境500 包括通过网络510连接的数据中心520、数据中心540和数据中心560。每个数据中心容宿提 供各种游戏标题的游戏服务。所述游戏服务可以与先前参考图3描述的游戏服务器340类 似。

数据中心520包括四个游戏池。游戏池522和游戏池526容宿游戏标题一的实例。游 戏池530容宿标题二的实例,以及游戏池534容宿游戏标题三的实例。游戏池522包括游戏标 题一的1002个活动实例525和100个备用实例524。游戏池526包括20个备用实例527和100个 活动实例528。游戏池530包括1025个活动游戏实例533和50个备用游戏实例532。游戏池534 包括505个活动实例536和20个备用实例535。

游戏池522和526两者都专用于容宿同一游戏标题。游戏池526是沙盒的示例。沙盒 是专用于特定任务的计算资源的虚拟分区。例如,游戏开发人员或高级成员可以是能够访 问游戏池526内的游戏的仅有个人。对每个游戏池的预期需求可以基于正被评估的特定游 戏池的特性被单独地计算。

数据中心540容宿三个游戏池,所述三个游戏池具有由数据中心520容宿的相同的 三个标题。注意,针对每个标题的备用活动游戏的量与数据中心520或数据中心560内的游 戏池中的那些不同。对游戏的需求可以随数据中心而不同。在一个实施例中,对游戏的每个 池进行需求计算。需求计算考虑容宿游戏池的数据中心内的性能。例如,计算资源在某些数 据中心里比在其它里可以更快地被引入(broughton)。所有其它都相同的情况下,更快将 游戏上线的数据中心为满足需求需要更少备用实例。另外,在不同数据中心处的历史使用 可以用于计算对数据中心内的特定游戏池的需求。

游戏池542包括60个备用实例543和900个活动实例544。游戏池546包括100个备用 实例547和1500个活动备用实例548。游戏池550包括30个备用实例551和500个活动实例 552。

数据中心560容宿三个游戏池。游戏池562包括20个备用实例563和300个活动实例 564。游戏池565包括35个备用实例566和500个活动实例567。游戏池570包括40个备用实例 572和800个活动实例574。

除管理游戏实例之外,关联于游戏实例的计算资源可以根据需要通过对游戏服务 添加和减除计算资源被管理。在游戏服务内,计算资源可以被指派给游戏实例的监视组或 池。网络资源也可以被游戏服务管理,以便为客户端设备和游戏会话之间的通信提供便利。 由此,当附加的计算设备被分配给游戏服务时,网络资源可以被更新,以便将通信适当地路 由到该游戏服务正运行在上面的计算设备。

当向游戏服务分配新资源时,资源可以因为其与已正在为该游戏服务提供服务的 计算资源的最近而被选择。例如,在正运行在多个数据中心上的游戏服务中,位于同一中心 内的计算资源可以比不同服务器群中的计算资源更受偏爱。类似地,与已是游戏会话的部 分的机器在机架内具有紧密接近度或具有紧密虚拟关系的服务器可以比具有不太近关系 的那些更优选。计算资源可以从结束的活动游戏会话被回收利用到可能处在同一游戏阶段 的、正在运行同一标题的活动游戏会话。

预测对游戏实例的需求

如在图5中可见,不同游戏池具有备用游戏的不同的量。如提到的,对特定游戏的需求 可以被预测并用于确定提供多少备用游戏实例。每个游戏以及每个游戏池可以关联于产生 备用游戏的不同最优量的不同特性。为简单起见,需求预测的本说明描述了针对单一游戏 池的计算的需求。在实际实施例中,将对每个游戏池执行类似计算。类似地,计算可以针对 每个数据中心或游戏的其它分组来计算,并被用于预测对与游戏实例相关的资源的需求。 例如,容宿游戏实例所需的计算机资源可以以对游戏实例的需求增长的相同的速率被添 加。

需求计算可以在检测到各种事件时被触发。例如,需求计算可以每当资源进入如 图4中所示的正在部署状态时被执行。资源进入备用状态可以类似地触发需求的重新计算。 取决于重新计算的结果,备用游戏实例可以被终止或被允许保持在备用池中。到达正在初 始化状态、活动状态或隔离状态也可以触发对需求的重新计算。在一个实施例中,周期性地 生成对重新计算需求的请求。在一个实施例中,如果重新计算在最后一个分钟门限量内还 没有另外被触发,则在每个分钟门限量生成请求。

需求计算是对资源分配功能的一个输入。资源分配功能本质上询问当前多少备用 资源应当被创建或销毁。资源分配功能不创建或销毁处在活动状态下的游戏实例。活动游 戏实例在有来自玩家的特定请求时被创建,以及在玩游戏结束时或者可能在检测到错误时 被终止。如图4中所示,活动游戏实例从备用游戏实例被创建。

向资源分配功能的回答可以被描述为资源增量。资源函数可以被描述为所需资源 减现有资源。现有资源可以被定义为处在备用状态下的游戏实例、加处在正在初始化状态 下的游戏、加处在正在部署状态下的游戏实例、加已指定用于备用状态的处在已终止状态 下的游戏的当前计数。在一个实施例中,除非检测到错误,否则全部已终止实例被指定用于 正在初始化状态。由此,注定被销毁或隔离的处在已终止状态下的游戏不被包括在现有资 源变量中。所需资源可以使用预测模型被计算。

预测模型尝试估计在未来的一个点处多少资源将被需要。在一个实施例中,未来 的该点被指定为当前正在开始的部署过程将到达备用状态的点。例如,如果游戏标题的实 例在正在部署状态和备用状态之间转移花费六分钟,则预测模型可以尝试预测在未来的六 分钟时需要的资源。可替换地,需求可以在例如一小时的未来固定时间处被预测。

在一个实施例中,结合预测需求使用资源补充。资源的补充量被添加到预测量的 最优量,以便生成最终的预测量。资源补充可以临时或永久地被建立。例如,临时补充可以 结合可以导致不一般的需求的已知事件被建立。例如,发行日、竞赛或其它促销可以导致需 求达到尖峰。该需求可以通过添加在特定时间内所需量的补充资源来预期。资源补充可以 是编辑地建立的固定量。当预测需求为零时,则资源补充充当最低限。

用于预测需求的函数可以被表述为:当前所需资源等于对新活动游戏实例的请求 的速率乘以平均创建时间。被表述为方程:

#当前所需资源=分配请求的速率*平均创建时间。

在一个实施例中,平均创建时间是游戏实例从正在部署状态转移到备用状态花费 的时间。平均创建时间可以使用对历史数据的分析被计算。历史数据的范围可以改变。在一 个实施例中,平均创建时间使用诸如最后半小时的最近时间段来计算。在另一实施例中,平 均创建时间在诸如最后一周的更长时间段上被计算。

为用数字示出资源预测,假设具有60秒平均创建时间的、每秒10个的对新游戏实 例的分配请求。然后,当前所需资源的#=每秒10个分配请求*60秒平均创建时间=600 个备用游戏实例。由此,如果分配请求的速率和平均创建时间保持恒定,则为满足需求大约 600个游戏实例将需要在备用状态下。

然而,贯穿一天或一天天地,需求不总是恒定的。在一个实施例中,每秒的分配请 求和平均创建时间被基于最近数据频繁地重新计算。例如,需求趋势可以通过使用最后30 秒或某个其它门限时间段内每秒的实际请求被计及;类似地,平均创建时间可以被重新计 算以计及当前状况。

在一个实施例中,波动需求使用可配置的概率被计及,使得在任意时间点处的未 来需求将少于或等于需求预测。在概率计算内,将对备用游戏实例向活动游戏实例的转移 的每个调用称为冲击。冲击的瞬时速率称为到达速率λ。在一个实施例中,概率计算假设λ遵 循马尔科夫过程,并且因此具有泊松分布。

继续可配置概率的阐述,针对游戏实例的平均部署时间为W正在部署。针对游戏实例的 平均活动时间(如根据当实例离开备用直到其在容宿会话之后重新进入备用的时间被测量 的)为W活动。如在时间系列预测的数学域中定义的时间系列被分为系统部分和非系统部分。 系统部分可以被划分为三个分量:级别、趋势和季节性。非系统部分称为噪声。系统分量被 假设为无法观察的,因为其表征底层系列,其通过添加的噪声被观察。级别描述系列的平均 值,趋势是从一个时间段到下一个的系列的改变,以及季节性描述可以在给定系列内多次 被观察到的短期循环行为。

在一个实施例中,从概率计算中省略季节性。当在诸如几分钟或小时的相对短时 间上计算概率时,可以忽略季节性。如先前提到的,诸如比赛或发行场景的基于事件的改变 可以单独地通过建立临时资源补充被计及。可替换地,基于事件的改变可以通过在事件期 间为游戏标题设置最小资源可用性被计及。

在相对短时间段内,在数十分钟或几小时的数量级上,时间系列级别和趋势可以 使用多项式外推来预测。冲击被登记并会聚为一系列观察Z。观察Zt是λ在时间间隔(t-1)到 t上的积分除以t-(t-1);换句话说,时间t-1和t之间每单位时间的冲击的平均数量。观察时 间系列可以针对每个游戏实例被计算Zt-n,…,Zt-2,Zt-1,Zt

时间系列预测算法可以被应用于该时间系列,其帮助预测未来资源需要Et+W部署。换 句话说,对到来速率的估计被用于生成对现在开始的部署平均将在何时被完成的估计。

由于单独的冲击向观察的汇聚是平滑的,所以该估计自身不计及观察内的噪声。 因为λ是马尔科夫过程,已校正的估计可以被计算为CEt+W部署=PPF泊松(Et+W部署;P标题),其中, PPF泊松是针对泊松分布的百分点函数。在每个观察的结尾,CE值可以针对每个游戏池、已计 算的资源增量和已做出的资源分配或调整被计算。

上面提到的观察时间系列可以被外推以平滑需求计算。在一个实施例中,观察的 线性外推被计算,考虑部署时间:EZt+W部署=CEIL(MAX(Zt*W部署,AVG(Zt-n,…,Zt-2,Zt-1, Zt))。最新观察的最大值和整个系列的平均在外推中被使用。这帮助进一步平滑化当系统 中存在少量流量时的曲线。这使算法处理突然短期突增,同时使用在整个系列上的平均使 算法不“忘记”当存在不活动的短时间段时的流量。接下来,也称为‘需求’的CEt+W部署被计算: CEt+W部署=PPF泊松(EZt+W部署+St;P标题)。St是时间t处活动会话的数量。

多项式外推可以通过作为图表上的点来查看观察的时间系列中的观察的集合来 完成,其中时间系列观察在y轴上,以及时间在x轴上。多项式方程可以被构造使得其适合图 表上的点。最小平方方法可以用于使k次多项式方程适合观察的点。这可以通过解矩阵方程 来达到。

假设A是方程的多项式系数的1*k矩阵。

假设Y是观察的值的1*n矩阵。

假设X是范德蒙矩阵:

矩阵方程Y=X*A可以在每次确定对游戏实例的未来需求时被求解。

假设XT表示矩阵X的转置。

(两边乘以XT)。

(两边乘以)。

(化简右边)。

由此,给定观察的集合和对多项式的多少次k的判定,可以针对适合数据集合的最 小平方解出系数。龙格(Runge)现象指出,k越高,观察越近似,但方程振荡得越快。由于实施 例可以使用所述方程来计算未来的预测,所以其存在振荡的风险。进一步地,k次多项式可 以近似具有k-2个拐点的曲线。历史数据显示,对于短时帧(数十分钟),可以使用仅一个拐 点的模型。为最小化振荡的风险,在一个实施例中,k被设置为3。

一旦确定了针对观察的系数,则对λ的估计可以在任意时间点被计算。该估计可以 用于做出到未来W分钟的预测,其中W被连续地测量。针对一组边界条件检查所述预测,以便 在非常低负载时避免“曲棍球棍曲线(hockeysticks)”,以及确保高负载下存在用于极端 拐点的足够缓冲。

在一个实施例中,所述预测可以不高于过去的最高实际观察乘以十,以及所述预 测可以不低于在过去24小时中见到的最高实际观察。一旦已做出预测,则如上面描述那样, 将泊松百分点函数应用于该预测。未来W分钟所需的资源的估计数量然后被计算为:当前正 在等候的会话的数量+活动会话的数量+预测*W/观察窗口尺寸。正在等候的会话可以 包括正在部署的会话、正在初始化的会话和备用会话。

现在转向图6,根据本发明的实施例提供了一种管理远程游戏服务内的游戏实例 的方法600。所述游戏服务器可以与先前描述的游戏服务类似。所述游戏服务向一个或多个 客户端设备提供远程游戏体验。所述游戏体验的全部或部分可以由运行在游戏服务上的代 码提供。所述代码在可以包括一个或多个玩家的游戏会话内运行。运行游戏标题的单一游 戏会话可以被描述为单一游戏实例。所述游戏服务在任一时间可以正在提供数千游戏实 例。所述游戏服务可以使用几个不同的数据中心。方法600对游戏实例进行管理,以确保游 戏实例在玩家想使用其时是可用的。为使游戏实例可用,游戏实例运行在其上的计算资源 也被管理。

在步骤610处,监视针对游戏服务中的游戏标题的游戏实例的量。针对标题的游戏 实例可以在不同监视组中被监视。在一个实施例中,针对特定标题的全部游戏实例一起在 单一数据中心内被监视。每个数据中心可以具有其自己的针对特定游戏标题的监视组。在 某些实施例中,在单一数据中心上可以存在针对单一游戏标题的多个监视组。如先前在图4 中描述的,针对游戏标题的游戏实例可以处在不同状态下。每个状态下的游戏实例的量可 以被监视和跟踪。

在步骤620处,对游戏标题的预期需求被当前地确定。所述预期需求是针对未来的 时间点的。例如,预期需求可以是针对未来12分钟的。在一个实施例中,未来需求针对如果 部署立即被开始的话游戏实例的部署将到达备用状态时的时间点被计算。所述未来需求可 以被看作未来所需的活动游戏会话的量。

在本发明的实施例中,使用处在备用状态下的游戏实例来启动活动游戏。在步骤 630处,确定对满足预期需求最优的、游戏标题的备用实例的数量。这可以称为备用实例的 最优量。在一个实施例中,该最优量通过用活动游戏实例从头开始被创建花费的时间乘以 对活动游戏实例的请求的速率被计算。在另一实施例中,使用备用游戏实例从头开始被创 建花费的时间。如在上面详细描述的,多项式外推可以用于对请求速率的改变进行预期。

在步骤640处,游戏标题的备用实例被动态管理,以便停留在对满足针对未来的预 期需求最优的备用实例的数量的门限之内。在一个实施例中,每当游戏实例到达正在终止 状态时,执行计算以确定是需要更多还是更少的备用实例。如果需要更多,则已终止游戏状 态被重新开始并被指定用于备用状态池。如果需要更少实例,则游戏实例被销毁,并且关联 的计算资源被重新分配给不同游戏池。在另一实施例中,仅对备用池进行评估,并且游戏实 例根据需要被添加到该备用池或从该备用池移除。

现在转向图7,根据本发明的实施例提供了一种管理远程游戏服务内的游戏实例 的方法700。在步骤710处,监视远程游戏服务中的游戏池内的游戏实例的量。如先前关于图 4描述的,针对游戏标题的游戏实例在不同时间可以处在不同状态下。所述监视可以包括多 少游戏实例处在不同状态下。被监视的游戏实例包括至少未连接到玩家的备用实例和连接 到玩家的活动实例。如已提到的,活动实例从备用实例被生成。这允许活动实例被快速生 成,并且避免延迟。

在步骤720处,确定适于满足对活动游戏实例的未来请求的备用实例的最优量。已 描述了确定备用实例的最优量的方法。另外,为计算最优量可以将资源补充添加到预测补 充。所述资源补充可以在预期到需求变更事件时被特别地调整。例如,新游戏的发行、游戏 比赛或游戏改进的发行可能导致需求以这样一种方式临时增大,所述方式不通过基于正常 历史使用的计算被轻松预期。在一个实施例中,提供一个界面以便于开发人员或其他人指 定补充资源的量和补充资源应当被添加的持续期间。

在步骤730处,确定将添加到游戏池中的现有备用实例以等于最优量的附加备用 实例的新量。该新量可以通过从最优量减除现有量被计算。

在步骤740处,在游戏池内启动对所述新量的备用实例的生成。启动新游戏实例可 能需要请求附加计算资源被分配到游戏池。可替换地,附加资源可以已被分配给游戏池,并 且它们现在被投入使用以生成附加的备用游戏实例。

现在转向图8,根据本发明的实施例提供了一种管理远程游戏服务内的游戏实例 的方法800。在步骤810处,检测到触发对游戏实例增量的确定的事件的发生。游戏实例增量 是满足预期需求所需的备用游戏实例的最优量与备用游戏实例的当前水平之间的差。在步 骤820处,游戏标题的备用实例被动态管理,以便根据游戏实例增量调整备用游戏实例的当 前量。游戏实例可以通过添加或减除备用游戏实例被调整。在一个实施例中,备用游戏实例 的水平被损耗耗尽。即,备用游戏实例根据请求变成活动游戏实例,但直到游戏实例增量到 达零之前,新备用游戏实例都不被生成以取代变成活动游戏实例的那些。

本发明的实施例已被描述为说明性的而非限制性的。应当理解,特定特征和子组 合具有实用性,并且可以在不参考其它特征和子组合的情况下被使用。这已被设想,并且在 权利要求书的范围内。

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号