阅读说明：本技术 检测和补偿游戏系统中的显示滞后 (Detecting and compensating for display lag in gaming systems ) 是由 多夫·齐姆林 保罗·莱文蒂斯 本杰明·弗伦克尔 马修·罗杰斯 克林顿·斯马伦 罗伯特·麦库 于 2019-04-01 设计创作，主要内容包括：电子游戏服务器在以当前游戏状态操作的游戏会话期间从位于远程站点的游戏控制器接收输入事件,其中,该输入事件包括在游戏会话期间通过与游戏控制器的用户交互生成的第一命令；确定在用户交互期间在远程站点处显示的第一帧,其中,该第一帧是在服务器接收到输入事件之前的游戏会话期间由服务器发送的多个输出帧之一；确定与第一帧相关联的第一游戏状态,其中,该第一游戏状态是当前游戏状态之前的游戏状态；根据第一命令和第一游戏状态处理游戏玩法输出；基于游戏玩法输出渲染响应帧；以及传输响应帧以用于在远程站点处显示。(The electronic game server receiving an input event from a game controller at a remote site during a game session operating in a current game state, wherein the input event comprises a first command generated by user interaction with the game controller during the game session; determining a first frame displayed at the remote site during the user interaction, wherein the first frame is one of a plurality of output frames transmitted by the server during the game session prior to the server receiving the input event; determining a first game state associated with the first frame, wherein the first game state is a previous game state to the current game state; processing a game play output based on the first command and the first game state; outputting a rendering response frame based on the game play; and transmitting the response frame for display at the remote site.)

检测和补偿游戏系统中的显示滞后

技术领域

本申请总体上涉及计算机技术，包括但不限于用于管理服务器系统以支持与一个或多个实时用户交互式应用相对应的在线交互式会话的方法和系统。

背景技术

连接互联网的电子设备可以支持各种基于云的媒体和娱乐应用。这些应用包括其中服务器将内容流送到用户设备的媒体流送应用、其中用户从用户设备与在服务器上执行的游戏进行交互的游戏应用、以及允许大量用户经由他们的连接互联网的设备彼此同时交互和与云托管的内容和应用进行交互的各种社交媒体和通信应用。在基于云的应用当中，由于以下原因，云游戏呈现一些独特的挑战：游戏名称的广泛地变化的硬件需求；其中可以(例如，由一个玩家、由单个位置中的多个玩家或由多个位置中的多个玩家)玩基于云的游戏的多种拓扑结构；需要可靠地且无延迟地将玩家输入传输到执行游戏会话的游戏服务器并将来自于游戏服务器的游戏会话输出传输到玩家的设备/显示器；关于游戏玩法(gameplay)的速度和响应能力的广泛地变化的玩家预期；以及在某些情况下向观众提供近乎实时的游戏内容的愿望。基于云的游戏的其他挑战涉及为玩家提供一致的游戏玩法体验、无论他们位于何处(例如，靠近服务器或者远离服务器)、他们如何连接到游戏服务(例如，经由快速或慢速互联网连接)、以及他们使用哪种类型的设备玩游戏(例如，通用个人设备或专用游戏控制器)并且查看游戏玩法输出(例如，连接到媒体流送设备的个人设备或媒体设备)。

具体地，需要一种云游戏系统，该云游戏系统支持多个游戏名称的多个游戏会话，其中游戏可以以可接受的延迟和响应能力同时执行，包括对于正在玩同一游戏名称的来自同一或不同位置的多个用户，以及通过各种各样的输入和输出设备以及网络连接。此外，需要一种云游戏系统，该云游戏系统在游戏会话中接收到玩家输入(例如，在最终用户游戏设备/控制器上键入的游戏输入)之后，立即处理用户输入并为所有游戏玩家同时并且以可接受的延迟输出反映玩家输入动作的结果的高清图像。还需要一种游戏系统，在一些情况下，该游戏系统提供游戏玩法活动的高清视频流，以允许观众在相应显示设备上实时跟踪游戏玩法。这样，从在同一位置聚集的用户的自发游戏玩法到来自多个位置的多个用户的在线交互式游戏玩法，向云游戏系统提供有效的游戏处理和输出机制以扩展广泛的游戏设置中的游戏体验将是有益的。

发明内容

本说明书中描述的实施方式针对提供一种游戏应用编程接口(API)和云平台，以实现第三方游戏内容的高效、可移植和低延迟托管。一些实施方式动态地分配云游戏硬件资源，并监视和利用可用于各个最终用户的网络带宽以提供最佳的云游戏体验。一些实施方式提供多个性能层，包括支持具有高清媒体输出和最终用户流的高性能、实时游戏会话的层。一些实施方式支持不同的订阅模型和/或被配置成提供一个或多个并发的实时游戏玩法和/或评论媒体流，其几乎没有延迟或者没有延迟地对应于一个或多个实际游戏流(例如，输出到经由移动应用或基于浏览器的程序参与在线/云游戏会话的用户的客户端的视频流)。在一些实施方式中，经由诸如YouTube的媒体流送站点向一个或多个用户几乎没有延迟或没有延迟地提供并发游戏玩法和/或评论视频。

在本申请的一个方面，一种控制游戏过程的方法在服务器系统处实现，该服务器系统包括一个或多个处理器以及存储一个或多个程序以供一个或多个处理器执行的存储器。该方法包括在以当前游戏状态操作的游戏会话期间，从位于远程站点处的游戏控制器接收输入事件，其中输入事件包括在游戏会话期间通过与游戏控制器的用户交互生成的第一命令；确定在用户交互期间在远程站点处显示的第一帧，其中，第一帧是在服务器接收输入事件之前的游戏会话期间通过服务器发送的多个输出帧之一；确定与第一帧相关联的第一游戏状态，其中第一游戏状态是当前游戏状态之前的游戏状态；根据(i)第一命令和(ii)第一游戏状态来处理游戏玩法输出；基于游戏玩法输出渲染响应帧；以及传输响应帧以用于在远程站点处显示。

在本申请的另一方面，一种在服务器系统处实现一种渲染在线交互式游戏会话的方法，该服务器系统包括一个或多个处理内核以及存储用于由一个或多个处理内核执行的程序的存储器。该方法包括：从与在线游戏会话相关联的第一客户端设备接收第一命令；确定第一命令的类型以及与所述第一命令的类型相关联的第一预期响应延迟；确定网络延迟；基于网络延迟与第一预期延迟的比较来确定第一引入延迟；生成第一数量的中间帧，当以预定帧速率传输时，该第一数量的中间帧占用与第一引入延迟相对应的传输时间；生成反映第一命令的初始结果的第一响应帧；以及以预定帧速率传输第一数量的中间帧紧接着第一响应帧，使得第一响应帧在与第一预期响应延迟相对应的时间在与第一客户端设备相关联的第一媒体设备处接收到。

在本申请的另一方面，一种方法在包括多个虚拟机的服务器系统处实现，每个虚拟机具有相应资源简档。该方法包括：从客户端设备接收建立实时交互式游戏会话的请求，其中该请求是通过与客户端设备的网络连接来接收的；确定与客户端设备相关联的输出设备的设备能力；确定网络连接的连接能力；基于设备能力和连接能力，确定实时交互式游戏会话的一个或多个目标质量参数；基于一个或多个目标质量参数，选择多个虚拟机中的第一虚拟机；与客户端设备建立实时交互式游戏会话；以及根据第一虚拟机的资源简档向实时交互式游戏会话提供用于在实时交互式游戏会话中处理来自客户端设备的输入并且根据所处理的输入生成游戏玩法输出的资源。

在本申请的另一方面，一种方法在服务器系统处实现，该服务器系统包括一个或多个处理器以及存储一个或多个程序以供一个或多个处理器执行的存储器。该方法包括与第一客户端设备建立实时交互式游戏会话，该游戏会话与特定游戏类型相关联；在游戏会话期间监视与第一客户端设备的用户相关联的游戏中的表现数据；根据游戏中的表现数据确定第一客户端设备的用户的游戏玩法体验容忍水平；以及基于游戏玩法体验容忍水平，调整游戏会话资源，该游戏会话资源包括帧速率、分辨率、延迟水平或流送源。

根据本申请的一些方面，服务器系统包括存储器，该存储器存储用于使服务器系统执行上述任何方法的指令。

此外，根据本申请的一些方面，存储在服务器系统的存储器中的指令包括用于使服务器系统执行上述任何方法的指令。

根据本说明书中的描述和附图，其他实施例和优点对于本领域的技术人员而言可以是显而易见的。

附图说明

为了更好地理解各种所描述的实施方式，应结合以下附图参考以下实施方式的描述，在附图中，相同的附图标记指代整个附图中的相应部分。

图1是根据一些实施方式的示例在线交互式游戏环境。

图2是图示根据一些实施方式的游戏环境的示例客户端设备的框图。

图3是图示根据一些实施方式的游戏环境的示例媒体设备的框图。

图4是图示根据一些实施方式的游戏环境的示例服务器的框图。

图5A描绘根据一些实施方式的示例游戏环境。

图5B和图5C描绘根据一些实施方式的示例游戏场景。

图6是根据一些实施方式的游戏玩法过程的流程图。

图7至图12是根据一些实施方式的各种触发帧确定过程的流程图。

图13是根据一些实施方式的延迟检测和补偿过程的流程图。

图14A和14B是根据一些实施方式的响应时间设置的示例表。

图14C是根据一些实施方式的示例设备/网络评估模块。

图15是根据一些实施方式的示例在线交互式游戏环境。

图16是根据一些实施方式的在显示器上渲染的帧的示例序列。

图17和图18是描绘根据一些实施方式的引入的延迟的图。

图19A是根据一些实施方式的示例在线交互式游戏环境。

图19B描绘根据一些实施方式的在线交互式游戏环境的示例截屏。

图20A是根据一些实施方式的示例在线交互式游戏环境。

图20B描绘根据一些实施方式的在线交互式游戏环境的示例截屏。

图21是根据一些实施方式的延迟调整过程的流程图。

图22是根据一些实施方式的资源存储库的示例实施方式。

图23是根据一些实施方式的资源分配过程的流程图。

图24A是根据一些实施方式的用于用户可玩性简档的存储库的示例实施方式。

图24B是根据一些实施方式的资源设置的示例表。

图25是根据一些实施方式的资源调优过程的流程图。

在整个附图中，相似的附图标记指代对应的部分。

具体实施方式

本说明书中描述的实施方式针对提供一种云平台和API，以实现对包括第三方游戏内容的云游戏内容的高效、可移植、低延迟的托管。一些实施方式动态分配云游戏硬件资源(例如，CPU、GPU、存储器、输入/输出和视频流编码器)，并监视和利用对单个最终用户可用的网络带宽，以同时向游戏玩家社区提供最佳的在线游戏体验。一些实施方式提供多个性能层，包括支持具有针对最终用户的高清媒体流的高性能、实时游戏会话的层。一些实施方式支持不同的订阅模型和/或被配置成提供一个或多个并发的实时游戏玩法和/或评论媒体流，其几乎没有延迟或者没有延迟对应于一个或多个实际游戏流(例如，输出到经由移动应用或基于浏览器的程序参与在线/云游戏会话的用户的客户端设备的视频流)。在一些实施方式中，通过诸如YouTube的媒体流送网站向一个或多个用户几乎没有延迟或没有延迟地提供实时游戏玩法和/或评论媒体流。

在云游戏环境的一些实施方式中，服务器系统为实时、交互式游戏会话提供硬件资源，以用于处理玩家输入并生成输出流以向一个或多个玩家，并且可选地，向游戏观众显示。响应于建立实时交互式游戏会话的请求，服务器系统确定请求的客户端设备(即，玩家的控制器设备)的设备能力(例如，硬件和/或软件能力)、网络连接的连接能力(例如，带宽、延迟和/或错误率)、以及游戏会话的一个或多个目标质量参数(例如，输出视频流的分辨率、游戏响应延迟等)，并因此，将其虚拟机之一与实时交互式会话相关联以建立该会话。

在一些实施方式中，针对托管实时、在线和交互式游戏环境的服务器系统中的一个或多个处理内核(例如，GPU内核和编码器内核)管理游戏数据的处理和编码能力(例如，为玩家和/或观众产生输出视频流)。例如，在一些实施方式中，一个或一个以上处理内核与多个处理切片一起操作(例如，每个在内核上在16.67ms内执行)，并且服务器系统将多个处理切片中的每个分配给要在其上执行的多个在线游戏会话的子集。对于处理切片之一，服务器系统确定分时处理排程，使得游戏会话的相应子集共享处理切片的占空比，并根据它们相应的实时数据处理需要并行执行。另外，为了在时间间隔内加速图像编码，服务器系统的编码器不需要等待直到GPU已经使图像帧的所有数据可用为止。而是，在一些实施方式中，一旦由GPU提供用于编码图像帧的一部分所需的信息，就对该部分进行编码，与使图像帧的与已编码的部分无关的其他部分是否GPU可用无关。

另外，服务器系统可以响应于从参加在线游戏会话的用户接收到的用户命令动态地生成多个帧。根据用户命令的类型，服务器系统确定预期的响应延迟、实际的通信和处理延迟以及实际的传输延迟。然后，通过生成反映命令效果的帧集合在在线游戏会话中执行用户命令。当以预定帧速率传输的帧集合占用与实际传输延迟相对应的传输时间，并且可以在与预期响应延迟相对应的时间内在用户的客户端设备处被接收。

图1图示根据一些实施方式的示例在线交互式游戏环境100。在线交互式游戏环境100包括一个或多个客户端设备(例如，客户端设备102和104)。每个客户端设备102执行一个或多个游戏应用。游戏会话可以在特定游戏应用上运行，以允许客户端设备102的用户玩由服务器系统114托管的在线交互式游戏。在一些实施方式中，客户端设备102(例如，主机客户端)被配置成邀请一个或多个其他客户端设备102加入特定游戏应用的游戏场景。这些客户端设备102的游戏会话被同步以显示相同的游戏场景，所述游戏场景可选地具有与它们相应的用户相对应的不同视角。

相反，服务器系统114托管在线交互式游戏平台以支持客户端设备102参加一个或多个游戏应用，其包括特定游戏应用。具体地，服务器系统114包括与客户端设备102相关联的多个用户账户，并且与一个或多个游戏应用中的每个相关联地认证客户端设备的用户。服务器系统114在客户端设备102上渲染并刷新在线交互式游戏的场景，该客户端设备102加入与该场景相关联的对应游戏会话。在一些实施方式中，服务器系统114评估客户端设备102的能力和/或服务器系统114与每个客户端设备102之间的通信连接的质量，并且自适应地生成用于与客户端设备102相关联的游戏会话的同步数据流。通过这些手段，服务器系统114被配置成同时并且以相当低的延迟促进两个或更多个客户端设备102上的在线交互式游戏的同步游戏会话。

在一些实施方式中，服务器系统114包括游戏服务器122和媒体流送服务器124。游戏服务器122被配置成同时为在第一客户端设备102A上运行的在线交互式游戏会话提供两个或更多个媒体流。两个或更多个媒体流包括低延迟流和正常延迟流，所述低延迟流和正常延迟流分别经由一个或多个通信网络112提供给第一客户端设备102A和评论者客户端设备104。可选地，提供正常延迟流，用于教学目的。当第一客户端设备102的用户在第一客户端设备102A上参加游戏会话时，该游戏会话被记录并经由正常延迟流广播给一个或多个观众，即，观众可以在评论者客户端上评论游戏会话。低延迟流对应于在线交互式游戏会话的游戏玩法，并且具有比对应于相关联的评论会话的正常延迟流更快的响应速率和更低的传输延迟。例如，低延迟流具有每秒60帧(fps)的预定义帧速率，并且在每个16.67ms的时间间隔期间向第一客户端设备102A提供至少一个帧，并且正常延迟流具有30fps的预定义帧速率，并在每个33.33ms的时间间隔内向评论者客户端设备104提供至少一个帧。在一些实施方式中，正常延迟流具有比低延迟流低的分辨率。

在一些实施方式中，客户端设备102或104具有集成在其中的用于显示媒体内容的显示屏。在一些实施方式中，客户端设备102或104被耦合到媒体设备106和输出设备108。具体地，客户端设备102或104可以直接(例如，经由蓝牙或其他无线通信链路)、经由本地网络110(例如，Wi-Fi网络)或经由一个或多个通信网络112通信耦合到媒体设备106。在一些实施方式中，客户端设备(102或104)和媒体设备106彼此都是本地的(例如，在同一房间、在同一所房子等)。媒体设备106进一步耦合到一个或多个可以输出视觉和/或音频内容的输出设备108(例如，电视、显示监视器、声音系统、扬声器等)。媒体设备106被配置成将内容输出到输出设备108。在一些实施方式中，媒体设备106是投放设备(例如，Google有限公司的CHROMECAST)或否则包括投放功能的设备。

