CN101336424B - Xna关系管理 - Google Patents

Abstract

一种数据提供者应用程序编程接口(API)被配置成用于游戏内容编辑应用程序。用该数据提供者API生成的资产关系管理文件包括诸如关系引用和注释等信息，并在编辑数字资产时由数据提供者API更新。该资产关系管理文件然后被存储到数据存储中。基于数据存储中的资产关系管理文件生成资产关系图。该资产关系图包括绘制资产文件之间的依赖性关系的资产图节点。还描述了图形API。该图形API被配置成通过服务器进程访问关系图以向诸如应用程序等客户机进程展示依赖性关系和注释。因此，可容易地评估一个资产的改变对其他资产的影响。

Description

XNA关系管理

技术领域

本发明涉及用于管理数字游戏内容关系信息的方法和系统。

背景技术

诸如用于玩视频游戏的控制台等媒体控制台在近年来实现了重要的市场渗透。因此，游戏开发者尤其关注以有利的方式生产游戏以便出售。然而，开发游戏和其他媒体控制台软件要求大艺术家和程序员团队相当的努力。由艺术家和程序员组成的游戏开发团队通常对新游戏的离散部分工作，而对其自己开发组内的其他艺术家和程序员的并发工作没有清楚的了解。在这样的开发环境中，由艺术家开发的游戏组件可包括若干组件元素，这些元素也可被包括在其他组件中。

游戏或其他软件应用程序的多个组件可共享软件元素，不同的组件对同一元素文件或数据具有依赖性关系。例如，游戏中汽车的形状可由原始“汽车”网格定义，对其应用若干颜色、材质和纹理。例如，可将特定的红色用于车身颜色，而包括纹理和颜色两者的“铬黄”可用于汽车上的高光处。在该示例中，颜色/纹理“铬黄”也可能用于游戏的其他汽车和组件。不幸的是，在游戏开发期间，当艺术家改变其他组件共享的颜色或纹理元素时，不可能容易地确定哪些其他组件受到该艺术家的改变的影响。而且，多个依赖性可能直到应用程序被编译和执行时才变得明显，导致不期望的改变仅在质量审阅周期期间才变得明显。而且，有可能难以在编译步骤之前确定在修改互相共享的组件纹理或颜色时实际导致不期望改变而未审阅游戏中可能受到影响的每一组件的艺术家。

通常作出导致曾经使用的纹理文件在游戏中不再被使用但仍被包括在该游戏的文件集中的改变。结果，众多游戏包括不再被游戏使用或不再为游戏所需的剩余的内容和/或孤立的文件。因为可能不清楚什么组件可能会受到删除纹理文件的不利影响，因此游戏开发员在开发期间对删除内容是犹豫的。相应地，在游戏开发行业内需要开发便于管理游戏内容以及组件与呈现这些组件所使用的文件之间的关系的新方法。需要以最小成本普遍适用，且解决在游戏开发期间出现的这些和其他相关问题的方法。

发明内容

以下提供描述用于管理数字游戏内容关系信息的实现的若干示例。游戏内容关系信息一般与存在于诸如客户机-服务器游戏开发环境等分布式处理系统内的一组数字游戏内容文件相关联。

以下更详细描述的一个实现包括诸如提供用于在客户机进程与服务器进程之间通信的数据提供者API的步骤。该数据提供者API被描述为被配置成用于游戏内容编辑应用程序或工具。另一步骤针对使用该数据提供者API来生成资产关系管理文件。在该示例性实现中，该资产关系管理文件包括诸如关系引用和注释等信息。该资产关系管理文件由数据提供者API为正由客户机内容编辑进程编辑的数字资产而产生。该内容和编辑进程例如可以是艺术编辑或声音编辑应用程序的一部分。又一步骤针对将该资产关系管理文件存储到一数据存储。最后，该示例性实现包括生成基于一组资产关系管理文件的资产关系图的步骤。该资产关系图一般包括绘制数字游戏内容文件之间的依赖性关系的资产图节点。以下描述的另一示例性实现包括提供用于在分布式处理系统中在客户机进程与服务器进程之间通信的图形API的步骤。在该示例性实现中，图形API被配置成通过服务器进程访问关系图以向客户机进程展示资产关系数据和注释数据。

提供本概述以便以简化形式介绍将在以下描述中进一步描述的一些概念。然而，本概述不旨在标识所要求保护的主题的关键或必要特征，也不旨在用于帮助确定所要求保护的主题的范围。

附图说明

当结合附图参考以下详细描述时，可以更容易领会并更好地理解一个或多个示例性实施例及其修改的各个方面和附带的优点，附图中：

图1是适于实现一个或多个分级标记和/或搜索功能的一般的常规计算设备的功能框图；

图2是用于启用数字内容关系管理的系统的功能框图；

图3是用于启用数字内容关系管理的系统的另一功能框图；

