U.S. Pat. No. 10,891,125

DETAILED DESCRIPTION OF EMBODIMENTS

Overview

Quickly delivering updates to an application, such as a game application, on a user's computing device can improve the user's experience. However, the required review process for updates to precompiled machine code increases the time and cost to deliver the update. One solution to quickly deliver updates and avoid the required review process is to use an interpreted scripting language, rather than precompiled machine code. The interpreted scripting language can be deployed directly to customers without prior review and approval by the application marketplace provider during runtime of the application. However, interpreted scripting language can be slower than precompiled machine code, which can limit the quantity of scripting language used in an application.

Embodiments of the disclosed technology utilize both precompiled machine code and interpreted script logic to facilitate rapid distribution of updates, while retaining the speed, quality, and content of the application. In order to accomplish this, a particular application can be distributed in phases. For example, when the application is first distributed, it is in precompiled machine code, which can ensure that the application runs as fast as possible. Subsequently, should bugs be found in the original precompiled machine code or should other updates to the original precompiled machine code be desired, the bug fixes or new features can be implemented using scripted logic. This scripted logic can be rapidly distributed to the user's computing device as a data update, and, during runtime of the application, the application can detect that the newer script-based version of a function is available and begin using it.

As described above, interpreted scripting language can be orders of magnitude slower than compiled code. As such, over time, and as a result of many scripted logic updates to the compiled code, the performance of the application may deteriorate. This reduction in performance can be referred to as an accumulation of “script performance debt.” In some cases, based on the amount of accumulated script performance debt, one or more scripts can be converted into compiled code. This compiled code can be submitted to the application marketplace provider for review and approval and can be delivered as a binary patch to the application. The binary patch can replace or be utilized instead of the previous script-based updates, which can recoup all of the script performance debt that was accumulated via the script-based updates.

Programming languages generally fall into one of two categories: Compiled or Interpreted. For purposes of this disclosure, a compiled language (sometimes referred to as binary code or precompiled machine code) is a programming language that is implemented by a compiler, which is a translator that generates machine code from source code. In contrast, for purposes of this disclosure, interpreted language is a programming language that is implemented by an interpreter, which is a step-by-step executor of source code, where no pre-runtime translation (e.g., compiling) takes place. An interpreted language (sometimes referred to as interpreted scripting language, scripting language, or scripts) includes non-binary code or non-compiled information objects, such as scripts, images (e.g., image information, texture information, and/or other information related to images), and/or other non-compiled information, that do not require the step of being compiled into machine-language instructions, but instead are interpreted. Example interpreted scripting languages include, but are not limited to, JavaScript, PHP, Python, VBScript. Compiled programs generally run faster than interpreted ones, at least because interpreted programs are generally reduced to machine instructions at runtime.

Overview of Video Game Environment

FIG. 1illustrates an embodiment of a computing environment100for implementing a videogame patch. The computing environment100includes a network108, a plurality of user computing systems102, an interactive computing system130, which includes application host systems132, an application marketplace server140, an update server150, and a developer system160. To simplify discussion and not to limit the present disclosure,FIG. 1illustrates only one user computing system102, one interactive computing system130, one application marketplace server140, one update server150, and one developer system160, though multiple devices or systems may be used.

Network

Any of the foregoing devices or systems of computing environment100may communicate via a network108. Although only one network108is illustrated, multiple distinct and/or distributed networks108may exist. The network108can include any type of communication network. For example, the network108can include one or more of a wide area network (WAN), a local area network (LAN), a cellular network, an ad hoc network, a satellite network, a wired network, a wireless network, and so forth. In some embodiments, the network108can include the Internet.

User Computing System

The user computing system102can be controlled by a user. The user computing system102may include hardware and software components for establishing communications over the network108. For example, the user computing system102may be equipped with networking equipment and network software applications (for example, a web browser) that facilitate communications via one or more networks (for example, the Internet or an intranet). The user computing system102may have varied local computing resources such as central processing units and architectures, memory, mass storage, graphics processing units, communication network availability and bandwidth, and so forth. Further, the user computing system102may include any type of computing system. For example, the user computing system102may include any type of computing device(s), such as desktops, laptops, video game platforms/consoles, television set-top boxes, televisions (for example, Internet TVs), network-enabled kiosks, car-console devices computerized appliances, wearable devices (for example, smart watches and glasses with computing functionality), and wireless mobile devices (for example, smart phones, PDAs, tablets, or the like), to name a few.

The user computing system102is capable of executing a game application110, such as a video game, which may be stored and/or executed locally and/or in a distributed environment. In certain embodiments, the user computing system102may execute another application instead of or in addition to executing a portion of the game application110, which may complement and/or interact with the game application110during execution of a gameplay session of the game application110. In a locally executed game applications, generally, the game application110does not rely or utilize an external computing system (for example, the interactive computing system130) to execute the game application110. In distributed game applications, the user computing system102may execute a portion of the game application110and another system, such as the interactive computing system130or an application host system132of the interactive computing system130, may execute another portion of the game application110. For instance, the game may be a massively multiplayer online role-playing game (MMORPG) that includes a client portion executed by the user computing system102and a server portion executed by one or more application host systems132. For the present discussion, the type of game application110can be a locally executable game, a distributed application, or an application that includes a portion that executes on the user computing system102and a portion that executes on at least one of the application host systems132.