在一些实施方式中，一个或者多个客户端设备102或104能够与彼此、中央服务器或云计算系统(例如，服务器系统114)和/或被网络连接的其他设备(例如，另一个客户端设备102或104、媒体设备106和输出设备108))进行数据通信和信息共享。可以使用各种自定义或标准无线协议(例如，IEEE 802.15.4、Wi-Fi、ZigBee、6LoWPAN、Thread、Z-Wave、Bluetooth Smart、ISA100.11a、WirelessHART、MiWi等)的任何一种和/或各种自定义或标准有线协议(例如，以太网、HomePlug等)中的任何一种，或包括截至本文档提交之日尚未开发的通信协议的任何其他合适的通信协议来执行数据通信。在一些实施例中，在线交互式游戏环境100包括常规网络设备(例如，路由器)，客户端设备102和104以及它们的对应媒体和输出设备(如果有的话)的集合经由该常规网络设备在本地网络110(例如，局域网)上彼此通信地耦合，并且本地网络110被通信地耦合到通信网络112(例如，广域网和因特网)。在一些实施例中，客户端设备102和104中的每个客户端设备使用一个或多个无线电通信网络(例如，ZigBee、Z-Wave、Insteon、蓝牙、Wi-Fi和/或其他无线电通信网络)与一个或者多个其它客户端设备、相应媒体设备106或者相应输出设备108可选地通信。

在一些实施方式中，客户端设备102彼此远离，即，它们不位于相同房间或甚至建筑物中。可以通过启动游戏应用(例如，图2中的游戏应用228)来开始游戏，以在每个客户端设备102上执行。在一些实施方式中，对于每个客户端设备102，游戏应用与服务器系统114独立建立在线游戏会话116。两个或更多个客户端设备102(例如，102A和102B)的在线游戏会话116彼此相关(例如，因为它们都在游戏应用的相同游戏域中玩游戏)，并且因此，在游戏应用中共享游戏场景。相关的在线游戏会话116彼此同步，并且每个在线游戏会话116可选地以对应于相应客户端设备102的唯一玩家视角示出相同游戏场景。因此，每个客户端设备102的用户可以在相应客户端设备上玩游戏，并影响其他客户端设备102上的在线游戏会话116的输出。

可选地，在一些其他实施方式中，在第一客户端设备102A的游戏应用建立在线游戏会话116之后，通过邀请消息邀请一个或多个第二客户端设备102B加入在线游戏会话116，并且例如，将具有加入在线游戏会话116的链接(例如，URL地址)的消息发送到第二客户端设备102B中的每个。适当的控制器配置被提供给被邀请加入在线游戏会话116的每个第二客户端设备102B。在此应用中，当第二客户端102B加入在线游戏会话116时，服务器系统114为每个单独的第二客户端设备102B创建单独的游戏会话。相应的第二客户端设备102B的每个单独的游戏会话116与第一客户端设备102A的游戏会话116同步并且与该游戏会话116共享相同的场景，但是可以具有与相应第二客户端设备102B相对应的唯一玩家视角。在每个第二客户端设备102B已经接收到适当的控制器配置并加入在线游戏会话116(更准确地，开始其相关的在线游戏会话116)之后，用户可以在相应第二客户端设备102B上玩游戏并且影响在其他客户端设备102上运行的在线游戏会话116的输出。

客户端设备102是包括并且可以运行包括游戏应用的一个或多个不同用户应用的设备。在一些实施方式中，客户端设备102是智能手机、平板设备、膝上型计算机、台式计算机或多媒体设备。在一些实施方式中，客户端设备102是专用的游戏控制器，其包括被配置成当激活或以其他方式操纵时控制游戏玩法的某些方面的游戏控件(例如，一个或多个按钮、操纵杆、触摸屏开供性(affordance)、运动控件、压力控件、视觉控件、音频控件和/或其他触觉界面)。在一些实施方式中，客户端设备102包括被配置成与媒体设备106结合操作的一个或多个用户应用。在一些实施方式中，应用包括用于将客户端设备102与媒体设备106配对并且配置媒体设备106的媒体设备应用。应用还包括可以将相关联的内容投放到媒体设备106的一个或多个应用。在一些实施方式中，通过(例如，经由本地网络)直接将数据/内容发送到媒体设备106和/或通过将媒体设备106定向到从其媒体设备106能够流送或者以其它方式接收数据/内容的远程位置(例如，到服务器系统处的某个位置的URL或其他链接)，应用将数据和/或内容投放到媒体设备106。媒体设备106从应用和/或远程位置接收数据/内容，并将与接收到的数据/内容相对应的视觉和/或音频内容输出到输出设备108。因此，在客户端设备102上运行的游戏应用、远程服务器系统114和媒体设备106之间建立在线游戏会话116。

在一些实施方式中，作为链接相关的在线游戏会话116的过程的一部分，服务器系统114评估每个对应客户端设备102的能力和/或服务器系统114与客户端设备102之间的通信连接的质量。在一些实施方式中，服务器系统114测量客户端设备102和服务器系统114之间的网络延迟。如果所测量到的延迟高于阈值并且较低延迟的连接可用，则服务器系统114可以建议客户端设备102更改为较低延迟的连接，或邀请客户端设备102的用户将客户端设备102更改为较低延迟的连接。例如，如果客户端设备102在蜂窝无线连接118上，并且本地网络可用，则服务器系统114可以建议客户端设备102应该通过可用本地网络进行连接。在一些实施方式中，延迟阈值要求在游戏之间有所不同。例如，一些游戏(例如，动作游戏)在较低延迟的连接上体验最好，而其他一些游戏(例如，在线棋盘游戏或纸牌游戏)对延迟的要求不高。鉴于与不同类型的游戏相关联的这些不同要求，服务器系统114可以做出连接推荐。

在一些实施方式中，作为开始或加入游戏会话116的客户端设备102的一部分，服务器系统114与客户端设备102通信以在客户端设备102上设置控制器(例如，游戏控制器配置和/或接口)。在一些实施方式中，这包括服务器系统114评估客户端设备102是否具有控制器所需的资源和通信能力。取决于客户端设备102处的可用资源、连接质量和游戏要求，可以在客户端设备102处不同地实现控制器。在一些实施方式中，可以使用基于网页的控制器界面来玩游戏。例如，用于游戏的控制器接口可以被嵌入在网页中，并且该网页被渲染在客户端设备102上的网页浏览器中。可替选地，在一些实施方式中，标准化控制器被实现在非特定于游戏或直接与游戏相关联的预定义应用(例如，投放设备应用，诸如Google有限公司的CHROMECAST或GOOGLE CAST，或其他媒体设备应用)中，或客户端设备102的操作系统中。例如，客户端设备102上的设备操作系统或预定义的应用可以具有控制器子模块。控制器子模块包括一个或多个标准化控制器配置、模板等。每个标准化控制器配置将控制器子模块配置成以一些方式利用客户端设备102上的输入设备和/或传感器来实现虚拟控制器。使用的标准化控制器配置可能随游戏和/或客户端设备的类型而变化。

此外，在一些实施方式中，游戏具有可以在控制器子模块上实现的特定控制器配置。这样的配置可以被存储在服务器系统114处并且被传输到客户端设备102，作为客户端设备102加入或开始在线游戏会话116的过程的一部分。在一些实施方式中，特定控制器配置可以是完全自定义控制器或标准控制器和自定义控制器的混合。另外，在一些实施方式中，游戏需要与该游戏相关联的特定应用。例如，游戏可能需要专门与该游戏相关联的控制器应用。在一些实施方式中，可以指导客户端设备102下载特定应用或预定义的应用作为开始或加入会话116的一部分。例如，如果客户端设备102还没有预定义的应用(和控制器子模块)或者与游戏相关联的特定应用，并且这样的应用被需要用于玩游戏，则服务器系统114指示客户端设备102提示其用户需要下载并向用户请求许可继续进行。

在一些实施方式中，服务器系统114存储与托管在服务器系统114上的一个或多个游戏应用中的每个(例如，图2的游戏应用228)的用户账户相关联的用户信息。用户信息的示例包括但不限于，用户账户信息(例如，标识和密码)、成员资格类型、偏好和活动历史。在一些实施方式中，服务器系统114存储与在客户端设备102上参加的在线游戏会话相关联的会话数据。每个在线游戏会话的会话数据的示例包括但不限于帧速率、渲染规范、正常延迟要求、GPU分配信息、编码器分配信息、相关会话的标识以及最新状态信息。

在一些实施方式中，服务器系统114提供游戏API和云平台，以启用在线游戏会话116中使用的第三方游戏内容的高效、便携式、低延迟托管。在一些实施方式中，游戏API和云平台由服务器系统114启用，该服务器系统114进一步包括下述中的一个或者多个：前端服务器134、媒体流送服务器124、游戏服务器122和一个或多个第三方内容服务器136。在一些实施方式中，游戏API平台由游戏服务器122创建和/或托管，并结合前端服务器134和内容服务器136一起启用游戏会话116。前端服务器134被配置成向游戏会话116的用户提供服务，并且管理用户的账户。可选地，用户经由前端服务器134订阅游戏服务。内容服务器136提供与游戏会话116有关的游戏内容。

在一些实施方式中，前端服务器134管理与客户端设备102和104相关联的用户账户，例如，通过用户账户对一个或多个在线交互式游戏的成员资格的订阅。在客户端设备102登录其相应的用户账户并加入其在线游戏会话116之后，游戏服务器122设置游戏会话116，并通过从内容服务器136中获取游戏内容，将游戏内容发送到在客户端设备102上执行的游戏应用，识别用户请求或动作，响应于用户请求或动作为客户端设备102渲染游戏玩法输出，以及在相应游戏会话116期间存储游戏状态数据，来管理相应客户端设备102的每个特定游戏会话116。游戏服务器122包括一个或多个处理单元(例如，CPU 138、GPU 140和编码器142)、存储器146和数据缓冲器144，其临时存储GPU 140生成的多媒体内容并且将多媒体内容提供给编码器142以进行进一步的编码(例如，标准化或压缩)。数据缓冲器144可选地集成在存储器146中或独立于存储器146。

在一些实施方式中，游戏服务器122动态分配云游戏硬件资源(例如，GPU 140和编码器142)，并且监视和利用可用于个人最终用户的网络带宽以提供最佳的云游戏体验。在一些实施方式中，游戏服务器122提供多个性能层，包括利用高清视频/媒体流支持高性能、实时游戏会话的层。在一些实施方式中，游戏服务器122支持不同的订阅模型和/或被配置成提供一个或多个并发的实时游戏玩法和/或评论媒体流，其几乎没有延迟或没有延迟地对应于一个或多个实际游戏流(例如，输出到经由移动应用或基于浏览器的程序参与在线/云游戏会话的用户的客户端设备的视频流)。具体地，游戏服务器122被配置成生成用于游戏玩法的并发媒体流和评论视频，并且向媒体流送服务器104提供用于并发游戏玩法的评论视频。经由媒体流送网站，诸如YouTube，向一个或多个用户几乎没有延迟或没有延迟地提供此类评论视频。媒体流送站点可选地由媒体流送服务器124管理。

一些实施方式使得能够结合游戏竞赛来进行公共事件的托管。例如，结合基于已托管的游戏的多玩家游戏事件或竞赛，由游戏服务器122托管的云游戏站点可以可选地经由媒体流送服务器123将以下广播或流送到特定评论者客户端设备104：(a)一个或多个并发辅助或补充媒体流，包括相关联的评论曲目/流，(b)来自于不同竞争者的视角的游戏流，重点流基于云服务器分析和/或对与游戏事件相关联的多个游戏会话的评分而显示特别引人注目的游戏动作，(c)反映一个或多个活跃玩家的游戏玩法会话116的一个或多个游戏视点流，和/或(d)来自一个或多个活跃玩家和/或评论者的教学曲目，可能包括主动玩家发送给云游戏服务器系统114的实时画中画(PIP)视频以及他们相应的游戏玩法响应。

根据一些实施方式，可以由内容服务器136有效地托管的第三方内容的示例包括但不限于体育游戏、赛车游戏、角色扮演游戏(RPG)和第一人称射击(FPS)游戏。这些游戏的不同实例可能基于不同的相关联延迟要求和预期、输出视频分辨率和游戏服务器计算工作量和视频编码/流传输资源、以及网络带宽而具有广泛变化的云硬件要求和网络(例如，以确保最佳的用户游戏体验-在某些情况下与不同的订阅性能层一致)。

在一些实施方式中，前端服务器134提供账户管理API和/或软件模块，该账户管理API和/或软件模块监视游戏玩法活动和订户的相关请求(例如，最终用户邀请其他玩家参与游戏会话，升级他们的游戏工具、和/或游戏性能的请求)，并且通过API将相关联的信息传输到第三方内容服务器136或使API可用该相关联的信息，以使内容提供商能够跟踪他们的订户和/或关注者的设置(包括但不限于计费信息、游戏中信用、订阅级别等)。在一些实施方式中，托管的内容的内容提供商可以经由相同的托管平台为托管的内容提供一个或多个不同的订阅模型。在一些实施方式中，向用户(例如，游戏服务的订户)授予对由内容提供商在托管平台上提供的所有游戏的无限访问和游戏玩法。在一些实施方式中，用户被授予对内容提供商在托管平台上提供的一个或多个特定游戏特许经营权(例如，特定的足球或第一人称射击特许经营权)的无限制访问和游戏玩法。在一些实施方式中，订阅是为了用户的有限参与-可以根据游戏玩法时间、最终用户所委托的硬件资源级别或最终用户设备类型/位置来限制参与。在一些实施方式中，账户API和模块配置和监视游戏玩法会话，并且使内容提供商能够根据其最新订阅信息来跟踪各个订户的游戏活动，甚至在活动游戏玩法期间也是如此。

服务器系统114启用云功能，该云功能允许用户四处移动，例如，悬挂在第一客户端设备102上执行的第一游戏会话的第一游戏流，并且在第二客户端设备102的第二游戏会话上重新启动第一游戏流以继续第一游戏会话。服务器系统114还大规模地支持多个玩家，并提供更丰富、更持久的基于云的世界。服务器系统114使用基于云的系统来存储与相同用户的不同游戏会话116或不同用户的不同游戏会话116有关的会话数据。

服务器系统114在多个客户端设备102和104上渲染游戏内容，所述多个客户端设备包括但不限于移动电话、平板计算机、台式计算机和电视。可选地，游戏内容被动态地调整以符合这些客户端设备102和104的规范。在一些实施方式中，客户端设备102和104具有有限的存储能力或没有存储能力，因为游戏API平台提供即时访问并且要求没有或几乎没有的用户设备存储(例如，用户可以在5秒钟内开始播放并节省250GB的控制台硬盘空间)。

除了游戏内容之外，服务器系统114还向客户端设备102和104流送附加内容，例如，新的联赛名册、统计数据以及对早期标题的预览访问，其被可选地定期更新(例如，随时更新、每天或每小时升级)。在一些实施方式中，附加内容包括互联网搜索或数据库搜索的搜索结果。

在一些实施方式中，服务器系统114支持与游戏应用相关联的实时在线社区。用户(例如，服务的订户)整天参与对应游戏API平台上的现场事件、锦标赛或活动。现场事件、锦标赛或活动的示例包括观看其他用户玩的现场游戏会话、将成就发布到公共域(例如，YouTube)、以及得到现场提示和指导视频。例如，响应于用户动作，游戏服务器122提供两个或更多个实时流130和132。在将第一游戏流130保持在游戏玩家的第一客户端设备102A的第一游戏会话116上的同时，服务器系统114还向(例如，订户的)一个或多个其他客户端设备104广播第二实时评论流132(例如，YouTube流)。第二实时评论流132允许用户与听众分享他的或者她的游戏体验。可选地，第二实时流是玩家的第一客户端设备102A的屏幕的再现。服务器系统114可以获得其中玩家解释第一游戏会话116的音频流，或者播放并解释第一游戏会话116的玩家的视频流。在为听众播放第二实时评论流132的同时为听众可选地播放音频流。视频流可选地在第二实时评论流132中的嵌入式窗口中播放。

一些实施方式提供移动游戏，允许用户将他或她的所预期的游戏带到任何位置或者客户端设备。例如，用户可以在他或她的通勤中在移动设备102A上开始在线游戏会话116，然后在膝上型计算机102B上在他或她的目的地无缝地恢复游戏会话116。而且，在一些实施方式中，基于当游戏会话116在不同设备102之间切换时用户可用的不同客户端设备资源，服务器系统114(具体地，游戏服务器122)可以动态地部署不同的硬件资源集合(例如，GPU 140和编码器142)以基于不同的最终用户当前设备资源(例如，客户端硬件能力和网络带宽)来优化用户的游戏体验。

在服务器系统114中，前端服务器134和游戏服务器122可以具有相应用户账户系统。在示例中，用于前端服务器134的用户账户系统被用于管理对特定游戏内容和服务的订阅，并且用于游戏服务器122的用户账户系统(例如，YouTube或Google账户)被用于管理游戏体验(例如，渲染游戏内容以满足特定游戏标准)和许多其他目的。在一些实施方式中，这两个用户账户系统共享客户和使用数据(例如，社交、朋友、存在、认证、账户信息、账单信息)。而且，内容前端服务器134提供坐落在由游戏服务器122启用的技术层的顶部上的服务层。在一些实施方式中，游戏内容服务器管理用于访问他们的内容的附加用户账户系统。可选地，用于游戏内容的附加用户账户系统与用于管理用户订阅的前端服务器134的用户账户系统集成在一起。