图4是示出用于在分布式处理系统内管理与数字游戏内容文件相关联的数字游戏内容关系信息的示例性方法的步骤的流程图；

图5是示出用于通过ARM_图形应用程序编程接口(API)来访问资产关系的示例性方法的流程图；以及

图6是示出用于用ARM数据提供者API生成资产关系管理文件的示例性方法的流程图。

具体实施方式

附图和所公开的实施例不是限定性的

示例性实施例在所参考的附图中示出。此处公开的实施例和附图旨在被认为是说明性而非限制性的。而且，在以下权利要求书中，当备选项列表在短语“至少其中之一”或短语“之一”之前使用连词“和”时，“和”的意义对应于连词“或”。

示例性计算系统

图1是用于实现在计算设备上诸如通过网络、因特网或甚至在单个计算设备上起动的数字内容关系管理功能的各个方面的示例性计算设备和/或计算机服务器的功能框图。

以下讨论旨在提供对可实现以下讨论的某些方法的合适的计算环境的简要概括描述。此外，以下讨论示出了用于用计算系统实现诸如程序模块等计算机可执行指令的上下文。一般而言，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等。本领域的技术人员可以认识到，可应用其他计算系统配置，包括多处理器系统、大型机、个人计算机、处理器控制的消费电子产品、个人数字助理(PDA)(但在需要服务器功能时可能没有)等。一个实现包括分布式计算环境，其中任务由通过通信网络链接的远程处理设备来执行。在分布式计算环境中，程序模块可以位于本地和远程存储器存储设备中。

参考图1，描述了用于实现各个方法的示例性系统。该系统包括常规PC 20形式的通用计算设备，其配备有处理单元21、系统存储器22和系统总线23。系统总线将包括系统存储器在内的各个系统组件耦合至处理单元21，且可以是若干类型的总线结构中的任一种，包括存储器总线或存储器控制器、外围总线和使用各种总线体系结构中的任一种的局部总线。系统存储器包括只读存储器(ROM)24和随机存取存储器(RAM)25。

基本输入/输出系统26(BIOS)包含允许诸如系统启动时在PC 20中的元件之间传递信息的基本例程，它被存储在ROM 24中。PC 20还包括用于对硬盘(未示出)进行读写的硬盘驱动器27、用于对可移动磁盘29进行读写的磁盘驱动器28、以及用于对诸如压缩盘只读存储器(CD ROM)或其它光介质等可移动光盘30进行读写的光盘驱动器31。硬盘驱动器27、磁盘驱动器28以及光盘驱动器30分别通过硬盘驱动器接口23、磁盘驱动器接口32和光盘驱动器接口33连接至系统总线23。驱动器及其关联的计算机可读介质为PC 20提供了对计算机可读机器指令、数据结构、程序模块和其它数据的非易失性存储。尽管所述示例性环境采用硬盘27、可移动磁盘29和可移动光盘31，但本领域的技术人员可以认识到，也可使用可存储可由计算机访问的数据和机器指令的其他类型的计算机可读介质，诸如磁带盒、闪存卡、数字视频盘(DVD)、贝努利盒式磁带、RAM、ROM等。

多个程序模块和/或数据可被存储在硬盘27、磁盘29、光盘31、ROM24或RAM 25上，包括操作系统35、一个或多个应用程序36、其它程序模块37和程序或其他数据38。用户可通过如键盘40和定位设备42等输入设备在PC 20中输入命令和信息并提供控制输入。定点设备42可包括鼠标、指示笔、无线遥控器或其他用户交互式指示器。如以下描述中所使用的，术语“鼠标”旨在涵盖可用于控制光标在屏幕上的位置的任何定点设备。其它输入设备(未示出)可以包括话筒、操纵杆、触觉操纵杆、摇杆、脚踏开关、游戏手柄、圆盘式卫星天线、扫描仪等。而且，PC 20可包括用于与其他接口设备，诸如打印机或网络通信的蓝牙无线电或其他无线接口。这些和其他输入/输出(I/O)设备可通过耦合到系统总线23的I/O接口46而连接到处理单元21。短语“I/O”接口旨在涵盖专门用于串行端口、并行端口、键盘端口和/或通用串行总线(USB)的每一接口。可任选地，监视器47可经由诸如视频适配器48等适当的接口连接至系统总线23。一般而言，PC也可耦合到其他外围输出设备(未示出)，诸如扬声器(通过未示出的声卡或其他音频接口)和打印机。

以下详细描述的某些进程可在单个机器上实践，尽管PC 20也可使用至诸如远程计算机49等一台或多台远程计算机的逻辑连接在网络化环境中操作。远程计算机49可以是另一台PC、服务器(可如PC一般配置)、路由器、网络PC、对等设备或卫星或其他常见的网络节点(它们均未被示出)，且远程计算机一般包括以上结合PC 20描述的众多或全部元素，尽管在图1中仅对远程计算机示出外部存储器存储设备50。图1中描绘的逻辑连接包括局域网(LAN)51和广域网(WAN)52。这样的联网环境在办公室、企业级计算机网络、内联网和因特网中是常见的。在一个特定的实现中，PC 20是包括诸如服务器计算机、其他PC、数据库等其他计算设备的游戏开发环境的组件。