The user computing system can include various input devices120that can be used to capture player input for use during execution of a game application110. The game application110can be configured to generate instructions to the computing resources104to output execution of the game application110on the display122. User input from input devices120and/or game data may be used to generate display video for display on the display122. Game data114can include game rules, prerecorded motion capture poses/paths, environmental settings, constraints (such as strength and velocity constraints), and skeleton models. A game engine112can receive the game data114and user inputs from the input devices120and can determine character events, such as actions, collisions, runs, throws, attacks and other events appropriate for the game. From the character events, appropriate motions or poses for the characters can be determined and rendered. Character images can be combined with animate, inanimate and background objects into a full scene. The full scene can be conveyed to a renderer, which can generate a new frame therefrom.

The game application110executed by the user computing system102may be created using a particular application programming interface (API) or compiled into a particular instruction set that may be specific to the user computing system102. In some embodiments, user computing system102may be a general purpose computing device capable of executing game application110and non-game applications.

A game application110can be configured to be executed on the user computing system102. The game application110may also be referred to as a videogame, a game, game code and/or a game program. A game application should be understood to include software code that a user computing system102can use to provide a game for a user to play. A game application110may comprise software code that informs user computing system102of processor instructions to execute, but may also include data used in the playing of the game, such as data relating to constants, images and other data structures. For example, in the illustrated embodiment, the game application includes a game engine112and game data114.

The game engine112can be configured to execute aspects of the operation of the game application110within the user computing system102. Execution of aspects of gameplay within a game application can be based, at least in part, on the user input received and the game data114. The game data114can include game rules, prerecorded motion capture poses/paths, environmental settings, constraints, skeleton models, and/or other game application information.

The game engine112can execute gameplay within the game according to the game rules. Examples of game rules can include rules for scoring, possible inputs, actions/events, movement in response to inputs, and the like. Other components can control what inputs are accepted and how the game progresses, and other aspects of gameplay. During execution of the game application110, the game application110can store game state information, which can include a game state, character states, environment states, scene object storage, and/or other information associated with a state of execution of the game application110. For example, the game state information can identify the state of the game application at a specific point in time, such as a character position, character action, game level attributes, and other information contributing to a state of the game application. The game state information can include dynamic state information that continually changes, such as character movement positions, and static state information, such as the identification of a game level within the game.

The game engine112can receive the user inputs and determine in-game events, such as actions, collisions, runs, throws, attacks and other events appropriate for the game application110. During operation, the game engine112can read in game data114and a game state information116to determine the appropriate in-game events. In one example, after the game engine112determines the character events, the character events can be conveyed to a movement engine that can determine the appropriate motions the characters should make in response to the events and passes those motions on to a physics engine. The physics engine can determine new poses for the characters and provide the new poses to a skinning and rendering engine. The skinning and rendering engine, in turn, can provide character images to an object combiner in order to combine animate, inanimate, and background objects into a full scene. The full scene can be conveyed to a renderer, which generates a new frame for display to the user. The process can repeated for rendering each frame during execution of the game application. Though the process has been described in the context of a character, the process can be applied to any process for processing events and rendering the output for display to a user.

The user computing system102, such as the game application110on the user computing system102, can communicate with an external server, such as the update server150or the interactive computing system130, to retrieve information associated with the game, such as game patches, game authentication, clouds saves, or other features.

In some cases, the user computing system102can be a developer system160. A developer system160can be utilized to manage, develop, and/or update the game application110. For example, the developer system160can have the same or different capabilities and/or applications as the user computing system102. In some cases, a developer of the developer system160can generate the game applications110and/or updates thereto. The game applications110and/or updates can be communicated to one or more systems, such as the interactive computing system130, the application marketplace server140, the update server, or the user computing system102.

Interactive Computing System (e.g., Online Game Servers)

The interactive computing system130can include one or more application host systems132. The interactive computing system130may include one or more computing systems configured to execute a portion of the game application110and/or host application. In some embodiments, the one or more application host systems132can include one or more computing devices, such as servers and databases that may host and/or execute a portion of one or more instances of the game application110and/or host application. In certain embodiments, instead of or in addition to executing a portion of the game application110and/or host application, the application host systems132may execute another application, which may complement and/or interact with the application104during execution of an instance of the application104.

The application host systems132can be configured to execute a portion of the game application110. In certain embodiments, the application host systems132may execute another application instead of or in addition to executing a portion of the game application110, which may complement and/or interact with the game application110during execution of a gameplay session of the game application110.

The interactive computing system130may enable multiple players or computing systems to access a portion of the game application110. In some embodiments, the portion of the game application110executed by application host systems132of the interactive computing system130may create a persistent virtual world. This persistent virtual world may enable one or more players to interact with the virtual world and with each other in a synchronous and/or asynchronous manner. For purposes of the present disclosure, the term “player” can refer to a game application that is being operated by a person during a gameplay session.