图2是图示根据一些实施方式的游戏环境100的示例客户端设备102的框图。贯穿本申请，除非另有说明，否则对客户端设备102的引用对应于参考图1描述的客户端设备102A、102B和104中的一个或多个。客户端设备102的示例包括但不限于移动电话、平板计算机、膝上型计算机、台式计算机和可穿戴个人设备。在一些实施方式中，客户端设备102是专用的游戏控制器，其包括游戏控制输入210(例如，一个或多个按钮、操纵杆、触摸屏元件、运动控件、压力控件、视觉控件、音频控件和/或配置成在激活时控制游戏玩法的某些方面的其它触觉接口元件)。客户端设备102包括一个或多个处理单元(CPU)202、一个或多个网络接口204、存储器206以及用于互连这些组件(有时称为芯片组)的一个或多个通信总线208。客户端设备102包括促进用户输入的一个或多个输入设备210，诸如键盘、鼠标、语音命令输入单元或麦克风、触摸屏显示器、触敏输入板、手势捕获相机、或其他输入按钮或控件。此外，一些客户端设备200可以使用麦克风和语音识别或相机和手势识别来补充或替换要求接触的接口(例如，键盘和按钮)。在一些实施方式中，客户端设备102包括一个或多个相机、扫描仪或照片传感器单元，用于捕获例如印制在电子设备上的图形系列代码的图像。在一些实施方式中，客户端设备102包括能够呈现用户界面和显示内容的一个或多个输出设备212，包括一个或多个扬声器和/或一个或多个可视显示器。可选地，客户端设备102包括位置检测设备214，诸如GPS(全球定位卫星)或其他地理位置接收器，用于确定客户端设备102的位置。客户端设备102还可以包括接近度检测设备215，例如，IR传感器，用于确定媒体设备106和/或其它客户端设备102的接近度。客户端设备102还可以包括一个或多个传感器213(例如，加速度计、陀螺仪等)，用于感测客户端设备102的运动、定向、和其他参数，其可以用作输入(例如，用于在上面描述的输入210)。

存储器206包括高速随机存取存储器，诸如DRAM、SRAM、DDR RAM或其他随机存取固态存储器设备；并且可选地，包括非易失性存储器，诸如一个或多个磁盘存储设备、一个或多个光盘存储设备、一个或多个闪存设备或一个或多个其他非易失性固态存储设备。存储器206可选地包括与一个或多个处理单元202远程定位的一个或多个存储设备。存储器206或可替选地，存储器206内的非易失性存储器，包括非暂时性计算机可读存储介质。在一些实施方式中，存储器206或存储器206的非暂时性计算机可读存储介质存储下述程序、模块和数据结构或其子集或超集：

·操作系统216，包括用于处理各种基本系统服务和用于执行硬件相关任务的过程；

·网络通信模块218，用于经由一个或多个网络接口204(有线或无线)和诸如互联网、其他广域网、局域网、城域网等的一个或多个网络110和/或112将客户端设备102连接到其他设备(例如，服务器系统114、媒体设备106和其他客户端设备102)；

·用户界面模块220，用于能够经由一个或多个输出设备212(例如，显示器、扬声器等)在客户端设备102处呈现信息(例如，用于呈现应用、窗口小部件、网站和其网页、和/或游戏、音频和/或视频内容、文本等的图形用户界面)；

·输入处理模块222，用于检测来自一个或多个输入设备210之一的一个或多个用户输入或交互，并解释检测到的输入或交互；

·输入事件报告模块223，用于向服务器系统114报告输入标识和/或时间戳信息，以用于延迟计算；

·Web浏览器模块225，用于导航、请求(例如，经由HTTP)和显示网站和其网页，包括用于加入会话116的web界面；

·媒体设备应用226，用于与媒体设备106进行交互，包括登录到与媒体设备106相关联的用户账户，如果与该用户账户相关联控制媒体设备106，以及编辑和评论与媒体设备106相关联的设置和数据；

·游戏应用228，用于在客户端设备102上提供游戏，包括促进对应游戏玩法和促进其他玩家的邀请；

·游戏控制器模块230，用于向游戏应用228提供游戏玩法输入界面；

·数据下载模块231，用于从服务器系统114和其他内容主机和提供商下载数据(例如，游戏控制器配置456(图4)、游戏应用228和其他应用、对模块和应用以及存储器206中的数据的更新)；和

·客户端设备数据232，至少存储与游戏应用228和其他应用/模块相关联的数据，包括：

ο客户端设备设置234，用于存储与客户端设备102本身相关联的信息，包括公共设备设置(例如，服务层、设备模型、存储容量、处理能力、通信能力等)；

ο媒体设备设置236，用于存储与媒体设备应用226的用户账户相关联的信息，包括账户访问信息以及设备设置(例如，服务层、设备模型、存储容量、处理能力、通信能力等)的信息中的一个或多个；

ο游戏应用设置238，用于存储与游戏应用228的用户账户相关联的信息，包括账户访问信息、游戏中用户偏好、游戏玩法历史数据和关于其他玩家的信息中的一项或多项；

ο游戏控制器配置240，用于存储与用于游戏应用228的游戏控制器模块230的配置(例如，从图4的游戏控制器配置456接收的配置)相关联的信息；以及

ο位置/接近度数据242，包括与客户端设备102以及媒体设备106中的任何一个的存在、接近度或位置相关联的信息。

在一些实施方式中，游戏控制器模块230是媒体设备应用226或存储器206中的另一应用的一部分(例如，子模块)。在一些实施方式中，游戏控制器模块230是操作系统216的一部分。在一些实施方式中，游戏控制器模块230是不同的模块或应用。

在客户端设备102的一些实施方式中，媒体设备应用226(以及对应的媒体设备设置236)和游戏应用228(以及对应的游戏应用设置238)是可选的。取决于邀请客户端设备102加入的特定游戏，不需要玩媒体设备应用226和游戏应用228。如果为了玩游戏需要这些应用中的任何一个(例如，游戏使用媒体设备应用226中的游戏控制器模块230)，并且该应用不在存储器206中，则可以提示客户端设备102下载该应用。

上面识别的元素中的每个可以被存储在一个或多个前面提到的存储设备中，并且对应于用于执行上述功能的指令集。上面识别的模块或程序(即，指令集)不需要被实现为单独的软件程序、过程、模块或数据结构，并且因此这些模块的各种子集可以在各种实施方式中被组合或以其他方式重新排列。在一些实施方式中，存储器206可选地存储在上面识别的模块和数据结构的子集。此外，存储器206可选地存储以上未描述的附加模块和数据结构。

图3是图示根据一些实施方式的游戏环境100的示例媒体设备106的框图。媒体设备106通常包括一个或多个处理单元(CPU)302、一个或多个网络接口304、存储器306以及用于互连这些组件(有时称为芯片组)的一个或多个通信总线308。可选地，媒体设备106包括接近度/位置检测单元310，诸如IR传感器，用于确定客户端设备102的接近度。

存储器306包括高速随机存取存储器，诸如DRAM、SRAM、DDR RAM或其他随机存取固态存储器设备；并且可选地包括非易失性存储器，诸如一个或多个磁盘存储设备、一个或多个光盘存储设备、一个或多个闪存设备或一个或多个其他非易失性固态存储设备。存储器306可选地包括与一个或多个处理单元302远程定位的一个或多个存储设备。存储器306或可替选地存储器306内的非易失性存储器包括非暂时性计算机可读存储介质。在一些实施方式中，存储器306或存储器306的非暂时性计算机可读存储介质存储以下程序、模块和数据结构或其子集或超集：

·操作系统316，包括用于处理各种基本系统服务和用于执行硬件相关任务的过程；

·网络通信模块318，用于经由一个或多个网络接口304(有线或无线)和一个或多个网络110和/或112(诸如互联网、其他广域网、局域网、城域网、有线电视系统、卫星电视系统、IPTV系统等)将媒体设备106连接到其他计算机或系统(例如，服务器系统114和客户端设备102)；

·内容解码模块320，用于解码从一个或多个内容源(例如，从游戏会话116输出的服务器系统114)接收到的内容信号，并且将解码后的信号中的内容输出到耦合到媒体设备106的输出设备108；

·接近度/位置确定模块322，用于基于接近度检测单元310检测到的或服务器系统114提供的接近度相关信息，确定客户端设备102的接近度；

·媒体显示模块324，用于控制媒体显示；以及

·显示事件报告模块325，用于向服务器系统114报告显示事件标识和/或时间戳信息，以用于延迟计算；

·延迟计算模块326，用于基于游戏环境中的其他组件报告的延迟数据334计算延迟值；

·媒体设备数据328，用于至少存储包括下述的数据：

ο媒体设备设置330，用于存储与媒体设备应用的用户账户相关联的信息，包括账户访问信息和设备设置信息(例如，服务层、设备模型、存储能力、处理能力、通信能力等)中的一项或多项；

ο位置/接近度数据332，包括与客户端设备102以及媒体设备106中的任何一个的存在、接近度或位置相关联的信息；以及

ο延迟数据334，其包括延迟计算模块326计算延迟值所必需的信息(例如，时间戳)。

上面识别的每个元素可以存储在一个或多个前面提到的存储器设备中，并且对应于用于执行上述功能的指令集。上面识别的模块或程序(即，指令集)不需要被实现为单独的软件程序、过程、模块或数据结构，并且因此这些模块的各种子集可以在各种实施方式中被组合或以其他方式重新排列。在一些实施方式中，存储器306可选地存储以上识别的模块和数据结构的子集。此外，存储器306可选地存储以上未描述的附加模块和数据结构。

图4是图示根据一些实施方式的游戏环境100的服务器系统114中的示例服务器的框图。服务器系统114通常包括一个或多个处理单元(例如，CPU 138、GPU 140和编码器142)、一个或多个网络接口404、存储器146以及用于互连这些组件(有时称为芯片组)的一个或多个通信总线408。服务器系统114可以可选地包括促进用户输入的一个或多个输入设备410，诸如键盘、鼠标、语音命令输入单元或麦克风、触摸屏显示器、触敏输入板、手势捕获相机或其他输入按钮或控件。此外，服务器系统114可以使用麦克风和语音识别或相机和手势识别来补充或替换键盘。在一些实施方式中，服务器系统114可选地包括一个或多个相机、扫描仪或照片传感器单元，用于捕获例如印制在电子设备上的图形系列代码的图像。服务器系统114还可以包括能够呈现用户界面和显示内容的一个或多个输出设备412，包括一个或多个扬声器和/或一个或多个可视显示器。

存储器146包括高速随机存取存储器，诸如DRAM、SRAM、DDR RAM或其他随机存取固态存储器设备；并且可选地包括非易失性存储器，诸如一个或多个磁盘存储设备、一个或多个光盘存储设备、一个或多个闪存设备或一个或多个其他非易失性固态存储设备。存储器146可选地包括与一个或多个处理单元远程定位的一个或多个存储设备。存储器146或可替选地存储器146内的非易失性存储器，包括非暂时性计算机可读存储介质。在一些实施方式中，存储器146或存储器146的非暂时性计算机可读存储介质存储下述程序、模块和数据结构或其子集或超集：

·操作系统416，包括用于处理各种基本系统服务和用于执行硬件相关任务的过程；

·网络通信模块418，用于通过一个或多个网络接口404(有线或有线)和一个或多个网络110和/或112(诸如互联网、其他广域网、局域网、城域网等)将服务器系统114连接到其他设备(例如，服务器系统114中的各种服务器、客户端设备102和媒体设备106)；

·用户界面模块420，用于能够在客户端设备102处呈现信息(例如，用于呈现应用、窗口小部件、网站和其网页和/或游戏、音频和/或视频内容、文本等的图形用户界面)；

·媒体设备模块422(可选)，被执行以提供服务器端功能，用于与媒体设备106相关联的设备供应、设备控制和用户账户管理；

·接近度/位置确定模块424，用于基于客户端设备102和媒体设备106中的任何一个的位置信息来确定客户端设备102与媒体设备106的接近度；

·游戏服务器模块426，用于提供与游戏(例如，游戏应用228)相关联的服务器端功能，包括但不限于设置游戏会话、存储会话状态数据和其他与游戏相关的数据、处理来自客户端设备102的游戏玩法输入、以及响应于游戏玩法输入而渲染游戏玩法输出；

·媒体流送服务器模块438，用于托管媒体流送站点，接收与在线游戏会话相关联的并发辅助或补充媒体流，并且将并发媒体流提供给客户端设备104以与在相同客户端设备104或不同客户端设备102的游戏应用228上正在执行的在线游戏会话并发显示；

·前端服务器模块440，用于管理与客户端设备102相关联的用户账户，例如，通过用户账户对一个或多个在线交互式游戏的会员资格的订阅，能够进行用于订户请求转发到游戏服务器模块426的到订户的服务，并监控游戏玩法活动和订户的相关请求；

·媒体内容服务器模块442，用于提供对由一个或多个第三方内容提供商托管的游戏内容的访问；

·设备/网络评估模块444，用于评估客户端设备102的设备和网络能力，包括但不限于评估与客户端设备102的连接的网络带宽以及评估客户端设备102是否具有玩游戏所需的模块或应用；

·数据传输模块446，用于向客户端设备102提供数据(例如，游戏控制器配置456、软件更新等)；以及

·服务器系统数据448，包括：

ο客户端设备设置450，用于存储与客户端设备102相关联的信息，包括公共设备设置(例如，服务层、设备模型、存储容量、处理能力、通信能力等)；

ο媒体设备设置452(可选)，用于存储与媒体设备应用422的用户账户相关联的信息，包括账户访问信息和设备设置信息(例如，服务层、设备型号、存储容量、处理能力、通信能力等)中的一个或者多个；

ο位置/接近度数据454，包括与客户端设备102以及媒体设备106中的任何一个的存在、接近度或位置相关联的信息；

ο游戏控制器配置456，用于存储各种游戏的控制器配置；以及

ο用户信息458，用于存储与托管在服务器系统114上的一个或多个游戏应用(例如，图2中的游戏应用228)中的每个的用户账户相关联的信息，包括例如用户账户信息(例如，标识和密码)、会员类型、偏好和活动历史；以及

ο游戏会话事件日志460，用于存储与游戏会话相关联的事件数据(例如，游戏状态数据、输入事件、显示事件、其他与游戏相关的数据)，包括例如第一游戏会话的数据460-1和第二游戏会话的数据460-2，其中每个游戏会话的会话数据460包括但不限于帧速率、渲染规范、正常延迟要求、GPU分配信息、编码器分配信息、相关会话的标识、与相应游戏会话相关联的最新状态信息、输入事件的日志和显示事件的日志；

ο响应时间设置462，用于存储各种用户命令类型的预期延迟值；

ο资源存储库464，用于存储虚拟机资源简档和容器图像；以及

ο资源设置466，用于基于用户容忍水平来存储可用资源的配置；和

·数据缓冲器144，用于与一个或多个输出媒体流相关联地临时存储由GPU 140生成的游戏性多媒体内容。

在一些实施方式中，游戏服务器模块426包括以下程序、模块或其子集或超集：

·意图确定模块428，用于将用户输入传输时间(例如，在客户端设备102和服务器系统114之间)与显示传输时间(例如，在媒体设备106和服务器系统114之间)进行比较，并且通过将输入事件与相应的触发帧进行匹配确定用户的意图背后的特定输入；

·延迟调整模块430，用于确定GPU 140在(i)在接收到用户输入时正在处理的当前帧与(ii)示出接收到的输入的结果的响应帧之间插入的中间帧的数量：

·资源分配模块432(在本文中可选地称为“会话协调器”)，用于从端点(例如，控制器102)接收会话请求并确定哪个资源指配给该会话；和

·资源调优模块434，用于确定特定用户的延迟容限。

在一些实施方式中，存储器146还包括数据缓冲器144，其被配置成将编码器142耦合到GPU 140。具体地，数据缓冲器144与一个或多个输出媒体流相关联地临时存储由GPU140生成的游戏玩法多媒体内容，使得编码器142可以从数据缓冲器144中检索游戏玩法多媒体内容，并将检索到的内容编码到一个或多个媒体流中，例如，用于标准化、速度或压缩。

上面识别的元素中的每个可以被存储在一个或多个前面提到的存储器设备中，并且对应于用于执行上述功能的指令集。上面识别的模块或程序(即，指令集)不需要被实现为单独的软件程序、过程、模块或数据结构，并且因此这些模块的各种子集可以在各种实施方式中被组合或以其他方式重新排列。在一些实施方式中，存储器146可选地存储以上识别的模块和数据结构的子集。此外，存储器146可选地存储以上未描述的附加模块和数据结构。

检测和补偿显示滞后

上述基于云的游戏平台的各种实施方式提供许多好处(例如，可移植、可扩展性、效率、易于访问和控制等)。但是，这些游戏平台的基于云的性质面临各种挑战，诸如网络和处理资源的可变性，如果不加以适当考虑，可能会对游戏玩法体验产生负面影响。由于在玩家设备102和服务器系统114之间的网络110/112中引入的可变延迟，这样的挑战可能潜在地创建不均匀的游戏体验。以下公开内容描述检测和补偿可能存在于实时交互的基于云的游戏环境中的不同类型的延迟的各种实施方式。通过补偿这些延迟，本文描述的实施方式为每个玩家提供平滑统一的游戏体验，而与可用的网络和处理资源无关。