当在LAN联网环境中使用时，PC 20通过网络接口或适配器53连接至LAN 51。当在WAN联网环境中使用时，PC 20一般包括调制解调器54，或诸如电缆调制解调器、数字用户线(DSL)接口或综合业务数字网络(ISDN)接口等用于在诸如因特网等WAN 52上建立通信的其它装置。可以是内置或外置的调制解调器54可经由I/O设备接口46，即通过串行端口连接至系统总线23或耦合至总线。在网络化环境中，PC 20所使用的程序模块或其部分可被存储在远程存储器存储设备中。可以理解，所示网络连接是示例性的，且可以使用诸如无线通信和宽带网络链路等在计算机之间建立通信链路的其它手段。

示例性操作环境

图2是用于实现管理数字内容之间的关系的各个方法的示例性操作环境200的框图。如图2中所示，服务器200与数据存储210和客户机220通信。在图2中示出正由客户机220生成的资产关系管理(ARM)文件235。

服务器200可以是任何计算设备，诸如参考图1讨论的示例性计算设备和/或计算机服务器。尽管本领域的技术人员可以理解，服务器200包括这样的组件，但为清楚并为简化本公开起见，仅将服务器200示为包括处理器206和存储器207。存储器207被示为包括关系管理器应用程序201，它包括对象模型模块202、关系引擎模块203，且也可包括ARM图形API(ARM_graph)250，它们各自将在以下详细讨论。

客户机220可以是任何计算设备或系统，诸如参考图1讨论的示例性计算设备和/或计算机服务器。在某些实现中，客户机220是通过因特网上的安全连接(未示出)耦合至诸如LAN或WAN等网络或一个或多个其他计算设备的PC。在其他实现中，客户机220可以是被配置成运行诸如艺术编辑器、声音编辑器、资产报告生成器和其他生产性应用程序等应用程序的任何计算设备。如图2中所示，客户机220包括艺术编辑器应用程序221，它可用于访问、创建、修改和/或管理诸如数字游戏组件等数字内容。数字游戏组件是可执行游戏应用程序的一个元素，包括例如网格文件、纹理和/或材质文件、声音文件、人工智能(AI)文件、或其他逻辑文件、或可与其他游戏组件共享依赖性的任何其他数字资产文件。艺术编辑器221被示为包括ARM数据提供者API(ARM_data_provider)230。然而，ARM数据提供者API 230可以是追加到艺术编辑器221的或仅仅是艺术编辑器221通过API调用可访问的附加组件或模块。ARM数据提供者API 230旨在将被容易地配置成对大量现有应用程序进行翻新，以便允许按照开发平台无关的格式提供有价值的资产关系数据。

ARM文件235可包括关于特定数字资产的任何可导出信息，包括关系引用236和注释237。关系引用236是定义特定数字资产对任何其他数字资产具有的依赖性或引用关系的逻辑陈述和/或指示符。例如，如果特定的数字资产是网格文件，则关系引用236可以是该网格引用特定材质文件的逻辑陈述。然而，如果特定的数字资产改为是特定的材质文件(诸如定义颜色的文件)，则关系引用236可以是网格依赖于该特定材质文件的逻辑陈述。注释237可包括可用于导出的其他信息。例如，注释可包括资产版本指示符、资产批准指示符(例如，指示艺术家停止操作)、资产描述、资产类型指示符、与资产相关联的规则以及与资产相关联的属性。注释也可提供特定信息，诸如色深度指示符、与资产相关联的压缩算法信息、或诸如用于指示对资产的最后一次编辑的特定日期或最后停止操作日期。在一个实现中，ARM文件235是以根据资产关系管理模式的XML文档具体化的数据结构。在该实现中，模式定义表示由ARM数据提供者API从资产文件中写出的数据的对象(诸如资产标识、与资产相关联的关系引用和各个注释)的格式。尽管XML是广泛接受且应用程序中立的文档格式，但应注意，ARM文件可用任何适当的文档格式来具体化而不限于XML格式。

数据存储210包括诸如ARM文件211和资产文件212以及资产关系图215等多个数据结构，并对其提供存储。ARM文件211可以是如关于ARM文件235所述的任何资产关系管理文件。资产文件212一般是数字内容文件，诸如网格文件、材质文件、声音文件或另一数字游戏组件文件。资产关系图215可包括如图2中由节点A、B和C示出的多个节点。作为说明，图2示出节点A引用节点B和节点C，而节点B引用节点C，节C既不引用节点A也不引用节点B。而且，节点A、B和C可包括树结构，该结构还定义节点依赖性和诸如注释等附加信息的绘制(未示出)。

