US20070178968A1

US20070178968A1 - Displaying game asset relationship in a game development environment

Info

Publication number: US20070178968A1
Application number: US11/343,813
Authority: US
Inventors: Rejean Cote-Charpentier; Nicolas Gauvin; Shawn Hargreaves; Mel MacMahon; Boyd Multerer; Frank Savage
Original assignee: Microsoft Corp
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2006-01-31
Filing date: 2006-01-31
Publication date: 2007-08-02
Also published as: WO2007089350A1

Abstract

Methods, systems, and software products are described that display relationships between game assets in a game development environment. In one implementation, a selection of a particular game asset is received, and a selection of a particular type of relationship is received to display for the selected game asset. The type of relationship may be a parent relationship, a child relationship, a category relationship, etc. Other game assets are then identified that have the selected relationship with the selected game asset. The other game assets that are identified are displayed to a user.

Description

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. Developing games and other media console software requires considerable effort by large teams of artists and programmers. Game development teams composed of artists 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 or other development groups. In such a game development environment, a game component or game asset 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. For example, the shape of a car in a game might be defined by an original “car” mesh, to which several colors 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. 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. A game developer may have to navigate through a large file system to find each instance of a component, which may be difficult. Furthermore, multiple dependencies may not become apparent until an application has been compiled and executed, rendering an unintended change apparent only during a quality review cycle. Moreover, it may be difficult to identify the artist that actually caused an undesirable change when modifying a mutually shared component texture or color without reviewing each component of a game that would be affected, prior to the step of compiling.
Changes are often made that result in texture files that were once used being no longer used in a game, but still included in the file set for the game. As a result, many games include surplus content or and/or orphaned files that are no longer used or needed by the game. Because it may not be clear what components would be adversely affected by deleting texture files, game developers are hesitant to delete content during development. Accordingly, there is need within the game development industry for new approaches to be developed that facilitate managing game content and the relationships between components and files used in rendering those components. An approach is needed that is universally applicable at minimal cost, and which address these and other related problems that arise during the development of games.

SUMMARY

Several examples are provided below that describe implementations for displaying relationships between game assets in a game development environment. As game assets are created, edited, or referenced by another game asset, an asset relationship management (ARM) file or another data structure is generated that specifies the relationships among the game assets. A corresponding asset relationship graph may be generated that also specifies the relationships among the game assets.
One implementation described in more detail below includes steps such as receiving a selection of a particular game asset. Another step is directed to receiving a selection of a particular type of relationship to display for the selected game asset. The type of relationship may be a child relationship, a parent relationship, a category relationship, etc. Another step is directed to identifying one or more other game assets having the selected relationship with the selected game asset. Another step is directed to displaying the other game assets having the selected relationship with the selected game asset. The displaying step may include displaying the children of the selected game asset, displaying the parents of the selected game asset, displaying other game assets in the same category as the selected game asset, etc.
By displaying the relationships of the game assets, a game developer may easily identify each of the other game assets having a particular type of relationship with a selected game asset, such as before editing or deleting the selected game asset. The game developer can navigate through the game assets logically based on the relationships that the game assets have with one another. The game developer advantageously does not need to navigate through a file system to try to determine the relationships of a particular asset file. The game development process is thus more streamlined to more effectively allow separate game development groups to share game assets.
This Summary has been provided to introduce a few concepts in a simplified form that are further described in detail below in the Detailed Description. However, this Summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

DESCRIPTION OF THE DRAWINGS

The same reference number represents the same element on all drawings.
FIG. 1 is a functional block diagram of a generally conventional computing device.
FIG. 2 is a functional block diagram of a system for enabling digital content relationship management.
FIG. 3 is another functional block diagram of a system for enabling digital content relationship management.
FIG. 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.
FIG. 5 is a flow diagram illustrating an exemplary method for accessing an asset relationship through an ARM_graph application programming interface (API).
FIG. 6 is a flow diagram illustrating an exemplary method for generating an asset relationship management file with an ARM_data_provider API.
FIG. 7 is another functional block diagram of a suitable operating environment for providing a user interface such that relationships between assets may be displayed to a user.
FIG. 8 is a flow diagram illustrating an exemplary method for displaying relationships between game assets in a game development environment.
FIG. 9 illustrates an exemplary screen generated by a user interface application.
FIG. 10 illustrates an exemplary screen generated by a user interface application to show the “Children” of a game asset.
FIG. 11 illustrates an exemplary screen generated by a user interface application to show the “Parents” of a game asset.
FIG. 12 illustrates another exemplary screen generated by a user interface application to show the “Children” of a game asset.
FIG. 13 illustrates another exemplary screen generated by a user interface application to show the “Parents” of a game asset.
FIGS. 14-17 illustrate an example of displaying relationships between game assets in a game development environment.