In some cases, multiple instances of the persistent virtual world may be created or hosted by the interactive computing system130. A set of players may be assigned to or may access one instance of the persistent virtual world while another set of players may be assigned to or may access another instance of the persistent virtual world. In some embodiments, the application host systems132may execute a hosting system for executing various aspects of a game environment. For example, in one embodiment, the game application110may be a competitive game, such as a first person shooter or sports game, and the host application system132can provide a dedicated hosting service for hosting multiplayer game instances or facilitate the creation of game instances hosted by user computing devices. In some embodiments, the host application system132can provide a lobby or other environment for users to virtually interact with one another. Such environments may include environments for conducting transactions between players, such as an auction house or type of environment for facilitating transactions.

In some embodiments, the interactive computing system130can be responsible for managing and/or distributing updates to the game application110. For example, as described herein, the developer system160can develop the game application110or updates thereto. The interactive computing system130can be in communications with the developer system160so as to receive updates to the game application110. The interactive computing system130can be in communications with the user computing system102and can communicate the update to the user computing system102. For example, the interactive computing system130can transmit the update to the user computing system102or can provide a server from which the game application110and/or updates thereto can be downloaded by the user computing system102.

Application Marketplace Server

The application marketplace server140can provide an application marketplace from which the game application110and/or updates thereto can be communicated to or downloaded by the user computing system102. In some implementations, the application marketplace server140is controlled by a third party that does not create or develop the game application110or the updates. For example, the application marketplace server140can receive the game application110or updates from a developer system160or an update server150. A provider of the application marketplace server140or the application marketplace reviews or approves of the game application110or updates before they are available for download through the application marketplace server140. The game application110and/or updates that are available through the application marketplace server140typically include precompiled machine code.

An update from the application marketplace server140can include compiled code with changes from a previous version of the game application110. Obtaining the updated version of the game application110may include downloading the updated version from application marketplace server140. Obtaining the updated version of the game application110may include receiving a network address of another server, such as the interactive computing system130, from the application marketplace server140, and then requesting the updated version from this server.

The application marketplace of the application marketplace server140may exert some limitations and/or control over the release of updated versions of the game application110. For example, a developer of the game application110or the updates to the game application110may be required to submit the game application110or update thereto to the application marketplace server140for review. Once game application110or update thereto is approved, it may be made available to users for download through the application marketplace server140.

Due to this control, developers may experience inconveniences, inefficiencies, and/or other drawbacks associated with seeking and obtaining approval for game application110or update thereto from the provider of the application marketplace server140.

The ability of user computing system102, developer system160, or interactive computing system130to update game assets including, for example, interpreted scripting language and/or other assets separate from the compiled code of game application110may enable a functional update of the game application110that does not require communication through application marketplace server140. This may enhance one or more aspects of the updating process. The updating of game assets via interpreted scripting language that are different from compiled code may enable the developer system160, or a developer associated with the developer system160, to update the game application110piecemeal, and without requiring users to proactively update the game application110through the application marketplace server150.

The game application110can be configured to automatically update individual assets (or sets of assets) on the installed application with little or no user interaction or interaction with the application marketplace.

Update Server

The update server150can be configured to communicate with the user computing system102such that the user computing system102can obtain updates to the game application110. For example, the update server150can transmit the updates to the user computing system102via data packets. As another example, the user computing system102can download the updates from the update server150. In some implementations, the update server150does not create or develop the game application110or the updates. For example, the update server150can receive the game application110or updates from a developer system160, the interactive computing system130, the application marketplace server140, or the like A provider of the application marketplace server140or the application marketplace reviews or approves of the game application110or updates before they are available for download through the application marketplace server140. The game application110and/or updates that are available through the application marketplace server140typically include precompiled machine code. In some implementations, the update server150can be incorporated and/or integrated into the interactive computing system130and/or the developer system160.

Function Store

The game application110can include a function store, such as an electronic database, table, or array, which stores function assets that can be used to execute game functions of the game application. In some cases, a function asset that includes compiled code can be referred to as a code function asset, and a function asset that includes interpreted scripting language, can be referred to as a script function asset. The function store can be separate from application code that is used to execute the game application110. For example, the function store can include various function assets and, rather than including the function assets itself, the application code can query the function store for a function asset to use in order to execute to a game function.

FIG. 2illustrates a visual representation of a function store202, in accordance with example embodiments. In this example, the function store202includes a table that has three columns: game function identifier204, version identifier206, and function asset identifier208. In addition, the table has rows212,214,216, and218that are related to function assets. For example, row216indicates that function asset226is associated with version identifier224and game function identifier222.

A game function identifier can be utilized to identify the game function to which a particular function asset corresponds. For example, as illustrated by the function store202inFIG. 2, the first function asset242corresponds to a first game function identifier222(“0x01”), the second function asset244corresponds to a second game function identifier224(“0x02”), the third function asset246corresponds to a third game function identifier226(“0x03”), and the fourth function asset248corresponds to the first game function identifier228(“0x01”). Notably, the first function asset242and the fourth function asset248both correspond to the first game function.

