Addressable Assets in Software Development

Abstract

A method for tracking the location of a gaming asset is disclosed. Content for an application is created using a first asset. The first asset includes asset data describing at least a portion of content associated with the asset. The asset data is placed in one or more files within a location within one or more memories. A directory associated with the application is created on a server. A directory entry for the first asset is created. The directory entry includes an address that uniquely identifies the first asset. A request is received from the application for asset data associated with the first asset, the request including the address. Location data associated with the address is determined using the address and the directory. Asset data at the determined location is retrieved using the determined location data. The retrieved asset data is returned to the application.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application No. 62 / 671,244, filed on May 14, 2018, entitled “SYSTEM AND METHOD FOR ADDRESSABLE ASSETS IN SOFTWARE DEVELOPMENT,” which is incorporated herein by reference in its entirety. Technical Field

[0003] The present disclosure relates to tools for use in managing the tracking of data for virtual assets in games and other applications. Background Art

[0004] In the world of video game creation, there are many tools that guide creators through the main process of game creation, which includes designing the game, building the game, and deploying the game. Many of these tools enable junior computer programmers (and non-computer programmers) to perform some of the steps within these processes. However, when it comes to packaging and tracking data for digital assets (e.g., including characters, background objects, weapons, special effects, etc.) for games or other applications, the deployment process remains quite difficult. This is partly due to the large number of operating systems and devices that a game may have as deployment targets.

[0005] For example, operating systems and devices often have different format requirements for using digital assets. In addition, high-quality games often have large numbers of virtual assets, which becomes a problem for mobile games where device memory and download limitations may become issues. In addition, most games are developed after they are first released with new virtual assets (e.g., adding different game modes or adding game levels), making tracking virtual assets and associated data increasingly complex over time.

[0006] For game developers, it is difficult to construct the digital assets of the game in a way that can be effectively loaded during game time. One solution is to divide the digital assets into blocks and download them when needed (for example, when the assets in the block are needed). The limitation when using digital asset blocks is the high level of expertise required for game developers to understand and manage the complexity of digital asset blocks. Using asset blocks usually involves writing code to build, load, unload and manage the block and its dependencies. Incremental builds (for example, only updating blocks when adding new assets to the game) cannot be reliably performed, so that all assets in the block are usually forced to be rebuilt whenever the assets are updated, which will result in a potential huge time expenditure that increases in proportion to the number of assets in the game. As the complexity of the game increases over time, this may lead to the reconstruction of the code. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Features and advantages of example embodiments of the present disclosure will become apparent from the following detailed description taken in conjunction with the accompanying drawings, in which:

[0008] Figure 1 is a schematic diagram illustrating an addressable asset system according to one embodiment;

[0009] Figure 2 is a schematic diagram illustrating a development cycle using an addressable asset system according to one embodiment;

[0010] Figure 3 is a flow chart of a content creation process using an addressable asset system according to one embodiment;

[0011] Figure 4 is a flow chart of a build process using an addressable asset system according to one embodiment;

[0012] Figure 5 is a flow chart of a runtime process for using an addressable asset system according to one embodiment;

[0013] Figure 6 is a block diagram illustrating an example software architecture that may be used in conjunction with the various hardware architectures described herein; and

[0014] Figure 7 is a block diagram illustrating components of a machine configured to read instructions from a machine-readable medium (eg, a machine-readable storage medium) and perform any one or more of the methods discussed herein, according to some example embodiments.

[0015] It will be noted that throughout the drawings, like features are identified by like reference numerals. DETAILED DESCRIPTION

[0016] The following description describes, individually or in combination, example systems, methods, techniques, instruction sequences, and computing machine program products that include illustrative embodiments of the present disclosure. In the following description, for the purpose of illustration, many specific details are set forth to provide an understanding of the various embodiments of the subject matter of the invention. However, it will be apparent to those skilled in the art that the various embodiments of the subject matter of the invention may be practiced without these specific details.

[0017] An addressable asset system that uses addresses to provide efficient runtime loading of digital assets for games is described herein. The addressable asset system handles asset management for games and simplifies the creation and deployment of content. According to an embodiment, during game play (e.g., execution of game code), the addressable asset system allows the game code to simply query the address associated with the digital asset at runtime and receive data describing the digital asset residing at the address. Using the addressable asset system, development studios can greatly improve the iteration time of projects (e.g., development of games), thereby enabling studios to design, code, and test projects more frequently, thereby obtaining higher quality games or applications.

[0018] In an example implementation, a method for tracking the location of a gaming asset is disclosed. Content for an application is created using a first asset. The first asset includes asset data describing at least a portion of content associated with the asset. The asset data is placed in one or more files within a location within one or more memories. A directory associated with the application is created on a server. A directory entry for the first asset is created. The directory entry includes at least an address and location data, the address being a unique identifier for the first asset and the location data being a description of the location of the first asset. A request for asset data associated with the first asset is received from the application, the request including the address. Location data associated with the address is determined using the address and the directory. Asset data at the determined location is retrieved using the determined location data. The retrieved asset data is returned to the application.

[0019] The terms "environment" or "gaming environment" used throughout this specification should be understood to include 2D digital environments (e.g., 2D video game environments, 2D simulation environments, etc.), 3D digital environments (e.g., 3D gaming environments, 3D simulation environments, 3D content creation environments, virtual reality environments, etc.), and augmented reality environments that include both digital (e.g., virtual) components and real-world components.

[0020] As used herein, the term "game object" should be understood to mean any digital object or digital element included in an environment (e.g., a game environment). A game object can represent almost anything in the environment, including characters, weapons, scene elements (e.g., buildings, trees, cars, treasures, etc.), backgrounds (e.g., terrain, sky, etc.), lights, cameras, effects (e.g., sound and vision), animations, etc. A game object is associated with data that defines the properties and behavior of the object.