DETAILED DESCRIPTION

FIGS. 1-17 and the following description depict exemplary embodiments. It is intended that the embodiments and FIGS. disclosed herein are to be considered illustrative rather than restrictive.
Exemplary Computing System
FIG. 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. Generally, program modules include routines, programs, objects, components, data structures, etc, that perform particular tasks or implement particular abstract data types. The skilled practitioner will recognize that other computing system configurations may be applied, 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. One implementation includes distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.
With reference to FIG. 1, an exemplary system suitable for implementing various methods is depicted. 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 23 couples various system components including the system memory 22 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 22 includes read only memory (ROM) 24 and random access memory (RAM) 25.
A basic input/output system 26 (BIOS), 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. Although the described exemplary environment employs a hard disk 27, removable magnetic disk 29, and removable optical disk 31, those skilled in the art will recognize that 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. As used in the following description, 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 (not shown) may include a microphone, joystick, haptic joystick, yoke, foot pedals, game pad, satellite dish, scanner, or the like. Also, PC 20 may include a Bluetooth radio or other wireless interface for communication with other interface devices, such as printers or a network. These and other input/output (I/O) devices can be connected to processing unit 21 through an I/O interface 46 that is coupled to system bus 23. The phrase “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). Optionally, a monitor 47 can be connected to system bus 23 via an appropriate interface, such as a video adapter 48. In general, 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.
Certain processes described in detail below, can be practiced on a single machine, although PC 20 can also operate in a networking environment using logical connections to one or more remote computers, such as a remote computer 49. 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 49 has been illustrated in FIG. 1. The logical connections depicted in FIG. 1 include a local area network (LAN) 51 and a wide area network (WAN) 52. Such networking environments are common in offices, enterprise-wide computer networks, intranets, and the Internet. In one particular implementation, 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.
When used in a LAN networking environment, PC 20 is connected to LAN 51 through a network interface or adapter 53. 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, 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. In a networking environment, 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.
Exemplary Operating Environment
FIG. 2 is a block diagram of an exemplary operating environment 200 for implementing various methods for managing relationships between digital content. As shown in FIG. 2, 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 FIG. 2.
Server 200 can be any computing device, such as the exemplary computing device and/or computer server discussed with reference to FIG. 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 optionally 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 FIG. 1. In some implementations, client 220 is a PC coupled to a network such as a LAN or WAN, or one or more other computing devices through a connection over the Internet (not shown). In other implementations, client 220 can be any computing device configured to run applications such as art editors, sound editors, asset report generators and other productivity applications. As depicted in FIG. 2, 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 color file, a sound file, an artificial intelligence (Al) 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. However, 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. Those skilled in the art understand that client 220 and server 200 may be implemented in a single computing device.
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. For example, if the specific digital asset is a mesh file, relationship reference 236 can be a logical statement that the mesh references a specific color file. However, if the specific digital asset is instead the specific color file, the relationship reference 236 can be a logical statement that the mesh depends on the specific color file. Annotation 237 can include other information that may be useful to export. For example, 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. In one implementation, ARM file 235 is a data structure embodied in an XML document according to an asset relationship management schema. In this implementation, 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. Although 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, 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 color file, a sound file, or another digital game component file. Asset relationship graph 215 can include a plurality of nodes as illustrated in FIG. 2 by nodes A, B, and C. By way of illustration, FIG. 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. Furthermore, 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).
By way of illustration and clarity, server 200 is shown as including a relationship manager 201, which is depicted in FIG. 2 as including an object model module 202, and a relationship engine module 203. However, in some implementations, relationship manager 201 is actually one executable module, which provides the functionality of both object model 202 and relationship engine 203. In other implementations, 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. In one implementation, 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. In this instance, 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.
In one exemplary implementation, relationship engine 203 is configured to monitor data store 210 in real-time to identify new or modified ARM files as they are created. In this implementation, 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. In another implementation, which is not shown in FIG. 2, relationship engine 203 is configured to instantiate a relationship graph in memory on-the-fly, in response to an ARM_graph API call. In this implementation, 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.
By way of further illustration, FIG. 3 is another functional block diagram of a suitable operating environment for enabling digital content relationship management. As depicted in FIG. 3, server 200 is again shown in communication with a data store 210 and a client 220. The embodiment illustrated in FIG. 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. As discussed above, relationship manager 201 includes object model 202 and relationship engine 203. For a discussion of the functionality and capabilities of each of these elements, reference can be made to the discussion above regarding FIG. 2. Client 220 of FIG. 3 represents a computing device, such as discussed above with reference to FIGS. 1 and 2. Although it will be apparent to the skilled practitioner that client device 220 will incorporate many of the other components of FIG. 1, for clarity, FIG. 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.
As was discussed above, it is intended that 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 client 220. In one example, 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. In another implementation, 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 250 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.
FIG. 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 FIGS. 1-3. In some implementations, 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 is implemented when the computer-readable code is executed on a computing device, such as a microprocessor. In the following description, 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. In some implementations, 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. Those skilled in the art understand that the client device and the server may be implemented in a single computing device.
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. In one implementation, the data provider API can be configured for use with a game content editing application or tool. Generally, 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.
In a step 420, an asset relationship management file is generated with the data provider API. In some implementations, 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. Generally, 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.
In a step 430, 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. In some implementations, the ARM file is first cached and then stored. In another implementation 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. In one example, the asset relationship management file is embodied in an XML document according to the asset relationship management schema. In another example, 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 can include one or more of compression algorithm data associated with an asset, a date indicator, an asset type indicator, a rule associated with the asset, or an attribute associated with the asset. 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.
In a step 440, an asset relationship graph is generated, based on the asset relationship management file. In some implementations, 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. In one exemplary implementation, the step of generating includes the step of first providing the asset relationship management file to a relationship management engine. In this implementation, 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. In this step, the node tree is first associated with the asset relationship management file and then mapped to each asset node of the asset relationship graph that is associated with any relationship references and annotations that were identified in the step of parsing. Therefore, 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 relationship management file and then invoke the relationship engine to map each identified new asset relationship management file into an instantiation of the asset relationship graph as a unique node. It should be noted that 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. In some implementations, the graph API can be configured for accessing the asset 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 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. In this implementation, 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.
FIG. 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 FIGS. 1-3. In some implementations, one or more steps of method 500 are embodied in a computer-readable medium containing computer-readable code so that a series of steps is implemented when the computer-readable code is executed on a computing device, such as a microprocessor. In the following description, 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. In some implementations, certain steps of method 500 can be combined, and performed simultaneously or in a different order, without deviating from the objective of method 500 or without producing different results. Those skilled in the art understand that the client device and the server may be implemented in a single computing device. Method 500 generally describes an API process and begins at a step 510.
In 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. In some implementations, 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.
In a step 520, a server process receives the ARM_graph call and then parses the call to retrieve the parameters. In some implementations, the ARM_graph call immediately invokes a server process to parse the call and retrieve the parameters. In other implementations, where multiple calls may arrive from different clients within a small window, a call can be cached in a FIFO buffer or a queue and then served in the order of receipt.
In a step 530, 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-fly based on the call. The ARM graph can be loaded immediately or queued based on whether another load process is executing. In one implementation, 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.
In a step 540, the server process interrogates the ARM graph in response to the ARM_graph call. Generally, the interrogation is based on parameters parsed from the ARM_graph call. In one exemplary implementation, 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 based on 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.
In a step 550, 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. In some implementations, the acknowledgment parameters can include relationships and annotations determined by the ARM_graph interrogation. In some implementations, the server process can issue the ARM_graph acknowledgment immediately upon completion of an interrogation. In other implementations, the ARM_graph acknowledgment can be queued and issued at a later time, depending on external parameters.
In a step 560, the client process receives the ARM_graph acknowledgment. In some implementations 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. In an example, an ARM_graph API can be configured to receive the ARM graph acknowledgment, parse the acknowledgment parameters, and provide the retrieved parameters to a reporting application or art editor for example.
In one exemplary implementation, a data structure stored on a tangible computer-readable medium includes a first ARM graph node representing a first asset. In this implementation, 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. In this implementation, 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.
FIG. 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 FIGS. 1-3. In some implementations, 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. In the following description, 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. In some implementations, certain steps of method 600 can be combined, performed simultaneously or in a different order, without deviating from the objective of method 600 or without producing different results. Those skilled in the art understand that the client device and the server may be implemented in a single computing device. 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.
In 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. In one implementation, the client requested function is a request to write out one or more of the parameters to an ARM file. In one implementation, the application process is associated with an editor such as an art editor or a sound editor, or a report generating application.
In a step 620, 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. In one exemplary implementation, the client process is associated with an API module.
In a step 630, the client process issues an ARM file that includes the retrieved parameters. In one exemplary implementation, the ARM file is an XML document formatted according to an asset relationship management schema, which defines one or more objects corresponding to be one or more parameters. In one example, the asset relationship management schema is a simple list. In another example, 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 software packages.
In a step 640, a server process receives the ARM file and stores the ARM file in a data store (e.g., a hard drive). In some implementations, the ARM file may be stored locally with other files including asset files related to the ARM file. In other implementations, an off-site repository may store ARM files for retrieval on an as-needed basis. In yet other implementations, 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.
By way of further illustration, an exemplary application of the above-described content management applications and components can be described with reference to a game development environment. For example, 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, and 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 color file and a sound file which will be associated with the mesh file and used when the fire engine is rendered. 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 color 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.
Meanwhile, the second group builds a police car asset file from an existing car mesh file, selecting pre-existing color 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 color file, the chrome color 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 team wishes to know what the impact of such changes will be on any other files in the game, but since the groups are working independently, the third group has no idea whether the other groups are using the same content files or how a change made to the sound file for the engine sound may impact other assets of the game.
However, with a game development system employing the concept described above, when each of the above asset files is saved, an ARM file is also created by the ARM_data_provider API, which writes out essential relationships that the asset file has to other asset files, and annotations containing useful information about the asset file, to an XML document according to a relationship management schema. The ARM file is stored in a central data store along with other files such as the original asset file (e.g., a car mesh, color, texture, sound, logic file, 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 ARM files. It is important to note that 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.
For example, as the third group discussed above accesses the pre-existing engine sound file, 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 saved to a new file to avoid changing the engine sound of the fire engine. Similarly, as the third group accesses the chrome color file, the ARM_graph API can be employed to alert the group that the chrome color asset file is relied upon by the police car asset file and therefore, the chrome color 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. As is evident from the above example, multiple groups working on a game can track the asset files on which they are working, such as mesh files, color 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. Furthermore, through the ARM_data_provider API and the graph_API, it is possible to determine asset file dependencies prior to compiling a game, and therefore eliminate orphaned files and redundancies to reduce software “bloat,” streamline the development pipeline, and improve quality assurance processes.
Exemplary Display of Game Asset Relationships
The following description provides implementations for displaying game asset relationships. The game asset relationships may be generated according to the implementations described in relation to FIGS. 1-6, or may be generated in other ways. The game asset relationships may be stored in ARM files and/or asset relationship graphs as described in relation to FIGS. 1-6, or may be stored in another data structure that stores such relationships between game assets. For example, the relationships may be encoded in a single storage structure separate from the game assets or may be integrated with the game asset storage. Further, the relationships may be stored in indexed data structures to allow for rapid location of the relationships for one or more game assets.
The following description and claims refer to “game” assets and “game” development environments. However, the term “game” as used herein is not limited only to video games, but also relates to other multimedia presentations such as web applications and film applications. For instance, a game asset may apply equally to a video game asset, a film asset (e.g., animation), or a web asset. Also, a game development environment may apply equally to a video game development environment, a film development environment, and a web development environment.
FIG. 7 is another functional block diagram of a suitable operating environment for providing a user interface such that relationships between assets may be displayed to a game developer or another user. As depicted in FIG. 7, a server 704 is shown in communication with a data store 710 and a client 720. The embodiment illustrated in FIG. 7 depicts data store 710 as including ARM file 711, asset file 712, and asset relationship graph 715, although data store 710 may store other files or other data structures having relationship information on game assets. Server 704 is depicted as including processor 706 and memory 707, with memory 707 having a relationship manager 701 stored within it. As discussed above, relationship manager 701 includes object model 702 and relationship engine 703. For a discussion of the functionality and capabilities of each of these elements, reference can be made to the discussion above regarding FIG. 2. Client 720 of FIG. 7 represents a computing device, such as discussed above with reference to FIGS. 1 and 2. Although it will be apparent to the skilled practitioner that client device 720 will incorporate many of the other components of FIG. 1, for clarity, FIG. 7 only illustrates a processor 726 and a memory 727 used for storing a user interface application 700.
User interface application 700 may comprise an asset viewing software program or a navigation software program used to display relationships between game assets used in a game development environment. User interface application 700 may alternatively be an editing software program used to edit or create game assets used in a game development environment. User interface application 700 provides the user interface that displays relationships between game assets to a user. The relationships may be provided to the user in many desired ways, and some examples are illustrated in the following FIGS.
FIG. 8 is a flow diagram illustrating an exemplary method 800 for displaying relationships between game assets in a game development environment. Method 800 can be implemented in some embodiments with components and techniques discussed with reference to FIGS. 1-3 and 7 to provide a user interface to a game developer. In some implementations, one or more steps of method 800 are embodied in a computer-readable medium containing computer-readable code so that a series of steps is implemented when the computer-readable code is executed on a computing device, such as a microprocessor. In the following description, parts of method 800 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. In some implementations, certain steps of method 800 can be combined, and performed simultaneously or in a different order, without deviating from the objective of method 800 or without producing different results. Those skilled in the art understand that the client device and the server may be implemented in a single computing device. Method 800 begins at a step 810.
In step 810, a particular game asset is selected by a user and the selection is received by user interface application 700. User interface application 700 may provide one or more windows that allow a game developer to enter a name of the game asset if known to the game developer. The name entered by the game developer is thus the name of the selected game asset. User interface application 700 may alternatively provide one or more windows to provide a search mechanism to the game developer if the game developer does not know the name of the game asset. The game developer may enter one or more search parameters for the game asset through the search windows. Responsive to the search parameters, user interface application 700 may search for one or more game assets that match one or more of the search parameter(s), such as by searching the asset files 712 in data store 710 or by searching a directory (not shown) having the names of the asset files. User interface application 700 may then display a list of the search results to the game developer in one or more windows. The game developer can view the search results to find the game asset desired by the game developer. User interface application 700 then receives a selection of a game asset by the game developer, such as by a mouse selection or another type of selection. User interface application 700 may implement a variety of GUI controls to provide the game developer with a mechanism to select a game asset.
In a step 820, a particular type of relationship to display for the selected game asset is selected by a user and the selection is received by user interface application 700. In game development, relationships between game assets are generated, such as discussed in relation to FIGS. 1-6. One type of relationship is a “parent” relationship. If the selected game asset depends on or references another game asset, then the selected game asset may be referred to as having a “parent” relationship with the other game asset. A term other than “parent” may be used to describe this logical relationship between the game assets. If the selected game asset is a parent, then a change to the other game asset affects the selected game asset.
Another type of relationship is a “child” relationship. If another game asset depends on or references the selected game asset, then the selected game asset may be referred to as having a “child” relationship with the other game asset. A term other than “child” may be used to describe this logical relationship between the game assets. If the selected game asset is a child, then a change to the selected game asset affects the other game asset.
As an example of types of relationships, assume that a fire engine mesh is created by game developers as previously described. The fire engine mesh is associated with at least a color file, a sound file, and possibly other files. The fire engine mesh has a parent relationship with the color file and the sounds file as it depends on or references the color file and the sound file. A change to either the color file or the sound file would affect the fire engine mesh. The color file and the sound file have a child relationship with the fire engine mesh as they both are depended on or referenced by the fire engine mesh.
Other types of relationships may be defined between the game assets as desired. As an example, another type of relationship may be a “category” relationship. Game assets of the same category, such as sound, color, etc, may be related in some fashion.
User interface application 700 allows the user to select between different types of relationships. User interface application 700 may provide a menu displaying the relationship options that are selectable by the user. For instance, user interface application 700 may provide a menu displaying relationship options, such as “Children”, “Parents”, “Category”, etc. The “Children” option references the child relationship. The “Parents” option references the parent relationship. The “Category” option references the category relationship.
In a step 830, user interface application 700 identifies one or more other game assets having the selected relationship with the selected game asset. If the user has selected a child relationship for example, then user interface application 700 identifies one or more other game assets that are children of the selected game asset. If the user has selected a parent relationship for example, then user interface application 700 identifies one or more other game assets that are parents of the selected game asset. If the user has selected a category relationship for example, then user interface application 700 identifies one or more other game assets that are in the same category as the selected game asset.
In identifying the other game assets having the selected relationship with the selected game asset, user interface application 700 may access the ARM file 711 or another data structure having relationship information. As previously described, ARM file 711 includes any exportable information about a specific digital game asset, including a relationship reference and an annotation. The relationship reference is a logical statement and/or an indicator that defines a dependency or referential relationship that the specific digital game asset has with any other digital game asset. User interface application 700 may process the relationship references of the ARM file 711 to identify the other game assets related to the selected game asset.
Alternatively, user interface application 700 may access the asset relationship graph 715 to identify the other game assets having the selected relationship with the selected game asset. As previously described, 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 assets. User interface application 700 may process an ARM graph acknowledgment or acknowledgment parameters from the ARM graph acknowledgment as provided by the server process described in relation to FIG. 5 (see steps 550 and 560 of FIG. 5).
In a step 840, user interface application 700 displays the one or more other game assets having the selected relationship with the selected game asset. User interface application 700 may display the other game assets in any desired manner, such as in a tree structure. If the selected relationship is a child relationship, then user interface application 700 displays the children of the selected game asset. If the selected relationship is a parent relationship, then user interface application 700 displays the parents of the selected game asset. If the selected relationship is another relationship, then user interface application 700 displays the other game assets having that relationship with the selected game asset.
FIG. 9 illustrates an exemplary screen 900 generated by user interface application 700. Screen 900 includes a menu bar including a “File” menu, a “Tools” menu, and a “Help” menu. These menus are just examples and screen 900 may include different menus in other embodiments. Screen 900 also includes a search window 902 that provides a search mechanism to allow a user to search for game assets. Any desired search mechanism may be used for screen 900. Screen 900 also includes a drop down menu 903 that allows a user to select a particular type of relationship to be displayed for the selected game asset. Menu 903 is illustrated as including a “Children” option, a “Parents” option, and a “Category” option, although other options may be provided in other embodiments. The “Children” option refers to a child relationship. The “Parents” option refers to a parent relationship. The “Category” option refers to a category relationship.
Screen 900 also includes a window 904 that displays one or more game assets that are selectable by the user. In this example, game asset 1 is the selected game asset of the user. Screen 900 also includes a window 906 that displays one or more game assets that have the selected relationship (undefined in FIG. 9) with the selected game asset.
The user may select one of the options in menu 903. Assume for example that the user selects the “Children” option. Responsive to the selection of the child relationship, user interface application 700 identifies the other game assets that are children of game asset 1. FIG. 10 illustrates an exemplary screen 1000 generated by user interface application 700 to show the children of game asset 1. In screen 1000, the children of game asset 1 are displayed, which are game asset 2, game asset 3, and game asset 4. Those skilled in the art understand that game asset 1 may have more or less children than those illustrated in FIG. 10.
The user can then switch to another desired relationship. For instance, the user may again access menu 903 and select the “Parents” option. Responsive to the selection of the parent relationship, user interface application 700 identifies the other game assets that are parents of game asset 1. FIG. 11 illustrates an exemplary screen 1100 generated by user interface application 700 to show the parents of game asset 1. In screen 1100, the parents of game asset 1 are displayed, which are game asset 5, game asset 6, and game asset 7. Those skilled in the art understand that game asset 1 may have more or less parents than those illustrated in FIG. 11.
In FIG. 10, the user may access a new game asset (e.g., game asset 5, game asset 6, and game asset 7) that is displayed in window 906 (such as game asset 5). Responsive to the selection of game asset 5 (with the “Children” option already selected), user interface application 700 identifies the other game assets that are children of game asset 5. FIG. 12 illustrates an exemplary screen 1200 generated by user interface application 700 to show the children of game asset 5. In screen 1200, the children of game asset 5 are displayed, which are game asset 8, game asset 9, and game asset 10. Those skilled in the art understand that game asset 5 may have more or less children than those illustrated in FIG. 12.
The user can then switch to another desired relationship. For instance, the user may again access menu 903 and select the “Parents” option. Responsive to the selection of the parent relationship, user interface application 700 identifies the other game assets that are parents of game asset 5. FIG. 13 illustrates an exemplary screen 1300 generated by user interface application 700 to show the parents of game asset 5. In screen 1300, the parents of game asset 5 are displayed, which are game asset 11, game asset 12, and game asset 13. Those skilled in the art understand that game asset 5 may have more or less parents than those illustrated in FIG. 13.
The user may select different game assets and different relationships among the game assets in order to logically navigate through the game assets based on the relationships. User interface application 700 is not intended to be a tool to navigate through a file system where the game assets are stored, although it may include such functionality. User interface application 700 is intended to navigate through the game assets logically based on the relationships that the game assets have with one another. The logical navigation is based on relationships regardless of the structure of the file system used to store the game assets. Thus, a game developer can easily identify each of the other game assets having a relationship with a selected game asset, such as before editing or deleting the selected game asset. The game developer can advantageously identify each of the other game assets having a relationship with the selected game asset without having to search through a large file system to find each instance of the selected game asset as stored in the file system.

EXAMPLE

FIGS. 14-17 illustrate an example of displaying relationships between game assets in a game development environment. Assume again for this example that a game development team composed of three separate groups is charged with developing a set of vehicles for a video game. The first group is to develop a fire engine game asset, the second group is to develop a police car game asset, and the third group is to develop a sports car game asset. For the fire engine game asset (referred to below as fire_engine1), the first team develops a fire engine mesh (fire_engine_mesh), and selects a color file called fire_engine_red and a sound file called fire_engine_sound that are referenced by the fire engine mesh file. For the police car game asset, the second group develops a police car asset file from an existing car mesh file (car_mesh), selects color files for black, white, and chrome portions of the police car, and selects the fire_engine_sound file that are referenced by the police car asset mesh file. For the sports car game asset, the third group develops a sports car mesh (sports_car_mesh), and selects the fire_engine_red file, the chrome color file, and the fire_engine_sound file that are referenced by the sports car mesh.
At some point during development by the third group, they decide that the fire_engine_sound file may not be appropriate for the sports car and want to change the file. A game developer in the third group may access the user interface application 700 (see FIG. 7) to determine what other game assets have a relationship with the fire_engine_sound file.
FIG. 14 illustrates an exemplary screen 1400 generated by user interface application 700. Screen 1400 includes similar windows as described in FIG. 9. If the game developer is not sure of the name of the fire_engine_sound file, then the game developer may search for the file. The game developer knows that the fire_engine_sound file is used by a fire engine in the game. Thus, the game developer may enter the search parameters “fire” and “engine” into the search window 902 as illustrated in FIG. 14. Responsive to the search parameters, user interface application 700 identifies game assets that match the search parameters, and displays the search results in window 904. In this example, user interface application 700 displays a fire_engine1 file, a fire_engine2 file, and a fire_engine3 file. The game developer may then select one of the fire engine files (assume the fire_engine1 file) in window 904. The game developer also selects a particular type of relationship to display in menu 903, such as the children of the selected game asset, the parents of the selected game asset, etc. At the time represented in FIG. 14, game developer has selected the “Children” option.
Responsive to the selection of the fire_engine1 file and the “Children” option, user interface application 700 identifies other game assets that are children of the fire_engine1 file. In this example, user interface application 700 identifies the fire engine mesh file named fire_engine_mesh as being a child of the fire_engine1 file, and displays the fire_engine_mesh file in window 906. Those skilled in the art understand that the fire_engine1 file may have other children although only one is shown as an example.
The game developer may then select the fire_engine_mesh file to identify the children of that file. Responsive to the selection of the fire_engine_mesh file, user interface application 700 identifies the children of the fire_engine_mesh file. In this example, user interface 700 identifies the fire_engine_red file and the fire_engine_sound file as children of the fire_engine_mesh file, and displays the files in window 906 (see FIG. 15). FIG. 15 illustrates another exemplary screen 1500 generated by user interface application 700. The developer has thus located the desired fire engine sound file by searching the children of the fire_engine 1 file.
To determine what other asset files depend on the fire_engine_sound file, the game developer may select the fire_engine_sound file and select the “Parent” option from menu 903. FIG. 16 illustrates another exemplary screen 1600 generated by user interface application 700. The game developer drops down the options from menu 903, which are “Children”, “Parent”, and “Category”. There may be other options in menu 903 as desired to represent other relationships among the game assets. The “Parent” option may be selected according to other means, such as through the main menu of screen 1600, through a pop-up window responsive to a right-click on the fire_engine_sound file, etc. Responsive to the selection of the fire_engine_sound file and the “Parent” option, user interface application 700 identifies other game assets that are parents of the fire_engine sound file. User interface application 700 identifies the fire_engine_mesh, the car_mesh, and the sports_car_mesh as being parents of the fire_engine_sound file. User interface application 700 then displays the files in window 906 (see FIG. 17). FIG. 17 illustrates another exemplary screen 1700 generated by user interface application 700. In FIG. 17, window 906 displays each of the parents of the fire_engine_sound file, which are the fire_engine_mesh file, the car_mesh file, and the sports_car_mesh file. The game developer can thus determine what other game assets would be affected by a change to the fire_engine_sound file.
The game developer can select any particular game asset, and switch between the “Parent” option, the “Children” option, the “Category” option, or other relationship options to identify the relationships that the particular game asset has with other game assets. The game developer advantageously does not need to navigate through a file system to try do determine the relationships of the particular game asset.
Although the present novel development has been described in connection with the preferred form of practicing it and modifications thereto, those of ordinary skill in the art will understand that many other modifications can be made to the present concept within the scope of the claims that follow. Accordingly, it is not intended that the scope of the concept in any way be limited by the above description, but instead be determined entirely by reference to the claims that follow.

Claims

1. A method of displaying relationships between game assets in a game development environment, the method comprising:

receiving a selection of a game asset;

receiving a selection of a type of relationship to display for the selected game asset;

identifying other game assets having the selected relationship with the selected game asset; and

displaying the other game assets having the selected relationship with the selected game asset.

2. The method of claim 1 wherein receiving a selection of a type of relationship comprises:

receiving a selection of a child relationship.

3. The method of claim 2 wherein displaying the other game assets comprises:

displaying the children of the selected game asset responsive to the selection of the child relationship.

4. The method of claim 1 wherein receiving a selection of a type of relationship comprises:

receiving a selection of a parent relationship.

5. The method of claim 4 wherein displaying the other game assets comprises:

displaying the parents of the selected game asset responsive to the selection of the parent relationship.

6. The method of claim 1 wherein identifying other game assets comprises:

processing an asset relationship management file to identify the other game assets having the selected relationship with the selected game asset.

7. The method of claim 1 wherein identifying other game assets comprises:

processing an asset relationship graph to identify the other game assets having the selected relationship with the selected game asset.

8. The method of claim 1 wherein displaying the other game assets comprises:

displaying the other game assets in a tree structure.

9. The method of claim 1 further comprising:

providing a search window to allow the user to search for the selected game asset.

10. A computer program product adapted to navigate through game assets logically based on relationships that the game assets have with one another, the computer program product comprising:

computer useable medium including a computer-readable program, wherein the computer-readable program when executed on a computer causes the computer to:

display a first window displaying at least one game asset and a menu displaying a plurality of relationships between game assets, wherein the plurality of relationships includes at least a child relationship and a parent relationship;

receive a selection of a first game asset from the first window and a selection of the child relationship from the menu; and

display a second window displaying at least one other game asset having the child relationship with the selected first game asset.

11. The computer program product of claim 10 wherein the computer-readable program further causes the computer to:

receive a selection of a parent relationship from the menu; and

display the second window displaying at least one other game asset having the parent relationship with the selected first game asset.

12. The computer program product of claim 10 wherein the computer-readable program further causes the computer to:

receive a selection of a second game asset from the second window; and

display the second window displaying at least one other game asset having the child relationship with the selected second game asset.

13. The computer program product of claim 12 wherein the computer-readable program further causes the computer to:

receive a selection of the parent relationship from the menu; and

display the second window displaying at least one other game asset having the parent relationship with the selected second game asset.

14. The computer program product of claim 10 wherein the menu comprises a drop-down menu.

15. The computer program product of claim 10 wherein the computer-readable program further causes the computer to:

provide a search window to allow the user to search for the at least one game asset displayed in the first window.

16. The computer program product of claim 10 wherein the computer-readable program further causes the computer to:

display the at least one other game asset having the child relationship with the selected first game asset in a tree structure.

17. A method of navigating through game assets in a game development environment, the method comprising:

providing a tool to select game assets in the game development environment; and

providing a tool to select relationships among the game assets in order to provide logical navigation through the game assets based on the relationships.

18. The method of claim 17 wherein the logical navigation is based on relationships among the game assets regardless of the structure of the file system used to store the game assets.

19. The method of claim 17 wherein the relationships include at least a child relationship and a parent relationship.

20. The method of claim 17 further comprising:

providing a search window to allow the user to search for game assets.