图5A描绘将描述数个延迟源的示例游戏环境500。游戏环境500是游戏环境100(图1)的示例实施方式，具有类似地标记的相应组件。游戏环境500包括客户端设备102(在本文中也称为“游戏控制器”或“控制器”)，玩家(或“用户”)使用该客户端设备102例如通过激活或操纵输入210(图2)来控制游戏(或“游戏玩法”)的各个方面。游戏环境500还包括媒体设备106(例如，机顶盒)和输出设备108(例如，电视或其他输出显示器)。控制器102和媒体设备106分别经由本地通信链路502和504(例如，通过WiFi)通信地耦合到本地网络110(在该示例中被描绘为无线路由器)。本地网络110通过通信链路506经由通信网络112(例如，互联网)通信地耦合到服务器系统114。服务器系统114包括游戏服务器122(图1)。

虽然图中所描绘的游戏环境500仅包括具有单个控制器102的单个本地网络110，但是游戏环境500的一些实施方式可以包括多个本地网络110，其中一些本地网络110包括多于一个控制器102(例如，用于共享相同游戏会话的多玩家游戏，如上面参考图1至图4所描述的)。

游戏环境500中存在的数个元素可以引入可感知的(例如，影响至少一个帧)并且随时间变化的延迟。例如，本地网络110(例如，WiFi)可以在通信链路502和504中引入各种数量的延迟。如果在信道上没有竞争，则平均延迟可以非常低(例如，＜1ms)。但是，在诸如具有重叠WiFi网络的公寓楼或具有多个无线客户端设备的游戏玩法环境的繁忙环境中，延迟的平均量在10-50ms范围内更为常见，离群值超过200+ms。

此外，通信网络112(例如，互联网)可以在通信链路506中引入延迟。对于大多数用户而言，此延迟的可变性可能不如WiFi高；但是，在高峰的游戏时间(傍晚)，媒体共享(例如，在电缆调制解调器上)以及网络饱和会导致数据包延时或丢失。平均延迟将取决于从本地网络110到服务器系统114的边缘服务器的距离，其中示例延迟量在20-30ms范围内。

由于网络需求和链路容量的不对称性，上述网络引入的延迟可以基于业务流的方向(例如，从控制器102到服务器122，对比从服务器122到媒体设备106)而变化。因此，从路由器到服务器的链路506上的延迟可能与从服务器返回到路由器的延迟不匹配等等。

此外，游戏服务器122可以引入延迟。存在从输入事件到达GPU140到来自编码器142的帧输出的延迟。但是，在一些实施方式中，此延迟是完全可追踪的，并且因此，游戏服务器122已知该延迟。

最后，在帧到达输出设备108(例如，电视)与该帧的显示之间存在延迟。这可能取决于输出设备中的处理的性质，包括显示模式(例如，游戏模式对比非游戏模式)。例如，电视的显示滞后可能低至15-30ms，或者显示滞后可能高达50-60ms。不好的电视可能会具有120ms以上的显示滞后。

上述不同类型的延迟可能会对游戏玩法体验产生重大影响。图5B和5C示出两个示例游戏玩法体验，其包括相同的用户输入，但由于不同水平的延迟而导致输出完全不同。但是，在详细描述这些示例之前，首先有必要描述示例游戏玩法过程。

延迟补偿

图6是根据一些实施方式的游戏玩法过程600的流程图。该过程可以在具有一个或多个处理器(例如，CPU 138和/或GPU 140)和存储用于通过一个或者多个处理器执行的一个或者多个程序的存储器(例如，存储器146)的电子服务器(例如，服务器系统114，或更具体地说，游戏服务器122)；具有一个或多个处理器(例如，CPU 302)和存储用于由一个或多个处理器执行的一个或多个程序的存储器(例如，存储器306)的媒体设备(例如，媒体设备106)；和/或具有一个或多个处理器(例如，CPU 202)和存储用于通过一个或多个处理器执行的一个或多个程序的存储器(例如，存储器206)的用户设备(例如，控制器102)处执行。在一些实施方式中，服务器、媒体设备和用户设备包括一个或多个程序以及存储用于通过一个或多个相应处理器执行的一个或多个相应程序的存储器，并且一个或多个程序包括用于执行过程600的指令。在一些实施方式中，相应的非暂时性计算机可读存储介质存储一个或多个相应程序，该一个或多个相应程序包括指令，指令当由电子服务器、媒体设备和用户设备执行时，使具有一个或多个相应处理器的电子服务器、媒体设备和用户设备执行过程600。

控制器102的用户(在本文中也称为“玩家”)使用控制器102影响游戏中的事件，这些事件由显示在输出设备108上的视频帧(例如，510)描绘(参见图5A)。当玩家决定影响游戏玩法(例如，通过移动虚拟玩家、射击曲棍球等等)时，玩家激活(602)或以其他方式操纵控制器102上的输入210(例如，按下按钮)。有时将控制器102上的输入210的激活或操纵称为“输入事件”或“命令”。经由通信链路502和506(通过网络110和112)将输入事件传达(604)到服务器系统114(例如，到与游戏会话相关的事件日志460)。

在接收到输入事件(606)时，服务器系统114(例如，游戏服务器122的意图确定模块428)确定(608)用户激活与接收到的输入事件相关联的输入时在输出设备108上显示哪一个帧。在用户激活输入时向用户显示的帧在本文中称为“触发帧”，因为其触发用户通过激活输入做出响应。例如，在曲棍球游戏中，如果帧显示无人防守的球(open shot)，这将触发玩家通过激活映射到“射击冰球”功能的输入控件做出响应。触发帧是示出无人防守的球的帧510(例如，图5B中的帧510-1)，并且输入事件是用户响应于已看到触发帧510而激活控制器102上的“射击冰球”控件。

在确定触发帧之后，游戏服务器122(例如，意图确定模块428)确定(610)在向用户显示触发帧时游戏的状态(在本文中称为“触发状态”)。在一些实施方式中，意图确定模块428通过查阅事件日志460(图4)中维护的游戏状态的日志来确定触发状态。在一些实施方式中，事件日志460包括由帧指纹、帧ID和/或游戏时间数据(例如，时间戳或时钟数据)索引的游戏状态的日志。在一些实施方式中，意图确定模块428通过确定与触发帧相关联的游戏时间索引，并查阅事件日志460以确定在与该触发帧相关联的游戏时间索引时存在的游戏状态，来确定触发状态。取决于在输出设备108上显示触发帧和在游戏服务器122上接收输入事件之间流逝多少时间，相对于在游戏服务器122上正在处理的当前状态，触发状态可以是过去的。

返回到前面的示例，如果触发帧(示出对球门的无人防守的球)与游戏时间索引T1相关联，则时间索引T1处的游戏状态包括虚拟投手、虚拟防守者、虚拟冰球、虚拟球门以及这些对象中的每一个的位置。根据时间索引T1处的游戏状态，或更具体地，根据时间索引T1处的每个前述虚拟对象的位置，在冰球和球门之间存在无阻碍(clear)的路径。换句话说，控制游戏玩法规则的一个或多个算法将允许在显示触发帧时的某个时刻(时间索引T1)虚拟冰球从射击该冰球的虚拟玩家行进到虚拟球门同时无需被投手和球门之间的任何其他虚拟玩家来停止。但是，在一些情况下，当输入事件(例如“射击冰球”)到达服务器时，服务器当前正在处理后续状态T2的游戏玩法，该状态T2可能包括虚拟冰球不再具有到球门的无阻碍路径的游戏玩法的高级状态。在这些情况下，如果服务器将触发状态正确地确定为T1，则触发状态相对于服务器当前正在处理的状态T2是过去状态。

已经确定触发状态后，游戏服务器122(例如，GPU 140)根据(i)输入事件(例如，“射击冰球”)以及(ii)触发状态(例如，包括从冰球到球门的无阻碍路径)处理(612)随后的游戏状态(有时在本文中称为“游戏玩法输出”)。在一些实施方式中，处理游戏玩法输出包括将输入事件输入到算法或游戏引擎中，其基于输入事件和对应的游戏状态来确定游戏玩法输出。例如，游戏引擎可以基于在当前游戏状态期间每个玩家和冰球与球门相关的状态/位置以及在当前游戏状态期间相对于虚拟玩家接收到的任何输入命令(例如，“移动(move)”、“射击(shoot)”或“阻挡(block)”)来确定下一个游戏状态。在一些实施方式中，根据输入事件和触发状态来处理后续游戏状态(游戏玩法输出)包括，处理输入事件，就好像服务器在处理接近于触发状态(例如，触发状态之后的下一个状态，或紧随触发状态之后的状态)的游戏状态时该输入事件对于服务器而言是可用的。

在处理游戏玩法输出时，游戏服务器122渲染(614)描绘所处理的游戏玩法输出的一帧或一系列帧。描绘游戏玩法输出的帧(或一系列帧中的第一个)在本文中称为“响应帧”。例如，如果输入事件和触发状态导致包括特定虚拟玩家的运动的游戏玩法输出，则响应帧是描绘相对于该帧中的其他对象在修改的空间位置中的特定虚拟玩家与用户输入指定的方向保持一致的帧。可替选地，如果输入事件和触发状态导致特定虚拟玩家射击冰球的游戏玩法输出，则响应帧是描绘特定虚拟玩家射击曲棍球的一系列帧中的第一帧(例如，图5B的帧510-3)。在一些实施方式中，呈现响应帧包括根据处理的游戏玩法输出在响应帧中引入新虚拟对象，修改现有的虚拟对象或修改游戏玩法的任何其他方面并且包括新虚拟对象、经修改的现有虚拟对象或修改后的游戏玩法的任何其他方面。

服务器系统114继续(例如，使用编码器142)对响应帧进行编码，并将编码后的响应帧传输(616)到媒体设备106。在从服务器系统114接收到编码后的响应帧后，媒体设备106(例如，使用内容解码模块320)对响应帧进行解码，并使得(例如，使用输出设备108)向用户显示(620)解码后的响应帧。

返回到图5B和5C，描述两个序列的视频帧(510和520)，其示出相同的输入事件(射击冰球)但是由于游戏环境500中存在不同的延迟量而响应帧不同(成功的击球510-2与阻止的击球520-3)。这些序列是应用于游戏环境500的游戏玩法过程600的示例。

图5B描绘第一场景550，包括一系列视频帧510，其示出三个玩曲棍球游戏的虚拟玩家(A、B和C)以及游戏状态T1-T3的表格512(例如，存储在图4的日志460中)。玩家A由控制器102的用户控制，并且玩家B和C由其他控制器的其他用户，通过计算机控制算法或其组合来控制。在状态T1处，玩家A对球门有无阻碍的射击(在表512中表示为“无阻碍(clear)”)；因此，游戏服务器将表示该状态的帧510-1传输到用户的显示器108。当控制玩家A的用户查看显示器108上的帧510-1时，用户看到玩家A对球门具有无阻碍的射击，并且因此决定命令玩家A射击冰球。换句话说，帧510-1触发用户输入“射击”命令。将“射击”命令作为输入事件发送到游戏服务器122。当游戏服务器122接收到“射击”输入(在表512中表示为“In”)时，游戏服务器当前正在处理状态T2，此时玩家A不再有无阻碍的射击(在表512中表示为“无射击(no shot)”)。但是，游戏服务器122正确地确定触发帧(在表512中表示为“T”)是帧510-1。根据显示帧510-1时的游戏状态(触发状态T1)，玩家A仍然对球门具有无阻碍的射击；因此，游戏服务器122根据“射击”命令和T1状态(无阻碍射击)处理后续状态T3。根据游戏引擎，如果在玩家有无阻碍的射击的同时进行射击，则随后的状态包括成功射击序列，并且该序列在状态T3(表512中表示为“得分(score)”)进行处理。这样，游戏服务器渲染描绘玩家A经过玩家C射击冰球的响应帧510-2，并将响应帧传输给用户。从用户的角度来看，响应帧描述用户在输入事件时期望的动作。这样，通过正确确定与用户输入相对应的触发状态，游戏服务器根据用户的意图来处理游戏玩法。

图5C描绘第二场景552，其包括示出与场景550相同的游戏和玩家的一序列的视频帧520，以及游戏状态T1-T3的表522(例如，存储在图4的日志460中)。与先前的场景类似，在状态T1处，玩家A对球门具有无阻碍的射击(在表522中表示为“无阻碍”)；因此，游戏服务器将表示该状态的帧520-1传输到用户的显示器108。当用户在屏幕108上观看帧520-1时，用户看到玩家A在对球门具有无阻碍的射击，并且因此决定命令玩家A射击冰球。将“射击”命令作为输入事件发送到游戏服务器122。与先前的场景一样，当游戏服务器122接收到“射击”输入(在表522中表示为“In”)时，游戏服务器当前正在处理状态T2，此时玩家A不再具有无阻碍的射击(在表522中被称为“无射击”)。但是，与先前的场景不同，游戏服务器122不能正确地确定触发帧(在表522中表示为“T”)。而是，游戏服务器假定触发帧是根据当前状态T2渲染的最后一帧，在此示例中其为帧520-2。可替选地，游戏服务器可能甚至没有尝试确定触发帧，而是基于当前状态T2(无射击)处理游戏玩法输出。在任意情况下，游戏服务器都根据“射击”命令和T2状态(无射击)处理后续状态T3。根据游戏引擎，如果玩家在没有无阻碍射击的情况下射击，则随后的状态包括被阻止的射击序列，并且该序列在状态T3被处理(在表522中称为“阻挡(block)”)。这样，游戏服务器渲染描绘玩家A试图射击冰球但被玩家C阻挡的响应帧520-3，并将该响应帧传输给用户。从用户的角度来看，响应帧描述用户在输入事件时不期望的动作。具体地说，用户期望让玩家A射击同时玩家C不挡道；相反，玩家A没有如用户期望的那么快射击并且因此射击被阻挡。这样，由于未能正确确定与用户输入相对应的触发状态，游戏服务器可能会处理与用户意图相反的游戏玩法事件，这有可能导致用户(和许多其他用户)对玩游戏并且/或使用游戏环境500失去兴趣。

在上述两种场景的每一种中，输入事件同时发生；但是，取决于输入事件到达游戏服务器所耗费的时间，响应帧描述两种截然不同的结果。这是因为，如果服务器在处理比触发用户进行输入的游戏状态(例如，T1)更晚的时间的游戏状态(例如，T2)时接收到用户的输入，则服务器可能会基于关于用户输入的定时的不正确的信息来错误地处理游戏输出。因为对于游戏平台而言避免这种不一致是至关重要的，所以对于游戏平台而言检测并补偿导致这些延迟的游戏环境中引入的各种延迟是很重要的。通过检测各种延迟，游戏平台可以更准确地将输入事件与实际触发状态相关(如在场景550中)。通过进行这些相关，游戏平台通过以与用户意图一致的方式处理每个输入事件减少无法控制和/或无法检测到延迟的影响。这样，本文所述的各种实施方式是对不试图确定或错误地确定与用户输入相对应的准确触发状态的游戏平台的改进。

在某些场景下，取决于触发状态与游戏服务器正在处理的当前状态之间流逝多少时间，特定游戏玩法输出可能与已经显示给一个或多个用户什么相矛盾。例如，在图5C中，帧520-3描绘被阻挡的射击。但是，如果游戏服务器在状态T3期间确定触发状态为T1，则在一些实施方式中，游戏服务器会尝试使用户的意图与游戏的当前状态进行追溯协调。换句话说，用户的意图是在玩家A进行无阻碍射击的同时射击冰球，而游戏的当前状态(T3)在玩家A和球门之间显示玩家C。为了使用户的意图(冰球向球门移动)与当前状态(玩家C挡道冰球)协调，游戏服务器可以在冰球向球门移动的情况下渲染一系列响应帧，尽管玩家C挡道(例如，图5B的帧510-3)。响应帧可能看起来与当前游戏状态不一致；但是，它们与过去(触发)游戏状态期间的用户意图一致。游戏开发人员可以例如通过设计协调不一致游戏状态的动画来预先计划这些意外情况。示例协调动画包括立即将虚拟角色或对象位移到期望位置(即使这可能看起来违反游戏中的物理学)，或以期望方式推进游戏状态同时不示出正确的动画(例如，在不示出冰球到达球门的情况下更新分数，或将怪兽归类为已受伤，即使该怪兽在被射击前似乎已经让开)。在一些实施方式中，在用户交互时使当前游戏状态与用户期望的游戏状态(期望游戏状态)协调包括修改描绘当前游戏状态的帧以创建描绘期望游戏状态的后续帧。

延迟检测

以下讨论根据一些实施方式描述用于检测游戏环境中的各种延迟的各种方法。延迟检测是使游戏服务器能够准确确定特定用户输入的触发帧的必要步骤(图6的步骤608)，从而使游戏服务器能够确定触发状态，并且通过扩展，确定在如上面讨论的输入后面的用户的意图。通过正确触发帧(并且通过扩展，触发状态)的知识，游戏服务器122可以通过考虑接近用户键入输入(例如，推动按钮)时的游戏玩法状态而不是输入到达服务器时的游戏状态(其可能对应于以后的游戏玩法状态)来处理更准确地反映用户意图的输出。