A version identifier can be utilized to identify the version of a particular function asset. For example, as illustrated, although the first function asset242and the fourth function asset248correspond to the first game function, they two function assets242,248are distinguishable from each other at least by their version identifiers232,238. For example, the function store202can be queried for the function asset corresponding to game function identifier “0x01”. In this example, game function identifier222and game function identifier228matches “0x03”. Based at least in part on the game function identifiers222and228matching the queried game function identifier (e.g., “0x01”), the function store202can identify one or more of function assets242or248. In some cases, for example if more than one function asset corresponds to a queried game function, the function store202can use the version identifiers to select the function asset to return. In this example, the first function asset242has a version identifier of “1,” while the fourth function asset248has a version identifier of “2.” In some cases, based at least in part on the version identifier238(i.e., “2”) corresponding to a later or more recent version than the version identifier232(i.e., “1”), the function store202can return the function asset248. In some cases, a game function identifier can include a set of numbers, letters, alphanumeric characters, or other identifier that associates the particular game function with a function asset. In some cases, a function asset can include a function that can be executed. In some cases, a function asset can include the memory address of a function that can be executed. For example, the function asset can be a pointer that references another location in memory.

Binary Release

FIG. 3is a data flow diagram illustrative of an embodiment of distributing a function of a video game to a user computing device. AlthoughFIG. 3illustrates the distribution of a single function of a video game, it will be understood that other functions of the video game, as well as application code of the video game, can be prepared and distributed using a similar process. Furthermore, althoughFIG. 3only shows interactions between the developer system160, the marketplace server150, and the user computing system102, it will be understood that fewer, more, or different devices or systems can be utilized as desired and/or be configured differently. For example, the communications can occur directly or via the network108. As another example, in some cases, the developer system160can communicate with the user computing system102or the update server150, rather than communicating with the application marketplace server140. Furthermore, it will be understood that the various steps described herein with reference toFIG. 3can be implemented in a variety of orders. For example, some steps can be implemented concurrently or the order changed as desired. Furthermore, it will be understood that fewer, more, or different steps can be used.

In this example, a game application110(e.g., a video game) that is written in an interpreted scripting language (script320) is completed and is ready for distribution. Although in this example, at step302, the developer system160converts the script320into binary code330and compiles it. In this example, the script320is associated with a first game function (specifically, game function “0x01”), which is denoted by the game function identifier334. Furthermore, the script320is associated with a version identifier332. Because this example represents the initial distribution of the game application110, the version identifier332corresponds to the first or original version of the first game function.

At step304, the developer system160wraps the binary code330as a code function asset340. At step306, the developer system160communicates the code function asset340to the application marketplace server140. As described herein, providers of the marketplace server140review the code function asset340. Once the update is approved, at step308, the code function asset340is compiled to form a compiled function asset342(sometimes referred to as a code function asset), and the compiled function asset342is made available for download from the application marketplace server140.

At step310, the user computing system102receives or downloads the compiled function asset342from the application marketplace server140. In some cases, in addition to the compiled function asset342, the user computing system102may also receive or download the application code350and/or one or more other function assets from the application marketplace server140.

Also at step310, the user computing system102stores the compiled function asset342in the function store202. As shown inFIG. 3, the game function identifier334and the version identifier332remain associated with the compiled function asset342when it is stored in the function store202.

At step312, the user computing system102executes the game application110using application code350to provide a game for a user to play. As described herein, the game application110may be stored and/or executed locally on the user computing system102and/or in a distributed environment.

At step314, the user computing system102executes the first game function within the game application110. In some cases, executing the first game function can itself include multiple steps, such as steps314aor314b. For example, to execute the first game function, at step314a, the application code queries the function store202for a function asset that is associated with the first game function, i.e., game function “0x01”. To identify which function asset to return to the application code, the function store202identifies the one or more function assets that correspond to game function “0x01”. To do this, the function store202identifies the one or more function assets that have a game function identifier corresponding to game function “0x01”. In this example, the compiled function asset342is the only function asset in the function store202that has a game function identifier334that corresponds to game function “0x01”. In some cases, based on a determination that only one function asset is available that corresponds to the requested game function, the function store202can return that function asset to the application code350. Alternatively, in some cases, to identify which function asset to return, the function store202can additionally or alternatively review or check the version identifier332of the compiled function asset342to ensure the selected function asset is the latest, or most recent, version. Thus, based at least in part on the game function identifier334corresponding to the first game function and/or the version identifier332being associated with latest or most recent version, at step314b, the function store202returns the compiled function asset342to the application code350, which the application code350uses to execute the first game function.

It will be understood that the various steps described herein with respect toFIG. 3can be implemented in a variety of orders, and that one or more of the steps ofFIG. 3can be implemented concurrently and/or the order changed, as desired. Furthermore, it will be understood that fewer, more, or different steps can be used as part of the routine ofFIG. 3. For example, in some cases, certain steps can be omitted, such as, but not limited to, steps302,304,306,308,310,312,314a, or314b. For example, in some embodiments, the developer system160can communicate with the user computing system102rather than the application marketplace server140.

Data Patch

FIG. 4is a data flow diagram illustrative of an embodiment of distributing a data update of video game to a user computing device. AlthoughFIG. 4illustrates the distribution of a single function of a video game, it will be understood that other functions of the video game, as well as application code of the video game, can be prepare and distributed using a similar process. Furthermore, althoughFIG. 4only shows interactions between the developer system160, the update server150, and the user computing system102, it will be understood that fewer, more, or different devices or systems can be utilized as desired and/or be configured differently. For example, the communications can occur directly or via the network108. As another example, in some cases, the developer system160or the interactive computing system130can communicate with the user computing system102, rather than communicating to the update server150which communicates to the user computing system102. Furthermore, it will be understood that the various steps described herein with reference toFIG. 4can be implemented in a variety of orders. For example, some steps can be implemented concurrently or the order changed as desired. Furthermore, it will be understood that fewer, more, or different steps can be used.