作为说明并为清楚起见，服务器200被示为包括关系管理器201，该管理器在图2中被示为包括对象模型模块202和关系引擎模块203。然而，在某些实现中，关系管理器201实际上是一个可执行模块，它提供对象模型202和关系引擎203两者的功能。在其他实现中，对象模型202和关系引擎203被实现为分开但操作上集成的模块。ARM图形API 250可任选地与对象模型202和关系引擎203一起位于服务器200上，或可被集成到服务器200的操作系统(未示出)内、或作为应用程序的一部分、或可被配置为独立的模块。ARM图形API 250旨在被配置成对大量现有应用程序翻新以便允许对资产关系图215中的资产关系数据的访问，从而对这些现有应用程序提供本方法的有利功能。

对象模型202被配置成提供到资产关系图215的接口。在一个实现中，对象模型202被配置成通过导航资产关系图中的节点并向作出调用的应用程序返回依赖性信息来响应于来自请求资产信息的ARM图形API的调用。在这个情况中，作出调用的应用程序可以是用于与对象模型202通信(例如，通过ARM图形API)的任何应用程序，诸如第三方工具、各种自定义工具、游戏构建系统或甚至游戏本身。关系引擎203一般被配置成聚集包含在数据存储210中的ARM文件(例如，ARM文件211)并生成该ARM文件所描述的所有不同关系、依赖性和内容注释的多图表示。

在一个示例性实现中，关系引擎203被配置成实时监控数据存储210以在新的或经修改的ARM文件被创建时标识这些文件。在该实现中，关系引擎可被配置成解析ARM文件并生成资产关系图中包含由ARM文件所标识的资产的关系信息和注释的节点。在未在图2中示出的另一实现中，关系引擎203被配置成响应于ARM图形API调用在其控制下在运行时在存储器中实例化关系图。在此实现中，资产关系图可驻留在存储器207中而非驻留在数据存储210内。该实现在运行时间效率方面是优选的，其中多个客户机寻求对迅速改变的资产关系信息的同时访问，且其中节点的总数不是特别大。

作为进一步的说明，图3是用于启用数字内容关系管理的合适的操作环境的另一功能框图。如图3中所示，服务器200再次被示为与数据存储210和客户机220通信。图2中所示的实施例将数据存储210再次示为包括ARM文件211、资产文件212和资产关系图215。服务器200被再次示为包括处理器206和存储器207，其中存储器207内存储有关系管理器201。如上所述，关系管理器201包括对象模型202和关系引擎203。为了讨论这些元素中的每一个的功能和能力，可对以上关于图2的讨论进行参考。图3的客户机220表示诸如以上参考图1和2所讨论的计算设备。尽管对于本领域的技术人员而言，显然客户机设备220将包括图1中的众多其他组件，但为清楚起见，图3仅示出处理器226和用于存储应用程序300的存储器227。ARM图形API 250被描绘在应用程序300内。然而，ARM图形API 250无需被集成到应用程序300内，且在某些实现中，它是用于客户机200的应用程序或操作系统(未示出)的插件或独立模块。

如上所述，ARM图形API 250旨在可被配置成对大量现有应用程序和/或操作系统翻新，以允许从在客户机设备上执行的进程对资产关系图215中的资产关系数据的访问。在一个示例中，应用程序300是可用于生成资产依赖性报告的报告工具，它可在游戏开发期间用来标识孤立资产或跟踪对资产文件的不想要的改变。在另一实现中，应用程序300可以是游戏构建流水线的组件应用程序，它可通过ARM图形API来调用资产关系图215以便例如优化游戏可执行代码的构建或重建、测试功能、实现质量保证任务以及实现证书批准进程。

图4是示出用于在分布式处理系统内管理与数字游戏内容文件相关联的数字游戏内容关系信息的示例性方法的步骤的流程图。方法400在某些实施例中可用如上参考图1-3讨论的组件、设备和技术来实现。在某些实现中，方法400的一个或多个步骤被体现在存储计算机可读代码的计算机可读介质上，使得当在诸如微处理器等计算设备上执行计算机可读代码时，实现一系列步骤。在以下描述中，参考可执行某些方法步骤且与同样可执行某些方法步骤的服务器适当通信的客户机设备的处理器来描述方法400的各个步骤。在某些实现中，方法400的某些步骤可被组合，且可同时或按不同次序执行，而不背离方法400的目的且也不产生不同的结果。

方法400开始于步骤410，在那里提供用于在分布式处理系统中在客户机进程与服务器进程之间通信的数据提供者API。在一个实现中，该数据提供者API可被配置成用于游戏内容编辑应用程序或工具。一般而言，数据提供者API可作为用于现有应用程序或软件模块的插件、或附加组件而提供。在数据提供者API被安装并被配置为用于诸如用于网格或声音编辑的艺术编辑器等应用程序时，启用该API。