接下来是从游戏服务器(例如，服务器122)的角度对延迟进行简短讨论，包括在一些实施方式中服务器可能有权访问的某些延迟值，以及在一些实施方式中服务器可能无法访问的某些延迟值。对于服务器无法访问的延迟值，将参考图7至图12描述几种用于检测或近似这些值的实施方式。

在一些实施方式中，游戏服务器122访问计算处理延迟所必需的信息，其是处理输入事件并传输产生的响应帧所耗费的时间量。在一些实施方式中，处理延迟基于每个事件而变化。在一些实施方式中，处理延迟根据游戏状态复杂度(例如，正在同时处理的游戏玩法事件的数量)而变化。在一些实施方式中，为了计算针对特定输入事件的处理延迟，服务器系统114记录与输入事件到达服务器系统114(例如，到达边缘服务器)的时间相对应的第一时间戳，以及与编码的响应帧离开服务器系统114的时间相对应的第二时间戳。根据这两个时间戳，服务器系统114(例如，通过从第二时间戳减去第一时间戳)计算与输入事件相关联的处理延迟。

在一些实施方式中，游戏服务器122还访问计算服务器系统114和控制器102之间的平均往返时间(RTT)所必需的信息。在一些实施方式中，服务器系统114通过向控制器102发送一个或多个测试数据报(例如，pings)，接收相应的响应，并计算一个或多个平均响应时间计算该RTT值。在一些实施方式中，游戏服务器122还访问计算服务器114与媒体设备106之间的RTT所必需的信息。在一些实施方式中，服务器系统114通过向媒体设备106发送一个或多个测试数据包(例如，pings)，接收相应的响应，并计算一个或多个平均响应时间来计算此RTT值。然而，由于如上所讨论的不对称网络延迟，仅平均RTT信息可能不足以确定从控制器102到服务器系统114或从媒体设备106到服务器系统114的准确的单向传输时间。如果服务器系统114不能直接计算前述的单向传输时间，则服务器系统114可能不能准确地确定触发帧。

通过访问上述RTT值，服务器系统114(例如，意图确定模块428)可以通过假定针对每个输入事件的平均RTT值，将RTT值除以一半并相加假定的输出设备显示滞后量(例如，电视显示滞后)来近似触发帧。即使两个网络节点之间的延迟通常不对称(正向和反向延迟不相等)，RTT值的一半是正向延迟和反向延迟的平均值；这样，一半的RTT值可以用作单向延迟的近似值(在本文中也称为“单向传输时间”和“单向延迟”)。

在一些实施方式中，意图确定模块428使用(i)在控制器和服务器之间，(ii)在媒体设备和服务器之间，或(iii)其组合的单向延迟值，以更准确地确定触发帧。以下讨论参考图7至图12描述几种实施方式，用于测量或更准确地近似单向传输时间，以便于更准确地确定特定输入事件的触发帧。

图7至图12是根据一些实施方式的触发帧确定过程700-1200的流程图。可以在具有一个或多个处理器(例如，CPU 138和/或GPU 140)和存储一个或多个程序以供一个或多个处理器执行的存储器(例如，存储器146)的电子服务器(例如，服务器系统114，或更具体地，游戏服务器122)；具有一个或多个处理器(例如，CPU 302)和存储一个或多个程序以供一个或多个处理器执行的存储器(例如，存储器306)的媒体设备(例如，媒体设备106，当与输出显示设备108结合或以其他方式耦合到输出显示设备108时也称为“显示器”)；和/或具有一个或多个处理器(例如，CPU 202)和存储一个或多个程序以供一个或多个处理器执行的存储器(例如，存储器206)的用户设备(例如，控制器102)处执行所述过程。在一些实施方式中，服务器、媒体设备和用户设备包括一个或多个程序以及存储一个或多个相应程序以供一个或多个相应处理器执行的存储器，并且一个或多个程序包括用于执行相应过程的指令。在一些实施方式中，相应的非暂时性计算机可读存储介质存储一个或多个相应程序，该一个或多个相应程序包括指令，当所述指令由电子服务器、媒体设备和用户设备执行时，其使具有一个或多个处理器的电子服务器、媒体设备和用户设备执行方法700-1200中的一个或多个。

图7描述根据一些实施方式的触发帧确定过程700。在过程700中，服务器114、媒体设备106和控制器102是使用非同步时钟的独立组件。这样，对从控制器发送到服务器和/或从媒体设备发送到服务器的时间戳的分析不会提供对各个组件之间的延迟的准确评估。在一些实施方式中，一个或多个时钟被同步。然而，服务器可以使用过程700来确定触发帧，不管前述时钟中的任何时钟是否同步。

过程700开始于服务器114向媒体设备106发送(702)一系列帧中的第一帧以用于在输出设备108上显示给用户。当媒体设备106使第一帧显示(704)给用户时，媒体设备106向服务器114(例如，与游戏会话相关联的事件日志460)传达(706)第一帧刚刚被显示。此通信在本文中被称为“显示事件”，并且在一些实施方式中，由媒体设备106的显示事件报告模块325报告。每次媒体设备106使帧被显示时，媒体设备106(例如，报告模块325)将相应的显示事件发回到服务器。在一些实施方式中，显示事件包括与刚刚已经显示的帧相对应的帧ID。同时，用户在观察第一帧并决定操纵控制器以便于影响游戏玩法时，激活输入。控制器102检测(708)用户的输入并将用户的输入传达(710)到服务器114。此通信在本文中被称为“输入事件”，并且在一些实施方式中，由控制器102的输入事件报告模块223报告。每次控制器102检测到用户输入时，控制器102就会向服务器发送相应的输入事件。在一些实施方式中，输入事件包括与用户激活的特定输入相对应的输入ID。

同时，连续渲染并发送要显示给用户的帧的服务器连续接收(712)与(例如，在步骤702期间)发送给用户的渲染帧相对应的显示事件。在接收到(712)(例如，来自步骤710的)输入事件之后，意图确定模块428将输入事件与最近接收到的显示事件进行匹配(714)。假定控制器和服务器之间以及媒体设备和服务器之间的单向延迟相似，则输入事件及其相应的显示事件应大致同时到达。这样，通过将输入事件与在时间上最接近接收到输入事件的时间接收到的显示事件进行匹配，意图确定模块428通过将与匹配的显示事件相关联的帧分类为触发帧来近似用户的输入事件意图。

由于上游链路(例如，图5A的链路502和504)的可变性，与控制器102和媒体设备106相关联的上游连接中的差异可能会引起不准确性。例如，媒体设备106可以使用有线连接，而控制器102可以使用具有增加的延迟的无线连接。在一些实施方式中，意图确定模块428通过平均两个链路之间的延迟的差异(例如，通过将平均服务器媒体设备RTT与平均服务器控制器RTT进行比较)来解决这些可变性。

图8描绘根据一些实施方式的触发帧确定过程800。在过程800中，服务器114和控制器102具有同步的时钟。在此过程以及其他涉及时钟同步的过程(例如，下面讨论的过程900-1200)中，一些实施方式经由网络时间协议(NTP)服务器完成同步。在一些实施方式中，由于时钟漂移，前述时钟中的一个或多个被周期性地重新同步。

过程800开始于控制器102检测(802)用户输入，并且报告模块223将相应的输入事件发送(804)到服务器114，如以上过程700中所述。然而，在过程800中，输入事件另外包括时间戳(例如，TS1)。服务器114在时间TS2处接收(806)输入事件，并且通过将TS1与TS2进行比较(例如，通过采用每个时间戳之间的差的绝对值)来计算(808)单向输入到显示器的延迟。然后，服务器114(例如，意图确定模块428)通过使用单向输入到服务器的延迟作为代理(例如，设置单向显示器到服务器的延迟等于单向输入到显示器的延迟)来近似(810)单向显示器到服务器的延迟。

然后意图确定模块428近似(812)单向服务器到显示器的延迟。在一些实施方式中，通过使用显示器到服务器的延迟的时间平均或滑动窗口作为代理(例如，将服务器到显示器的延迟设置为等于显示器到服务器的延迟)来近似服务器到显示器的延迟。可替选地，通过使用最近测量的服务器-显示器RTT(例如，通过将RTT划分成两半)，并且可选地添加假定的显示滞后来近似服务器到显示器的延迟(如在上面参考输出设备108的延迟所述)。

在确定用于单向服务器到显示器的延迟的值(例如，Dms)后，意图确定模块428确定(814)触发帧作为在TS1之前的D ms已传输到媒体设备的帧。

图9描绘根据一些实施方式的触发帧确定过程900。在过程900中，媒体设备106和控制器102具有同步时钟。在一些实施方式中，服务器114还具有与媒体设备的时钟、控制器的时钟或两者同步的时钟。

过程900开始于控制器102检测(902)用户输入，并且报告模块223发送(904)具有时间戳TS1的相应输入事件，如上面的过程800所述。服务器114接收(906)输入事件并渲染(908)响应帧，假定当前游戏状态触发输入事件，或者假定过去游戏状态触发输入事件(例如，偏移了预定量)。服务器114(例如，在帧的元数据中)包括时间戳TS1和响应帧，并将其传输到媒体设备106。媒体设备106接收(910)响应帧，并使响应帧在第二时间戳(例如，TS2)显示给用户。媒体设备106(例如，延迟计算模块326)测量(912)两个时间戳之间的差，以确定在用户在控制器102上键入输入的时间到用户在显示器108上看到对应的响应的时间之间的延迟量(在本文中称为“拇指到显示器的延迟”)。在一些实施方式中，媒体设备106将时间戳数据存储为延迟数据334，并且延迟计算模块326访问所存储的时间戳数据以便于计算上述各种延迟。在一些实施方式中，延迟计算模块326将拇指到显示器的延迟与(例如，来自一个或多个过程700-1200的)其他已知的延迟相结合，以更好地近似触发帧。

图10描绘根据一些实施方式的触发帧确定过程1000。在过程1000中，媒体设备106和控制器102具有同步时钟。在一些实施方式中，服务器114还具有与媒体设备的时钟、控制器的时钟或两者同步的时钟。

过程1000开始于服务器114在时间戳TS1处渲染(1002)第一帧，并且将该帧与该帧一起包括的时间戳TS1(例如，包括在帧的元数据中)发送到媒体设备106。媒体设备106接收(1004)该帧，并使该帧在时间戳TS2处显示。媒体设备(例如，延迟计算模块326)比较(1006)两个时间戳TS1和TS2以直接确定单向服务器到媒体设备的延迟，并且报告模块325向服务器114报告(1008)所确定的单向服务器到媒体设备的延迟。在一些实施方式中，该报告包括在与第一帧相对应的显示事件中。服务器114接收服务器到媒体设备的延迟，并且意图确定模块428将其与(例如，来自一个或多个过程700-1200，诸如关于最近媒体设备到服务器的延迟的数据的)其他已知延迟进行比较(1012)，以更好地近似触发帧。在一些实施方式中，因为可以假定显示事件在接近对应输入事件的时间到达，所以过程1000还包括控制器102检测(1014)用户输入，并且控制器的报告模块223向服务器114发送(1016)包括检测到的用户输入的输入ID的输入事件。服务器的意图确定模块428可选地将输入事件与最近的显示事件进行匹配，如上面的过程700中所述，以便更好地近似触发帧。

图11描绘根据一些实施方式的触发帧确定过程1100。在过程1100中，媒体设备106和控制器102具有同步时钟。在一些实施方式中，服务器114还具有与媒体设备的时钟、控制器的时钟或两者同步的时钟。

过程1100开始于服务器114在时间戳TS1渲染(1102)第一帧，与过程1000一样。但是，在过程1100中，服务器114可能无法在帧的传输中包括时间戳。这样，服务器114发送没有时间戳TS1的第一帧。媒体设备106接收(1104)第一帧，并使第一帧在时间戳TS2处显示。然后，媒体设备106(例如，报告模块325)将时间戳TS2单独或与如上所述的显示事件传输一起报告(1106)给服务器114。服务器114接收(1108)时间戳TS2并且服务器的意图确定模块428将时间戳TS2与时间戳TS1进行比较(1110)，以便于直接测量服务器到媒体设备的延迟。在一些实施方式中，意图确定模块428将服务器到媒体设备的延迟与(例如，来自一个或多个过程700-1200，诸如关于最近媒体设备到服务器的延迟的数据的)其他已知延迟进行比较(1112)以更好地近似触发帧。在一些实施方式中，因为可以假定显示事件在接近相应的输入事件的时间到达，所以过程1100还包括控制器102检测(1114)用户输入并且控制器的报告模块223向服务器114发送(1116)包括检测到的用户输入的输入ID的输入事件。服务器的意图确定模块428可选地将输入事件与最近的显示事件进行匹配，如上面的过程700中所描述的，以便更好地近似触发帧。

图12描绘根据一些实施方式的触发帧确定过程1200。在过程1200中，媒体设备106和控制器102具有同步时钟。在一些实施方式中，服务器114还具有与媒体设备的时钟、控制器的时钟或两者同步的时钟。

处理1200利用以下假定，即，如果大多数电视擅长嘴唇同步(延迟音频信号以匹配电视的图像延迟，并经由例如HDMI 1.3b与接收器协调)，则音频信号可用于测量媒体设备到眼球的延迟。在一些实施方式中，服务器114在第一时间戳(例如，TS1)向媒体设备106发送(1202)初始化时(例如，在登录或设置过程期间)独特的音频音调，并且媒体设备106使(1204)在第二时间戳(例如，TS2)在输出设备108上播放音频音调。可替选地，在没有服务器114的提示的情况下媒体设备106独立地播放(1204)在初始化时(在TS2处)独特的音频音调。在播放音频音调时，媒体设备(例如，报告模块325)向服务器114发送(1206)包括第二时间戳TS2的报告。当音频音调到达控制器102时，控制器102在第三时间戳(例如，TS3)(例如，通过嵌入式麦克风)检测(1208)音频音调，并且向服务器114发送(1210)包括第三时间戳TS3的报告。

服务器114从媒体设备105接收(1212)包括TS2的“音频发送”报告和从控制器102接收包括TS3的“音频检测”报告，并且意图确定模块428将时间戳TS2和TS3进行比较以确定输出设备到控制器的延迟。因为可以假定用户非常接近于控制器102，所以可以假定输出设备到控制器的延迟等于输出设备到耳朵的延迟。在一些实施方式中，意图确定模块428假定距显示设备108的扬声器的预定典型就座距离(例如，10英尺)或用户编程的就座距离，以便于考虑声波的传播时间。在一些实施方式中，由于假定在整个会话中显示滞后是固定的，所以意图确定模块428不重新测量显示设备到耳朵的延迟。在一些实施方式中，意图确定模块428还比较TS1与TS2和/或TS3以确定相应端到端的延迟，以便于更好地近似触发帧。

在一些实施方式中，音频信号包括编码的帧ID和/或编码的时间戳TS1，并且服务器114经由例如高频音频调制解调器(例如，耳语)周期性地发送音频信号，并且控制器102监听如上所述的音频信号。可替选地，媒体设备106(例如，经由过程1000或1100中的任意一个)接收帧ID和/或时间戳TS1，并且本地合成音频音调以从输出设备108进行传播。在此实施方式中，控制器直接接收触发帧本身的标识信息(例如，帧ID和/或时间戳TS1)并且继续将所标识的触发帧直接报告给服务器114。在一些实施方式中，实施校正以便于解决音频调制解调器的延迟。

在一些实施方式中，代替音频音调，服务器114用识别帧和/或时间戳TS1的图像图案渲染(1202)帧，并且控制器102上的相机或光电检测器检测(1208)显示设备108上的图像图案。其余步骤与上述类似。在一些实施方案中，图像图案包括强度的变化(例如，与所测量的强度基线比较)。

图13是根据一些实施方式的延迟检测和补偿过程1300的流程图。该过程可以在具有一个或多个处理器(例如，CPU 138和/或GPU 140)和存储一个或者多个程序以供一个或者多个处理器执行的存储器(例如，存储器146)的电子服务器(例如，服务器系统114，或更具体地说，游戏服务器122)处执行。在一些实施方式中，服务器包括一个或多个程序以及存储一个或多个程序以供一个或多个处理器执行的存储器，并且一个或多个程序包括用于执行过程1300的指令。在一些实施方式中，非暂时性计算机可读存储介质存储一个或多个相应程序，所述一个或多个相应程序包括指令，当该指令由具有一个或多个处理器的服务器执行时，该指令使服务器执行过程1300。

过程1300开始于当服务器114响应于在远程站点(例如，图1和5A的本地网络110)处的触发帧的显示而从位于该远程站点的游戏控制器102接收输入事件时，如参考上面的图6的步骤606所描述的。在一些实施方式中，服务器在以当前游戏状态(例如，图5B的状态T2)操作的游戏会话期间接收输入事件。输入事件包括在游戏会话期间由用户与游戏控制器的交互(例如，控件的激活或操纵)生成的用户命令。