Continuing from the example ofFIG. 3, in this example, a binary release of a game application110has previously occurred, and one or more updates or changes to a function asset associated with the first game function are completed and ready for distribution. At step402, in contrast to step302ofFIG. 3, the developer system160does not convert the script420into binary code and compile it. Rather, the developer system160wraps the script420as a script function asset440. In this example, similar to the script320ofFIG. 3, the script420is configured to perform the first game function, which is denoted by the game function identifier434. However, because the script function asset440is different from the code function asset340, it is associated with a different version identifier432. In this case, because the script420was developed after the script320ofFIG. 3, it is associated with a new version, in this case version 2.

Notably, the script function asset440can be incorporated into the video game without requiring the video game to be recompiled. Furthermore, because the script420was not converted into compiled code, the provider of the application marketplace server140does not require that the script function asset440be reviewed and/or approved by the provider of the application marketplace server140prior to it being distributed to a user computing device102. Rather, the script function asset440can be distributed, for example via the update server150, to the user computing device102as a data update that can be used to update one or more functions of the game during runtime of the game application110. By avoiding the review and approval process, the update (e.g., the script function asset440) can be delivered quickly and efficiently to the user computing device102. Furthermore, in some cases, the interpreted scripting language can be written in the same scripting language that the compiled code of the game application was written in prior to compiling the code. This can advantageously increase a developer's ability to develop updates to the game application110.

At step404, the developer system160communicates the script function asset440to the update server150, and at step406the update server150makes the script function asset440available to the user computing system102. For example, the user computing system102receives and/or downloads the script function asset440from the update server150and stores the script function asset440in the function store202. For example, the user computing system102can update the function store202to include the script function asset440. In some implementations, the update to the function store202occurs without recompiling and/or restarting the game application. In some implementations, the update server150can perform at least some processing on the script function asset440before it is provided to the user computing system102. In some cases, the developer system160can provide the script function asset440directly to the user computing system102. As shown inFIG. 4, the game function identifier434and the version identifier432remain associated with the script function asset440when it is stored in the function store202. Furthermore, as illustrated, the previously stored code function assets340can remain in the function store202, despite the game function identifier334of the code function asset340being the same as the game function identifier434of the script function asset440.

At step408, similar to step312ofFIG. 3, the user computing system102executes a game application110using application code350to provide a game for a user to play.

At step410, similar to step314ofFIG. 4, the user computing system102executes the first game function within the game application110. In some cases, step410can include steps, such as steps410aor410b. For example, at step410a, the user computing system102can query the function store202and, at step410b, the function store202can return the script function asset440based on the query. The user computing system102can execute the first game function using the script function asset440.

At step410a, the function store202receives the query from the application code350for the function asset that is associated with the first game function i.e., game function “0x01”. To identify which function asset to return to the application code, the function store202identifies the one or more function assets that correspond to game function “0x01”. To do this, the function store202identifies the one or more function assets that have a game function identifier corresponding to game function “0x01”. In this example, as indicated by the game function identifiers334and434, the function store202includes two code function assets340and440that each correspond to the first game function (i.e., game function “0x01”). For example, as indicated above, the code function asset340may correspond to an original, binary version of a function asset associated with the first game function, while the script function asset440may correspond to an updated, script version of the function asset associated with the first game function.

To identify which function asset to return to the application code350, the function store202reviews or checks the version identifiers332,432of each of the stored function assets340,440. In this case, the script function asset440corresponds to a later or more recent version than the code function asset340. Thus, based at least in part on the game function identifier434corresponding to the first game function and/or the version identifier432being associated with a later or more recent version than the version identifier332, at step410b, the function store202returns the script function asset440to the application code350, which the application code350uses to execute the first game function.

It will be understood that the various steps described herein with respect toFIG. 4can be implemented in a variety of orders, and that one or more of the steps ofFIG. 4can be implemented concurrently and/or the order changed, as desired. Furthermore, it will be understood that fewer, more, or different steps can be used as part of the routine ofFIG. 4. For example, in some cases, certain steps can be omitted, such as, but not limited to, steps402,404,406,408,410a, or410b. For example, in some embodiments, the developer system160can communicate with the user computing system102rather than the application marketplace server140.

Furthermore, it will be understood that the various steps described herein with reference toFIG. 3can be implemented in the routine ofFIG. 4, in a variety of orders. For example, some or all of various steps ofFIG. 3can be implemented concurrently with any one or more of the steps ofFIG. 5or change the order as desired.

Binary Patch

FIG. 5is a data flow diagram illustrative of an embodiment of distributing a binary patch of a video game to a user computing device. AlthoughFIG. 5illustrates the distribution of a single function of a video game, it will be understood that other functions of the video game, as well as application code of the video game, can be prepare and distributed using a similar process. Furthermore, althoughFIG. 5only shows interactions between the developer system160, the application marketplace server140, and the user computing system102, it will be understood that fewer, more, or different devices or systems can be utilized as desired and/or be configured differently. For example, the communications can occur directly or via the network108. As another example, in some cases, the developer system160can communicate with the update server150instead, or in addition or, the application marketplace server140. Furthermore, it will be understood that the various steps described herein with reference toFIG. 5can be implemented in a variety of orders. For example, some steps can be implemented concurrently or the order changed as desired. Furthermore, it will be understood that fewer, more, or different steps can be used.