[0021] As used herein, the terms "asset", "game asset" and "digital asset" should be understood to include any data that can be used to describe a game object or that can be used to describe aspects of a game or project. For example, an asset can include data for an image, a 3D model (textures, rigs, etc.), a set of 3D models (e.g., an entire scene), audio, video, animation, a 3D mesh, etc. The data describing an asset can be stored within a file, or can be contained within a collection of files, or can be compressed and stored in a file (e.g., a compressed file), or can be stored in a memory. The data describing an asset can be used to instantiate one or more game objects within the game at runtime.

[0022] Throughout the specification herein, the term "asset package" refers to a set of data that describes one or more assets. This set of data can be in a file or a set of files (e.g., a zip file) or in a memory. The data in an asset package is the following data that is stored outside the executable game file and is used by the game during runtime to create or modify objects in the game. Two or more asset packages can have dependencies on each other; for example, an asset representing a material in asset package "A" can reference an asset representing a texture in asset package "B". In addition, during the runtime of the game, an asset package can be represented by a programming object (e.g., an object-oriented programming object), which can interact with it via code (e.g., from within the executable game file) to load data describing the asset from a specific asset package into the game. The asset package programming object can include a mapping of a location (e.g., a file path to a file in the asset package) to an object in the game.

[0023] Turning now to the drawings, there is shown a system and method for addressable assets according to an embodiment of the present invention, the system and method including non-routine or unconventional components or operations or a combination of such components or operations. According to an embodiment, Figure 1An addressable asset system 100 for providing efficient runtime loading of assets by address is shown. In an example implementation, the addressable asset system 100 includes: a developer device 102 operated by a developer 130 (e.g., a game developer, an artist, etc.); a user device 162 operated by a user 160; and a content server 140 coupled in network communication via a network 150 (e.g., a cellular network, a Wi-Fi network, the Internet, a wired local area network, etc.). In some implementations, the content server 140 may be a content delivery network (CDN). The user device 162 is a computing device capable of providing a multimedia experience (e.g., a video game, a simulation, a virtual reality experience, an augmented reality experience, etc.) to the user 160. In some implementations, the user device 162 is a mobile computing device, such as a smart phone, a tablet computer, and a head mounted display (HMD) such as a virtual reality HMD, an augmented reality HMD, and a mixed reality HMD, etc. In some implementations, the user device 162 is a desktop computer or a game console. The developer device 102 is capable of providing an integrated development environment IDE or a game development platform (e.g., such as Unity) to the developer 130. TM In some implementations, the developer device 102 is a computing device that is powered by a game engine. In some implementations, the developer device 102 is a mobile computing device, such as a smartphone, a tablet computer, and a head mounted display (HMD) such as a virtual reality HMD, an augmented reality HMD, and a mixed reality HMD. In some implementations, the developer device 102 is a desktop computer.

[0024] According to an embodiment, content server 140 includes database 142 and server 144. Database 142 includes assets used by applications (eg, games) residing on user device 162.

[0025] According to an embodiment, the developer device 102 includes one or more central processing units 103 (CPUs) and a graphics processing unit 105 (GPU). The CPU 103 is any type of processor, a processor assembly including multiple processing elements (not shown), which is capable of accessing the memory 101 to retrieve instructions stored thereon and execute such instructions. When executing such instructions, these instructions enable the developer device 102 to perform a series of tasks as described herein. The memory 101 can be any type of memory device, such as a random access memory, a read-only or rewritable memory, an internal processor cache, etc.

[0026] The developer device 102 also includes one or more input / output devices 108 such as, for example, a keyboard or keypad, a mouse, a pointing device, and a touch screen. The developer device 102 also includes one or more display devices 109, such as, for example, a computer monitor, a touch screen, and a head mounted display, which can be configured to display digital content including videos, video game environments, integrated development environments, and virtual simulation environments to the developer 130. The display device 109 is driven or controlled by one or more GPUs 105 and optionally by the CPU 103. The GPU 105 processes various aspects of the graphical output that helps accelerate the rendering of the output through the display device 109. The developer device 102 also includes one or more networking devices 107 (e.g., a wired network adapter or a wireless network adapter) for communicating over a network 150.

[0027] The memory 101 in the developer device 102 may be configured to store an application 114 (e.g., an integrated development environment IDE) that includes a game engine 104 (e.g., executed by the CPU 103 or GPU 105) that communicates with a display device 109 and also with other hardware such as an input device 108 to present the application to the developer 130. The game engine 104 may generally include one or more modules that provide the following to provide an application environment (e.g., a video game or simulation environment) to the user: animation physics of game objects, collision detection of game objects, rendering, networking, sound, animation, etc. The application 114 includes an addressable asset module 116 that provides various addressable asset system 100 functions as described herein. The application 114 includes a build manager 118 and a resource manager 120. Each of the game engine 104, the application 114, the build manager 118, the resource manager 120, and the addressable asset module 116 includes computer executable instructions residing in the memory 101, which are executed by the CPU 103 during operation and optionally executed by the GPU 105. The game engine 104 includes computer executable instructions residing in the memory 101, which are executed by the CPU 103 during operation and optionally executed by the GPU 105 to create a runtime program such as a game engine. The application 114 includes computer executable instructions residing in the memory 101, which are executed by the CPU 103 during operation and optionally executed by the GPU 105 to create a runtime application such as an IDE. The addressable asset module 116, the build manager 118, and the resource manager 120 can be directly integrated within the game engine 104 or within the application 114, or can be implemented as an external software block (e.g., a plug-in).

[0028] According to an embodiment, the user device 162 includes one or more central processing units 163 (e.g., similar to the CPU 103 in the developer device 102) and a graphics processing unit 165 (e.g., similar to the GPU 105 in the developer device 102). The CPU 163 is any type of processor, a processor component including multiple processing elements (not shown), which is capable of accessing the memory 161 to retrieve instructions stored thereon and execute such instructions. When executing such instructions, these instructions enable the user device 162 to perform a series of tasks as described herein. The memory 161 can be any type of memory device similar to the memory 101 on the developer device 102.