重要的是要注意，尽管由控制器响应于已显示给远程站点的用户的先前传输的帧(“触发帧”)而生成输入事件，但是输入事件可能不一定会标识先前传输的帧中的哪一个是触发帧。因此，该过程继续进行服务器确定(1304)触发帧，如上面参考图6的步骤608所描述的。更具体地，服务器(例如，意图确定模块428)确定先前传输的多个中的哪一个是在用户交互期间在远程站点处显示的帧(例如，图5B的510-1)，其中在服务器接收输入事件之前，在游戏会话期间服务器将多个先前传输的帧发送到媒体设备106。在各种实施方式中，服务器通过执行以上参考图7至图12描述的一个或多个过程来确定触发帧。

过程继续，服务器使用所确定的触发帧来确定(1306)与触发帧相关联的游戏状态(“触发状态”)，如上面参考图6的步骤610所描述的。在一些实施方式中，取决于输入事件到达服务器所耗费的时间，当前游戏状态可能已经超过触发状态；因此，触发状态(例如，图5B的状态T1)将是当前游戏状态(例如，图5B的状态T2)之前的游戏状态。

在确定触发状态之后，游戏服务器根据(i)触发状态和(ii)输入事件中包括或描述的用户命令来处理(1308)游戏玩法输出，如上面参考图6的步骤612所描述的。具体地，对于服务器接收的每个输入事件，服务器将输入事件中描述的相应用户命令与相应触发状态进行匹配，以便于在触发用户启动该命令的游戏状态的场境中更准确地处理每个命令，从而遵守、满足和/或履行用户在每个命令后面的意图。在一些实施方式中，为了处理游戏玩法输出，游戏服务器必须使当前游戏状态与触发状态协调，特别是如果两个状态不一致时，如上所述。

服务器渲染(1310)描述游戏玩法输出的响应帧，如上面参考图6的步骤614所描述的，并传输(1312)结果帧以显示给远程站点处的用户，如上面参考图6的步骤616所描述的。

对游戏玩法调优的延迟调整

响应时间是在线游戏的重要方面，其直接影响用户体验。描述响应时间的一种方法是用户执行动作(例如，按下游戏控制器上的“跳转”按钮)的时刻到向用户显示该动作的结果的时刻(例如，数字渲染的播放器跳转到屏幕上)之间流逝的时间量。响应时间可能会受到在上面讨论的各种延迟来源的影响。大多数延迟来源被分成两个类别：处理延迟和网络延迟。

处理延迟是专用于特定游戏或在线游戏会话的处理资源的数量和质量的结果，并且可能受指配给处理用户输入和渲染相应的响应的处理器或处理内核的数量、速度和效率的影响。处理延迟可能进一步受到用户输入的复杂性或游戏会话中的其他用户正在处理的并发输入的数量和复杂性的影响。

网络延迟是用于支持在线游戏会话的通信网络(例如，110和/或112)的质量的结果，并且可能会受到许多诸如干扰的外部因素和诸如变化流量水平和可用带宽的内部因素的影响。随着用户(例如，102)和特定游戏服务器系统(例如，114)之间的距离增加，支持游戏会话所需的物理网络元件的数量增加，这增加引入更多网络延迟的可能性。例如，与容纳特定游戏服务器的数据中心相距很远的第一用户(例如，102A)可能在游戏服务器托管的在线会话期间比参与相同会话但是位于数据中心对面的街上的第二用户(例如，102B)经历更多的延迟。

虽然处理延迟和网络延迟通常不在游戏开发人员的影响范围之内，但开发人员可能有意添加并调优又一类型的延迟，以便于优化用户体验。通过调优开发人员增加的延迟，适当配备的游戏服务器可以抵消由不可控制的类型的延迟(例如，处理延迟和网络延迟)所引起的许多负面影响。

此外，延迟调优用作通过对现实生活中的动作建模游戏动作来优化用户体验。例如，就像计算机鼠标对手的最轻微的移动过于响应一样，游戏场境中的某些用户输入比其他人更容易受到变化延迟量的影响。例如，在冰上曲棍球游戏中，应仔细调优与运动相关联的输入的响应时间，因此它们足够灵敏以确保有竞争力的响应时间(例如，避免被对手检查)，但又不能如此敏感以至于防止准确的移动(例如，排队射击而不过度补偿)。另外，不同类型的输入可能需要不同的响应时间量。例如，用于射击和阻挡冰球的输入相关联的延迟值可以比与用于控制玩家的运动的输入相关联的那些在更快的响应时间内被调优，因为可能需要更高的精度以将玩家移动到位并且排队射击，不是例如精确决定何时进行射击。

游戏开发人员可以调优各种输入或输入类型的响应时间。在一些实施方式中，特定游戏的响应时间值随平台而变化，但是对于每个平台，响应时间是稳定的。对于涉及在线流的实施方式，响应时间基于网络条件和光速度的约束而变化。此外，上面讨论的各种类型的处理延迟和网络延迟使响应时间调优更加复杂，因为在输入和响应之间流逝的时间量对于每个用户，或者甚至对于单个用户随着时间流逝都是不一致的。

下面讨论用于在游戏玩法调优的场境中调整延迟的方法和系统的各种实施方式。本文描述的各种实施方式用作使基于网络条件的性能可变性对于用户而言不太明显，从而导致更好的用户体验。在一些实施方式中，在其中游戏被托管并离开计算机在地理上遥远的服务器(例如，114)中运行并在本地客户端(例如，102A)上显示的游戏流送系统上，游戏动态地位移在注册输入事件和显示对玩家的相应响应之间渲染的帧数。对于特定游戏，开发人员为每种类型的输入事件(例如，移动、动作、按钮按下、控制器定向改变等)定义输入和响应之间的理想或期望的帧数或时间量(例如，毫秒)。在一些实施方式中，游戏系统提供API，针对每个帧，该API报告现有输入延迟条件或代表用户所看到的内容的最近时间带。在一些实施方式中，一个或多个用户在可变的输入延迟条件下在相应的游戏控制器(在本文中也称为“客户端设备”或“控制器”)上玩游戏。在一些实施方式中，用户通过操纵操纵杆、按下按钮、选择可供性、移动或以其它方式操纵诸如游戏控制器的输入设备来生成输入事件。在生成输入事件后，与用户相关联的控制器将该输入事件发送到运行游戏的服务器(例如，114)。

在一些实施方式中，服务器查询现有延迟的量(例如，通过查询流转化器API)、输入延迟(例如，网络延迟)的最新值或时间带的最近估计。服务器在生成反映与输入事件相对应的响应的帧(在此称为“响应帧”)之前减少或增加将通过的帧(在此称为“中间帧”)的数量。服务器通过网络向媒体设备发送中间帧紧接着响应帧。在将响应帧发送到媒体设备时，媒体设备(例如，在输出设备108上)向用户显示响应帧。在一些实施方式中，基于在当前会话中显示的帧速率(例如，以每秒帧为单位)来计算从渲染时间增加或减去的帧的增量(例如，中间帧的数量)。增量的变化会减少或增加在输入和响应之间流逝的时间量，这使响应时间尽可能靠近特定类型输入的理想或期望的响应时间。重要的是要注意，因为不同的输入事件可能需要不同的调整量以满足理想的响应时间，所以本文公开的实施方式不需要全局延迟或帧的缓冲。而是，本文公开的实施方式的方面着重于输入和相应响应之间的帧数的每事件增加或减少。

如上所述，游戏开发人员可以为不同类型的输入事件定义相应输入和相应响应之间的理想的或期望的帧数或时间量。在一些实施方式中，这些关系在存储在服务器系统114中的响应时间设置462中定义(参见图4)。图14A和图14B是示例性响应时间设置462，用于将用户输入(在此也称为“命令”)与理想或期望的响应时间(在此也称为“预期延迟值”或“目标延迟值”)相关。在一些实施方式中，用于特定游戏的命令的索引与对应命令类型(也称为“预期延迟类型”或“延迟类别”)一起存储在表(例如，1412)中。例如，“躲避”和“射击”命令属于第一类别或命令类型(例如，“类型1”)，“行走”和“跳跃”属于第二类别或命令类型等等。在一些实施方式中，命令类型的索引与对应的预期延迟值一起存储在表(例如，1414)中。例如，“类型1”命令与16ms的预期(例如，理想的或期望的)延迟相关联，“类型2”命令与40ms的预期延迟相关联等等。可替选地，一个表(例如，1416)用于将命令与预期延迟直接相关。例如，“躲避”和“射击”命令与20ms的预期延迟相关联，“移动”和“跳跃”命令与40ms的预期延迟相关联等等。在一些实施方式中，表1412、1414和/或1416被存储在服务器系统114的存储器146(例如，响应时间设置462)中。

图14C是服务器系统114的设备/网络评估模块444的示例实施方式。设备/网络评估模块444为参与特定游戏会话的每个用户/控制器获得网络延迟信息1420。在一些实施方式中，网络延迟信息是往返定时(RTT)信息，其与将用户输入从控制器传输到服务器所耗费的时间量相关联，与将相应的响应帧从服务器传输到媒体设备所耗费的时间相结合。在一些实施方式中，RTT信息另外包括服务器处理用户输入并生成对应的响应帧所耗费的时间量。附加地或可替选地，网络延迟信息是相对于上面的图5至图12描述的任何延迟值。例如，在一些实施方式中，如果RTT信息对网络评估模块444来说不容易可用，则如上所述确定各种单向传输时间，并且网络评估模块444组合确定的传输时间(例如，单向控制器到服务器的延迟和单向服务器到媒体设备的延迟)以确定未知的延迟信息(例如，控制器到服务器到媒体设备的延迟)。

图15是根据一些实施方式的示例在线交互式游戏环境1500。游戏环境1500类似于游戏环境100(图1)和500(图5A)，其中相应组件被类似地编号。

在时间t₁处，控制器102A通过网络(例如，一个或多个本地和/或非本地通信网络110)将与输入相关联的用户命令(例如，来自表1412的命令)传输到服务器114。在一些实施方式中，用户命令是用户操纵游戏控制器上的控件(例如，按下按钮、移动操纵杆、旋转控制器本身等等)或以其它方式与游戏控制器交互的结果。用户操纵游戏控制器发出用户命令的动机(换句话说，“触发”)是基于正在玩的特定游戏。例如，如果用户正在玩在线冰上曲棍球游戏，则用户可以决定利用球门中的开口并按下“射击”按钮以便将冰球射入球门中。在一些实施方式中，触发(例如，球门中的开口)是由从服务器114传达并渲染在被控制器102A的用户使用以查看游戏玩法的输出设备(例如，108)上的图像引起的。因此，在观看图像(例如，描绘球门中的开口的图像帧)时，激励用户通过发布相关命令(例如，射击冰球)来做出响应。

在时间t₂处，服务器114接收命令。t₁和t₂之间的时间量是与上面讨论的网络延迟相关的各种因素的函数。在接收到命令后，服务器通过根据命令更新当前游戏状态并生成反映更新后的游戏状态的响应帧来处理命令。在一些实施方式中，处理命令包括确定接收到哪个命令，确定命令的类型，确定或更新网络延迟值，基于网络延迟值和接收到的命令的类型确定要引入的延迟量(例如，通过参考表来确定与该命令相关联的预期延迟，并将预期延迟与网络延迟进行比较)，并且基于所确定的引入延迟量生成一个或多个中间帧(例如，通过将当前帧速率乘以预期延迟和网络延迟之间的差)。

在时间t₃处，服务器114通过网络110/112将中间帧(如果有的话)和响应帧传输到媒体设备106，以在输出设备108上显示。t₂和t₃之间的时间量是与在上面讨论的处理延迟有关的各种因素的函数。在一些实施方式中，处理延迟受生成响应帧的过程影响。在一些实施方式中，生成响应帧包括(i)处理响应(例如，基于游戏场景中的每个玩家的当前位置和其他因素来确定描绘移动的冰球的一系列图像帧中的第一帧是什么，诸如射击的轨迹和玩家的力量)，(ii)渲染反映响应的帧(例如，渲染描绘玩家射击冰球的一系列帧中的第一帧)，(iii)对该帧进行编码，(iv)打包帧以在网络上流送。在一些实施方式中，响应帧是以预定义的帧速率传输的一系列帧中的一个。在一些实施方式中，通过例如使用速率控制过程，根据在线游戏会话的网络特性(例如，可用带宽)来确定预定义的帧速率，并且即使在确定网络延迟值已经改变之后也保持预定义的帧速率。例如，在接收用户命令之前(例如，在t₂之前)的时间实例的预定帧速率与在传输对应的响应帧的时间实例(例如，t₃)的预定义的帧速率相同。换句话说，预定义的帧速率保持恒定，不管添加了多少延迟(例如，通过插入更多的中间帧)或减去了多少延迟(例如，通过插入更少或没有插入中间帧)。通过不更改每个事件的延迟调整的总体帧速率，由于不受延迟调整的影响，游戏玩法的其他方面(例如，其他游戏玩法事件和交互、观看质量等)可以不受阻碍地进行。

在时间t₄处，媒体设备106接收响应帧1610，并使响应帧显示在输出设备108上。t₃和t₄之间的时间量是与上面讨论的网络延迟有关的各种因素的函数。在一些实施方式中，响应帧经过的网络路径与用户命令经过的网络路径不同。在各种实施方式中，网络延迟值基于单向控制器到服务器的传输时间(例如，t₁和t₂之间的差)，单向服务器到媒体设备的传输时间(例如，t₃和t₄之间的差)和/或处理延迟(例如，在t₂和t₃之间)。

图16是根据一些实施方式的在显示器108上渲染的帧的示例序列。在该示例中，帧1610-1至1610-6以每秒50帧(每20ms 1帧)的预定义帧速率传输和显示。另外，为了简单起见，假定网络延迟是可忽略的。图16中所示的时间戳是服务器114生成各个相应帧的时间。在t＝0ms时，服务器生成帧1610-1，该帧示出两个冰上曲棍球玩家A和B受两个用户和它们各自的控制器(例如，102A和102B)控制。玩家A具有冰球，而玩家B在球门中。此时，服务器从控制玩家A的控制器接收“移动”命令。在此特定示例中，“移动”命令还包括(到玩家的左边的)轨迹。在接收到“移动”命令时，服务器(例如，延迟调整模块430)(例如，通过查询表1412和1414或表1416)确定“移动”命令是与40ms的预期延迟相关联的命令类型。因为预定义的帧速率是1帧/20ms，并且服务器必须在生成响应帧之前满足40ms的预期延迟，所以延迟调整模块430确定应生成一个中间帧作为占位符，因为40ms(预期延迟)减去20ms(实际延迟)等于20ms，而20ms乘以1/20ms/帧(帧速率)等于1帧。这样，GPU 140在t＝20ms处生成(或以其他方式使其被处理、渲染或编码)一个中间帧1610-2，并且然后在t＝40ms处生成响应帧1610-3。在一些实施方式中，编码器142将一个或多个中间帧编码为跳过帧或一连串的跳过帧。

继续图16中的示例，看到玩家A移动之后，控制玩家A的用户决定在控制玩家B的用户有机会阻挡射击之前立即射击冰球。服务器在t＝160ms处接收与帧1610-4的生成并发的“射击”命令。延迟调整模块430(例如，通过查阅表1412和1414或表1416)确定“射击”命令仅与20ms的预期延迟相关联。因为预定义的帧速率是1帧/20ms，并且服务器在生成响应帧之前多满足20ms的预期延迟，所以延迟调整模块430确定不应该生成任何中间帧，因为20ms(预期延迟)减去20ms(实际延迟)等于0ms，0ms乘以1/20ms/帧(帧速率)等于0帧。这样，在t＝180ms处，GPU 140在20ms之后生成(或以其他方式导致对其进行处理、渲染或编码)响应帧1610-5，同时没有渲染任何中间帧。响应帧1610-5是描绘“射击”命令的结果的一系列响应帧中的第一个，其中帧1610-6是在t＝200ms的一系列响应帧中的第二个。

图17和18是描绘用于确定要引入多少延迟的示例技术的图。在附图中，中间帧描绘为实心，而响应帧架描绘为条纹。

在图17中，服务器通过两个不同的网络或通过具有两个不同的延迟值的同一网络接收相同的命令。网络延迟1720低于网络延迟1710。结果，如果不是针对引入的延迟，则对应的响应帧将在不同的时间发回给媒体设备。通过在具有较低网络延迟1720的场景中渲染附加中间帧，服务器确保预期总延迟(例如，响应时间)是一致的，不管网络延迟量如何。从不同的角度来看，通过(i)相对于另一场景生成更多的中间帧(场景1720)，(ii)相对于另一场景生成更少的中间帧(场景1710)，或(iii)(i)和(ii)的组合，将响应时间保持一致。

在图18中，服务器接收两个不同的命令，所述命令需要不同数量的处理延迟。例如，“跑”命令需要第一数量1810的处理延迟，而资源密集型的“平移”命令需要第二数量1820的处理延迟，该数量大于第一数量。如果每个命令都与相同的预期延迟相关联并且每个命令在同一时间被接收(假定网络延迟相似)，则服务器将通过下述考虑处理延迟中的不同：(i)相对于其它场景生成更多的中间帧(场景1810)，(ii)相对于其它场景生成更少的中间帧(场景1820)，或者(iii)(i)和(ii)的组合。