In general, an interpreted scripting language can be orders of magnitude slower than compiled code. As such, over time, and as a result of many data updates to the game application110, the performance of the game application110can be reduced. This reduction in performance can be referred to as an accumulation of “script performance debt.” Over time the game application100can accumulate “script performance debt” through shipping a large number of data updates. In this example, one or more data updates may have been previously provided to the user computing device102, and the developer has developed a script for conversion into a binary patch. In some cases, the binary patch can replace or be utilized instead of the previous data updates, which can recoup some or all of the script performance debt that was accumulated via the data updates.

At steps502and504, similar to steps302and304ofFIG. 3, the developer system160coverts the script520into binary code530, compiles it, and wraps the binary code530as a code function asset540. In this example, the game function identifier534corresponds to the game function identifiers334and434ofFIGS. 3 and 4, respectively. However, the version identifier532has been updated to a newer version, version 3.

At step506, similar to step306ofFIG. 3, the developer system160communicates the code function asset540to the application marketplace server150. As described herein, providers of the marketplace server140review the code function asset540. Once the update is approved, at step508, the code function asset540is compiled to form a compiled function asset542(sometimes referred to as a code function asset), and the compiled function asset542is made available for download from the application marketplace server140.

At step510, similar to step310ofFIG. 3, the user computing system102receives and/or downloads the compiled function asset542from the application marketplace server150and stores the compiled function asset542in the function store202. As illustrated, the previously stored script function asset440fromFIG. 4can remain in the function store202. Similarly, in some cases, the previously stored compiled function asset342fromFIG. 3can remain in the function store202. Alternatively, in some implementations, the binary patch removes the script function asset440and/or the compiled function asset342from the function store202.

At step512, similar to step312ofFIG. 3, the user computing system102executes a game application110using application code350to provide a game for a user to play.

At step514, the user computing system102executes a first game function within the game application110. In some cases, step514can include steps, such as steps514aor514b. For example, to execute the first game function, at step514a, the application code queries the function store202for the function asset that is associated with the first game function. In this case, the first game function is game function “0x01”. Thus, to identify which function asset to return to the application code, the function store202identifies the one or more function assets that correspond to game function “0x01”. To do this, the function store202identify the one or more function assets that have a game function identifier corresponding to game function “0x01”. In this example, both the compiled function asset542and the script function asset440include a game function identifier534,434that correspond to game function “0x01”.

To identify which function asset to return to the application code350, the function store202can review or check the version identifiers532,432of both the compiled function asset542and the script function asset440. In this case, as indicated be the higher version identifier, the compiled function asset542corresponds to a later, or more recent, binary patch associated with the first game function, while the script function asset440corresponds to an earlier, or less recent, data patch associated with the first game function. Thus, based at least in part on the game function identifier534corresponding to the first game function and/or the version identifier532being associated with a later or more recent version than the version identifier432, at step514b, the function store202returns the compiled function asset542to the application code350, which the application code uses to execute the first application.

It will be understood that the various steps described herein with respect toFIG. 5can be implemented in a variety of orders, and that one or more of the steps ofFIG. 5can be implemented concurrently and/or the order changed, as desired. Furthermore, it will be understood that fewer, more, or different steps can be used as part of the routine ofFIG. 5. For example, in some cases, certain steps can be omitted, such as, but not limited to, steps502,504,506,508, or510. For example, in some embodiments, the developer system160can communicate with the user computing system102rather than the application marketplace server140.

Furthermore, it will be understood that the various steps described herein with reference toFIGS. 3 and/or 4can be implemented in the routine ofFIG. 5, in a variety of orders. For example, some or all of various steps ofFIGS. 3 and/or 4can be implemented concurrently with any one or more of the steps ofFIG. 5or change the order as desired.

Process for Updating

FIG. 6illustrates an embodiment of a flowchart of a process for distributing a video game and updates thereto. The process600can be implemented by any system or combination of systems. For example, the process600, in whole or in part, can be implemented by one or more devices or systems of the computing environment100ofFIG. 1, such as a user computing systems102, an interactive computing system130, an application marketplace server140, an update server150, or a developer system160. Although any number of systems, in whole or in part, can implement the process600to simplify discussion, the process600will be described with respect to particular systems. Further, although embodiments of the process600may be performed with respect to variations of systems comprising various game application environments, to simplify discussion, the process600will be described with respect to the computing environment100ofFIG. 1. Furthermore, it will be understood that the various blocks described herein with reference toFIG. 3can be implemented in a variety of orders. For example, computing device100can implement some blocks concurrently or change the order as desired. Furthermore, it will be understood that fewer, more, or different blocks can be used. For example, in some embodiments, the solid blocks are part of routine600and the dotted blocks are not implemented. However, it will be understood that any of the blocks (and more or different blocks) can be implemented as part of routine600.

At block602, similar to steps312,408, and512ofFIGS. 3, 4, and 5, respectively, the user computing system102executes a game application110to provide a game for a user to play. For example, the game application110may be downloaded from the application marketplace server140via the network108.