在步骤420，用数据提供者API生成资产关系管理文件。在某些实现中，资产关系管理文件可包括唯一标识特定数字资产文件的数字资产标识、描述与其他数字资产文件的链接和/或依赖性关系的关系引用、以及可包括与资产文件有关的信息的注释。一般而言，资产关系管理文件由数据提供者API从正在由诸如编辑网格文件或声音文件的客户机内容编辑进程编辑的数字资产中写出。

在步骤430中，资产关系管理文件被存储在一数据存储中，例如被储存在硬盘上。资产关系管理文件可在其生成之后的任何时间存储。在某些实现中，ARM文件首先被高速缓存然后被存储。在另一实现中，ARM文件在被存储之前由关系引擎排队，以便允许对文件的即时处理。ARM文件的某些实现可包括定义注释对象和关系引用对象的资产关系管理模式。在一个示例中，资产关系管理文件以根据资产关系管理模式的XML文档来具体化。在另一示例中，注释可包括资产版本指示符、资产批准指示符、资产描述、或色深度指示符中的一个或多个。在其他示例中，注释可包括以下的一个或多个：与资产相关联的压缩算法数据、日期指示符、资产类型指示符、与资产相关联的规则、或与资产相关联的属性。注释可以是可用于从资产写出并作为资源对该进程中的其他用户可用的任何信息。

在步骤440中，基于资产关系管理文件生成资产关系图。在某些实现中，资产关系图由绘制一组数字游戏内容文件之间的依赖性和引用关系的一系列资产图节点组成。在一个示例性实现中，生成的步骤包括首先将资产关系管理文件提供给关系管理引擎的步骤。在该实现中，关系管理引擎可被配置成与数据存储通信。该实现还包括解析资产关系管理文件以标识每一关系引用和注释的步骤。该实现的最后一个步骤包括在资产关系图中生成节点树。在该步骤中，节点树首先与资产关系管理文件相关联，然后被映射到资产关系图中与在解析步骤中标识的任何关系引用和注释相关联的每一资产节点。从而，资产关系图的每一节点可对应于诸如游戏组件等数字内容文件，且可绘制该节点本身与关系管理引擎可访问的ARM文件所描述的任何其他数字内容文件之间的关系。另一示例性的实现还包括配置关系引擎以监控数据存储并标识每一新资产管理文件然后调用关系引擎以将每一标识的新资产管理文件作为唯一节点映射到资产关系图的实例化中的步骤。应注意到，资产关系图可在数据存储内或任何其他合适的存储器位置内实例化，诸如在服务器存储器内。

另一示例性实现还包括提供用于在分布式处理系统中在客户机进程与服务器进程之间通信的图形API的步骤。在某些实现中，图形API可被配置成通过服务器进程访问关系图以便向客户机进程展示资产关系数据和注释数据。图形API的一个实现包括一系列步骤，诸如接收请求与特定资产相关联的信息的客户机进程对图形API的调用，以及响应于该调用从图形API发出资产信息请求。其他步骤包括向关系图询问与特定资产相关联的信息，然后从图形API向客户机进程返回对请求的响应。在该实现中，响应与特定资产相关联且是基于询问的。

另一示例性实现包括一系列步骤，诸如通过图形API访问资产关系对象模型。在该实现中，资产关系对象模型被配置成导航资产关系图的多个资产节点，然后展示关系引用和注释。该实现中的下一步骤包括标识资产关系图中与特定资产相关联的每一关系引用。

图5是示出用于通过ARM图形应用程序编程接口(API)来访问资产关系的示例性方法500的流程图。方法500在某些实施例中可用如上参考图1-3讨论的组件和技术来实现。在某些实现中，方法500的一个或多个步骤被体现在包含计算机可读代码的计算机可读介质中，使得当在诸如微处理器等计算设备上执行计算机可读代码时，实现一系列步骤。在以下描述中，参考可执行某些方法步骤且与同样可执行该方法的其他部分的服务器适当通信的客户机设备的处理器来描述方法500的一部分。在某些实现中，方法500的某些步骤可被组合，且同时或按不同次序执行，而不背离方法500的目的且也不产生不同的结果。方法500大体描述API进程，并始于步骤510。

在步骤510中，客户机进程发出ARM图调用。ARM图调用可包括一个或多个调用参数，诸如资产标识符、数据存储标识符和客户机所请求的功能。ARM图调用可在启用图形API的任何时间进行。在某些实现中，图形API可位于客户机侧或服务器侧，但在这两种情况中均可由客户机进程调用。

在步骤520，服务器进程接收ARM图调用，然后解析该调用来检索参数。在某些实现中，ARM图调用立即调用服务器进程来解析该调用并检索参数。在其他实现中，在多个调用可在一小窗口内从不同客户机到达的情况下，调用可被高速缓存在FIFO缓冲区或队列中，然后按照接收的次序服务。