[0029] The user device 162 also includes one or more input / output devices 168 similar to the input / output devices 108 on the developer device 102. The user device 162 also includes one or more display devices 169 similar to the display device 109 on the developer device 102, which can be configured to display digital content including videos, video game environments, and virtual simulation environments to the user 160. The display devices 169 are driven or controlled by one or more GPUs 165 and optionally by the CPU 163. The GPU 165 processes various aspects of the graphical output that helps accelerate the rendering of the output through the display device 169. The user device 162 also includes one or more networking devices 167 (e.g., a wired network adapter or a wireless network adapter) for communicating over the network 150.

[0030] According to embodiments, the memory 161 in the user device 162 may be configured to store an application 174 (e.g., a video game, simulation, virtual reality experience, augmented reality experience) that includes a game engine 164 (e.g., executed by the CPU 163 or GPU 165) that communicates with a display device 169 and also with other hardware such as an input device 168 to present the application to the user 160. The game engine 164 is similar to the game engine 104 on the developer device 102. The application 174 includes an addressable asset module 166 that provides various addressable asset system 100 functions as described herein. The application 174 includes a resource manager 170. Each of the game engine 164, application 174, resource manager 170, and addressable asset module 166 includes computer executable instructions resident in the memory 161 that are executed by the CPU 163 and optionally by the GPU 165 during operation. The game engine 164 includes computer executable instructions resident in the memory 161, which are executed by the CPU 163 during operation and optionally by the GPU 165 to create a runtime program such as a game engine. The application 174 includes computer executable instructions resident in the memory 161, which are executed by the CPU 163 during operation and optionally by the GPU 165 to create a runtime application such as a video game or emulator. The addressable asset module 166 and the resource manager 170 can be directly integrated within the game engine 164 or within the application 174, or can be implemented as an external software block (e.g., a plug-in).

[0031] According to an embodiment, Figure 2 1 is an application development cycle 205 for creating an application using the addressable asset system 100. The first process in cycle 205 is application content creation 200, in which a developer 130 uses a developer device 102 to create content for an application (e.g., a video game, a virtual reality experience, a movie, a simulation, etc.). For example, a developer 130 may use an application 114 and a game engine 104 in the application 114 to create content by creating a 3D scene using game objects and assigning properties and behaviors to the game objects. The second process in cycle 205 is application build 202, in which a game that can be used on an operating system (e.g., including Microsoft Windows) is created. TM Operating system, Apple TM Operating system, Linux operating system, Android TM162 and present the application to the user 160 (e.g., a game, a virtual reality experience, a movie, a simulation, etc.).

[0032] According to an embodiment, Figure 3, operations of the application content creation process 200 from the application development cycle 205 are shown. At operation 300, the developer 130 creates content for the application using one or more assets. As part of the creation process, the developer 130 can import assets for the application and can create assets for the application. Creating content includes creating game objects (e.g., characters and scenery), game levels, etc. At operation 302, the game engine 104 generates a unique identifier (or unique ID) for each asset (e.g., including a string identifier of a number, letter, alphanumeric, or any type). The unique ID is a permanent unique identifier that identifies an asset. The data defining the asset is stored in one or more files. At operation 304, the developer 130 indicates that the asset will be addressable using the addressable asset system 100 (e.g., via a graphical user interface generated by module 116 or via code and application interface (API) provided by module 116). According to an embodiment, the addressable asset has an associated name (e.g., a string tag) to easily identify and reference the addressable asset. In some embodiments, the tag can be shared by a group of addressable assets. The tag of the addressable asset provides an auxiliary identifier that can be used to load multiple similar assets at runtime. For example, a game may include several types of space hazards that are labeled as "space hazards (space hazard)", and all of these space hazards can be accessed using a single command using the tag as input (e.g., load all ("space hazards")). At operation 306, the addressable asset module 116 provides an address for the asset and associates the address with a location (e.g., a file path name) for the asset data. According to an embodiment, the location includes a physical location such as a content server 140 (e.g., a content delivery network), a remote server, and a local data storage device (e.g., a local hard drive on the developer device 102). The address identifies the asset for efficient retrieval at runtime (e.g., when the game is being played). According to an embodiment, the asset address is initialized to a string value of the file path location of the file containing the data for the asset. At operation 308, the addressable asset module 116 tracks the location of the asset data (e.g., by tracking one or more files containing the data) as the data is moved (e.g., by the developer).

[0033] According to an embodiment, Figure 4, a build process 202 using the addressable asset system 100 is shown. At operation 400 of the build process 202, the addressable asset module 116 receives data describing a group of addressable assets to be packaged into an asset package (e.g., a list of addressable assets). For example, the developer 130 can create an addressable asset group using a user interface provided by the module 116 or the game engine 114. At operation 402, the build manager 118 receives a request for a build of an application. The request includes configuration file data (e.g., created by the developer), which includes settings for a build of an asset package (e.g., a build of an asset package including a packaged version ready for use by an executable application). As part of operation 402 of the build process 202, the developer can issue a request and create a configuration file (e.g., via a graphical user interface). At operation 404 of the build process 202, for each asset in the addressable asset group, the addressable asset module 116 searches for the most current location (e.g., the most current file path) of the asset file. At operation 406 of the build process 202, the addressable asset module 116 creates a content directory for the application, which includes one or more asset packages associated with the application. The content directory includes a list of asset addresses, wherein each asset in one or more asset packages is associated with at least one asset address entry in the list. According to an embodiment, for each asset address entry on the list, data for the location of a file describing the asset is provided. The content directory provides a mapping between an asset address and at least one location containing data describing the asset, the asset being associated with the asset address. Each content directory is associated with an executable application (e.g., an executable application may contain data pointing to a content directory associated therewith). The content directory may also include instructions for loading data describing the asset into the application. At operation 408 of the build process 202, the addressable asset module 116 packages assets and their dependencies from the addressable asset group into an asset package according to the settings in the request. Even when the asset is moved or renamed (e.g., due to the fact that the asset is tracked by the addressable asset module 116), the addressable asset module 116 understands the complex asset dependency chain and packages effectively. According to an embodiment, as part of operation 408, the addressable asset module 116 separates duplicate assets and places them in separate packages for cleaner loading at runtime. A duplicate asset is a single asset that has a dependency relationship with two or more assets. According to an embodiment, the addressable asset module 116 prioritizes a subset of assets to be included in an asset package (e.g., including assets for user interface menus, game or application tutorials, and first-level game content). As part of operation 408, the addressable asset module 116 can split the content build based on a maximum size limit indicated in a configuration file.For example, the addressable asset system 100 can be configured to limit the size of a built application (e.g., 100MB) and import the remaining assets into an asset package as downloadable content to optimize the packaging of the content of the game or application, thereby reducing the download of data over the network to the device and reducing the loading of data into memory.