在一些实施方式中，延迟调整模块430通过(i)确定或估计用户命令与相应响应帧之间的实际延迟量(例如，通过测量如上所述的网络延迟和可选地考虑处理延迟)，(ii)确定预期延迟(例如，通过查询如上所述的响应时间设置462)，以及(iii)确定实际延迟与预期延迟之间的差，来确定引入的延迟量。如果实际延迟短于预期(期望)延迟，则服务器会引入附加延迟。相反，如果实际延迟时间长于预期(期望)延迟，则服务器去除附加延迟(或完全不引入任何延迟)。在一些实施方式中，为了考虑上述每种情况，服务器总是添加引入的默认延迟量，从而可以对该引入的延迟进行加减。在已经确定引入的延迟量之后，延迟调整模块通过将帧速率乘以引入的延迟量来确定要渲染的中间帧的数量。在一些实施方式中，延迟调整模块430使用下述等式来确定要渲染的中间帧的数量：中间帧的数量＝帧速率*(预期延迟-实际延迟)。对于实际延迟高于预期延迟的场景，中间帧的数量为负。这样，对于总是存在中间帧的基线的实施方式，延迟调整模块430将从基线中减去适当数量的中间帧。然而，对于其中不存在中间帧的基线的实施方式，延迟调整模块430仅使在这种情况下不渲染任何中间帧。

在一些实施方式中，基于估计的响应帧到达时间来确定引入的延迟量。例如，如果响应帧被投射以比预期的或期望的到达时间更早到达媒体设备(例如，基于如上所述确定的网络和/或处理延迟值)，则服务器如上面所讨论呈现附加中间帧。相反，如果响应帧被投射以比预期的或期望的到达时间更晚到达媒体设备，则服务器如上面所讨论渲染较少的中间帧。在一些实施方式中，延迟调整模块430使用下述等式来确定要渲染的中间帧的数量：中间帧的数量＝帧速率*(目标到达时间-投射的到达时间)。对于其中投射的到达时间晚于目标到达时间的场景，中间帧的数量为负。这样，对于总是存在中间帧的基线的实施方式，延迟调整模块430将从基线中减去适当数量的中间帧。然而，对于其中不存在中间帧的基线的实施方式，延迟调整模块430仅使得在这种情况下不渲染任何中间帧。

图19A是根据一些实施方式的示例在线交互式游戏环境1900。游戏环境1900是与游戏环境1500相对应的示例实施方式，其中增加位于远离第一用户和服务器的站点处的第二用户的控制器102B和媒体/输出设备106B/108B。第一用户和第二用户都在玩同一游戏。在此示例中，第二用户与服务器之间的距离比第一用户与服务器之间的距离更远。这样，第二用户会经历更多的网络延迟。另外，在此示例中，为了简单起见，假定相应媒体设备106和显示器108之间的显示滞后为零。

在时间t₀处，第一控制器102A通过网络110/112(参见图15)将用户命令(例如“射击”)传输到服务器114，并且该命令耗费40ms以在时间t₂到达服务器。服务器耗费20ms来处理命令，并且在时间t₃将响应帧传输到第一和第二媒体设备106A和106B。响应帧耗费40ms以在时间t₅到达第一媒体设备106A，并且耗费60ms以在时间t₆到达第二媒体设备106B。这样，第二用户(在控制器102B处控制玩家B)在显示器108B上没有看到响应帧直到在第一用户(在控制器102A处控制玩家A)在显示器108A上看到响应帧之后的20ms。由于20ms的延迟，第二用户的响应时间可能会受到不公平的延迟。此外，在第二用户甚至看到这些事件在显示器108B上展开之前，玩家A可以得分，并且随后的游戏状态可以相应地更新。

图19B描绘由显示器108A和108B渲染的截屏1920-1928，其中时间戳对应于图19A中的时间戳。因为玩家A的响应时间比玩家B的响应时间快20ms，所以玩家A在t₅＝100ms处看到响应帧1926，而玩家B在20ms后看到响应帧1926。结果，在t₆＝120ms处，玩家A已经得分，但是从玩家B的角度来看，即使在服务器处(例如，通过给玩家A的团队的分值加分)已经更新了游戏状态，仍然有时间阻挡玩家A的射击。在一些场景下，玩家B可能会在未来的帧中成功阻挡玩家A的射击，创建就与实际游戏状态冲突的预期游戏状态。根据上述各种实施方式，可以通过引入延迟来避免这些种类的冲突的游戏状态。

图20A和20B描绘示例性游戏环境1900和相应的用户视图，但是其中添加额外的中间帧，该中间帧已经根据上述各种实施方式被添加。图20A/20B与图19A/19B相对应，不同之处被圈出。具体来说，通过添加附加中间帧2000，服务器将20ms的额外延迟引入到玩家A的响应时间，从而使响应帧1926同时到达媒体设备106A和106B。

图21是根据一些实施方式的延迟调整过程2100的流程图。该过程可以在具有一个或多个处理器(例如，CPU 138和/或GPU 140)和存储用于通过一个或多个处理器执行的一个或多个程序的处理器(例如，存储器146)的电子服务器(例如，服务器系统114，或更具体地说，游戏服务器122)处执行。在一些实施方式中，服务器包括一个或多个程序以及存储一个或多个程序以供一个或多个处理器执行的存储器，并且一个或多个程序包括用于执行过程2100的指令。在一些实施方式中，非暂时性计算机可读存储介质存储一个或多个相应程序，所述一个或多个相应程序包括指令，所述指令在由具有一个或多个处理器的服务器执行时使服务器执行过程2100。

过程2100包括从与在线游戏会话相关联的第一客户端设备(例如，游戏控制器102A)接收(2102)第一命令(例如，“射击”)；确定(2104)第一命令的类型(例如，表1412中的“类型1”)和与第一命令的类型相关联的第一预期响应延迟(例如，表1414或表1416中的“20ms”)；(例如，通过测量和/或估计第一游戏控制器和服务器之间的往返时间1420-1，或者通过以上参考图5至图12描述的任何其他方法)确定(2106)网络延迟；基于网络延迟与第一预期延迟的比较，确定(2108)第一引入延迟(例如，有意添加和/或调优的延迟以补偿其他类型的延迟，诸如已确定的网络延迟)；生成(2110)第一数量的中间帧(例如，图16中的帧1610-2或图20B中的帧2000)，当其以预定的帧速率被传输时，占用与第一引入延迟相对应的传输时间；生成(2112)(或以其他方式使得被处理、渲染或编码)反映第一命令的初始结果的第一响应帧(例如，图16中的帧1610-3或图20B中的帧1926)；以及以预定的帧速率传输(2114)第一数量的中间帧紧接着第一响应帧，使得在与第一预期响应延迟相对应的时间在与第一游戏控制器相关联的媒体设备(例如，106)处接收第一响应帧。

通过使用中间帧来调节命令和相应响应帧之间的响应时间，服务器可以在调优特定方面(例如，针对特定类型的用户输入的响应时间)时保持游戏会话的全局方面(例如，预定义的帧速率)。从在线游戏的角度来看，稳定的帧速率对于流畅和高质量用户体验是最佳的。此外，通过在本地级别上实现游戏调优(例如，仅针对特定类型的输入)，游戏的其他方面将继续不受阻碍，诸如不影响后续游戏状态的非关键游戏事件，但其连续渲染添加游戏玩法体验的流动性和质量。

交互式图形的基于分辨率的缩放

视觉模拟的实时渲染以与所渲染的分辨率(例如，像素数)成比例缩放的性能要求。如果通过网络将例如描绘游戏玩法场景的视频帧的视觉模拟通过网络运送给用户，则网络和/或用户的显示设备的性能可能会约束针对给定用户支持的最大分辨率。在多个用户的情况下，每个用户利用不同的网络和显示性能，高效的基础架构启用适合每个用户连接的特定分辨率的性能。以下描述包括有效、适合分辨率的虚拟化方法和底层硬件系统的各种实施方式。

诸如在线视频游戏的交互式图形应用利用底层硬件(例如，服务器系统114)来实现目标图像分辨率和帧速率。例如，如果所产生的图像帧通过网络(例如，网络112)被流送到端点(例如，媒体设备106)，则端点和网络连接的能力将决定可以维持的最大分辨率。

以下讨论用于建立交互式游戏会话并向该会话分配资源的方法和系统的各种实施方式。参考图15，在一些实施方式中，服务器系统114从客户端设备102A接收建立会话(例如，游戏会话)的请求。服务器系统(例如，设备/网络评估模块444)确定控制器102A、媒体设备106和/或显示设备108的特性以及网络110/112的特性。基于设备和网络特性，服务器系统(例如，资源指配模块432)确定会话的一个或多个目标质量参数，诸如分辨率、帧速率和延迟。根据目标质量参数，服务器(例如，资源指配模块432)将特定虚拟机或容器指配给会话，并根据该指配建立会话。根据与指配给该会话的特定虚拟机或容器相关联的资源简档(例如，存储在资源库464中)向会话提供资源。通过在服务器系统处指配底层硬件资源的专用虚拟化，游戏应用(例如，在数据中心)对硬件资源的消耗适应网络和端点的功能，从而优化效率，同时仍实现对于每个会话的所预期的性能度量。

图22是资源存储库464的示例实施方式。该存储库包括虚拟机设置2202(包括用于M个虚拟机的设置)、容器图像存储库2204(包括用于N个容器的图像)和资源简档2206(包括用于P个简档的设置)。虚拟机是安装在模仿专用硬件的软件上的操作系统或应用环境，而容器是虚拟化的操作系统。尽管两者之间存在差异，但是它们都实现虚拟化的概念。这样，除非另有明确说明，否则在整个本公开中可互换地使用虚拟机和容器。

基于目标质量参数配置虚拟机或容器。例如，基于目标分辨率(例如，“小”、“中”、“大”或720p、1080p、1440p)提供虚拟机或容器。在该示例中，虚拟机2202-1可以被称为“小”并且用于提供具有720p的分辨率的输出流，虚拟机2202-2可以被称为“中”并且用于提供具有1080p的分辨率的输出流，虚拟机2202-3可以称为“大”并用于提供具有1440p的分辨率的输出流等等。在一些实施方式中，每个虚拟机和/或容器与资源简档2206相关联。每个资源简档包括针对特定资源和资源级别的设置，其可以分配给虚拟机和/或容器。这些资源用于在会话内处理输入(例如，如上所述的输入事件)并生成输出(例如，如上所述的响应帧)。示例资源包括下述中的一个或者多个：服务器系统处的图形处理器带宽、服务器系统处的通用处理器带宽、服务器系统处的图形存储器、服务器系统处的通用存储器、服务器系统处的存储容量以及服务器系统处的输入/输出信道。当资源分配模块432将特定虚拟机或容器指配给会话或将特定虚拟机或容器与会话相关联时，根据与特定虚拟机或容器相关联的资源简档2206为该会话提供给可用资源。

图23是根据一些实施方式的资源分配过程2300的流程图。该过程可以在具有一个或多个处理器(例如，CPU 138和/或GPU 140)和存储一个或者多个程序以供一个或者多个处理器执行的存储器(例如，存储器146)的电子服务器(例如，服务器系统114，或更具体地说，游戏服务器122)处执行。在一些实施方式中，服务器包括一个或多个程序以及存储一个或多个程序以由一个或多个处理器执行的存储器，并且一个或多个程序包括用于执行过程2300的指令。在一些实施方式中，非暂时性计算机可读存储介质存储一个或多个相应程序，所述一个或多个相应程序包括指令，所述指令由具有一个或多个处理器的服务器执行时使服务器执行过程2300。

该过程开始于当服务器114从客户端设备(例如，控制器102)接收(2302)建立会话的请求时。在一些实施方式中，客户端设备102请求建立实时交互式会话，并且通过与客户端设备102的网络连接(例如，网络110/112)来接收该请求。

在接收到请求之后，服务器(例如，设备/网络评估模块444)确定(2304)与客户端设备102(例如，媒体设备106、输出设备108和/或客户端设备102本身)相关联的设备的设备能力。在一些实施方式中，设备能力是与客户端设备相关联的输出设备(例如，108)处输出的显示的最大分辨率、与客户端设备相关联的的输出设备(例如，108)处输出的显示的最大帧速率、或两者。在一些实施方式中，输出设备本身将设备能力信息直接传达给服务器或通过客户端设备传达。在一些实施方式中，设备能力信息被本地存储在客户端设备上，并且客户端设备将设备能力信息与用于建立会话的初始请求一起发送。在一些实施方式中，客户端设备响应于设备/网络评估模块444的请求来发送设备能力信息。

另外，服务器(例如，设备/网络评估模块444)确定(2306)网络连接(例如，网络110/112)的连接能力。在一些实施方式中，连接能力是网络连接的带宽和/或与网络连接相关联的一个或多个延迟值。上面参考图5至图12讨论示例延迟值以及获得它们的方法。

在评估设备和网络能力之后，服务器(例如，资源指配模块432)基于设备能力和网络连接能力来确定(2308)用于实时交互式会话的一个或多个目标质量参数。在一些实施方式中，一个或多个目标质量参数包含目标分辨率、目标帧速率和/或对于传输到输出设备的内容(例如，响应帧)的目标延迟中的一个或者多个。

在已经确定目标质量参数之后，服务器(例如，资源指配模块432)基于一个或多个目标质量参数来选择(2310)虚拟机或容器。在一些实施方式中，资源指配模块432通过(i)将一个或多个目标质量参数与多个虚拟机的相应资源简档中的对应参数进行比较；(ii)确定哪个资源简档包括与一个或多个目标质量参数最紧密匹配的参数；并且(iii)选择具有与一个或者多个目标质量参数最紧密匹配的资源简档的虚拟机作为第一虚拟机来选择虚拟机，来选择虚拟机或容器。例如，如果目标帧速率是120fps，则资源指配模块432将目标帧速率与支持120fps的帧速率的资源简档2206中的参数进行比较，确定特定资源简档(例如，2206-2)将能够最好地支持目标帧速率，并选择与简档2206-2相关联的虚拟机(例如，虚拟机2)。

在一些实施方式中，资源指配模块432通过(i)将一个或多个目标质量参数与多个虚拟机的相应资源简档中的对应参数进行比较；(ii)选择具有参数大于或等于一个或多个目标质量参数的资源简档的一个或多个虚拟机作为虚拟机候选；并且(iii)选择具有最少资源密集型资源简档的虚拟机候选作为第一虚拟机，来选择虚拟机或容器。例如，如果目标帧速率是120fps，则资源指配模块432将目标帧速率与资源简档2206中的参数进行比较，其选择具有等于或大于支持目标帧速率所需的那些的资源(例如，将支持100fps、120fps、240fps等目标帧速率的资源)的那些作为候选，并且选择资源具有最少的资源密集型资源简档(例如，可以支持100fps的简档，但是不一定是120fps的简档)的候选。通过选择资源最少的资源简档，服务器仅指配所需要的那些资源，为其他会话保留额外资源，并且从而在优化服务器处的效率的同时达到目标性能水平。

在一些实施方式中，选择虚拟机包括将所选择的虚拟机与实时交互式会话相关联，并且保持该关联，不管设备或网络连接能力的任何变化如何。在一些实施方式中，在预定时间段内保持关联。在一些实施方式中，资源指配模块432在检测到设备或网络连接能力的变化时重新评估该关联。在一些实施方式中，仅当变化大于预定阈值时，资源指配模块432才基于检测到的设备或网络连接能力的变化来重新评估该关联。通过限制虚拟机或容器的重新指配，服务器达到目标性能水平同时优化稳定性，并且因此在服务器处优化效率。

在选择虚拟机或容器的情况下，服务器114根据所选的虚拟机或容器建立(2312)实时交互式会话，并根据第一虚拟机的资源简档将实时交互式会话内的用于在该会话内处理输入(例如，如上所述的输入事件)并生成输出(例如，如上所述的响应帧)的资源提供(2314)给实时交互式会话。用于处理输入和生成输出的示例资源包括下述中的一个或者多个：服务器系统处的图形处理器带宽、服务器系统处的通用处理器带宽、服务器系统处的图形存储器、服务器系统处的通用存储器、服务器系统处的存储容量和/或服务器系统处的输入/输出信道。在一些实施方式中，通过将资源中的一个或多个的相应部分指配给实时交互式会话来提供资源。在一些实施方式中，通过将所选虚拟机或容器的资源简档映射到一个或多个资源的相应部分(例如，到特定存储器分区或特定输入/输出信道)来提供资源。

在一些实施方式中，基于所提供的资源等级，使虚拟机或容器的一个或多个子集作为不同的服务层可用。例如，为较高的服务层付费的用户可以接收对具有提供相对较高的资源(例如，“大”分辨率，较高的处理器带宽分配数等)的资源简档的虚拟机或容器的优先级访问。在一些实施方式中，在线游戏环境100的用户通过支付溢价，实现游戏中的奖励或高的游戏中的表现统计，或利用特定游戏公司提供的促销来得到对较高服务等级的访问。在一些实施方式中，用户基于特定偏好(例如，高分辨率和平均帧速率、平均分辨率和高帧速率等等)来构建定制包。在这些实施方式中，不同版本的自定义包与一个或多个虚拟机或容器相关联。