在步骤530中，服务器进程响应于ARM图调用加载ARM图。ARM图可从位于数据存储的现有ARM图加载，或可作为基于调用而在运行时生成的实例加载。ARM图可基于是否有另一加载进程正在执行而被立即加载或排队。在一个实现中，通过首先访问数据存储中对应于数字资产文件的每一ARM文件，然后从每一ARM文件提取对资产文件的每一引用，为每一资产文件生成节点，然后经由节点绘制资产文件之间的每一关系来加载ARM图。

在步骤540中，服务器进程响应于ARM图调用询问ARM图。一般，询问是基于从ARM图调用解析出的参数的。在一个示例性实现中，询问包括基于从ARM图调用中解析出的参数以及与特定资产文件有关的表面关系和注释来导航ARM图的一个或多个节点以标识对应于特定资产文件的一个或多个资产标识符。询问可在接收调用之后的任何时间进行，且ARM图可用于询问。

在步骤550，服务器进程发出具有包括资产标识符、以及资产关系引用和注释的至少其中之一的多个确认参数的ARM图确认。在某些实现中，确认参数可包括由ARM图询问确定的关系和注释。在某些实现中，服务器进程可在询问完成之后立即发出ARM图确认。在其他实现中，可根据外部参数对ARM_图确认排队并在稍后发出。

在步骤560中，客户机进程接收ARM图确认。在某些实现中，客户机进程可在确认发出之后的任何时间接收ARM图确认，且客户机进程对接收通信是活动的。其他实现包括解析ARM图确认以检索确认参数然后将所检索到的参数提供给客户机应用程序进程的步骤。在一个示例中，ARM图形API可被配置成接收ARM图确认，解析确认参数然后将检索到的参数提供给例如报告应用程序或艺术编辑器。

在一个示例性实现中，存储在有形计算机可读介质上的数据结构包括表示第一资产的第一ARM图节点。在该实现中，第一节点可包括用于唯一标识诸如游戏组件等第一数字资产的第一资产标识符、定义与另一资产的关系的关系引用、和可包括诸如二进制名或根目录等关于资产的信息的注释。在该实现中，该数据结构还包括表示第二资产的第二关系图节点，该第二资产包括第二资产标识符，以及映射到第一关系图节点的第二关系引用和第二注释的至少其中之一。

图6是示出用于用ARM数据提供者API来生成资产关系管理文件的示例性方法600的流程图。方法600在某些实施例中可用如上参考图1-3讨论的组件和技术来实现。在某些实现中，方法600的一个或多个步骤被体现在包含计算机可读代码的计算机可读介质上，使得当在诸如微处理器等计算设备上执行计算机可读代码时，实现一系列步骤。在以下描述中，参考可执行某些方法步骤且与同样可执行某些方法步骤的服务器适当通信的客户机设备的处理器来描述方法600的各个步骤。在某些实现中，方法600的某些步骤可被组合，同时或按不同次序执行，而不背离方法600的目的且也不产生不同的结果。方法600大体描述可包括应用程序进程与客户机进程之间的通信的API进程。方法600开始于步骤610。

在步骤610中，应用程序进程发出ARM数据提供者调用，它包括一个或多个调用参数，诸如资产标识符、客户机请求的功能、关系引用和注释。在一个实现中，客户机请求的功能是将参数中的一个或多个写出到ARM文件的请求。在一个实现中，应用程序进程与诸如艺术编辑器或声音编辑器等编辑器或报告生成应用程序相关联。

在步骤620中，客户机进程接收ARM数据提供者调用，并作为响应，解析调用以检索参数并执行客户机请求的功能。在一个示例性实现中，客户机进程与API模块相关联。

在步骤630中，客户机进程发出包括检索到的参数的ARM文件。在一个示例性实现中，该ARM文件是根据资产关系管理模式格式化的XML文档，该模式定义对应于一个或多个参数的一个或多个对象。在一个示例中，资产关系管理模式是简单列表。在另一示例中，资产关系管理模式是节点树。ARM文件可具有允许ARM文件与各种成品(即，现有)软件包容易地交换或一起使用的任何合适的文档格式和模式。

在步骤640中，服务器进程接收ARM文件并将ARM文件存储在数据存储(例如，硬盘驱动器)中。在某些实现中，ARM文件可与其他文件，包括与ARM文件有关的资产文件一起被本地存储。在其他实现中，站外(off-site)储存库可存储ARM文件供在按需的基础上检索。在又一实现中，ARM文件可被存储在由资产关系引擎控制的易失性或非易失性存储器位置中，以允许对运行时资产关系图创建的运行时访问。