[0034] According to an embodiment, Figure 5 1 is a runtime mode 204 of a development cycle 205, whereby an application is downloaded and executed on a user device 162 to present a runtime version of the application to a user 160. During runtime of the application, an addressable asset module 166 within the application 174 downloads assets from asset packages to memory 161 on the user device 162 (e.g., for use by the application). The addressable asset system 100 uses mappings within the content directory to enable loading of one or more addressable assets (e.g., entire asset scenes) by name (e.g., tag or address) at runtime, regardless of which asset package the one or more assets are in or where the asset package is located (e.g., on a remote device over a network or on a local device) or whether the addressable assets have been moved by the developer. Changes in asset locations are tracked and updated in real time in the content directory (e.g., by the addressable asset module 116 in operations 308 and 406), so the addressable asset module 166 always includes the current location of the addressable assets. Specifying assets by address enables developers to create applications that load assets at runtime without requiring the developer to write specific code to directly track the data location of the asset on disk or on a server or content delivery network (CDN).

[0035] According to the implementation mode, reference Figure 5 , at operation 500 of the runtime mode 204, the application is run (e.g., executed) on the user device 162. For example, the application may be executed by a user operating the user device 162 (e.g., to play a game via a runtime version of the application 174). According to an embodiment, at operation 502 of the runtime mode 204, the application 174 (when executed) requires an asset from within an asset package. The executing application determines the address of the required asset and sends a request including the address to the addressable asset module 166. The request includes the address and a request for data associated with the required asset (e.g., asset data within an asset file). According to an embodiment, at operation 504 of the runtime mode 204, the addressable asset module 166 communicates (e.g., sends a request) with a content directory on the content server 140 via the network 150 to determine the current location of the data associated with the address. According to an embodiment, at operation 506 of the runtime mode 204, the addressable asset module 166 asynchronously downloads the required asset data based on the current location received from the content directory.

[0036] According to an embodiment, the addressable asset system 100 includes dependency management, whereby the content directory includes dependency information for each address entry within the directory. Thus, at runtime, as part of operations 504 and 506, the addressable asset module 116 receives data associated with dependency assets for any requested address (e.g., without specifying the location of the dependency). For example, an application 174 may request an asset simply by the asset's address or tag, and the application 174 will receive data about the asset's dependency assets.

[0037] According to an embodiment, with asynchronous loading within operation 506, the requested assets and dependencies of the requested assets can reside in any location (locally, on a remote server, or on a CDN) for loading in any order (e.g., as opposed to synchronous loading, whereby a local asset with a dependency will require the dependency to be local and will also require the dependency to be loaded directly after the asset is loaded). By using asynchronous downloading and loading into memory for use by an executing application, the addressable asset system 100 enables users to flexibly move assets (e.g., from a local build group to a remote build group) without changing code within the application 174. Asynchronous loading in combination with addresses enables unique asset identifiers (e.g., created in operation 302) to be decoupled from location, packaging, and loading, so that these aspects can be changed during the development cycle 205 and adapt to deployment needs. More specifically, asynchronous loading in combination with addresses enables the location of an asset (e.g., local, remote, generated, etc.) to change throughout the development cycle 205 of an application without changing code (e.g., within the application) to reference the asset. Without the addressable asset system 100, developers would have to change application code (e.g., to handle additional asset loading logic) when moving assets from a local build group to a remote build group. The addressable asset system 100 allows end users to re-download as little data as possible when developers are updating applications 174. The addressable asset system 100 allows for an easy migration process to support starting with an early prototype with a simple content layout to a deliverable product with a more complex content layout that can span local data, multiple servers, and various platforms.

[0038] According to an embodiment, as part of the runtime mode 204, at operation 520, the developer updates one or more assets for the application 174. The change may include a change to the location of the asset by moving the asset to a different asset bundle of the build process that occurs multiple times (e.g., within the build process 202) or changing the physical location of the asset bundle file (after the build process 202). According to an embodiment, at operation 522, the addressable asset module 116 updates the content directory in real time when the developer makes the change (e.g., at operation 520). The new location information of the changed asset is recorded in the content directory associated with the address of the asset.

[0039] According to an embodiment, the addressable asset system 100 uses reference counting and automatic unloading of assets loaded from asset bundles when the application 174 no longer needs the assets loaded from the asset bundle.

[0040] It should be noted that the present disclosure can be performed as a method, can be implemented in a system, a computer readable medium, or an electronic or electromagnetic signal. The embodiments described above and shown in the accompanying drawings are intended to be exemplary only. It will be apparent to those skilled in the art that modifications can be made without departing from the present disclosure. Such modifications are considered possible variations and are within the scope of the present disclosure.

[0041] Certain embodiments are described herein as including logic or a number of components, modules or mechanisms. A module may constitute a software module (e.g., a code implemented on a machine-readable medium or in a transmission signal) or a hardware module. A "hardware module" is a tangible unit that can perform certain operations and can be configured or arranged in a certain physical manner. In various example embodiments, one or more computer systems (e.g., a stand-alone computer system, a client computer system, or a server computer system) or one or more hardware modules of a computer system (e.g., a processor or a group of processors) may be configured by software (e.g., an application or an application portion) to operate as a hardware module that performs certain operations as described herein.