重要的是要注意，由于上述实时交互式会话的游戏性质，控制器到显示器的延迟是必须被监视的问题，以便于保持高质量和一致的游戏玩法体验。这样，提供如上所述的虚拟机或容器确保通过确保给各个用户或用户组的专用资源满足确保最低延迟标准所必要的资源。此外，随着游戏会话的使用扩展到涉及多个玩家的游戏(例如，大型多玩家在线角色玩游戏)，资源通过虚拟机和容器的虚拟供应通过促进针对每个玩家的公平竞争环境，进一步确保高质量的游戏玩法体验(例如，通过确保满足每个玩家的最小延迟标准)。例如，如果两个玩家正在玩同一在线游戏，则可以为游戏服务器和第一客户端设备之间的第一会话指配虚拟机或容器，该虚拟机或容器与指配给第二游戏服务器和第二客户端设备之间第二会话的虚拟机或容器不同，即使第一和第二客户端设备正在并行玩同一游戏。通过基于每个会话指配虚拟机或容器，可以在确保每个用户所需的游戏玩法体验的同时优化硬件资源。

在某些实施方式中，使用软件开发工具包设计应用，其考虑底层容器的大小，并且可以“合理精简(right-size)”应用对硬件和/或虚拟化硬件的使用，以实现给定大小的所需性能。在一些实施方式中，使各种尺寸的容器的实例在接近端点的位置中可用。当端点连接到资源指配模块432以建立新会话时，设备/网络评估模块444评估端点能力和网络能力，并且资源指配模块432进行大小确定。一旦确定，就将会话附接到具有相应大小的虚拟机或容器，并以相应的分辨率、帧速率或延迟水平启动内容交付。通过“合理精简”应用对硬件资源的消耗到网络能力和端点能力两者的能力，服务器实现所需性能水平同时优化效率。

用户特定的网络条件调优

在在线、交互式、实时游戏环境中，延迟是影响游戏玩法质量的关键因素之一。如上所述，存在许多网络和处理元件，其可以将不同水平的延迟引入游戏环境。最小化延迟的负面影响通常会以处理能力和复杂性为代价，尤其是在处理来自多个游戏会话的许多游戏玩法输入并将游戏玩法输出内容并行流送给许多用户时。因此，对于游戏环境(例如，服务器系统114和/或游戏服务器122)而言，明智地分配处理资源是重要的。

分配处理资源的一种方法是在每个用户的基础上考虑游戏环境用户的需求和体验，并相应地分配资源。例如，不同用户具有对不良可玩性事件的不同容忍水平。一些用户可能比其他用户对特定级别的延迟更敏感。例如，一些玩家可能反对20ms的控制器到显示器的延迟，而其他玩家可能仅在120ms时观察到与延迟相关的问题。考虑到资源受限，确定对不良可玩性事件和条件的容忍水平的能力使其能够做出更好的分配决策。基于用户特定的资源分配的好处包括由于更高的优化处理效率而为所有用户带来更好的体验，这导致支持更多用户的能力，并降低为每个用户服务内容的成本。

以下讨论用于在用户特定的基础上调优网络条件(分配网络资源)的方法和系统的各种实施方式。在一些实施方式中，游戏服务器(例如，图4的资源调优模块458)考虑每个用户的可用游戏玩法统计信息的集合(例如，图24B的简档2402)，并基于每个用户的游戏玩法统计信息确定用于每个用户的可玩性的窗口。示例性游戏玩法统计信息包括游戏中的表现(例如，用户如何玩游戏)、控制器交互(例如，对运动、响应时间和/或操纵速度的过度补偿)、用户正在玩的游戏类型(例如，快节奏对比慢节奏)、以及用户偏好(由游戏服务器推断或由用户指定)。在一些实施方式中，游戏服务器基于自我报告的数据确定每个用户的可玩性。在一些实施方式中，游戏服务器观察用户在游戏中的行为以确定如何对游戏体验进行分类，并使用该信息来确定将从何处服务流以及服务器如何发送体验。在一些实施方式中，通过将确定针对每个游戏玩法统计信息的特定权重的机器学习应用于用户的可玩性分类来增加上述方法。

图24A是用于用户可玩性简档2402的存储库的示例实施方式。在一些实施方式中，可玩性简档(例如，表示N个用户的游戏玩法统计信息)作为用户信息458存储在存储器146中(图4)。

在一些实施方式中，游戏玩法统计信息包括游戏中的表现数据。用户的示例游戏中的表现数据包括特定游戏的用户技能水平(例如，用户玩游戏如如何的测量)。在一些实施方式中，游戏服务器(例如，资源调优模块458)通过将用户的活动或成绩与某些游戏特定基准进行比较来确定用户的技能水平，诸如是用户达到检查点所耗费的时间量、用户针对某个对手或挑战实现多少胜利、用户获得多少点等。在一些实施方式中，资源调优模块458将用户的游戏中的表现数据(例如，技能水平)与其他用户的对应表现数据或与代表当前正在玩或已经玩游戏的多个用户的平均表现度量进行比较。

在一些实施方式中，游戏玩法统计信息包括控制器交互数据，诸如描述用户与游戏控制器102的交互的数据。在一些实施方式中，控制器交互数据描述用户响应时间，诸如在(i)刺激在(例如，在显示器108上)被显示给用户的输出帧中被渲染，和(ii)用户通过将游戏玩法输入发送到服务器(例如，通过与游戏控制器102上的控件进行交互)而对刺激做出响应之间的时间量。例如，参考图5B，如果在第一游戏玩法时间t₁显示触发帧510-1，并且用户在第二游戏玩法时间t₂响应，则显示器到控制器的交互延迟是t₂和t₁之间的差。。具有更快反应时间的用户将与表示更短响应时间的控制器交互数据相关联。

在一些实施方式中，游戏玩法统计信息包括控制器操纵速度数据，诸如描述用户(例如，通过与两个控件进行串行交互，或者通过与同一控件连续两次交互)注册连续输入有多快的数据。例如，参考图16，如果用户试图通过操纵第一控件以移动玩家A就位(帧1610-3)并且然后操纵第二控件以使玩家A射击冰球(帧1610-5)来得分，用户的控制器操作速度是指在操作第一控件和操作第二控件之间耗费的时间量。能够更快地操纵游戏控制器102上的控件的用户将与表示在连续操纵或交互之间的较短操纵时间的控制器操纵数据相关联。

在一些实施方式中，游戏玩法统计信息包括控制器性能数据，诸如描述用户与控制器102如何准确交互的数据。例如，参考图16，当用户移动玩家A就位(帧1610-3)时，具有相对较高的技能的用户将与适当的控件进行交互(例如，按住和保持“移动”按钮)时间足够长，使虚拟玩家移动到正确位置，而具有相对较低的技能的用户可能会过度补偿或补偿不足(例如，将“移动”按钮按住太长或不够长)，从而将虚拟玩家移动到错误的位置并失去射击。可以更精确地操纵游戏控制器102上的控件的用户将与表示更高精确度的控制器性能数据相关联。

在一些实施方式中，可玩性简档2402包括正在玩的游戏的类型。例如，与不需要快速决策或运动的更为宽松的策略游戏相比，诸如以上各种示例中所描述的游戏的高速曲棍球游戏可能需要更快的游戏玩法和更少的延迟。这样，取决于游戏类型，在诸如表现或技能水平的其他统计信息的场境中，如控制器响应时间和精确度的统计信息可能具有不同的含义，或者完全没有意义。

在一些实施方式中，可玩性简档2402包括关于对游戏玩法的某些方面的容忍水平的可玩性偏好。例如，不管用户在游戏中的表现或者与控制器进行交互有多好或多差如何，用户都可能更喜欢某个水平的分辨率、帧速率和/或延迟。例如，如果用户习惯于或偏爱与特定延迟水平相关联的特定游戏玩法体验，则提供更快的响应时间可能是最好不必要的(因为用户更喜欢较慢的响应时间)，并且是最不利的(因为如果用户无法适应更快的响应时间，则用户可能也无法玩游戏)。作为又一示例，由于个人观看偏好，用户可能更喜欢比服务器系统114可以以其它方式提供的帧速率更慢的帧速率。结果，用户的偏好是服务器系统114如何分配资源的因素。在一些实施方式中，用户手动键入这些偏好并且服务器(例如，资源调优模块458)根据手动键入的设置存储用户的偏好。可替选地，服务器推断这些偏好。在一些实施方式中，服务器根据用户的游戏玩法统计信息(例如，游戏中的行为和表现数据)推断用户的偏好。

在确定如上所述的各种游戏玩法统计信息之后，资源调优模块458根据上述一个或多个游戏玩法统计信息(例如，游戏中的表现数据)向用户指配游戏玩法体验容忍水平。游戏玩法体验容忍水平是描述游戏服务器可以为用户提供的服务水平同时不会负面影响用户的感知游戏玩法体验的一种度量。游戏玩法体验容忍水平也可以描述为不良延迟水平、可玩性水平、质量预期水平和/或最小服务容忍水平。在一些实施方式中，体验容忍水平表示被确定为具有对与第一客户端设备的用户相关联的感知游戏玩法体验具有小于阈值量的影响的特定帧速率、特定分辨率和/或特定延迟水平。

图24B是资源设置466的表的示例实施方式。在一些实施方式中，资源设置466存储在存储器146(图4)中。根据示例资源设置466，第一容忍水平(“1”)与特定资源简档(“A”)相关联。上面参考图22描述资源简档的示例(资源简档2206)。通过向具有特定游戏玩法容忍水平的用户指配或分配资源简档(例如，服务器处理器带宽)，服务器系统114仅在提供游戏玩法水平体验所必需的最小限度的资源的情况下向用户提供预期的游戏体验(例如，在用户的容忍范围内)。

图25是根据一些实施方式的资源调优过程2500的流程图。该过程可以在具有一个或多个处理器(例如，CPU 138和/或GPU 140)和存储一个或多个程序以供一个或者多个处理器执行的存储器(例如，存储器146)的电子服务器(例如，服务器系统114，或更具体地说，游戏服务器122)处执行。在一些实施方式中，服务器包括一个或多个程序以及存储一个或多个程序以供一个或多个处理器执行的存储器，并且一个或多个程序包括用于执行过程2500的指令。在一些实施方式中，非暂时性计算机可读存储介质存储一个或多个相应程序，所述一个或多个相应程序包括指令，当该指令由具有一个或多个处理器的服务器执行时使服务器执行过程2500。

该过程开始于当服务器114与第一客户端设备(例如，游戏控制器102)建立(2502)实时交互式游戏会话时，该游戏会话与特定游戏类型(例如，快速节奏角色扮演游戏或较慢节奏的策略游戏)相关联。当游戏控制器102的用户通过游戏会话来玩游戏时，服务器(例如，资源调优模块458)在游戏会话期间监视(2504)与该用户相关联的游戏中的表现数据。示例游戏中的表现数据包括如上所述的游戏玩法统计信息、表现度量、技能水平、控制器响应时间、控制器操纵时间和/或控制器精度。在一些实施方式中，游戏中的表现数据被存储在用户的简档2402中。

基于游戏中的表现数据(例如，游戏玩法技能、控制器交互)、游戏类型和/或用户偏好，资源调优模块458确定(2506)用户的游戏玩法体验容忍水平。例如，如果用户具有相对较高的技能水平、更快的响应(更短的控制器响应时间)、更快的游戏控制能力(更短的控制器操纵时间)和/或更高的控制器精度，则调优模块458指配与更高的资源简档(例如，将更多的资源分配给用户的游戏会话)和/或与更高质量的游戏玩法体验(例如，更高的帧速率、更高的分辨率和/或更低的延迟)相对应的容忍水平。另一方面，如果用户具有相对较低的技能水平、较慢的响应(较长的控制器响应时间)、较慢的游戏控制能力(较长的控制器操纵时间)和/或较低的控制器精度，则调优模块458指配与较低的资源简档相对应(例如，将更多的资源分配给用户的游戏会话)和/或对应于较低质量的游戏玩法体验(例如，较低的帧速率、较低的分辨率和/或较高的延迟)的容忍水平。在一些实施方式中，容忍水平与其他游戏玩法统计信息一起存储在用户的可玩性简档2402中。

资源调优模块458基于游戏体验容忍水平调整(2508)用户游戏会话的服务器资源。会话资源示例包括服务器系统处的图形处理器带宽、服务器系统处的通用处理器带宽、服务器系统处的图形存储器、服务器系统处的通用存储器、服务器系统处的存储容量、服务器系统处的输入/输出信道、和/或流送源。在一些实施方式中，资源调优模块458通过指配如上面关于图22-23所描述的虚拟机或容器来将资源分配给游戏会话。通过调整会话资源的分配，游戏服务器影响与游戏玩法输出流(例如，描绘游戏玩法输出的视频流)相关联的帧速率、分辨率或延迟水平中的一个或多个。可替选地或另外，在一些实施方式中，资源调优模块458直接调整与游戏玩法输出流相关联的帧速率、分辨率和/或延迟水平。

在一些实施方式中，资源调优模块458通过最初将容忍水平设置为预定的起始点(例如，确定为高于确保对于大多数用户而言肯定的积极玩法体验所必需的容忍水平)，然后递增地调整容忍水平直到一个或多个用户的游戏玩法统计信息受到负面影响，确定特定用户的游戏玩法体验容忍水平。就在对用户的游戏统计信息造成负面影响之前的级别被确定为用户的游戏玩法体验容忍水平。例如，当用户建立游戏会话时，游戏服务器将初始带宽分配设置为已知或假定足够高的级别，以避免对用户在游戏中表现出色的能力产生不利影响。然后资源调优模块458递增地减少会话的带宽分配，直到用户的游戏玩法体验开始示出受到不利影响的迹象(例如，由于用户的游戏中的表现开始降低到阈值以下)。然后，将用户的游戏玩法不受影响或不受超过阈值影响的最低带宽级别记录为用户的游戏玩法容忍水平的一部分。

在一些实施方式中，用户访问用户的游戏体验容忍水平。例如，游戏服务器向用户提供用户的可玩性简档2402中的信息。通过向用户提供可选的信息以查看用户的可玩性简档信息，用户可以使用相关联的游戏玩法统计信息作为度量来跟踪用户的游戏玩法进度(例如，用户是否正在改善游戏中的表现)，和/或将某些游戏玩法统计信息与其他用户的统计信息进行比较。

本文所述的各种实施方式有效地利用带宽和计算资源，以基于如通过监视每个用户的游戏玩法表现来确定的用户自己的独特能力为用户提供最佳游戏玩法体验。通过根据每个用户的特定游戏风格、技能、需求和/或偏好在每个用户的基础上调优服务器资源，由于更高度优化的处理效率，本文所述的各种实施方式为所有用户提供更好的体验，这导致支持更多用户的能力，并降低为每个用户服务内容的成本。

关于本公开的注释

已经详细参考各种实施方式，其示例在附图中被图示。在以上详细描述中，阐述许多具体细节以便于提供对本发明和所描述的实施方式的透彻理解。然而，可以在没有这些具体细节的情况下实践本发明。在其他情况下，未详细描述公知的方法、过程、组件和电路，以免不必要地使实施方式的各方面不清楚。

将会理解，尽管在本文中可以使用术语“第一”、“第二”等来描述各种元件，但是这些元件不应受到这些术语的限制。这些术语仅用于区分一个元件和另一个元件。例如，第一设备可以被称为第二设备，并且类似地，第二设备可以被称为第一设备，同时不改变描述的含义，只要第一设备的所有出现都被一致地重命名并且第二设备的所有出现被一致重命名。第一设备和第二设备都是设备，但是它们不是同一设备。

本文所使用的术语仅出于描述特定实施方式的目的，并且不旨在限制权利要求。如在实施方式和所附权利要求书的描述中所使用的，单数形式“一”、“一个”和“该”也旨在包括复数形式，除非场境另外明确指出。还将会理解，本文所用的术语“和/或”指代并涵盖一个或多个相关联所列项目的任何和所有可能的组合。还将会理解，在本说明书中使用时，术语“包括”和/或“包含”指定存在所述特征、整数、步骤、操作、元件和/或组件，但不排除一个或多个其他特征、整数、步骤、操作、元素、组件和/或其组的存在或者添加。

如本文中所使用的，术语“如果”可以被解释为意指“当”、“在……时”或“响应于确定”或“根据确定”或“响应于检测”，所陈述的条件先例为真，具体取决于场境。类似地，短语“如果确定[所陈述的条件先例为真]”或“如果[所陈述的条件先例为真]”或“当[所陈述的条件先例为真]”可以被解释为意指，取决于场境，“在确定所陈述的条件先例为真之后”或者“响应于确定所陈述的条件先例为真”或者“根据确定所陈述的条件先例为真”或者“在检测所陈述的条件先例为真之后”或者“响应于检测所陈述的条件先例为真”。

出于解释的目的，已经参考特定实施方式描述前述描述。然而，以上说明性讨论并非旨在穷举或将本发明限制为所公开的精确形式。鉴于以上教导，许多修改和变化是可能的。选择和描述实施方式以便于最好地解释本发明的原理及其实际应用，从而使本领域的其他技术人员能够最佳地利用本发明以及具有各种修改的各种实施方式，以适合于预期的特定用途。