作为进一步的说明，可参考一个游戏开发环境来描述上述内容管理应用程序和组件的示例性应用。例如，由三个分开组构成的游戏开发团队承担为新的视频游戏开发一组车辆的任务。第一组要开发消防车，第二组要开发警车，而第三组要开发赛车。第一团队开发消防车网格，它是定义消防车形状的线框。该团队将网格文件保存到中央储存库，并开始开发材质文件和声音文件，它们将与网格文件相关联并在渲染消防车时使用。在仅开发了消防车红色的右侧阴影之后，第一组保存网格文件以及至消防车红色材质文件的链接和至预先存在的引擎声音文件的链接。消防车的所有文件都被保存到其他开发组可访问的同一储存库。

同时，第二开发组根据现有汽车网格文件建立警车资产文件，为警车的黑色、白色和铬黄部分选择预先存在的材质文件，然后创建警笛声音文件，其全部由警车资产网格文件在该文件与所引用的组件文件一起被保存到中央储存库时引用。第三组建立新的跑车网格，并将其链接至消防车红色材质文件、铬黄材质文件以及预先存在的引擎声音文件。然而，第三组在开发期间判定预先存在的引擎声音文件对跑车的低吼是不适当的，并打开声音文件以便编辑。该团队希望知道这样的改变将会对游戏中的任何其他文件造成什么影响，但由于各组独立工作，第三组不了解其他组是否正在使用同一内容文件或对引擎声音的声音文件作出的改变如何影响游戏的其他资产。

然而，有了采用上述概念的游戏开发系统，当保存上述资产文件中的每一个时，一ARM文件也由ARM数据提供者API创建，它向根据关系管理模式的XML文档写出资产文件对其他资产文件具有的基本关系以及包含关于资产文件的有用信息的注释。ARM文件与其他文件，诸如其表示的原始资产文件

(例如，诸如汽车网格、颜色、纹理和声音或逻辑文件等的材质文件)一起存储在中央数据存储中。ARM文件然后可用于生成绘制由ARM文件表示的资产文件之间的所有依赖性关系的资产关系图。重要的是注意到，可对现有游戏开发或内容编辑套件翻新ARM数据提供者API，且用于模式化ARM文件中所包含的数据的关系管理模式可相当容易地跨多个平台应用。该能力可向使用不同或甚至专用开发工具的不同公司提供按照可由其他方使用的形式导出资产文件依赖性信息和关于数字资产的其他数据的能力。

例如，在上述第三组访问预先存在的引擎声音文件时，内容编辑应用程序可经由图形API来访问关系图以确定另一资产文件，即消防车资产文件依赖于该引擎声音文件。第三组因此将认识到，所编辑的引擎声音必须被保存到新文件以避免改变消防车的引擎声音。类似地，当第三组访问铬黄材质文件时，可采用ARM图形API来向该组警告警车资产文件依赖于该铬黄材质文件，从而铬黄材质文件不应改变(在同一文件名的情况下)，因为这样的改变将影响新游戏中警车的外观。如可从以上示例中明显的，工作于一游戏上的多个组可实时地、在文件被编辑和创建时、甚至跨不同的开发平台跟踪他们正在工作的资产文件，诸如网格文件、材质文件、声音文件、人工智能(AI)文件等。而且，通过ARM数据提供者API和图形API，有可能在编译游戏之前确定资产文件依赖性，从而消除孤立文件和冗余以减轻软件“肿胀”，使开发流水线流线化，并改进质量保证进程。

尽管本新颖的开发结合实现它的优选形式及其修改描述，但本领域的普通技术人员可以理解，可在所附权利要求书的范围之内对本概念作出众多其他修改。相应地，概念的范围决不旨在受到以上描述的限制，而是完全通过参考所附权利要求书来确定。

Claims (14)

1.一种用于管理与内容开发环境内的多个数字游戏内容文件相关联的数字游戏内容关系信息以允许在内容编辑进程请求时向其展示数字游戏内容文件之间的依赖性的方法，包括以下步骤：

(a)提供用于在所述内容开发环境中在客户机进程与服务器进程之间通信的数据提供者应用程序编程接口，所述数据提供者应用程序编程接口被配置成用于游戏内容编辑应用程序；

(b)用所述数据提供者应用程序编程接口生成资产关系管理文件，所述资产关系管理文件包括资产标识符以及关系引用和注释的至少其中之一，其中所述资产关系管理文件由所述数据提供者应用程序编程接口从正由所述客户机内容编辑进程编辑的数字资产中写出；

(c)将所述资产关系管理文件存储到数据存储；以及

(d)至少基于所述资产关系管理文件来生成资产关系图，所述资产关系图包括多个资产图节点，所述资产图节点绘制多个数字游戏内容文件之间的依赖性关系，每一节点由一特定的资产标识符唯一标识，从而允许在内容编辑进程请求时向其展示所述数字游戏内容文件之间的依赖性关系。

2.如权利要求1所述的方法，其特征在于，还包括提供用于在所述内容开发环境中在客户机进程与服务器进程之间通信的图形应用程序编程接口的步骤，所述图形应用程序编程接口被配置成用于通过服务器进程访问所述关系图以向所述客户机进程展示资产关系数据和注释数据。