[0042] In some embodiments, the hardware module can be implemented mechanically, electronically, or in any suitable combination thereof. For example, the hardware module may include a dedicated circuit or logic that is permanently configured to perform certain operations. For example, the hardware module may be a dedicated processor, such as a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC). The hardware module may also include a programmable logic or circuit that is temporarily configured by software to perform certain operations. For example, the hardware module may include software contained in a general-purpose processor or other programmable processor. It should be understood that the decision to mechanically implement the hardware module in a dedicated and permanently configured circuit or in a temporarily configured circuit (e.g., configured by software) may be driven by cost and time considerations.

[0043] Therefore, the phrase "hardware module" should be understood to include a tangible entity, that is, an entity that is physically constructed, permanently configured (e.g., hardwired) or temporarily configured (e.g., programmed) to operate in a specific manner or perform certain operations described herein. As used herein, a "hardware-implemented module" refers to a hardware module. Considering an embodiment in which a hardware module is temporarily configured (e.g., programmed), each of the hardware modules does not need to be configured or instantiated in time at any one time. For example, in the case where a hardware module includes a general-purpose processor that is configured by software to be a special-purpose processor, the general-purpose processor can be configured as a different special-purpose processor (e.g., including different hardware modules) at different times. Software can configure a specific one or more special-purpose processors accordingly, for example, to constitute a specific hardware module at one time and to constitute different hardware modules at different times.

[0044] A hardware module can provide information to other hardware modules and receive information from other hardware modules. Therefore, the described hardware module can be regarded as being coupled in communication. In the case of multiple hardware modules being present at the same time, communication can be achieved by signal transmission (e.g., by appropriate circuits and buses) between two or more hardware modules or among two or more hardware modules. In an embodiment in which multiple hardware modules are configured or instantiated at different times, communication between such hardware modules can be achieved, for example, by storing information in a memory structure that multiple hardware modules can access and retrieving information in the memory structure. For example, a hardware module can perform an operation, and the output of the operation is stored in a memory device coupled in communication. Then, other hardware modules can access the memory device at a later time to retrieve and process the stored output. The hardware module can also initiate communication with an input device or an output device, and can operate on resources (e.g., the collection of information).

[0045] The various operations of the example methods described herein may be performed, at least in part, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the associated operations. Such processors, whether temporarily or permanently configured, may constitute processor-implemented modules that operate to perform one or more operations or functions described herein. As used herein, a "processor-implemented module" refers to a hardware module implemented using one or more processors.

[0046] Similarly, the method described herein can be implemented at least in part by a processor, wherein specific one or more processors are examples of hardware. For example, at least some operations in the operation of the method can be performed by one or more processors or the module implemented by the processor. In addition, one or more processors can also be operated to support the execution of the related operations in the "cloud computing" environment or operate as "software as a service" (SaaS). For example, at least some operations can be performed by a group of computers (as an example of a machine including a processor), wherein these operations can be accessed via a network (for example, the Internet) and via one or more suitable interfaces (for example, application program interface (API)).

[0047] The execution of certain operations may be distributed among processors, not just residing in a single machine, but deployed in multiple machines. In some example embodiments, the processor or processor-implemented modules may be located in a single geographic location (e.g., in a home environment, an office environment, or a server farm). In other example embodiments, the processor or processor-implemented modules may be distributed in many geographic locations.

[0048] Figure 6 7 is a block diagram 700 illustrating an example software architecture 702 that may be used in conjunction with the various hardware architectures described herein to provide components of a game engine 701 and / or addressable asset system 100 . Figure 6 is a non-limiting example of a software architecture, and it should be understood that many other architectures may be implemented to facilitate the functionality described herein. Software architecture 702 may be implemented in a system such as Figure 7 800, which includes a processor 810, a memory 830, and an input / output (I / O) component 850, among others. A representative hardware layer 704 is shown and may represent, for example, Figure 7The machine 800 of the embodiment of the present invention. The representative hardware layer 704 includes a processing unit 706 with associated executable instructions 708. The executable instructions 708 represent executable instructions of the software architecture 702, including implementations of the methods, modules, etc. described herein. The hardware layer 704 also includes a memory / storage device 710, which also includes the executable instructions 708. The hardware layer 704 may also include other hardware 712.

[0049] exist Figure 6 In the example architecture of , software architecture 702 can be conceptualized as a stack of layers, each of which provides specific functionality. For example, software architecture 702 may include layers such as operating system 714, library 716, framework or middleware 718, application 720, and presentation layer 744. In operation, application 720 and / or other components within the layer may call application programming interface (API) 724 through the software stack and receive a response as message 726. The layers shown are representative in nature, and not all software architectures have all layers. For example, some mobile operating systems or dedicated operating systems may not provide framework / middleware 718, while other operating systems may provide such a layer. Other software architectures may include additional layers or different layers.

[0050] The operating system 714 can manage hardware resources and provide public services. The operating system 714 can include, for example, a kernel 728, services 730, and drivers 732. The kernel 728 can be used as an abstraction layer between the hardware layer and other software layers. For example, the kernel 728 can be responsible for memory management, processor management (e.g., scheduling), component management, networking, security settings, etc. The services 730 can provide other public services for other software layers. The drivers 732 can be responsible for controlling or interfacing with the underlying hardware. For example, depending on the hardware configuration, the drivers 732 can include a display driver, a camera driver, drives, flash drives, serial communications drivers (e.g., Universal Serial Bus (USB) drivers), Drivers, audio drivers, power management drivers, etc.

