EP1979825A1 - Gestion des relations avec xna - Google Patents

Gestion des relations avec xna

Info

Publication number
EP1979825A1
EP1979825A1 EP06850415A EP06850415A EP1979825A1 EP 1979825 A1 EP1979825 A1 EP 1979825A1 EP 06850415 A EP06850415 A EP 06850415A EP 06850415 A EP06850415 A EP 06850415A EP 1979825 A1 EP1979825 A1 EP 1979825A1
Authority
EP
European Patent Office
Prior art keywords
asset
graph
relationship
arm
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP06850415A
Other languages
German (de)
English (en)
Other versions
EP1979825A4 (fr
Inventor
Mel Macmahon
Boyd C. Multerer
Frank F. Savage
Josefa M. Nalewabau
Nicolas Gauvin
Shawn Hargreaves
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Corp
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Publication of EP1979825A1 publication Critical patent/EP1979825A1/fr
Publication of EP1979825A4 publication Critical patent/EP1979825A4/fr
Ceased legal-status Critical Current

Links

Classifications

    • A63F13/10—
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/60—Generating or modifying game content before or while executing the game program, e.g. authoring tools specially adapted for game development or game-integrated level editor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/45—Controlling the progress of the video game
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70—Game security or game management aspects
    • A63F13/77—Game security or game management aspects involving data related to game devices or game servers, e.g. configuration data, software version or amount of memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/36—Software reuse
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/60—Methods for processing data by generating or executing the game program
    • A63F2300/6009—Methods for processing data by generating or executing the game program for importing or creating game content, e.g. authoring tools during game development, adapting content to different platforms, use of a scripting language to create content

Definitions

  • XNA RELATIONSHIP MANAGEMENT Background Media consoles such as those used for playing video games have achieved significant market penetration over the last few years. Consequently, game developers are particularly concerned with producing games to bring to market in an expedient manner. However, developing games and other media console software requires considerable effort by large teams of artists and programmers. Game development teams composed of artist and programmers often work on discrete portions of a new game without explicit knowledge of concurrent efforts of other artists and programmers within their own development groups. In such a development environment, a game component developed by an artist may include several component elements that are also included in other components.
  • a number of components of a game or other software application may share software elements, with different components having a dependency relationship with the same element file or data.
  • the shape of a car in a game might be defined by an original "car” mesh, to which several colors, materials and textures are applied. For example, a specific red may be employed for the car body color, and "chrome,” which may comprise both a texture and a color, might be used for highlights on the car. In this example, the color/texture "chrome" will also likely be used for other cars and components of the game.
  • chrome will also likely be used for other cars and components of the game.
  • Unfortunately during game development when an artist changes a color or texture element that is shared by other components, it may not be possible to easily determine which other components are affected by the artist's changes.
  • the game content relationship information is generally associated with a set of digital game content files that exist within a distributed processing system, such as a client-server game development environment, for example.
  • One implementation described in more detail below includes steps such as providing a data provider API for communicating between a client process and a server process.
  • the data provider API is described as being configured for use with a game content editing application or tool.
  • Another step is directed to generating an asset relationship management file using the data provider API.
  • the asset relationship management file includes information, such as a relationship reference and an annotation.
  • the asset relationship management file is produced by the data provider API for a digital asset being edited by the client content editing process. This content and editing process can be, for example, part of an art editing, or sound editing application.
  • Yet another step is directed to storing the asset relationship management file to a data store.
  • the exemplary implementation includes the step of generating an asset relationship graph that is based on a set of asset relationship management files.
  • the asset relationship graph generally includes asset graph nodes that map dependency relationships between digital game content files.
  • Another exemplary implementation described below includes the step of providing a graph API for communicating between a client process and a server process in the distributed processing system.
  • the graph API is configured for accessing the relationship graph through a server process to expose asset relationship data and annotation data to the client process.
  • FIGURE 1- is a functional block diagram of a generally conventional computing device that is suitable of implementing one or more grade level tagging and/or searching functions;
  • FIGURE 2 is a functional block diagram of a system for enabling digital content relationship management;
  • FIGURE 3 is another functional block diagram of a system for enabling digital content relationship management
  • FIGURE 4 is a flow diagram illustrating the steps of an exemplary method for managing digital game content relationship information associated with digital game content files within a distributed processing system
  • FIGURE 5 is a flow diagram illustrating an exemplary method for accessing an asset relationship through an ARM_graph application programming interface (API).
  • API application programming interface
  • FIGURE 6 is a flow diagram illustrating an exemplary method for generating an asset relationship management file with an ARM_data_provider API.
  • FIGURE 1 is a functional block diagram of an exemplary computing device and/or computer server for enabling various aspects of digital content relationship management functions initiated on computing devices, such as over a network, the Internet, or even on a single computing device.
  • the following discussion is intended to provide a brief, general description of a suitable computing environment in which certain methods discussed below may be implemented. Further, the following discussion illustrates a context for implementing computer-executable instructions, such as program modules, with a computing system.
  • program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types.
  • computing system configurations including multiprocessor systems, mainframe computers, personal computers, processor-controlled consumer electronics, personal digital assistants (PDAs) (but likely not when a server functionality is required), and the like.
  • PDAs personal digital assistants
  • One implementation includes distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network.
  • program modules may be located in both local and remote memory storage devices.
  • the system includes a general purpose computing device in the form of a conventional PC 20, provided with a processing unit 21, a system memory 22, and a system bus 23.
  • the system bus couples various system components including the system memory to processing unit 21 and may be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures.
  • the system memory includes read only memory (ROM) 24 and random access memory (RAM) 25.
  • a basic inpmVoutput system 26 which contains the fundamental routines that enable transfer of information between elements within the PC 20, such as during system start up, is stored in ROM 24.
  • PC 20 further includes a hard disk drive 27 for reading from and . writing to a hard disk (not shown), a magnetic disk drive 28 for reading from or writing to a removable magnetic disk 29, and an optical disk drive 30 for reading from or writing to a removable optical disk 31, such as a compact disk-read only memory (CD-ROM) or other optical media.
  • Hard disk drive 27, magnetic disk drive 28, and optical disk drive 30 are connected to system bus 23 by a hard disk drive interface 32, a magnetic disk drive interface 33, and an optical disk drive interface 34, respectively.
  • the drives and their associated computer readable media provide nonvolatile storage of computer readable machine instructions, data structures, program modules, and other data for PC 20.
  • PC 20 computer readable machine instructions
  • data structures data structures
  • program modules data for PC 20.
  • removable magnetic disk 29 removable magnetic disk 29
  • removable optical disk 31 removable optical disk 31
  • other types of computer readable media which can store data and machine instructions that are accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks (DVDs), Bernoulli cartridges, RAMs, ROMs, and the like, may also be used.
  • a number of program modules and/or data may be stored on hard disk 27, magnetic disk 29, optical disk 31 , ROM 24, or RAM 25, including an operating system 35, one or more application programs 36, other program modules 37, and program or other data 38.
  • a user may enter commands and information in PC 20 and provide control input through input devices, such as a keyboard 40 and a pointing device 42.
  • Pointing device 42 may include a mouse, stylus, wireless remote control, or other user interactive pointer.
  • the term "mouse” is intended to encompass any pointing device that is useful for controlling the position of a cursor on the screen.
  • Other input devices may include a microphone, joystick, haptic joystick, yoke, foot pedals, game pad, satellite dish, scanner, or the like.
  • PC 20 may include a Bluetooth radio or other wireless interface for communication with other interface devices, such as printers, or a network.
  • I/O input/output
  • PC 20 may include a Bluetooth radio or other wireless interface for communication with other interface devices, such as printers, or a network.
  • I/O input/output
  • PCs can be connected to processing unit 21 through an I/O interface 46 that is coupled to system bus 23.
  • I/O interface is intended to encompass each interface specifically used for a serial port, a parallel port, a game port, a keyboard port, and/or a universal serial bus (USB).
  • a monitor 47 can be connected to system bus 23 via an appropriate interface, such as a video adapter 48.
  • PCs can also be coupled to other peripheral output devices (not shown), such as speakers (through a sound card or other audio interface - not shown) and printers.
  • Remote computer 49 can be another PC, a server (which can be configured much like PC 20), a router, a network PC, a peer device, or a satellite or other common network node, (none of which are shown), and a remote computer will typically include many or all of the elements described above in connection with PC 20, although only an external memory storage device 50 for the remote computer has been illustrated in FIGURE 1.
  • the logical connections depicted in FIGURE 1 include a local area network (LAN) 51 and a wide area network (WAN) 52.
  • PC 20 is a component of a game development environment that includes other computing devices, such as server computers, other PCs, databases and the like.
  • PC 20 When used in a LAN networking environment, PC 20 is connected to LAN 51 through a network interface or adapter 53.
  • PC 20 When used in a WAN networking environment, PC 20 typically includes a modem 54, or other means such as a cable modem, Digital Subscriber Line (DSL) interface, or an Integrated Service Digital Network (ISDN) interface for establishing communications over WAN 52, such as the Internet.
  • modem 54 or other means such as a cable modem, Digital Subscriber Line (DSL) interface, or an Integrated Service Digital Network (ISDN) interface for establishing communications over WAN 52, such as the Internet.
  • DSL Digital Subscriber Line
  • ISDN Integrated Service Digital Network
  • Modem 54 which may be internal or external, is connected to the system bus 23 or coupled to the bus via I/O device interface 46, i.e., through a serial port.
  • program modules, or portions thereof, used by PC 20 may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used, such as wireless communication and wide band network links.
  • FIGURE 2 is a block diagram of an exemplary operating environment 200 for implementing various methods for managing relationships between digital content.
  • a server 200 is in communication with a data store 210 and a client 220.
  • An asset relationship management (ARM) file 235 being generated by client 220 is illustrated in FIGURE 2.
  • ARM asset relationship management
  • Server 200 can be any computing device, such as the exemplary computing device and/or computer server discussed with reference to FIGURE 1. Although it will be apparent to the skilled practitioner that server 200 includes such components, for clarity and to simplify the disclosure, server 200 is only illustrated as including a processor 206 and a memory 207. Memory 207 is shown including a relationship manager application 201 that includes an object model module 202, a relationship engine module 203, and can also include an ARM_graph API 250, each of which will be discussed in detail below.
  • Client 220 can be any computing device or system such as the exemplary computing device and/or computer server discussed with reference to FIGURE 1.
  • client 220 is a PC coupled to a network such as a LAN or WAN, or one or more other computing devices through a secure connection over the Internet (not shown).
  • client 220 can be any computing device configured to run applications such as art editors, sound editors, asset report generators and other productivity applications.
  • client 220 includes an art editor application 221, which may be used to access, create, modify and/or manage digital content, such as digital game components.
  • a digital game component is one element of an executable game application, including for example, a mesh file, a texture and/or material file, a sound file, an artificial intelligence (AI) file, or other logic file, or any other digital asset file that can share dependencies with other game components.
  • Art editor 221 is shown as including an ARM_data_provider API 230.
  • ARM data provider API 230 can be an add-on component or module that is appended to art editor 221, or merely accessed by art editor 221 through an API call. It is intended that ARM_data_provider API 230 will be readily configured to retrofit a broad range of existing applications in order to enable the provision of valuable asset relationship data in a development platform independent format.
  • ARM file 235 can include any exportable information about a specific digital asset, including a relationship reference 236, and an annotation 237.
  • Relationship reference 236 is a logical statement and/or an indicator that defines a dependency or referential relationship that the specific digital asset has with any other digital asset.
  • the specific digital asset is a mesh file
  • relationship reference 236 can be a logical statement that the mesh references a specific material file.
  • the specific material file such as a file that defines a color
  • the relationship reference 236 can be a logical statement that the mesh depends on the specific material file.
  • Annotation 237 can include other information that may be useful to export.
  • the annotation can include an asset version indicator, an asset approval indicator (e.g., indicating sign off by an artist), an asset description, an asset type indicator, a rule associated with an asset, and an attribute associated with the asset.
  • the annotation can also provide specific information, such as a color depth indicator, compression algorithm information associated with the asset, or a specific date such as for indicating the last edit of the asset or a final sign off date for example.
  • ARM file 235 is a data structure embodied in an XML document according to an asset relationship management schema.
  • the schema defines a format for objects representing data written out from an asset file by the ARM_data_provider API, such as asset identification, relationship references associated with the asset and various annotations.
  • XML is a widely accepted and application neutral document format, it should be noted that the ARM file can be embodied in any appropriate document format and is not limited to an XML format.
  • Data store 210 provides storage for and includes a plurality of data structures such as ARM file 211 and asset file 212, and asset relationship graph 215.
  • ARM file 211 can be any asset relationship management file as described in relation to ARM file 235.
  • Asset file 212 is generally a digital content file, such as a mesh file, a material file, a sound file, or another digital game component file.
  • Asset relationship graph 215 can include a plurality of nodes as illustrated in FIGURE 2 by nodes A, B, and C. By way of illustration, FIGURE 2 shows that node A refers to node B and node C, while node B refers to node C, yet node C refers to neither ⁇ node A nor node B.
  • nodes A, B, and C can include a tree structure that further defines a mapping of nodal dependencies and additional information, such as annotations (not shown).
  • server 200 is shown as including a relationship manager 201, which is depicted in FIGURE 2 as including an object model module 202, and a relationship engine module 203.
  • relationship manager 201 is actually one executable module, which provides the functionality of both object model 202 and relationship engine 203.
  • object model 202 and relationship engine 203 are implemented as separate, but operationally integrated modules.
  • ARM_graph API 250 can optionally be located with object model 202 and relationship engine 203 on server 200, or can be integrated into an operating system (not shown) of server 200, or as part of an application, or can be configured as a freestanding module. It is intended that ARM graph API 250 be configured to retrofit a broad range of existing applications in order to enable access to asset relationship data in asset relationship graph 215, thereby providing the beneficial functionality of this approach to these existing applications.
  • Object model 202 is configured to provide an interface to asset relationship graph 215.
  • object model 202 is configured to respond to a call from an ARM_graph API requesting asset information by navigating the nodes of the asset relationship graph and returning dependency information to a calling application.
  • the calling application can be any application enabled for communication with object model 202 (e.g., through the ARM_graph API), such as a third-party tool, various custom tools, a game build system, or even a game itself.
  • Relationship engine 203 is generally configured to aggregate the ARM files (e.g., ARM file 211) contained in data store 210 and to generate a multi-graph representation of all of the different relationships, dependencies, and content annotations described by the ARM files.
  • relationship engine 203 is configured to monitor data store 210 in real-time to identify new or modified ARM files as they are created.
  • the relationship engine can be configured to parse the ARM file and generate a node in the asset relationship graph that contains relationship information and annotations for an asset identified by the ARM file.
  • relationship engine 203 is configured to instantiate a relationship graph in memory under its control on-the-fiy, in response to an ARM_graph API call.
  • the asset relationship graph would reside in memory 207 rather than within data store 210. This implementation may be preferable in terms of run time efficiency, where a number of clients seek simultaneous access to asset relationship information that is rapidly changing, and where the total number of nodes is not exceptionally large.
  • FIGURE 3 is another functional block diagram of a suitable operating environment for enabling digital content relationship management.
  • server 200 is again shown in communication with a data store 210 and a client 220.
  • the embodiment illustrated in FIGURE 2 depicts data store 210 as again including ARM file 211, asset file 212, and asset relationship graph 215.
  • Server 200 is again depicted as including processor 206 and memory 207, with memory 207 having relationship manager 201 stored within it.
  • relationship manager 201 includes object model 202 and relationship engine 203.
  • Client 220 of FIGURE 3 represents a computing device, such as discussed above with reference to FIGURES 1 and 2.
  • FIGURE 3 only illustrates a processor 226 and a memory 227 used for storing an application 300.
  • An ARM_graph API 250 is depicted within application 300. However, ARM_graph API 250 need not be integrated into application 300, and in some implementations, is a plug-in or a freestanding module for use with an application or an operating system (not shown) of client 220.
  • ARM graph API 250 can be configured to retrofit a broad range of existing applications and/or operating systems, to enable access to asset relationship data in the asset relationship graph 215 from a process executing on the client device,
  • application 300 is a reporting tool that can be used to generate asset dependency reports, which can be utilized during game development to identify orphaned assets or to trace unwanted changes to asset files.
  • application 300 may be a component application of a game build pipeline, which can call the asset relationship graph 215 through the ARM_graph API in order to, for example, optimize the building or rebuilding of a game executable, test functionality, implement quality assurance tasks, and implement a certification approval process.
  • FIGURE 4 is a flow diagram illustrating the steps of an exemplary method for managing digital game content relationship information associated with digital game content files within a distributed processing system.
  • Method 400 can be implemented in some embodiments with components, devices, and techniques as discussed with reference to FIGURES 1-3.
  • one or more steps of method 400 are embodied on a computer readable medium that stores computer readable code so that a series of steps are implemented when the computer readable code is executed on a computing device, such as a microprocessor.
  • various steps of method 400 are described with respect to a processor of a client device that can perform certain method steps, in communication (as appropriate) with a server that can also perform certain method steps.
  • certain steps of method 400 can be combined, and performed simultaneously or in a different order, without deviating from the objective of method 400 or without producing different results.
  • Method 400 begins at a step 410, where a data provider API is provided for communicating between a client process and a server process in the distributed processing system.
  • the data provider API can be configured for use with a game content editing application or tool.
  • the data provider API can be provided as a plug- in, or add-on component for use with an existing application or software module.
  • the data provider API is enabled when it is installed and configured for operation with an application, such as an art editor for mesh or sound editing.
  • an asset relationship management file is generated with the data provider API.
  • an asset relationship management file can include a digital asset identification that uniquely identifies a specific digital asset file, a relationship reference that describes linking and/or dependency relationships with other digital asset files and an annotation which can include information related to or about the asset file.
  • the asset relationship management file is written out by the data provider API from a digital asset that is being edited by a client content editing process, such as editing a mesh file or a sound file.
  • the asset relationship management file is stored in a data store, e.g., on a hard drive.
  • the asset relationship management file can be stored at any time after it is generated.
  • the ARM file is first cached and then stored.
  • the ARM file is queued by a relationship engine prior to being stored, in order to allow immediate processing of the file.
  • Some implementations of the ARM file can include an asset relationship management schema that defines an annotation object and a relationship reference object.
  • the asset relationship management file is embodied in an XML document according to the asset relationship management schema.
  • an annotation can include one or more of an asset version indicator, an asset approval indicator, an asset description, or a color depth indicator. In other examples, an annotation.
  • Annotations can be any information that could be useful to write out from an asset and make available as a resource for other users in the processes.
  • an asset relationship graph is generated, based on the asset relationship management file.
  • the asset relationship graph is composed of a series of asset graph nodes that map dependency and referential relationships between a set of digital game content files.
  • the step of generating includes the step of first providing the asset relationship management file to a relationship management engine.
  • the relationship management engine can be configured for communication with the data store.
  • This implementation also includes the step of parsing the asset relationship management file to identify each relationship reference and annotation.
  • a final step of the implementation includes generating a node tree in the asset relationship graph.
  • each node of the asset relationship graph will correspond to a digital content file such as a game component, and will map the relationship between itself and any other digital content file described by an ARM file accessible to the relationship management engine.
  • Another exemplary implementation further includes the step of configuring the relationship engine to monitor the data store and identify each new asset management file and then invoke the relationship engine to map each identified new asset management file into an instantiation of the asset relationship graph as a unique node.
  • the asset relationship graph can be instantiated within a data store or any other suitable memory location, such as for example within server memory.
  • Another exemplary implementation further includes the step of providing a graph API for communicating between a client process and a server process in the distributed processing system.
  • the graph API can be configured for accessing the relationship graph through a server process in order to expose asset relationship data and annotation data to the client process.
  • One implementation of the graph API includes a series of steps, such as receiving a call to the graph API from a client process requesting information associated with a specific asset, and issuing an asset information request from the graph API in response to the call. Further steps include interrogating the relationship graph for the information associated with the specific asset, and then returning a response to the request to the client process from the graph API. In this implementation, the response is associated with the specific asset and is based on the interrogation.
  • Another exemplary implementation includes a series of steps, such as accessing an asset relationship object model through the graph API.
  • the asset relationship object model is configured to navigate the plurality of asset nodes of the asset relationship graph and then expose relationship references and annotations.
  • the next step in this implementation includes identifying each relationship reference in the asset relationship graph that is associated with the specific asset.
  • FIGURE 5 is a flow diagram illustrating an exemplary method 500 for accessing an asset relationship through an ARM_graph application programming interface (API).
  • Method 500 can be implemented in some embodiments with components, and techniques discussed with reference to FIGURES 1-3.
  • one or more steps of method 500 are embodied in a computer readable medium containing computer readable code so that a series of steps are implemented when the computer readable code is executed on a computing device, such as a microprocessor.
  • parts of method 500 are described with respect to a processor of a client device that can perform certain method steps, in communication (as appropriate) with a server that can also perform other parts of the method.
  • Method 500 generally describes an API process and begins at a step 510.
  • an ARM_graph call is issued by the client process.
  • the ARM_graph call can include one or more call parameters, such as, an asset identifier, a data store identifier, and a client requested function.
  • the ARM_graph call can occur at any time that a graph API is enabled.
  • the graph API can be located at either the client side or server side, but can be invoked by a client process in both instances.
  • a server process receives the ARM_graph call and then parses the call to retrieve the parameters.
  • the ARM_graph call immediately invokes a server process to parse the call and retrieve the parameters.
  • a call can be cached in a FIFO buffer or a queue and then served in the order of receipt.
  • the server process loads an ARM graph in response to the ARM_graph call.
  • the ARM graph can be loaded from an existing ARM graph located in a data store or alternatively can be loaded as an instance generated on-the-fiy based on the call.
  • the ARM graph can be loaded immediately or queued based on whether another load process is executing.
  • the ARM graph is loaded by first accessing each ARM file in a data store that corresponds to a digital asset file and then extracting each reference to an asset file from each ARM file, generating a node for each asset file and than mapping each relationship between asset files via the nodes.
  • the server process interrogates the ARM graph in response to the- ARM_graph call.
  • the interrogation is based on parameters parsed from the ARM_graph call.
  • the interrogation includes navigating one or more nodes of the ARM graph to identify one or more asset identifiers corresponding to specific asset files, based on the parameters parsed from the ARM_graph call, and surface relationships and annotations related to the specific asset files. The interrogation can occur at any time after the call is received, and an ARM graph is available for interrogation.
  • the server process issues an ARM_graph acknowledgment having a plurality of acknowledgment parameters including the asset identifier, and at least one of an asset relationship reference and an annotation.
  • the acknowledgment parameters can include relationships and annotations determined by the ARM_graph interrogation.
  • the server process can issue the ARM_graph acknowledgment immediately upon completion of an interrogation.
  • the ARM_graph acknowledgment can be queued and issued at a later time, depending on external parameters.
  • the client process receives the ARM_graph acknowledgment.
  • the client process can receive the ARM_graph acknowledgment at any time after the acknowledgment has issued and a client process is active for receiving communications.
  • a further implementation includes the steps of parsing the ARM_graph acknowledgment to retrieve the acknowledgment parameters and then providing the retrieved parameter to a client application process.
  • an ARM_graph API can be configured to receive the ARM_graph acknowledgment, parse the acknowledgment parameters and then provide the retrieved parameters to a reporting application or art editor for example.
  • a data structure stored on a tangible computer readable medium includes a first ARM graph node representing a first asset.
  • the first node can include a first asset identifier for uniquely identifying a first digital asset, such as a game component, a relationship reference defining a relationship to another asset, and an annotation that can include information about the asset, such as a binary name or root directory.
  • the data structure further includes a second relationship graph node representing a second asset, the second asset including a second asset identifier and at least one of a second relationship reference mapping to at least the first relationship graph node and a second annotation.
  • FIGURE 6 is a flow diagram illustrating an exemplary method 600 for generating an asset relationship management file with an ARM_data_provider API.
  • Method 600 can be implemented in some embodiments with components, and techniques, as discussed with reference to FIGURES 1 -3.
  • one or more steps of method 600 are embodied on a computer readable medium containing computer readable code so that a series of steps are implemented when the computer readable code is executed on a computing device, such as a microprocessor.
  • various steps of the method 600 are described with respect to a processor of a client device that can perform certain method steps, in communication (as appropriate) with a server that can also perform certain method steps.
  • Method 600 generally describes an API process that can include communication between an application process and a client process. Method 600 begins at a step 610.
  • an application process issues an ARM_data_provider call including one or more call parameters such as an asset identifier, a client requested function, a relationship reference and an annotation.
  • the client requested function is a request to write out one or more of the parameters to an ARM file.
  • the application process is associated with an editor such as an art editor or a sound editor, or a report generating application.
  • a client process receives the ARM__data_provider call and in response, parses the call to retrieve the parameters and execute the client requested function.
  • the client process is associated with an API module.
  • the client process issues an ARM file that includes the retrieved parameters.
  • the ARM file is an XML document formatted according to an asset relationship management schema, which defines one or more objects corresponding to one or more parameters.
  • the asset relationship management schema is a simple list.
  • the asset relationship management schema is a tree of nodes.
  • the ARM file can have any suitable document format and schema that allow the • ARM file to be readily exchanged and utilized with a wide variety of off-the-shelf (i.e., existing) software packages.
  • a server process receives the ARM file and stores the ARM file in a data store (e.g., a hard drive).
  • a data store e.g., a hard drive
  • the ARM file may be stored locally with other files including asset files related to the ARM file.
  • an off-site repository may store ARM files for retrieval on an as-needed basis.
  • the ARM files may be stored in a volatile or non-volatile memory location controlled by an asset relationship engine to allow run-time access for on-the-fly asset relationship graph creation.
  • a game development team composed of three separate groups is charged with developing a set of vehicles for a new video game.
  • the first group is to develop a fire engine
  • the second group is to develop a police car
  • the third group is to develop a racy sports car.
  • the first team develops a fire engine mesh, which is a wire frame that defines the shape of the fire engine.
  • the team saves the mesh file to a central repository and begins developing a material file and a sound file which will be associated with the mesh file and used when the fire engine is rendered.
  • the first group After developing just the right shade of fire-engine red, the first group saves the mesh file with a link to the fire-engine red material file and a link to a pre-existing engine sound file. All of the files for the fire engine are saved to the same repository accessible to the other development groups.
  • the second group builds a police car asset file from an existing car mesh . file, selecting pre-existing material files for black, white, and chrome portions of the police car, and then creates a siren sound file, all of which are referenced by the police car asset mesh file when it is saved to the central repository along with the referenced component files.
  • the third group builds a new sports car mesh and links it to the fire engine red material file, the chrome material file, and to the pre-existing engine sound file. However the third group decides during development that the pre-existing engine sound file isn't appropriate to the deep throated roar of a sports car and opens the sound file for editing.
  • the ARM file is stored in a central data store along with other files such as the original asset file (e.g., a material file such as a car mesh, color, texture, and sound or logic files, etc.) that it represents.
  • the ARM file can then be used to generate an asset relationship graph that maps all of the dependency relationships between the asset files represented by the AEM files.
  • the ARM_data__provider API can be retrofitted to an existing game development or content editing suite and that the relationship management schema used to schematize the data contained in the ARM file can be applied quite easily across multiple platforms. This capability can provide different companies using different or even proprietary development tools the capability to export asset file dependency information and other data about a digital asset in a form that can be used by other parties.
  • the content editing application can access a relationship graph via the graph API to determine that the engine sound file is relied upon by another asset file, namely the fire engine asset file.
  • the third group will thus recognize that the edited engine sound must be save to a new file to avoid changing the engine sound of the fire engine.
  • the ARM_graph API can be employed to alert the group that the chrome material file is relied upon by the police car asset file and therefore, the chrome material file should not be changed (with the same file name) because such changes will impact the appearance of the police car in the new game.
  • multiple groups working on a game can track the asset files on which they are working, such as mesh files, material files, sound files , artificial intelligence (AI) files, and the like, in real time, as the files are edited and created, even across different development platforms.
  • asset files on which they are working such as mesh files, material files, sound files , artificial intelligence (AI) files, and the like
  • AI artificial intelligence

Abstract

Selon l'invention, une interface de programmation d'applications (API) de fourniture de données est configurée pour être utilisée avec une application d'édition du contenu d'un jeu. Un fichier de gestion des relations entre des biens, qui est généré avec l'API de fourniture de données, comprend des informations telles que des références relationnelles et des annotations et est mis à jour par l'API de fourniture de données lorsqu'un bien numérique est édité. Le fichier de gestion des relations entre les biens est ensuite stocké dans une mémoire de données. Un graphe des relations entre les biens est généré, sur la base du fichier de gestion des relations entre les biens stocké dans la mémoire de données. Le graphe des relations entre les biens comprend des noeuds de graphe des biens qui mappent les relations de dépendance entre fichiers de biens. On décrit également une API du graphe configurée pour assurer l'accès au graphe des relations par le biais d'un processus de serveur destiné à présenter des relations de dépendance et des annotations à un processus de client, tel qu'une application. Ainsi, l'effet de modifications apportées à un bien sur d'autres biens peut être évalué.
EP06850415A 2006-01-31 2006-12-29 Gestion des relations avec xna Ceased EP1979825A4 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/343,455 US7836055B2 (en) 2006-01-31 2006-01-31 XNA relationship management
PCT/US2006/049661 WO2007089353A1 (fr) 2006-01-31 2006-12-29 Gestion des relations avec xna

Publications (2)

Publication Number Publication Date
EP1979825A1 true EP1979825A1 (fr) 2008-10-15
EP1979825A4 EP1979825A4 (fr) 2009-09-16

Family

ID=38327719

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06850415A Ceased EP1979825A4 (fr) 2006-01-31 2006-12-29 Gestion des relations avec xna

Country Status (6)

Country Link
US (1) US7836055B2 (fr)
EP (1) EP1979825A4 (fr)
JP (1) JP2009525533A (fr)
KR (1) KR20080096758A (fr)
CN (1) CN101336424B (fr)
WO (1) WO2007089353A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11039014B1 (en) 2019-06-13 2021-06-15 Express Scripts Strategic Development, Inc. Relationship determination system

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080104203A1 (en) * 2006-10-31 2008-05-01 Microsoft Corporation Viewing Digital Information Over a Network
US20090077091A1 (en) * 2007-09-18 2009-03-19 Gilad Khen System for development and hosting of network applications
US20110225074A1 (en) * 2010-03-12 2011-09-15 Microsoft Corporation System and method for providing information as a service via web services
CN104854578A (zh) * 2012-11-23 2015-08-19 布莱阿姆青年大学 用于协同CAx编辑的系统、方法和设备
US9183092B1 (en) * 2013-01-21 2015-11-10 Amazon Technologies, Inc. Avoidance of dependency issues in network-based service startup workflows
US9405605B1 (en) 2013-01-21 2016-08-02 Amazon Technologies, Inc. Correction of dependency issues in network-based service remedial workflows
US9075718B2 (en) * 2013-03-14 2015-07-07 Vmware, Inc. Dynamic field extraction of log data
KR101403095B1 (ko) * 2013-04-01 2014-06-11 한국과학기술원 그래프 채색 알고리즘을 이용한 태스크 지향적 서비스의 분산 코디네이션 방법 및 그 시스템
US9912546B2 (en) * 2014-03-28 2018-03-06 Sciencelogic, Inc. Component detection and management using relationships
US10156841B2 (en) 2015-12-31 2018-12-18 General Electric Company Identity management and device enrollment in a cloud service
US10116725B2 (en) * 2016-05-27 2018-10-30 Intuit Inc. Processing data retrieval requests in a graph projection of an application programming interfaces (API)
US9753744B1 (en) * 2016-05-27 2017-09-05 Intuit Inc. Defining application programming interfaces (APIS) using object schemas
US10701377B2 (en) * 2016-09-14 2020-06-30 Amazon Technologies, Inc. Media storage
US10871918B2 (en) * 2017-08-02 2020-12-22 Intuit Inc. Writing composite objects to a data store
US10987587B2 (en) * 2017-12-22 2021-04-27 Take-Two Interactive Software, Inc. System and method for game object and environment generation
US20190340255A1 (en) * 2018-05-07 2019-11-07 Apple Inc. Digital asset search techniques
US11922116B2 (en) * 2022-04-11 2024-03-05 Contentful GmbH Annotations in a content model of a content management system

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6181336B1 (en) * 1996-05-31 2001-01-30 Silicon Graphics, Inc. Database-independent, scalable, object-oriented architecture and API for managing digital multimedia assets
US20020133516A1 (en) * 2000-12-22 2002-09-19 International Business Machines Corporation Method and apparatus for end-to-end content publishing system using XML with an object dependency graph
WO2005119496A2 (fr) * 2004-05-17 2005-12-15 Pixar Procede et dispositif de comptes-rendus de populations d'agregats a base de graphes de dependance

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6901433B2 (en) * 1995-06-07 2005-05-31 Microsoft Corporation System for providing users with a filtered view of interactive network directory obtains from remote properties cache that provided by an on-line service
WO1997025679A1 (fr) 1996-01-12 1997-07-17 Hitachi, Ltd. Procede et appareil de gestion de fichiers electroniques
US6681265B1 (en) * 1999-11-02 2004-01-20 International Business Machines Corporation Providing command files with access to data stores that are inaccessible to command line operations
JP2003263317A (ja) * 2002-03-07 2003-09-19 Toshiba Corp 情報処理装置
US7126607B2 (en) * 2002-08-20 2006-10-24 Namco Bandai Games, Inc. Electronic game and method for effecting game features
US7191186B1 (en) 2002-11-27 2007-03-13 Microsoft Corporation Method and computer-readable medium for importing and exporting hierarchically structured data
US7103600B2 (en) * 2003-03-06 2006-09-05 Thought Inc. Displayable presentation page and SQL searchable relational data source implementation of a system, method and software for creating or maintaining distributed transparent persistence of complex data objects and their data relationships
JP2005107590A (ja) 2003-09-26 2005-04-21 Nippon Telegraph & Telephone West Corp 構造化ファイルアクセス方法およびシステム、ならびに構造化ファイルアクセス用プログラム
US9047915B2 (en) * 2004-04-09 2015-06-02 Sony Corporation Asset revision management in media production
JP2005354659A (ja) * 2004-05-10 2005-12-22 Sony Computer Entertainment Inc コンテンツ提供システム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6181336B1 (en) * 1996-05-31 2001-01-30 Silicon Graphics, Inc. Database-independent, scalable, object-oriented architecture and API for managing digital multimedia assets
US20020133516A1 (en) * 2000-12-22 2002-09-19 International Business Machines Corporation Method and apparatus for end-to-end content publishing system using XML with an object dependency graph
WO2005119496A2 (fr) * 2004-05-17 2005-12-15 Pixar Procede et dispositif de comptes-rendus de populations d'agregats a base de graphes de dependance

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
OTAMERE OMORUYI: "Managing Digital Assets in Game Development" INTERNET ARTICLE, [Online] 21 May 2001 (2001-05-21), pages 1-5, XP002540103 GameDev Homepage Retrieved from the Internet: URL:http://www.gamedev.net/reference/articles/article1371.asp> [retrieved on 2009-08-05] *
See also references of WO2007089353A1 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11039014B1 (en) 2019-06-13 2021-06-15 Express Scripts Strategic Development, Inc. Relationship determination system
US11457109B2 (en) 2019-06-13 2022-09-27 Express Scripts Strategie Development, Inc. Relationship determination system

Also Published As

Publication number Publication date
CN101336424B (zh) 2012-10-10
JP2009525533A (ja) 2009-07-09
KR20080096758A (ko) 2008-11-03
EP1979825A4 (fr) 2009-09-16
CN101336424A (zh) 2008-12-31
US20070220031A1 (en) 2007-09-20
US7836055B2 (en) 2010-11-16
WO2007089353A1 (fr) 2007-08-09

Similar Documents

Publication Publication Date Title
US7836055B2 (en) XNA relationship management
US20070178968A1 (en) Displaying game asset relationship in a game development environment
US7424485B2 (en) Method and apparatus for generating user interfaces based upon automation with full flexibility
US7698293B2 (en) System and methods for capturing structure of data models using entity patterns
JP4812337B2 (ja) フォームタイプを使用してフォームを生成する方法および装置
US7363578B2 (en) Method and apparatus for mapping a data model to a user interface model
US8261248B2 (en) System and method of executing a dynamic program in a structured environment
US20160004516A1 (en) Code Generation Framework for Application Program Interface for Model
US8307015B2 (en) Decorated model architecture for efficient model-driven application development
US20090132211A1 (en) Automated solution for generating architectural design models for service-oriented architecture (soa) information services
US10699243B2 (en) Business model data management
US7636911B2 (en) System and methods for capturing structure of data models using entity patterns
US20130019225A1 (en) Incremental Inferences for Developing Data Models
US20050027783A1 (en) Method and system for logging test data
US8935657B2 (en) Model-to-model transformation by kind
US9244706B2 (en) Command line shell command generation based on schema
US6886172B2 (en) Method for mapping procedural C++ code to java object-oriented classes
US20070150246A1 (en) Context-Supported Structures in a Modeling Language
Starr et al. Models to Code
Schattkowsky et al. Uml model mappings for platform independent user interface design
CN112015560B (zh) 一种用于构建it基础设施的装置
KR101219960B1 (ko) 엔터티 패턴들을 사용하여 데이터 모델의 구조를 캡처하는시스템 및 방법
Bian et al. Integrating ADTs in KeY and their application to history-based reasoning about collection
US20090007157A1 (en) Mapping Data Sources to a Procedural API
Smith System support for design and development environments

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20080721

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

A4 Supplementary search report drawn up and despatched

Effective date: 20090819

RIC1 Information provided on ipc code assigned before grant

Ipc: G06F 9/44 20060101AFI20090811BHEP

17Q First examination report despatched

Effective date: 20091103

DAX Request for extension of the european patent (deleted)
REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20121106