3.如权利要求2所述的方法，还包括以下步骤：

(a)从请求与特定资产相关联的信息的客户机进程接收对所述图形应用程序编程接口的调用；

(b)响应于所述调用，从所述图形应用程序编程接口发出资产信息请求；

(c)向所述资产关系图询问与所述特定资产相关联的信息；以及

(d)从所述图形应用程序编程接口返回对于所述对客户机进程的调用的响应，所述响应与所述特定资产相关联，并基于从所述询问步骤得到的信息。

4.如权利要求3所述的方法，其特征在于，所述向关系图询问与特定资产相关联的信息的步骤包括以下步骤：

(a)通过所述图形应用程序编程接口访问资产关系对象模型，所述资产关系对象模型被配置成导航所述资产关系图的多个资产图节点，从而展示关系引用和注释；以及

(b)在所述资产关系图中标识与所述特定资产相关联的每一关系引用。

5.如权利要求1所述的方法，其特征在于，还包括提供资产关系管理模式的步骤，所述资产关系管理模式定义注释对象和关系引用对象的至少其中之一。

6.如权利要求5所述的方法，其特征在于，所述资产关系管理文件包括以XML文档来具体化的资产关系管理模式。

7.如权利要求1所述的方法，其特征在于，所述注释是以下其中之一：

(a)资产版本指示符；

(b)资产批准指示符；

(c)资产描述；

(d)色深度指示符；

(e)与所述资产相关联的压缩算法数据；

(f)日期指示符

(g)资产类型指示符；

(h)与所述资产相关联的规则；以及

(i)与所述资产相关联的属性。

8.如权利要求1所述的方法，其特征在于，所述生成关系图的步骤包括以下步骤：

(a)将所述资产关系管理文件提供给关系管理引擎，所述关系管理引擎被配置成用于与所述数据存储通信；

(b)解析所述资产关系管理文件以标识每一关系引用和注释；以及

(c)在所述资产关系图中生成节点树，所述节点树与所述资产关系管理文件相关联，并映射到所述资产关系图中与在所述解析步骤中标识的关系引用和注释的至少其中之一相关联的每一资产节点。

9.如权利要求8所述的方法，还包括以下步骤：

(a)将所述关系管理引擎配置成监控所述数据存储并标识每一新资产管理文件；以及

(b)调用所述关系管理引擎以将由此标识的每一新资产管理文件映射到所述资产关系图的实例化内作为资产节点。

10.一种用于在分布式处理系统中允许多个数字内容文件之间的关系信息被展示的方法，其中提供用于在所述分布式处理系统中在客户机进程与服务器进程之间通信的数据提供者应用程序编程接口，所述方法包括：

(a)由所述客户机进程发出具有多个调用参数的资产关系管理图调用，所述参数包括资产标识符、数据存储标识符和客户机请求功能；

(b)由所述服务器进程接收所述资产关系管理图调用，并解析所述资产关系管理图调用以检索所述多个调用参数；以及

(c)由所述服务器进程响应于所述资产关系管理图调用而加载资产关系管理图，由此允许展示所述数字内容文件之间的关系信息。

11.如权利要求10所述的方法，其特征在于，所述方法还包括：

(a)由所述服务器进程响应于所述资产关系管理图调用而询问所述资产关系管理图；

(b)由所述服务器进程发出具有包括所述资产标识符、以及资产关系引用和注释的至少其中之一的多个确认参数的资产关系管理图确认；以及

(c)由所述客户机进程接收所述资产关系管理图确认。

12.如权利要求11所述的方法，其特征在于，所述方法还包括：

(a)解析所述资产关系管理图确认以检索所述多个确认参数的至少其中之一；以及

(b)将检索到的至少一个参数提供给客户机应用程序进程，由此展示所述数字内容文件之间的关系信息。

13.如权利要求11所述的方法，其特征在于，所述资产关系管理图包括如下数据结构：

(a)表示第一资产的第一资产关系管理图节点，所述第一资产关系管理图节点包括第一资产标识符以及关系引用和注释的至少其中之一；以及

(b)表示第二资产的第二关系图节点，所述第二资产包括第二资产标识符，以及映射到所述第一关系图节点的第二关系引用和第二注释的至少其中之一。

14.如权利要求10所述的方法，其特征在于，所述方法允许应用程序进程与客户机进程之间的通信，且所述方法还包括：

(a)由所述应用程序进程发出具有多个调用参数的资产关系管理数据提供者调用，所述参数包括资产标识符、客户机请求的功能以及关系引用和注释的至少其中之一；

(b)由所述客户机进程接收所述资产关系管理数据提供者调用，并解析所述调用来检测所述参数并执行所述客户机请求的功能；

(c)由所述客户机进程发出包括检索到的参数的资产关系管理文件；以及

(d)由所述服务器进程接收所述资产关系管理文件，并将所述资产关系管理文件存储在数据存储中。

Images