[0051] The library 716 may provide a common infrastructure that can be used by the application 720 and / or other components and / or layers. Compared with directly interfacing with the underlying operating system 714 functions (e.g., kernel 728, service 730 and / or driver 732), the library 716 generally provides functions that allow other software modules to perform tasks in an easier manner. The library 716 may include a system library 734 (e.g., a C standard library), which may provide functions such as memory allocation functions, string manipulation functions, mathematical functions, etc. In addition, the library 716 may include an API library 736, such as a media library (e.g., a library that supports the presentation and manipulation of various media formats such as MPEG4, H.264, MP3, AAC, AMR, JPG, PNG), a graphics library (e.g., an OpenGL framework that can be used to present 2D and 3D graphics content on a display), a database library (e.g., SQLite that can provide various relational database functions), a network library (e.g., WebKit that can provide network browsing functions), etc. The library 716 may also include a variety of other libraries 738 to provide many other APIs to the application 720 and other software components / modules.

[0052] Framework 718 (also sometimes referred to as middleware) provides a higher level common infrastructure that can be used by applications 720 and / or other software components / modules. For example, framework / middleware 718 can provide various graphical user interface (GUI) functions, advanced resource management, advanced location services, etc. Framework / middleware 718 can provide a wide range of other APIs that can be utilized by applications 720 and / or other software components / modules, some of which may be specific to a particular operating system or platform.

[0053] Applications 720 include built-in applications 740 and / or third-party applications 742. Examples of representative built-in applications 740 may include, but are not limited to, contact applications, browser applications, book reader applications, location applications, media applications, messaging applications, and / or game applications. Third-party applications 742 may include applications that are created by entities other than the vendor of a particular platform using Android TM or iOS TM Any application developed with a software development kit (SDK) and can be run on platforms such as iOS TM 、Android TM , Mobile software running on the mobile operating system of the phone or other mobile operating system. The third-party application 742 can call the API call 724 provided by the mobile operating system (eg, operating system 714) to facilitate the functions described herein.

[0054] Applications 720 may create user interfaces using built-in operating system functionality (e.g., kernel 728, services 730, and / or drivers 732), libraries 716, or framework / middleware 718 to interact with a user of the system. Alternatively or additionally, in some systems, interaction with the user may occur through a presentation layer such as presentation layer 744. In these systems, the application / module "logic" may be separated from aspects of the application / module that interact with the user.