The user computing system102can execute the game application110using application code. The application code can include compiled software code that the user computing system102uses to provide the game for the user to play. The compiled software code can inform the user computing system102of processor instructions to execute and can include data used in the playing of the game, such as data relating to constants, images and other data structures. In some cases, the game application110includes a function store, such as function store202, which stores a plurality of function assets that correspond to game functions.

At block604, in some cases, user computing system102identifies a first function asset from the plurality of function assets stored in the function store. To identify which function asset to return to the application code, the function store202identifies the one or more function assets that correspond to a first game function. For example, as described herein, each of the plurality of function assets stored in the function store can have an associated game function identifier and/or version identifier. Based at least in part on a game function identifier and/or a version identifier associated with the first function asset, the user computing system102identifies the first function asset.

At block606, in some cases, the user computing system110executes the first game function using the first function asset.

At block608, similar to step406ofFIG. 4, during runtime of the game application, the user computing system102receives a second function asset via the network. The second function asset can be in the form of a data packet that the user computing system102receives and/or downloads from an update server1150.

At block610, similar to step406ofFIG. 4, the user computing system102stores the second function asset in the function store. As described herein, the second function asset can include an associated game function identifier and/or the version identifier432.

At block612, similar to step410aofFIG. 4, the user computing system102can identify the second function asset from the plurality of function assets stored in the function store. To determine which function asset to identify, the user computing system102identifies the one or more function assets that correspond to first game function. In this example, each of the first function asset and the second function asset as associated with the first game function. To determine which function asset to identify, the user computing system102reviews or checks the version identifiers of each of the first function asset and the second function asset. Based at least in part on the second version identifier associated with the second function asset, the user computing system102identifies the second function asset.

At block606, the user computing system110executes the first game function using the second function asset, rather than the first function asset.

It will be understood that the various blocks described herein can be implemented in a variety of orders, and that the computing device100can implement one or more of the blocks concurrently and/or change the order, as desired. For example, the computing device100can concurrently identify the first function asset and identify the second function asset. Similarly, the computing device100can concurrently execute the game application and the first game function. Further still, in some cases, the computing device100can receive the second function asset prior to, or concurrently with, the execution of the game application or the first game function.

Furthermore, it will be understood that fewer, more, or different blocks can be used as part of the routine600. For example, in some cases, the routine600can omit certain blocks, such as, but not limited to, blocks602,604,606,608, and/or610. For example, in some embodiments, the computing device100may not identify the first function asset or execute the first function asset.

In addition, it will be understood that the various steps described herein with reference toFIGS. 3, 4, and/or5can be implemented in routine600, in a variety of orders. For example, the computing device100can implement some or all of various steps ofFIGS. 3, 4, and/or5in routine600concurrently with any one or more of the blocks of routine600or change the order as desired.

Overview of Computing Device

FIG. 7illustrates an embodiment of computing device10according to the present disclosure. Other variations of the computing device10may be substituted for the examples explicitly presented herein, such as removing or adding components to the computing device10. The computing device10may include a game device, a smart phone, a tablet, a personal computer, a laptop, a smart television, a car console display, a server, and the like. As shown, the computing device10includes a processing unit20that interacts with other components of the computing device10and also external components to computing device10. A media reader22is included that communicates with media12. The media reader22may be an optical disc reader capable of reading optical discs, such as CD-ROM or DVDs, or any other type of reader that can receive and read data from game media12. One or more of the computing devices may be used to implement one or more of the systems disclosed herein.

Computing device10may include a separate graphics processor24. In some cases, the graphics processor24may be built into the processing unit20. In some such cases, the graphics processor24may share Random Access Memory (RAM) with the processing unit20. Alternatively, or in addition, the computing device10may include a discrete graphics processor24that is separate from the processing unit20. In some such cases, the graphics processor24may have separate RAM from the processing unit20. Computing device10might be a handheld video game device, a dedicated game console computing system, a general-purpose laptop or desktop computer, a smart phone, a tablet, a car console, or other suitable system.

Computing device10also includes various components for enabling input/output, such as an I/O32, a user I/O34, a display I/O36, and a network I/O38. I/O32interacts with storage element40and, through a device42, removable storage media44in order to provide storage for computing device10. Processing unit20can communicate through I/O32to store data, such as game state data and any shared data files. In addition to storage40and removable storage media44, computing device10is also shown including ROM (Read-Only Memory)46and RAM48. RAM48may be used for data that is accessed frequently, such as when a game is being played or the fraud detection is performed.

User I/O34is used to send and receive commands between processing unit20and user devices, such as game controllers. In some embodiments, the user I/O can include a touchscreen inputs. The touchscreen can be capacitive touchscreen, a resistive touchscreen, or other type of touchscreen technology that is configured to receive user input through tactile inputs from the user. Display I/O36provides input/output functions that are used to display images from the game being played. Network I/O38is used for input/output functions for a network. Network I/O38may be used during execution of a game, such as when a game is being played online or being accessed online and/or application of fraud detection, and/or generation of a fraud detection model.

Display output signals produced by display I/O36comprising signals for displaying visual content produced by computing device10on a display device, such as graphics, user interfaces, video, and/or other visual content. Computing device10may comprise one or more integrated displays configured to receive display output signals produced by display I/O36. According to some embodiments, display output signals produced by display I/O36may also be output to one or more display devices external to computing device10, such a display16.