[0055] Some software architectures use virtual machines. Figure 6 In the example of , this is illustrated by virtual machine 748. Virtual machine 748 creates a software environment in which applications / modules can execute as if they were on a hardware machine (such as, for example Figure 7 The virtual machine 748 is hosted by a host operating system (e.g., operating system 714) and typically, but not always, has a virtual machine monitor 746 that manages the operation of the virtual machine 748 and the interface with the host operating system (i.e., operating system 714). The software architecture is executed within the virtual machine 748 such as an operating system (OS) 750, libraries 752, frameworks 754, applications 756, and / or presentation layer 758. These layers of the software architecture executed within the virtual machine 748 may be the same as the corresponding layers previously described or may be different.

[0056] Figure 7 800 is a block diagram illustrating components of a machine 800 according to some example embodiments, the components of the machine 800 being configured to read instructions from a machine-readable medium (e.g., a machine-readable storage medium) and perform any one or more of the methods discussed herein. In some embodiments, the machine 800 is similar to the developer device 102 and the user device 162. Specifically, Figure 7A schematic illustration of a machine 800 is shown in the form of an example of a computer system, within which instructions 816 (e.g., software, programs, applications, applet, app or other executable code) for causing the machine 800 to perform any one or more of the methods discussed herein can be executed. Thus, instructions 816 can be used to implement the modules or components described herein. The instructions transform a general unprogrammed machine into a specific machine that is programmed to perform the functions described and shown in the described manner. In an alternative embodiment, the machine 800 operates as a standalone device or can be coupled (e.g., networked) to other machines. In a networked deployment, the machine 800 can operate as a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine 800 may include, but is not limited to, a server computer, a client computer, a personal computer (PC), a tablet computer, a laptop computer, a netbook, a set-top box (STB), a personal digital assistant (PDA), an entertainment media system, a cellular phone, a smart phone, a mobile device, a wearable device (e.g., a smart watch), a smart home device (e.g., a smart appliance), other smart devices, web appliances, a network router, a network switch, a network bridge, or any machine capable of executing instructions 816 that specify actions to be taken by the machine 800, either sequentially or otherwise. In addition, while only a single machine 800 is shown, the term "machine" should also be understood to include a collection of machines that individually or jointly execute instructions 816 to perform any one or more of the methodologies discussed herein.

[0057] The machine 800 may include a processor 810, a memory 830, and an input / output (I / O) component 850 that may be configured to communicate with each other, for example, via a bus 802. In an example embodiment, the processor 810 (e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP), an application specific integrated circuit (ASIC), a radio frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, a processor 812 and a processor 814 that may execute instructions 816. The term "processor" is intended to include a multi-core processor that may include two or more independent processors (sometimes referred to as "cores") that may execute instructions simultaneously. Although Figure 7 Multiple processors 810 are shown, but machine 800 may include a single processor with a single core, a single processor with multiple cores (e.g., a multi-core processor), multiple processors with a single core, multiple processors with multiple cores, or any combination thereof.

[0058] The memory / storage 830 may include memory such as a main memory 832, a static memory 834, or other memory storage devices, and a storage unit 836, both of which are accessible by the processor 810, for example, via the bus 802. The storage unit 836 and the memories 832, 834 store instructions 816 that implement any one or more of the methods or functions described herein. The instructions 816 may also reside, completely or partially, within the memories 832, 834, within the storage unit 836, within at least one of the processors 810 (e.g., within a cache memory of the processor), or within any suitable combination thereof during execution thereof by the machine 800. Thus, the memories 832, 834, the storage unit 836, and the memory of the processor 810 are examples of machine-readable media 838.

[0059] As used herein, "machine-readable medium" refers to a device capable of temporarily or permanently storing instructions and data, and may include, but is not limited to, random access memory (RAM), read-only memory (ROM), buffer memory, flash memory, optical media, magnetic media, cache memory, other types of storage devices (e.g., erasable programmable read-only memory (EEPROM)), and / or any suitable combination thereof. The term "machine-readable medium" should be deemed to include a single medium or multiple media (e.g., a centralized database or distributed database or associated cache memory and server) capable of storing instructions 816. The term "machine-readable medium" should also be deemed to include any medium or combination of multiple media capable of storing instructions (e.g., instructions 816) for execution by a machine (e.g., machine 800) such that the instructions, when executed by one or more processors (e.g., processor 810) of machine 800, cause machine 800 to perform any one or more of the methods described herein. Therefore, "machine-readable medium" refers to a single storage device or device, as well as a "cloud-based" storage system or storage network including multiple storage devices or devices. The term "machine-readable medium" does not include the signal itself.

[0060] The input / output (I / O) components 850 may include a variety of components for receiving input, providing output, generating output, transmitting information, exchanging information, capturing measurements, etc. The specific input / output (I / O) components 850 included in a particular machine will depend on the type of machine. For example, a portable machine such as a mobile phone will likely include a touch input device or other such input mechanism, while a headless server machine will likely not include such a touch input device. It should be understood that the input / output (I / O) components 850 may include Figure 7850 is grouped according to function only to simplify the following discussion, and the grouping is by no means limiting. In various example embodiments, the input / output (I / O) component 850 may include an output component 852 and an input component 854. The output component 852 may include a visual component (e.g., a display such as a plasma display panel (PDP), a light emitting diode (LED) display, a liquid crystal display (LCD), a projector, or a cathode ray tube (CRT)), an acoustic component (e.g., a speaker), a tactile component (e.g., a vibration motor, a resistance mechanism), other signal generators, etc. The input component 854 may include an alphanumeric input component (e.g., a keyboard, a touch screen configured to receive alphanumeric input, an optical keyboard, or other alphanumeric input component), a point-based input component (e.g., a mouse, a touch pad, a trackball, a joystick, a motion sensor, or other pointing instrument), a tactile input component (e.g., a physical button, a touch screen or other tactile input component that provides the location and / or force of a touch or touch gesture), an audio input component (e.g., a microphone), etc.

[0061] In other example embodiments, the input / output (I / O) component 850 may include a biological component 856, a motion component 858, an environmental component 860, or an orientation component 862, as well as various other components. For example, the biological component 856 may include a component for detecting expressions (e.g., hand expressions, facial expressions, voice expressions, body postures, or eye tracking), measuring biological signals (e.g., blood pressure, heart rate, body temperature, sweating, or brain waves), identifying people (e.g., voice recognition, retinal recognition, facial recognition, fingerprint recognition, or EEG-based recognition), etc. The motion component 858 may include an acceleration sensor component (e.g., an accelerometer), a gravity sensor component, a rotation sensor component (e.g., a gyroscope), etc. The environment component 860 may include, for example, an illumination sensor component (e.g., a photometer), a temperature sensor component (e.g., one or more thermometers that detect ambient temperature), a humidity sensor component, a pressure sensor component (e.g., a barometer), an acoustic sensor component (e.g., one or more microphones that detect background noise), a proximity sensor component (e.g., an infrared sensor that detects nearby objects), a gas sensor (e.g., a gas detection sensor for safely detecting concentrations of hazardous gases or measuring pollutants in the atmosphere), or other components that can provide indications, measurements, or signals corresponding to the surrounding physical environment. The orientation component 862 may include a position sensor component (e.g., a global positioning system (GPS) receiver component), an altitude sensor component (e.g., an altimeter or barometer that detects air pressure from which altitude can be derived), a direction sensor component (e.g., a magnetometer), etc.

[0062] A variety of technologies may be used to implement communications. Input / output (I / O) components 850 may include communications components 864 operable to couple machine 800 to network 880 or device 870 via coupling 882 and coupling 872, respectively. For example, communications components 864 may include a network interface component or other suitable device to interface with network 880. In another example, communications components 864 may include a wired communications component, a wireless communications component, a cellular communications component, a near field communications (NFC) component, Components (e.g. Low power consumption), Components and other communication components that provide communication via other modalities. Device 870 may be another machine or any of a variety of peripheral devices (eg, a peripheral device coupled via a universal serial bus (USB)).

[0063] In addition, the communication component 864 can detect the identifier or can include a component that is capable of operating to detect the identifier. For example, the communication component 864 can include a radio frequency identification (RFID) tag reader component, an NFC smart tag detection component, an optical reader component (e.g., an optical sensor for detecting the following: a one-dimensional barcode, such as a universal product code (UPC) barcode; a multi-dimensional barcode, such as a Quick Response (QR) code, Aztec code, Data Matrix, Dataglyph, MaxiCode, PDF417, Hypercode, UCC RSS-2D barcode and other optical codes), or an acoustic detection component (e.g., a microphone for identifying an audio signal of the tag). In addition, various information can be obtained via the communication component 864, such as the location of the geographic location via the Internet Protocol (IP), the location of the ... The location of signal triangulation, the location of an NFC beacon signal via detection that can indicate a specific location, etc.

[0064] Throughout this specification, multiple instances can implement the parts, operations or structures described as single instances. Although the individual operations of one or more methods are shown and described as discrete operations, one or more individual operations can be performed simultaneously, and do not require the operations to be performed in the order shown. The structure and function presented as independent components in the example configuration can be implemented as a combined structure or component. Similarly, the structure and function presented as a single component can be implemented as an independent component. These and other variations, modifications, additions and improvements fall within the scope of the subject matter herein.

[0065] The embodiments shown herein are described in sufficient detail to enable those skilled in the art to practice the disclosed teachings. Other embodiments may be used and derived therefrom, so that structural and logical substitutions and changes may be made without departing from the scope of the present disclosure. Therefore, this specific embodiment is not adopted in a restrictive sense, and the scope of the various embodiments is limited only by the appended claims and the full scope of equivalents to which these claims are assigned.

[0066] As used herein, the term "or" may be interpreted as inclusive or exclusive meanings. In addition, multiple instances may be provided for resources, operations, or structures described herein as single instances. In addition, the boundaries between various resources, operations, modules, engines, and data stores are somewhat arbitrary, and specific operations are shown in the context of specific illustrative configurations. Other allocations of functions are foreseen and may fall within the scope of various embodiments of the present disclosure. Typically, structures and functions presented as independent resources in the example configuration may be implemented as combined structures or resources. Similarly, structures and functions presented as single resources may be implemented as independent resources. These and other variations, modifications, additions, and improvements fall within the scope of the embodiments of the present disclosure as represented by the appended claims. Therefore, the specification and the accompanying drawings are considered to be illustrative rather than restrictive.

Claims

1. A system for tracking the location of a gaming asset, the system comprising: A developer device, the developer device being communicatively coupled to a server, wherein the developer device comprises one or more memories and one or more computer processors, the one or more memories comprising an addressable asset module, the addressable asset module configuring the one or more computer processors to perform operations comprising: creating content for an application using a first asset, the first asset comprising asset data describing at least a portion of content associated with the asset; placing the asset data in one or more files within a location within the one or more memories or additional storage; creating a directory associated with the application on the server; creating a directory entry for the first asset, the directory entry comprising at least an address and location data, the address being a unique identifier for the first asset and the location data being a description of the location of the first asset; receiving a request from the application for asset data associated with the first asset, the request including the address; determining the location data associated with the address using the address and the directory; asynchronously downloading required asset data based on the current location received from the directory without changing code within the application; retrieving the asset data at the determined location using the determined location data; and The retrieved asset data is returned to the application.

2. The system according to claim 1, wherein: The addressable asset module also configures the one or more computer processors to build an executable version of the application, the executable version including data pointing to the directory.

3. The system according to claim 1, wherein: The one or more files are moved to a second location, and wherein the addressable asset module further configures the one or more computer processors to modify the location data within the directory entry using data describing the second location.

4. The system according to claim 1, wherein: The first asset is dependent upon additional data from a second asset, and with the additional data, the addressable asset module further configures the one or more computer processors to perform operations including: placing the additional data in one or more files within the one or more memories or locations within additional storage; adding an additional unique address for the second asset to the directory entry associated with the first asset; as well as Data describing the location of the additional data is added to the entry associated with the first asset.

5. The system according to claim 4, wherein: Retrieving the asset data includes: determining a location of the additional data using the additional address and the directory; retrieving the additional data using the determined location; and returning the retrieved additional data to the executing application.

6. The system according to claim 2, wherein: Placing the assets includes creating an asset package for the executable version of the application, the asset package including a plurality of assets and associated asset data.

7. A method for tracking the location of a gaming asset, the method comprising: Using one or more computer processors of a developer device, creating content for an application using a first asset, the first asset comprising asset data describing at least a portion of content associated with the asset; placing the asset data in one or more files within one or more locations within memory; creating a directory associated with the application on the server; creating a directory entry for the first asset, the directory entry comprising at least an address and location data, the address being a unique identifier for the first asset and the location data being a description of the location of the first asset; receiving a request from the application for asset data associated with the first asset, the request including the address; determining the location data associated with the address using the address and the directory; asynchronously downloading required asset data based on the current location received from the directory without changing code within the application; using the determined location data to retrieve the asset data at the determined location; as well as The retrieved asset data is returned to the application.

8. The method according to claim 7, wherein: The one or more computer processors are also used to construct an executable version of the application, the executable version including data pointing to the directory.

9. The method according to claim 7, wherein: The one or more files are moved to a second location, and wherein the one or more computer processors are further employed to modify the location data within the directory entry with data describing the second location.

10. The method according to claim 7, wherein: The first asset is dependent upon additional data from a second asset and, with the additional data, further uses the one or more computer processors to perform operations including: placing the additional data in one or more files within a location within the one or more memories; adding an additional unique address for the second asset to the directory entry associated with the first asset; as well as Data describing the location of the additional data is added to the entry associated with the first asset.

11. The method according to claim 10, wherein: Retrieving the asset data includes: determining a location of the additional data using the additional address and the directory; retrieving the additional data using the determined location; and returning the retrieved additional data to the executing application.

12. The method according to claim 8, wherein: Placing the assets includes creating an asset package for the executable version of the application, the asset package including a plurality of assets and associated asset data.

13. A non-transitory machine-readable medium comprising a set of instructions that configure one or more computer processors to perform operations comprising: creating content for an application using a first asset, the first asset comprising asset data describing at least a portion of content associated with the asset; placing the asset data in one or more files within one or more locations within memory; creating a directory associated with the application on the server; creating a directory entry for the first asset, the directory entry comprising at least an address and location data, the address being a unique identifier for the first asset and the location data being a description of the location of the first asset; receiving a request from the application for asset data associated with the first asset, the request including the address; determining the location data associated with the address using the address and the directory; asynchronously downloading required asset data based on the current location received from the directory without changing code within the application; using the determined location data to retrieve the asset data at the determined location; as well as The retrieved asset data is returned to the application.

14. The non-transitory machine-readable medium of claim 13, wherein: The set of instructions also configures the one or more computer processors to construct an executable version of the application, the executable version including data pointing to the directory.

15. The non-transitory machine-readable medium of claim 13, wherein: The one or more files are moved to a second location, and wherein the set of instructions further configures the one or more computer processors to modify the location data within the directory entry using data describing the second location.

16. The non-transitory machine-readable medium of claim 13, wherein: The first asset is dependent upon additional data from a second asset, and with the additional data, the set of instructions further configures the one or more computer processors to perform operations including: placing the additional data in one or more files within one or more locations within memory; adding an additional unique address for the second asset to the directory entry associated with the first asset; as well as Data describing the location of the additional data is added to the entry associated with the first asset.

17. The non-transitory machine-readable medium of claim 16, wherein: Retrieving the asset data includes: determining a location of the additional data using the additional address and the directory; retrieving the additional data using the determined location; and returning the retrieved additional data to the executing application.

18. The non-transitory machine-readable medium of claim 14, wherein: Placing the assets includes creating an asset package for the executable version of the application, the asset package including a plurality of assets and associated asset data.

Images