The computing device10can also include other features that may be used with a game, such as a clock50, flash memory52, and other components. An audio/video player56might also be used to play a video sequence, such as a movie. It should be understood that other components may be provided in computing device10and that a person skilled in the art will appreciate other variations of computing device10.

Program code can be stored in ROM46, RAM48or storage40(which might comprise hard disk, other magnetic storage, optical storage, other non-volatile storage or a combination or variation of these). Part of the program code can be stored in ROM that is programmable (ROM, PROM, EPROM, EEPROM, and so forth), part of the program code can be stored in storage40, and/or on removable media such as game media12(which can be a CD-ROM, cartridge, memory chip or the like, or obtained over a network or other electronic channel as needed). In general, program code can be found embodied in a tangible non-transitory signal-bearing medium.

Random access memory (RAM)48(and possibly other storage) is usable to store variables and other game and processor data as needed. RAM is used and holds data that is generated during the execution of an application and portions thereof might also be reserved for frame buffers, application state information, and/or other data needed or usable for interpreting user input and generating display outputs. Generally, RAM48is volatile storage and data stored within RAM48may be lost when the computing device10is turned off or loses power.

As computing device10reads media12and provides an application, information may be read from game media12and stored in a memory device, such as RAM48. Additionally, data from storage40, ROM46, servers accessed via a network (not shown), or removable storage media46may be read and loaded into RAM48. Although data is described as being found in RAM48, it will be understood that data does not have to be stored in RAM48and may be stored in other memory accessible to processing unit20or distributed among several media, such as media12and storage40.

It is to be understood that not necessarily all objects or advantages may be achieved in accordance with any particular embodiment described herein. Thus, for example, those skilled in the art will recognize that certain embodiments may be configured to operate in a manner that achieves or optimizes one advantage or group of advantages as taught herein without necessarily achieving other objects or advantages as may be taught or suggested herein.

All of the processes described herein may be embodied in, and fully automated via, software code modules executed by a computing system that includes one or more computers or processors. The code modules may be stored in any type of non-transitory computer-readable medium or other computer storage device. Some or all the methods may be embodied in specialized computer hardware.

Many other variations than those described herein will be apparent from this disclosure. For example, depending on the embodiment, certain acts, events, or functions of any of the algorithms described herein can be performed in a different sequence, can be added, merged, or left out altogether (for example, not all described acts or events are necessary for the practice of the algorithms). Moreover, in certain embodiments, acts or events can be performed concurrently, for example, through multi-threaded processing, interrupt processing, or multiple processors or processor cores or on other parallel architectures, rather than sequentially. In addition, different tasks or processes can be performed by different machines and/or computing systems that can function together.

The various illustrative logical blocks and modules described in connection with the embodiments disclosed herein can be implemented or performed by a machine, such as a processing unit or processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A processor can be a microprocessor, but in the alternative, the processor can be a controller, microcontroller, or state machine, combinations of the same, or the like. A processor can include electrical circuitry configured to process computer-executable instructions. In another embodiment, a processor includes an FPGA or other programmable device that performs logic operations without processing computer-executable instructions. A processor can also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Although described herein primarily with respect to digital technology, a processor may also include primarily analog components. For example, some or all of the signal processing algorithms described herein may be implemented in analog circuitry or mixed analog and digital circuitry. A computing environment can include any type of computer system, including, but not limited to, a computer system based on a microprocessor, a mainframe computer, a digital signal processor, a portable computing device, a device controller, or a computational engine within an appliance, to name a few.

Conditional language such as, among others, “can,” “could,” “might” or “may,” unless specifically stated otherwise, are otherwise understood within the context as used in general to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or steps. Thus, such conditional language is not generally intended to imply that features, elements and/or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without user input or prompting, whether these features, elements and/or steps are included or are to be performed in any particular embodiment.

Disjunctive language such as the phrase “at least one of X, Y, or Z,” unless specifically stated otherwise, is otherwise understood with the context as used in general to present that an item, term, etc., may be either X, Y, or Z, or any combination thereof (for example, X, Y, and/or Z). Thus, such disjunctive language is not generally intended to, and should not, imply that certain embodiments require at least one of X, at least one of Y, or at least one of Z to each be present.

Any process descriptions, elements or blocks in the flow diagrams described herein and/or depicted in the attached figures should be understood as potentially representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or elements in the process. Alternate implementations are included within the scope of the embodiments described herein in which elements or functions may be deleted, executed out of order from that shown, or discussed, including substantially concurrently or in reverse order, depending on the functionality involved as would be understood by those skilled in the art.

Unless otherwise explicitly stated, articles such as “a” or “an” should generally be interpreted to include one or more described items. Accordingly, phrases such as “a device configured to” are intended to include one or more recited devices. Such one or more recited devices can also be collectively configured to carry out the stated recitations. For example, “a processor configured to carry out recitations A, B and C” can include a first processor configured to carry out recitation A working in conjunction with a second processor configured to carry out recitations B and C.

It should be emphasized that many variations and modifications may be made to the above-described embodiments, the elements of which are to be understood as being among other acceptable examples. All such modifications and variations are intended to be included herein within the scope of this disclosure.