Tracking file system read operations for instant play of video games and for discarding and pre-fetching game data on the client side

Abstract

The client machine may utilize a file system proxy component that tracks read operations performed by a game executable file during a game session, generates access data based on the tracked read operations, and reports the access data to a remote system. This approach enables the remote system to collect access data reported by multiple client machines, catalog the access data according to client system configuration, and analyze the access data to generate data usable by the client machine to implement various features such as "instant play" of a video game, discarding unused blocks of game data to free up local memory resources, and / or local pre-fetching of game data to reduce latency during game play.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application is a PCT application claiming priority to U.S. Patent Application No. 16 / 821,716, entitled "TRACKING FILE SYSTEM READ OPERATIONS FOR INSTANT PLAY OF VIDEO GAMES," filed March 17, 2020, the entire contents of which are incorporated herein by reference. [Background technology]

[0002] A service for distributing personal computer (PC) video games may utilize a network-accessible computing platform to distribute digital copies of the video games to a PC. For example, a user may purchase a video game that is made available through a distribution service, which may then be downloaded to the user's PC from a remote computing system over the Internet. Many of today's video games are relatively large, and as a result, it may take a significant amount of time to download the video game, and once downloaded to a user's PC, the video game may use a significant amount of disk storage on the PC to store all of its game data. For example, a video game may contain over 100 gigabytes (GB) of game data, which may take several hours to download using existing technology, depending on the download speed of the user's network connection. Unless the video game developer has written the game code in such a way that the video game can be played with some, but not all, of the game data downloaded to the PC, the user must wait to play the game until the game download is complete. Furthermore, because most games are so large, users often choose to store the game on a hard disk drive (HDD), which provides the most storage space for the PC. However, despite the current availability of large capacity HDDs, local storage capacity remains limited, and HDDs offer relatively slow read access speeds, which can result in latency when the PC loads game data from the HDD during a game session.

[0003] Provided herein are technical solutions for improving and enhancing these and other systems. [Brief description of the drawings]

[0004] The detailed description is set forth with reference to the accompanying drawings, in which the leftmost digit(s) of a reference number identifies the figure in which the reference number first appears, and the use of the same reference number in different drawings indicates similar or identical components or features.

[0005] [Figure 1] A diagram illustrating an example environment including a video game distribution platform configured to implement the techniques described herein. [Diagram 2] A block diagram illustrating exemplary components of a client machine for tracking file system read operations to generate access data and for transmitting the access data to a remote system and an exemplary process flow diagram are shown. [Diagram 3] A block diagram and an example process flow diagram illustrating example components of a remote system for implementing the techniques described herein for accepting access data from client machines and for analyzing the access data across one or more users are shown. [Figure 4] FIG. 13 is a flow diagram of an example process for generating download sequence data for use by client machines to download blocks of game data in a particular sequence of blocks based on access data received from a plurality of client machines. [Diagram 5] FIG. 1 is a flow diagram of an example process for generating block dependency data for use by client machines based on access data received from multiple client machines to pre-fetch blocks of game data to reduce latency during game play. [Figure 6] FIG. 11 is a flow diagram of an example process for determining unused blocks of game data based on access data received from a client machine and for instructing the client machine to discard the unused blocks of game data. [Figure 7]FIG. 11 is a flow diagram of an exemplary process for discarding unused blocks of game data from non-volatile memory of a client machine. [Figure 8] 1 is a flow diagram of an exemplary process for running a video game on a client machine before the game has completed download. [Figure 9] FIG. 1 is a flow diagram of an example process for pre-fetching blocks of game data to reduce latency during game play. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0006] A video game distribution platform may enable users to obtain video games, download digital copies of the video games to their respective client machines, and execute the video games using the installed client applications. As users play video games on their client machines, the game executable file of the video game running on each client machine may continuously request to read blocks of game data of the video game using the client machine's file system. As used herein, "game executable file" means the executable code (e.g., one or more executable files) of the video game that, when executed, enables the user to play the video game on the client machine by rendering frames based on user input provided via the client machine's input device. As used herein, "game data" means data that is read by the game executable file of the video game during execution of the game executable file through a series of frames. The game data may be used, among other things, to render the graphics of the video game, to calculate gameplay logic, and / or to calculate the physical properties of the video game. Examples of game data include, but are not limited to, textures, virtual objects, maps, game characters, parameters and other characteristics of the virtual objects, and / or virtual game worlds, etc. Such game data may be stored in memory by dividing the game data into blocks (e.g., uniformly sized blocks), and the client machine's file system is configured to control how these blocks of game data are stored in and retrieved from the client machine's local memory. When a video game is played on a client machine, each request to read a block of game data made by the game executable file of a video game is referred to herein as a "read operation."Thus, the game executable file of a video game may perform a series of read operations against the file system throughout a game session.

[0007] Techniques, devices, and systems described herein relate to tracking read operations performed by a game executable file of a video game during a game session using a file system proxy component of a client machine, generating access data based on the tracked read operations, and reporting the access data to a remote system. An exemplary process implemented by a client machine may include executing a game executable file of a video game for playing the video game on the client machine, determining read operations performed by the game executable file on a file system of the client machine, generating access data based at least in part on the read operations, and transmitting the access data, an identifier of the video game, and a configuration of the client machine to the remote system. The read operations performed by the game executable file may request reading a block of game data of the video game. Thus, the access data generated by the client machine may specify (i) an identifier of a block of game data accessed during the game session, and (ii) a time during the execution of the game executable file at which the block of game data was accessed based at least in part on the read operations.

[0008] This telemetry approach enables a remote system to collect access data reported by multiple client machines, catalog the access data according to client system configuration, and analyze the access data to generate data usable by the client machines to implement various game-related features, including, but not limited to, "instant play" of a video game, discarding unused blocks of game data to free up local memory resources, and / or local pre-fetching of game data to reduce latency during game play. An exemplary process implemented by the remote system may include receiving access data associated with a video game from multiple client machines having a common client system configuration, analyzing the access data, generating data based at least in part on analyzing the access data, and transmitting the data to one or more client machines having the client system configuration. The access data received by the remote system may specify, for each client machine, (i) identifiers of blocks of game data of the video game that were accessed by the game executable file of the video game during execution of the game executable file on the each client machine, and (ii) times during execution of the game executable file that the blocks of game data were accessed by the game executable file. Further, the data generated by the remote system based at least in part on analyzing the access data may include at least one of (i) download sequence data specifying the sequence in which at least some of the blocks of game data are downloaded to a client machine having a client system configuration, or (ii) block dependency data specifying individual associations between two or more blocks of game data.

[0009] As mentioned, one exemplary game-related feature that can be enabled is an "instant play" feature. The instant play feature described herein can allow a user who acquires a video game to begin playing the video game responsive to acquiring the video game and before the download of the game data to the user's client machine is complete. Thus, the user does not have to wait until the download of the video game is complete before beginning a game session of the video game. To enable the instant play feature, a remote system may receive access data (as described herein) from a plurality of client machines for a particular video game, and the remote system may generate download sequence data that specifies a sequence of blocks of game data of the video game based on the access data. The sequence may position blocks that are more likely to be accessed first toward the beginning of the sequence and blocks that are less likely to be accessed first toward the end of the sequence. In this manner, as blocks of game data begin downloading to a client machine, the blocks of game data that are most likely to be accessed early during a game session are stored in the non-volatile memory of the client machine before downloading other blocks of game data that are less likely to be accessed early during a game session. This allows a user to begin playing a video game responsive to acquiring the video game even while blocks of game data are still being downloaded to the non-volatile memory of the client machine. In fact, the techniques and systems described herein allow a user to begin playing a video game even before the first block of game data has completed downloading to the user's client machine.This is enabled at least in part by the use of a file system proxy component on the client machine, which is configured to receive read operations made by the game executable file and to determine whether the requested block of game data has been downloaded to non-volatile memory or whether the block still needs to complete download. If the block is "realized" in non-volatile memory, this means that the download of the block of game data to the non-volatile memory has completed, and the game executable file can read the block of game data using the file system. If the block has not completed download to the non-volatile memory, the file system proxy component can block the read operation, request the unrealized block of game data from the remote system, and, in response to receiving the block from the remote system, can read the block using the file system. There may be a brief interruption in the execution of the video game while the unrealized block of game data is retrieved from the remote system, but this is unlikely to occur frequently or at all, assuming that the download of game data begins in response to acquisition of the video game, and assuming that the blocks of game data are downloaded in a sequence that aligns with the sequence in which the game executable file accesses the blocks of data during a game session.

[0010] Another exemplary game-related feature that can be enabled is freeing up local memory resources on the client machine by discarding unused blocks of game data. By freeing up local memory resources, the client machine can reclaim valuable storage capacity that can be utilized for game data of other video games and / or other data in general. To enable client-side game data discarding, the client machine - in which the game data of the video game is stored in non-volatile memory - can execute a game executable file of the video game and can generate access data throughout one or more game sessions when a read operation is performed by the game executable file against the file system of the client machine. The access data can specify a first subset of blocks of game data that were accessed over the one or more game sessions, as well as the times during which those blocks were accessed during the game sessions. A remote system can receive the access data from the client machine, and based on the access data, the remote system can determine one or more second blocks of game data, which can be classified as "unused" blocks based on blocks that were not accessed by the game executable file on the client machine for at least a threshold time period or a threshold number of game sessions. In this case, the remote system may send an instruction to the client machine instructing the client machine to delete one or more second blocks of the game data from the non-volatile memory. If the client machine deletes these unused blocks from the non-volatile memory, storage capacity on the client machine may be increased. Furthermore, if the game executable file requires that the deleted blocks of game data be read, the file system proxy component of the client machine may request the blocks of game data from the remote system in an on-demand manner, with some additional latency as compared to storing the blocks on local memory.

[0011] Another exemplary game-related feature that may be enabled is local pre-fetching of blocks of game data to reduce latency when loading game data during a game session. To enable the local pre-fetching feature, a remote system may receive access data (as described herein) from a plurality of client machines relating to a particular video game, and the remote system may generate block dependency data that specifies individual associations between two or more blocks of game data based on the access data. For example, the block dependency data may indicate that whenever a first block of game data is accessed during a game session, a second block of game data will typically be accessed within a threshold period of time. In this manner, the block dependency data may describe relationships between blocks of a set of two or more blocks based on access patterns indicated in the access data received at the remote system. The remote system may transmit the block dependency data to a client machine having a video game installed thereon, and when the client machine executes a game executable file for the video game, the client machine may pre-fetch blocks of game data by caching the blocks in a local memory that provides faster read access speeds than memory in which the game data is persistently stored (e.g., non-volatile memory such as HDD, SD card, etc.). This local prefetching can reduce latency during load times when the game executable requires reading a block of game data.

[0012] The techniques and systems described herein may improve the gameplay capabilities of client machines without requiring game developers to change the way they create video games today. For example, implementing a client-side component such as the file system proxy component described herein allows a user of a client machine to play a video game upon acquiring the video game, meaning that the user does not have to wait (potentially hours) for the game to download before beginning a game session. It also allows game data to be intelligently downloaded in a sequence of blocks that positions the blocks most likely to be accessed first at the beginning of the sequence, which helps reduce latency during game play while the download of game data is in progress. The gameplay capabilities of client machines may additionally or alternatively be improved by pre-fetching game data during a game session according to block dependency data. This is because the client machine can predict which blocks of game data are likely to be accessed next in a sequence of read operations performed by the game executable file of the video game, and such blocks can be cached in a local memory (e.g., a volatile memory such as a random access memory (RAM)) that offers faster read access speeds than the non-volatile memory in which the game data remains. This "primes" the game data for quick access when the video game requests it.

[0013] The techniques and systems described herein may additionally or alternatively enable one or more devices to conserve resources, at least with respect to memory resources. For example, using access data generated by one or more client machines to determine unused blocks of game data and deleting unused blocks of game data may free up local memory resources on the client machines. For example, if a client machine and / or a remote system determines from access data associated with tracked file system read operations that a user has never played a game in single player mode and always plays the game in multiplayer mode, single player game data of a video game may be deleted from the non-volatile memory of the client machine based on a determination that the blocks have not been used for at least a threshold period of time or a threshold number of game sessions.

[0014] FIG. 1 illustrates an example environment 100 including a video game distribution platform configured to implement the techniques described herein. Users 102 (sometimes referred to as "customers") of the community may be associated with one or more client machines 104. Thus, the client machines 104(1)-(N) shown in FIG. 1 represent computing devices that may be utilized by the user community (or customer base) to execute programs, such as video games. The client machines 104 may be implemented as any suitable type of computing device configured to process and render graphics on an associated display and to transmit / receive data over a network, including, but not limited to, a PC, a desktop computer, a laptop computer, a mobile phone (e.g., a smartphone), a tablet computer, a portable digital assistant (PDA), a wearable computer (e.g., a virtual reality (VR) headset, an augmented reality (AR) headset, smart glasses, etc.), an in-vehicle (e.g., in-car) computer, a television (smart TV), a set-top box (STB), a game console, and / or any similar computing device.

[0015] The configuration of the client machines 104 may vary. For example, a subset of the client machines 104 may each use a particular type, version, or characteristics of hardware (e.g., a central processing unit (CPU) model, a graphics processing unit (GPU) model, etc.) and / or a particular type, version, or characteristics of firmware and / or software (e.g., a version of a graphics driver, a downloadable content (DLC) package for use in an installation script, the language in which the video game client runs, etc.). These and other aspects of the client machines 104 hardware, firmware, and / or software make up the "configuration" of the client machines 104 and may be referred to as a "client system configuration" as used herein, and may represent a finite set of depots used to download game data (divided into blocks of data) of a video game to a video game distribution platform. Thus, a subset of the client machines 104 may share a common client system configuration, and the client system configuration may vary among these subsets of the client machines 104. Client machines 104 that differ in terms of client system configuration may download, store, and / or access blocks of game data differently, even for the same video game. Determining whether a pair of client machines 104 have a common client system configuration may be based on the machines 104 sharing a threshold number of common types, versions, or characteristics of hardware, software, or firmware. For example, if two client machines 104 use at least the same DLC package for installation scripts, the machines may be considered to have the same client system configuration, even if they differ in some other aspects (e.g., different GPU models, etc.).

[0016] Referring again to FIG. 1, the client machine 104 may communicate with a remote computing system 106 (sometimes shortened to “remote system 106”) through a computer network 108. This computer network 108 may represent and / or include, but is not limited to, the Internet, other types of data and / or voice networks, wired infrastructures (e.g., coaxial cable, fiber optic cable, etc.), wireless infrastructures (e.g., radio frequency (RF), cellular, satellite, etc.), and / or other connection technologies. The remote system 106 may, in some cases, be part of a network-accessible computing platform that is maintained and accessed via the computer network 108. Such network-accessible computing platforms may be referred to using terms such as “on-demand computing,” “software as a service (SaaS),” “platform computing,” “network-accessible platform,” “cloud services,” “data center,” and the like. In general, the remote system 106 is configured to collect access data 110 from the client machines 104 and to catalog (e.g., organize, categorize, classify, etc.) the access data 110 it receives in a data store 112. The remote system 106 may also be configured to analyze the access data 110 to generate data usable by the client machines 104 to implement various game-related features described herein. For example, as described herein, the remote system 106 may be configured to generate download sequence data 114 and / or block dependency data 116, which the remote system 106 may deliver to the client machines 104.The remote system 106 may additionally or alternatively be configured to analyze the access data 110 to determine unused blocks of game data on one or more client machines 104 and may send instructions 118 to the client machines 104 to delete unused blocks of game data in order to free up local memory resources on the client machines 104.

[0017] In some embodiments, the remote system 106 acts as or has access to a distribution service that distributes (e.g., downloads) programs (and data) to the client machine 104. In one example, the client machine 104 may install a client application. The client application, which may be a video game client (e.g., game software for playing a video game), may be configured to execute a program, such as a video game, on the client machine 104 on which the client application is installed. With the client application installed, the client machine 104 may then have the ability to download a program (e.g., a video game) from the remote system 106 over the computer network 108. To this end, any type of content distribution model may be utilized, such as a direct purchase model in which a program (e.g., a video game) can be individually purchased for download and execution on the client machine 104, a subscription-based model, a content distribution model in which a program is rented or leased for a period of time, etc. Thus, an individual client machine 104 may include one or more installed video games that can be executed by loading a client application, and these video games may render graphics on a display during execution. In one embodiment, a user 102 may select to play one of multiple video games that he or she has acquired (e.g., purchased, rented, leased, etc.) and downloaded from a remote system 106, such as by loading a video game client, selecting the desired video game, and starting execution of the video game.

[0018] Consider the example of FIG. 1, in which several of users 102 play a video game that has been made available to these users 102 by remote system 106. As the video game is played on each of the users 102's client machines 104, a game executable file running on each client machine 104 may successively make requests to a file system to read blocks of game data for the video game. The read operations made by the game executable files may be tracked by a file system proxy component of the client machine 104 to generate access data 110. For example, a game executable file running on client machine 104(1) may issue requests to the file system of client machine 104(1) to read blocks of game data from one or more local memory resources of client machine 104(1) during game execution, such as by reading blocks of game data from sectors of a hard disk drive (HDD) or from sectors of a secure digital (SD) card that is removably coupled to client machine 104(1). Thus, a game executable file for a video game running on client machine 104(1) may perform a series of read operations to the file system throughout a game session, and a file system proxy component of client machine 104(1) may track the read operations to generate access data 110.

[0019] The access data 110 may specify (i) block identifiers that identify the accessed blocks of game data of a video game (e.g., blocks accessed by a game executable file during a game session), as well as (ii) the time during execution of the game executable file that the accessed blocks of game data were accessed by the game executable file performing a read operation. As mentioned, game data of a video game may include textures, virtual objects, maps, game characters, and the like. In some embodiments, game data may be stored across sectors of non-volatile memory (e.g., sectors of an HDD, SD card, etc.) and organized into blocks of game data within the sectors. The use of blocks is a flexible way of dealing with files of different sizes while avoiding the need to store every file using contiguous storage space in a file system. Each block of game data may be referenced and / or located using a block identifier (e.g., a number). In general, one or more processors of the client machine 104 may perform read, write, and / or other storage operations as directed by one or more device drivers. In some embodiments, client machine 104 may create a mapping between blocks of game data and sectors of non-volatile memory to determine which blocks have been accessed and from where (e.g., which sectors) based on read operations performed by a game executable file during game play. For example, if a game executable file performs a read operation to access game data stored in a first sector of non-volatile memory, an identifier for the particular block of game data stored in the first sector may be specified in access data 110.Additionally, the access times specified in the access data 110 may enable determination of the order (or sequence) in which blocks were accessed during a game session (e.g., block A was accessed first, followed by block D, followed by block F, etc.), as well as the relative times of access (e.g., 4 minutes into the game session, 9 minutes into the game session, 1 hour into the game session, etc.).

[0020] The access data 110 received by the remote system 106 may be cataloged in the data store 112 according to a unique client system configuration and / or according to a video game ID of the corresponding video game. The access data 110 may additionally be stored in association with a user account of a user logged into a video game client executing on the client machine 104 that sent the access data 110. FIG. 1 illustrates a data store 112 maintained by the remote system 106 for storing, cataloging, or otherwise organizing the access data 110 received from the client machine 104. The data store 112 may organize the access data 110 into groups (or buckets), each associated with a unique combination of a client system configuration and a video game ID. In other words, each bucket of the access data 110 in the data store 112 may be tied to a particular program (e.g., a video game) and to a particular client system configuration, as described herein.

[0021] 1 illustrates a client machine 104(N) sending a request 120 to acquire (e.g., purchase, rent, lease, etc.) a video game from a remote system 106. For example, a user of the client machine 104(N) logging into his or her user account via an installed video game client may transact through the remote system 106 to purchase the video game. In response to the request 120, the client machine 104(N) may receive from the remote system 106 a game executable file 122 for the video game, and the client machine 104 may also receive download sequence data 114 and / or block dependency data 116 for the acquired video game and for the particular client system configuration of the client machine 104. Thus, it should be understood that the request 120 may include a configuration of the client machine 104(N), which tells the remote system 106 to locate download sequence data 114 and block dependency data 116 that may be available for that particular client system configuration.

[0022] FIG. 1 also depicts the remote system 106 initiating download of blocks 124 of game data 126 for the acquired video game according to a sequence of blocks specified in the download sequence data 114. FIG. 1 illustrates an example where a first block 124(1) is downloaded, followed by a second block 124(2), followed by a third block 124(3), and so on. Although FIG. 1 depicts three blocks 124 as being downloaded to the client machine 104(N), it should be understood that the download sequence may include any number of blocks 124, including additional blocks downloaded after block 124(3). The client machine 104(N) may download the blocks 124 to a non-volatile memory of the client machine 104(N), such as a HDD, an SD card, or the like.

[0023] As shown in FIG. 1, the client machine 104(N) may implement an instant play 128 feature, in which case the client machine 104(N) may begin executing the game executable file 122 of the acquired video game before or during the download of the block 124 of the game data 126. For example, the client machine 104(N) may begin executing the game executable file 122 even before the first block 124(1) of game data is downloaded. The game executable file 122 may begin launching the newly acquired video game in response to user input received by the client machine 104(N), such as the user 102 if the user uses a mouse and / or keyboard, a game controller, or the like. In this sense, there may not be any constraints imposed on the user 102 as to when the user 102 begins playing the video game. As a result, the user 102 may begin playing the game and the game executable file 122 may begin executing before the first block 124(1) of game data is downloaded to the client machine 104(N). If the user 102 chooses to wait a period of time after acquiring the video game, the game executable file 122 may begin execution after at least one block 124(1) of game data 126 has been downloaded to the client machine 104(N).

[0024] In some embodiments, the video game client operating on the client machine 104(N) may be configured to prevent the game executable file 122 from starting until a predetermined time has elapsed since starting the download of blocks 124 or until a predetermined event occurs (e.g., by waiting until a threshold number of blocks 124 have been downloaded before allowing the user 102 to start playing the game). The predetermined time or event may be determined by the remote system 106 based on how suitable the video game is for the instant play 128 feature, and the remote system 106, in response to obtaining the video game, may send instructions to the video game client to wait until a predetermined period of time has elapsed and / or until a predetermined event occurs before allowing the game executable file 122 to run on the client machine 104(N). In some embodiments, the remote system 106 may send data to the client machine 104(N) for outputting a recommendation to the user 102 via the client machine 104(N), such as by displaying a recommendation stating, "For the best user experience, we recommend that you wait five minutes after starting the download of [video game X] before playing." In one embodiment, if the video game is sufficiently suitable for the instant play 128 feature, the remote system 106 may instruct the client machine 104(N) to output a notification stating, "This game is ready for instant play so you can start playing right away. Have fun!"

[0025] As shown in FIG. 1, another client machine 104(2) may implement a local prefetching 130 feature, where the client machine 104(2) may prefetch one or more realization blocks 124 of game data 126 to reduce latency during game play. For example, game data 126 of a video game may be stored in a first memory 132(1) that provides read access at a first rate. This first memory 132(1) may represent a non-volatile memory, such as a HDD, SD card, etc., on which the game data 126 resides. The client machine 104(2) may also include a second memory 132(2) that provides read access at a second rate that is faster than the first rate. This second memory 132(2) may be additional non-volatile memory (e.g., SSD) or may be volatile memory (e.g., working memory, such as RAM). In either case, the block dependency data 116 may be used by the client machine 104(2) to determine whether the block 124 is likely to be next read by the game executable file 122, and if so, the block 124 may be cached in the second memory 132(2) so that when the game executable file 122 eventually requests to read the block 124, the block 124 may be immediately accessed from the second memory 132(2) rather than accessing the block 124 from the relatively slower first memory 132(1). As described in more detail below, multiple different local memory resources 132 may be utilized to cache the blocks 124 of the game data 126 as part of a local prefetching 130 feature, which may improve overall bandwidth and may also reduce latency much more than caching the blocks 124 in, for example, only working memory. This is based on the concept that the game executable file 122 can be read from different local storage resources 132, including the first memory 132(1), in parallel, improving overall bandwidth and further reducing latency significantly.

[0026] 1, yet another client machine 104(1) may implement an unused game data deletion 134 feature, where the client machine 104(1) receives instructions 118 from the remote system 106 to delete one or more blocks 124 of game data 126 stored in non-volatile memory of the client machine 104(1), and in response, the client machine 104(1) may delete the one or more blocks 124 to free up local memory on the client machine 104(1). For example, the remote system 106 may determine from the access data 110 received from the client machine 104(1) that the user 102 of the client machine 104(1) has never played a single player mode of a video game, and as a result, determine that a block 124 of the game data 126 of the video game that is usable for playing the video game in a single player mode has not been accessed by the game executable file 122 for a threshold period of time or a threshold number of game sessions. Thus, remote system 106 may send instructions 118 to one or more client machines 104, such as client machine 104(1), to instruct client machine 104 to delete from non-volatile memory residing therein one or more unused blocks 124 of game data 126 that were previously downloaded to client machine 104 and that were determined to be classifiable as “unused” blocks 124. Instructions 118 may specify identifiers of the unused blocks 124 such that client machine 104(1) can delete the correct blocks 124 of game data 126, thereby freeing up local memory capacity without compromising the user experience of playing the game on client machine 104(1).

[0027] 2 shows a block diagram illustrating exemplary components of a client machine 104, as well as a flow diagram of an exemplary process 200 for tracking file system read operations to generate access data 110 and for transmitting the access data 110 to a remote system 106. In the illustrated implementation, the client machine 104 includes, among other components, one or more processors 202, such as a central processing unit (CPU), a graphics processing unit (GPU), one or more input devices 204, one or more output devices 206, a non-transitory computer-readable medium 208, a local memory 132, and a communication interface 210.

[0028] The non-transitory computer-readable medium 208 may include removable and non-removable media implemented in any method or technology for storing information, such as volatile and non-volatile memory, computer-readable instructions, data structures, program modules, or other logic and / or data. Such memory may include, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVDs) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, RAID storage systems, or any other medium that may be used to store the desired information and that may be accessed by a computing device. The computer-readable medium 208 may be implemented as a computer-readable storage medium ("CRSM"), which may be any available physical medium accessible by the processor 202 to execute instructions stored on the computer-readable medium 208. In one basic implementation, the CRSM may include random access memory ("RAM") and flash memory. In other implementations, the CRSM may include, but is not limited to, read-only memory ("ROM"), electrically erasable programmable read-only memory ("EEPROM"), or any other tangible medium that may be used to store the desired information and that may be accessed by the processor 202. Additionally, while the local memory 132 is shown as being separate from the computer-readable medium 208, it should be understood that in some implementations the computer-readable medium 208 and any one or more of the local memories 132(1), 132(2), and / or 132(3) may represent the same memory or at least a portion of the same memory.

[0029] Reference is now made to the process 200 shown in FIG. 2. The processes described herein are illustrated as a collection of blocks in a logic flow graph and represent sequences of operations that may be implemented in hardware, software, firmware, or combinations thereof (sometimes referred to herein as "logic"). In the context of software, the blocks represent computer-executable instructions that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform particular functions or implement particular abstract data types. The order in which the operations are described is not intended to be construed as a limitation, and any some of the described blocks may be combined in any order and / or in parallel to implement a process.

[0030] For purposes of discussion, assume that the client machine 104 performing the process 200 has already installed the video game client 212, which represents a client application stored on the computer-readable medium 208 and configured to execute a game executable file 122 for the video game. A user 102 of the client machine 104 may acquire (e.g., purchase, rent, lease, etc.) a video game, and in response to the acquisition, the video game may be installed (e.g., downloaded from the remote system 106) and maintained in non-volatile memory. In some embodiments, the first local memory 132(1) (sometimes referred to as “first memory 132(1)”) may represent a non-volatile memory (e.g., HDD, SD card, etc.), and the first memory 132(1) may provide read access at a first rate. When the blocks 124 of the game data 126 are downloaded from the remote system 106, the blocks 124 of the game data 126 may be downloaded to the first memory 132(1). On the other hand, the second memory 132(2) may represent additional non-volatile memory (e.g., a solid-state drive (SSD)), and the second memory 132(2) may provide read access at a second rate that is faster than the first rate provided by the first memory 132(1). Additionally, the third memory 132(3) may represent volatile memory (e.g., a working memory such as RAM), and the third memory 1320(3) may provide read access at a third rate that is faster than the second rate. It should be understood that the client machine 104 may implement fewer local memory 132 resources than those shown in FIG. 2 (e.g., by removing the second memory 132(2)) or may implement additional local memory 132 resources.

[0031] At 214, the video game client 212 may execute a game executable file 122 of a video game on the client machine 104. For example, a user 102 of a client machine 104 may load a video game client 212, which may provide the user 102 with the ability to execute a previously downloaded video game (through execution of the game executable file 122) and / or obtain a new video game from a remote system 106. The game executable file 122 may be loaded into a working memory, such as third memory 132(3), and execute to, among other things, render graphics on a display of the client machine 104. During a game session, there may be a startup phase and a playtime phase. During a game session, the game executable file 122 may be configured to receive input data from the input devices 204 (e.g., a mouse and / or keyboard, a game controller, a head mounted display (HMD), a microphone, etc.) and may determine which blocks 124 of game data 126 to access in order to render the next frame of video game content on the display (i.e., the output device 206) of the client machine 104. For example, the game executable file 122 may be configured to determine which portions of the game world to render in the upcoming frame and which objects and / or textures to render in the upcoming frame and may issue a read operation to read the corresponding blocks 124 of the game data 126 for presenting the upcoming frame.

[0032] At 216, a file system proxy component 218 executing on the client machine 104 may determine (e.g., receive, monitor, intercept, etc.) read operations (e.g., first read operation, second read operation, etc.) made by the game executable file 122 to a file system 220 of the client machine 104. The file system 220 may be configured to control how data, including blocks 124 of game data 126 of the video game, is stored and retrieved. Regardless of whether all of the game data 126 of the video game is embodied in local memory resources, such as the first memory 132(1), the file system proxy component 218 may be configured to “lie” to the video game as to what blocks 124 (e.g., files) of game data 126 are present in non-volatile memory (e.g., on a HDD, SD card, etc.) of the client machine 104. For example, the video game client 212, through the file system proxy component 218, may know, based on the identifier of the video game, a list of game files that are supposed to be stored in non-volatile memory, the size of the game files, and possibly the sectors of non-volatile memory in which the game files are stored. This may, for example, make the video game (e.g., the game executable file 122) believe that the blocks 124 of all game data 126 of the video game are stored in the first memory 132(1). The file system proxy component 218 may be an extension of the file system 220 to fake and expose this information to the game executable file 122 as needed. In any case, consider an example where the blocks 124 of all game data 126 of the video game are stored in and accessible from the first memory 132(1) of the client machine 104. In this example, the file system proxy component 218 may act as a pass-through, merely monitoring read operations made by the game executable file 122 to the file system 220.As described in more detail herein, particular blocks 124 of game data 126 may be pre-fetched from first memory 132(1) and cached in at least one of second memory 132(2) or third memory 132(3), both of which provide faster read access speeds than those provided by first memory 132(1). File system 220 may keep track of where blocks 124 of game data 126 are stored at any given moment and may access blocks 124 of game data 126 from the appropriate memory resource 132 to service read operations performed by game executable file 122 during a session.

[0033] At 222, the file system proxy component 218 may generate access data 110 to receive from the game executable file 122 based at least in part on the read operation. As described elsewhere herein, this access data 110 may specify (i) an identifier of a block 124 of game data 126 accessed by the game executable file 122 during a game session, and (ii) a time during the execution of the game executable file 122 at which the accessed block 124 of game data 126 was accessed by the game executable file 122. For example, with respect to two blocks 124 of game data 126, the access data 110 may specify (i) a first identifier of a first block of game data, (ii) a first time during the execution of the game executable file at which the first block of game data was accessed based at least in part on the first read operation, (iii) a second identifier of a second block of game data, and (iv) a second time during the execution of the game executable file at which the second block of game data was accessed based at least in part on the second read operation. In some embodiments, the access time of each accessed block 124 may be expressed in the access data 110 as a time measured from the start of the game session (e.g., block A was accessed 4 minutes after the game session started, block D was accessed 13 minutes after the game session started, etc.).

[0034] At 224, the client machine 104 may transmit the access data 110 to the remote system 106, such as via the communication interface 210 and through the computer network 108. The communication interface 210 may implement multiple types of wired and / or wireless or radio technologies. For example, the communication interface 210 may implement a radio, such as a Bluetooth Low Energy (BLE) radio, a Wi-Fi radio, and / or a cellular radio. It should be appreciated that the communication interface 210 may further include a physical port that facilitates a wired connection to a network, a connected peripheral device, or a plugged-in network device that communicates with other wireless networks.

[0035] As shown in sub-block 226, at 224, the access data 110 may be transmitted along with the configuration of the client machine 104 and the identifier of the video game. Additionally, the access data 110 may be transmitted to the remote system 106 at any suitable time, when the access data 110 is generated, and / or in response to an event (e.g., periodically, during a relatively low idle time such as when processing resource consumption is below a threshold percentage of resource consumption, upon resuming network connectivity (e.g., after playing the game offline), after the client machine 104 stops executing the game executable file 122 (e.g., after the user 102 ends the game session by exiting the video game), etc.), in real time or substantially real time, etc., by streaming the access data 110 to the remote system 106. The access data 110 may also be transmitted in any suitable format for transmitting metadata resulting from tracked read operations on the client machine 104, such as by transmitting the access data 110 to the remote system 106 as an artifact. Process 200 represents a "telemetry" approach to collecting access data 110 at a remote system 106. Given that a large number of client machines 104 may perform process 200, the remote system 106 may collect access data 110 transmitted (e.g., uploaded, reported, etc.) at block 224 from a large number of client machines 104 having different client system configurations.

[0036] 3 shows a block diagram illustrating exemplary components of a remote system 106 for implementing the techniques described herein, as well as a flow diagram of an exemplary process 300 for receiving access data 110 from a client machine 104 and analyzing the access data 110 across one or more users 102. In the illustrated implementation, the remote system 106 includes, among other components, one or more processors 302, memory 304 (or non-transitory computer-readable medium 304), and a communication interface 306. The memory 304 (or non-transitory computer-readable medium 304) may include volatile and non-volatile memory, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable instructions, data structures, program modules, or other data. Such memory may include, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage device, RAID storage system, or any other medium that may be used to store the desired information and that may be accessed by a computing device. The computer-readable medium 304 may be implemented as a computer-readable storage medium ("CRSM"), which may be any available physical medium that is accessible by the processor 302 to execute instructions stored on the memory 304. In one basic implementation, the CRSM may include random access memory ("RAM") and flash memory. In other implementations, the CRSM may include, but is not limited to, read-only memory ("ROM"), electrically erasable programmable read-only memory ("EEPROM"), or any other tangible medium that may be used to store the desired information and that may be accessed by the processor 302.The download sequence component 308, the block dependency component 310, and / or the game data usage component 312 may represent instructions stored in the memory 304 that, when executed by the processor 302, cause the remote system 106 to perform the techniques and operations described herein. For example, as described herein, the download sequence component 308 may be configured to generate the download sequence data 114 based on the access data 110. As described herein, the block dependency component 310 may be configured to generate the block dependency data 116 based on the access data 110. As described herein, the game data usage component 312 may be configured to determine unused blocks 124 of the game data 126 based on a per-user or per-client machine 104.

[0037] The communication interface 306 may implement multiple types of wired and / or wireless or radio technologies. For example, the communication interface 306 may implement a radio, such as a Bluetooth Low Energy (BLE) radio, a Wi-Fi radio, and / or a cellular radio. It should be appreciated that the communication interface 306 may further include a physical port that facilitates a wired connection to a network, a connected peripheral device, or a plugged-in network device that communicates with other wireless networks.

[0038] Reference is now made to process 300 shown in Figure 3. At 314, the remote system 106 may receive access data 110 from a client machine 114 (e.g., as part of a "telemetry" approach using process 200, as described above). The received access data 110 may specify, for a particular client machine 104, an identifier of a block 124 of game data 126 of a video game that was accessed at the particular client machine 104 by a game executable file 112 of a video game, and a time during a game session that the block 124 was accessed (e.g., during execution of the game executable file 122 of the video game). As indicated by sub-block 316, the access data 110 may be received along with a configuration of the particular client machine 104 and along with an identifier of a video game that was executed during the generation of the access data 110.

[0039] In 318, the remote system 106 may catalog the access data 110 received in block 314 by (or according to) the client system configuration and the game identifier. For example, the data store 112 may include multiple groups or buckets 320(1)-(M) categorized by unique combinations of game ID and client system configuration. Taking a first client machine 104(1) having a client system configuration “1” as an example, in block 314, upon receiving the first access data 110 from the first client machine 104(1), in block 318, the first access data 110 may be cataloged in a first bucket 320(1) (or groups), and in sub-block 316, this bucket 320(1) may be tagged with the game ID of the video game received from the first client machine 104(1) and the client system configuration of the first client machine 104(1). Similarly, the second client machine 104(2) may send second access data 110, which may be cataloged in block 318 in a second bucket 320(2), which may be tagged with the game ID of the video game received from the second client machine 104(2) and the second client system configuration “2” of the second client machine 104(2) in sub-block 316. This may continue for any number of “M” buckets, depending on the number of client machines 104 reporting access data 110, whether the client machines 104 have different client system configurations, and / or the number of different video games running on the client machine 104.

[0040] At 322, the remote system 106 may perform an analysis of the access data 110 received in block 314 to generate data (e.g., results of the analysis) that may include, but is not limited to, a determination of unused blocks 124 of game data 126 based on download sequence data 114 of one or more video games, block dependency data 116 of one or more video games, and / or per user / per client machine.

[0041] At 324, the remote system 106 may determine whether a trigger event has occurred. The trigger event may vary, but may include, but is not limited to, receiving a request 120 to acquire (e.g., purchase, rent, lease, etc.) a video game from the client machine 104, generating new download sequence data 114 and / or new block dependency data 116 for the video game, determining that the client machine 104 has unused blocks 124 of game data 126 that have not been accessed for a threshold period of time or a threshold number of game sessions, etc.

[0042] If, at block 324, the remote system 106 determines that a trigger event has not occurred, the process 300 may follow a "no" route from block 324 back to block 314, and the remote system 106 may continue to collect / receive access data 110 from the client machine 104. If, at block 324, the remote system 106 determines that a trigger event has occurred, the process 300 may follow a "yes" route from block 324 to block 326, and the remote system 106 may transmit data to one or more client machines 104. For example, if the trigger event includes the client machine 104 acquiring a video game, the remote system 106 may retrieve download sequence data 114 for the video game and transmit the download sequence data 114 to the client machine 104 along with the game executable file 122 for the video game. Additionally or alternatively, the remote system 106 may retrieve block dependency data 116 for the video game and transmit the block dependency data 116 to the client machine 104. As yet another example, if the triggering event includes determining that unused blocks 124 of game data 126 are present at the client machine 104, the remote system 106 may send instructions to delete the unused blocks of game data.

[0043] It should be appreciated that in some embodiments, at least some of the components of the client machine 104 shown in FIG. 2 may be implemented as components of the remote system 106. For example, the game executable file 122 may execute on the remote system 106 (e.g., as part of a service that streams video games), and the game executable file 122 may receive data indicative of user input from the client machine 104 over the network 108 while playing the video game. In this scenario, the game data 126 of the video game may be stored on the remote system 106 as well, and the file system proxy component 218 may be a component of the remote system 106 that receives read operations from the game executable file 122 and monitors blocks 124 of the game data 126 accessed during game play. In this configuration, the client machine 104 may act as a thin client, with most processing occurring in the cloud during a video game session. In another example, the download sequence component 308, the block dependency component 310, and / or the game data usage component 312 may be components of the client machine 104. In this example, the client machine 104 may receive access data 110 generated by other client machines 104 collected by the remote system 106, and the client machine 104 may perform an analysis of its own access data 110 and / or the access data 110 generated by the other client machines 104 to determine unused blocks 124 of the download sequence data 114, block dependency data 116, and / or game data 126 stored on the client machine 104.

[0044] FIG. 4 is a flow diagram of an example process 400 for generating download sequence data 114 used by a client machine 104 to download blocks 124 of game data 126 in a particular sequence of the blocks 124 based on access data 110 received from multiple client machines 104.

[0045] At 402, the remote system 106 may receive access data 110 related to a video game from a plurality of client machines 104. The access data 110 received at block 402 may specify, for each client machine 104, (i) an accessed block 124 of game data 126 associated with the video game that was accessed by the game executable file 122 of the video game during execution of the game executable file 122 on the each client machine, and (ii) a time during execution of the game executable file 122 that the accessed block 124 of the game data 126 was accessed by the game executable file 122. As indicated by sub-block 404, the access data 110 may be received along with a configuration of the client machine 104 that sent the access data 110 and / or a game identifier of a video game that was executing on the client machine 104 when the access data 110 was generated.

[0046] At 406, the remote system 106 may generate, based at least in part on the access data 110, download sequence data 114 associated with a client system configuration and a game identifier of the video game. The download sequence data 114 may specify a sequence of blocks 124 of game data 126 of the video game, which may represent the order in which the blocks 124 of game data are downloaded to a client machine 104 having a particular client system configuration. The download sequence of the video game may be determined in any suitable manner. As indicated by sub-blocks 408 and 410, generating the download sequence data 114 may include multiple sub-operations.

[0047] At 408, statistics (e.g., time, location / order / rank, etc.) may be calculated for at least some of the blocks 124 of the game data 126 of the video game based at least in part on when the blocks 124 were accessed (as specified in the access data 110) over the N game sessions of the N corresponding users 102 who played the video game (where "N" is any positive integer). For example, based on the access data 110 associated with the N users 102 who played the video game, the remote system 106 may determine statistics (e.g., average values) based on the time the blocks 124 were accessed by each of the N users 102 during a game session (e.g., during a first game session). The remote system 106 may determine, for example, (based on multiple different times that block A was accessed by the N different users) that the average access time of block A to the first game session was 30 minutes, the average access time of block B to the first game session was 45 minutes, the average access time of block C to the first game session was 2 hours, etc. The remote system 106 may additionally or alternatively determine that for N users, block A was the first block accessed by user A during an initial game session, block A was the fifth block accessed by user B during the initial game session, block A was the seventh block accessed by user C during the initial game session, etc., and the remote system 106 may then determine statistics (e.g., average position / order / rank) for block A based at least in part on information about when the blocks were accessed by the N different users 102. This may be repeated for other blocks 124 accessed during the game session. These analyses may be performed for at least the initial game session. Analyses may be performed for any subsequent game sessions as well to determine which blocks 124 of game data 126 are typically accessed during the game session.

[0048] At 410, a download sequence can be determined for a number of blocks 124 of game data 126 of the video game based on the calculated statistics. The blocks 124 specified in the download sequence can be some of the blocks 124 of the game data (e.g., a portion of the total number of blocks 124), or the download sequence can include all of the blocks 124 of the game data 126. It should be appreciated that for a given video game, the ratio between the initial number of blocks 124 that are likely to be accessed during an initial period of play time, and the length of the initial period of play time, can be somewhat disproportionate. In other words, 2 gigabytes of game data 126 may provide the first 6 hours of play time for a particular video game, while the remainder of the game data 126 may be less likely to be accessed during this initial play period. This means that certain games may be well suited for the "instant play" 128 feature, and these games can be flagged as "good instant play games" that are well suited for instant play based on this ratio. In other words, a particular game may be flagged as being able to support a relatively long initial play period with a relatively small amount of game data 126. As an example, a single player game may be well suited for an "instant play" 128 feature with little or no latency, since a new player may be required to play the same level for the first time. This means that for a single player game, the remote system 106 may determine that all or nearly all players playing the game for the first time will access the same blocks 124 within the first X hours of play time, and this pattern may be substantially linear and consistent across a set of N players - for example, all N players may access block A, then block H, block Q, etc. - although there may be discrepancies in the exact times that blocks 124 are accessed, there may be a common order of blocks 124 accessed over the initial period of play time of a given video game.In contrast, a multiplayer game may have an open game world with a large map. For example, across N users, the N users may initially enter the game at different locations in the open world, and each game executable 122 will have access to different blocks 124 of game data 126 that correspond to the different locations in the open world where the matched players enter the game. This is an example of a game that is not suitable for the instant play 128 feature.

[0049] Assuming the video game can support the instant play 128 feature, the download sequence may specify an order of block A, block D, block G, block C, block F, block E, etc. Thus, for any video game, and for any client system configuration, the remote system 106 may determine that, over at least some play time (e.g., the first six hours of play time), the average user 102 is likely to access only a particular subset of the blocks 124 of the game data during that period of play time, and is also likely to access the blocks 124 in a particular sequence. It should be appreciated that in some embodiments, the download sequence may be user-specific. That is, for the same video game and the same client system configuration, a first download sequence may be determined for a first user 102 and a second download sequence may be determined for a second user 102, where the second download sequence is different from the first download sequence. This may be based on unique access patterns indicated in the user-specific access data 110.

[0050] At 412, the remote system 106 may receive a request 120 to acquire a video game from the client machine 104, the request 120 including a configuration of the client machine 104. For example, a user 102 of the client machine 104 logging into his or her user account via a video game client 212 may conduct a transaction via the remote system 106 to purchase a video game.

[0051] At 414, the remote system 106 may send a game executable file 122 of the video game to the client machine 104. The game executable file 122 may be executable code (e.g., a file) that is executable by the processor 202 of the client machine 104 to initiate play of the video game on the client machine 104. As indicated by sub-block 416, the remote system 106 may send download sequence data 114 to the client machine 104 to initiate downloading of blocks 124 of game data 126 of the retrieved video game in a sequence specified by the download sequence data 114.

[0052] At 418, the remote system 106 may download the blocks 124 of game data to the client machine 104 according to the sequence specified in the download sequence data 114. This may take some time depending on the achievable downlink data rate of the client machine 104. Thus, as the sequence 124 of blocks is downloaded, the blocks 124 that are most likely to be accessed first are realized in the local memory 132 of the client machine 104 before the other blocks, and by the time the game executable file 122 of the video game requests to read the other blocks, those blocks are likely to have completed downloading to the client machine 104.

[0053] FIG. 5 is a flow diagram of an example process 500 for generating block dependency data 116 for use by client machines 104 based on access data 110 received from multiple client machines 104 to pre-fetch blocks 124 of game data 126 to reduce latency during game play.

[0054] At 502, the remote system 106 may receive access data 110 related to a video game from a plurality of client machines 104. The access data 110 received at block 502 may specify, for each client machine 104, (i) an accessed block 124 of game data 126 associated with the video game that was accessed by the game executable file 122 of the video game during execution of the game executable file 122 on the each client machine, and (ii) a time during execution of the game executable file 122 that the accessed block 124 of the game data 126 was accessed by the game executable file 122. As indicated by sub-block 504, the access data 110 may be received along with a configuration of the client machine 104 that sent the access data 110 and / or a game identifier of a video game that was executing on the client machine 104 when the access data 110 was generated.

[0055] At 506, the remote system 106 may generate, based at least in part on the access data 110, block dependency data 116 associated with the client system configuration and the game identifier of the video game. The block dependency data 116 may specify individual associations between two or more blocks 124 of the game data 126 of the video game. In other words, the remote system 106 may predict one or more blocks 124 of the game data 126 that will be accessed if a particular event occurs. In this manner, based on the access data 110, a map of dependencies (e.g., branching, tree-like dependencies) between the blocks 124 of the game data 126 and / or between the blocks 124 and context cues may be constructed. As indicated by sub-blocks 508 and 510, the generation of the block dependency data 116 may include one or more sub-operations.

[0056] At 508, the remote system 106 may determine an association between the contextual cue and a block 124 of the game data 126 of the video game based on the access patterns (e.g., access times) indicated in the access data 110 received from the N users 102 who played the video game. For example, the remote system 106 may determine that whenever a particular contextual cue is detected (e.g., whenever a user 102 navigates to a library page of the video game), a particular block 124 of the game data 126 is typically accessed within a threshold period (e.g., averaged across the N users). This type of correlation may be determined at least in part based on the access times specified in the access data. For example, if, across the N users, block A is the most accessed block within the first 15 seconds by the N users who navigate to the library page of the video game, then block A may be associated with this type of contextual cue.

[0057] At 510, the remote system 106 may determine associations between pairs of blocks 124 of game data 126 of a video game based on access patterns (e.g., access times) indicated in the access data 110 received from the N users 102 who played the video game. For example, the remote system 106 may determine, based on the access data 110 received from the N users 102 who played the video game, that whenever a first block 124(1) of game data 126 was accessed during a game session, a second block 124(2) of game data 126 was typically accessed during a threshold period of time. In this manner, the remote system 106 may determine relationships between blocks of a group of two or more blocks 124 based on the access patterns indicated in the access data 110.

[0058] It should be appreciated that in some embodiments, the block dependency data 116 may be user-specific. That is, for the same video game and the same client system configuration, a first map of block dependencies may be determined for a first user 102 and a second map of block dependencies may be determined for a second user 102, where the second map is different from the first map. This may be based on unique access patterns indicated in the user-specific access data 110.

[0059] At 512, the remote system 106 may transmit the block dependency data 116 to one or more client machines 104. The block dependency data 116 may be transmitted in response to various triggering events. For example, the remote system 106 may transmit the block dependency data 116 of a video game to a client machine 104 in response to a user 102 of the client machine 104 acquiring (e.g., purchasing, renting, leasing, etc.) the video game. As another example, the block dependency data 116 generated at block 506 may represent new data (or updated data) relative to a previous version of the block dependency data 116 of the video game, and in response to generating the new / updated block dependency data 116 at block 506, the remote system 106 may transmit the block dependency data 116 to a client machine 104 known to be associated with the owner of the video game. As yet another example, a user may select to have a local prefetching feature implemented on his or her client machine 104, and in response to the selection, the remote system 106 may transmit block dependency data 116 to the selected user's client machine 104.

[0060] FIG. 6 is a flow diagram of an example process 600 for determining unused blocks 124 of game data 126 based on access data 110 received from a client machine 104 and for instructing the client machine 104 to discard the unused blocks 124 of game data 126.

[0061] At 602, the remote system 106 may receive access data 110 related to a video game from a client machine 104. The access data 110 received at block 602 may specify (i) an accessed block 124 of game data 126 associated with a video game that was accessed by the game executable file 122 of the video game during execution of the game executable file 122 on the client machine 104, and (ii) a time during execution of the game executable file 122 at which the accessed block 124 of the game data 126 was accessed by the game executable file 122. It should be understood that the remote system 106 may have previously received access data 110 from the same client machine 104 at some time in the past. Thus, the remote system 106 may have access to access data 110 generated through multiple game sessions played on the client machine 104. As indicated by subblock 604, the access data 110 may be received along with the configuration of the client machine 104 that sent the access data 110 and / or a game identifier of a video game executing on the client machine 104 when the access data 110 was generated.

[0062] At 606, the remote system 106 may determine, based on the access data 110 (and possibly additional access data 110 previously received from the client machine 104), whether any blocks 124 of the game data 126 of the video game currently stored in the non-volatile memory (e.g., the first memory 132(1)) of the client machine 104 can be classified as “unused” blocks 124 of the game data 126. As indicated by sub-block 608, this determination may include determining whether an individual block 124 has not been accessed by the game executable file 122 of the video game on the client machine 104 for a threshold period of time or for a threshold number of game sessions. For example, blocks X-Z of the game data 126 may be determined to be unused blocks if they have not been accessed for the past P game sessions (where “P” is any suitable integer) or for the last Q weeks (where “Q” is any suitable integer, such as the past 10 weeks).

[0063] In some embodiments, other factors are considered in classifying a block 124 of game data 126 as an unused block. For example, the remote system 106 may determine that a particular block 124 of game data 126 has been accessed once by a game executable file 122 across N users of a particular video game and has not been accessed again, in which case the remote system 106 may determine that the particular block 124 has already been accessed once and may designate the block 124 as unused, regardless of how recently the block 124 was accessed by the game executable file 122. Similarly, other heuristics may be used to determine an unused block 124.

[0064] If, at block 606, it is determined that none of the blocks 124 of the game data 126 stored in the non-volatile memory (e.g., the first memory 132(1)) of the client machine 104 can be classified as unused blocks 124, the process 600 may follow a “no” route from block 606 back to block 602, and the remote system 106 may receive (or wait to receive) additional access data 110 from the client machine 104. If, at block 606, it is determined that one or more of the blocks 124 of the game data 126 stored in the non-volatile memory of the client machine 104 can be classified as unused blocks 124, the process 600 may follow a “yes” route from block 606 to block 610.

[0065] At 610, the remote system 106 may send instructions 118 to the client machine 104 to delete unused blocks 124 of the game data 126 from the non-volatile memory of the client machine 104. These instructions 118 may include identifiers of the blocks 124 to be deleted. In response to the deletion, local memory resources 132 of the client machine 104 may be freed up to increase local memory capacity for potentially storing other data therein.

[0066] 7 is a flow diagram of an example process 700 for discarding unused blocks of game data from non-volatile memory of a client machine 104. As indicated by off-page reference "A" in FIGS. 2 and 7, process 700 may continue from block 224 of process 200 after the client machine 104 transmits access data 110 to the remote system 106.

[0067] At 702, the client machine 104 may receive instructions 118 from the remote system 106 to delete one or more blocks 124 of game data 126 of a video game from non-volatile memory. The remote system 106 may determine from access data 110 previously transmitted by the client machine that the blocks 124 to be deleted represent unused blocks 124 of game data 126 that have not been accessed for a threshold period of time or a threshold number of game sessions.

[0068] At 704, the client machine 104 may delete one or more blocks 124 of the game data 126 from the non-volatile memory (e.g., the first memory 132(1)) based on the instructions 118 received from the remote system 106. As indicated by sub-block 706, the client machine 104 may be configured to wait until the client machine 104 is rebooted before discarding the blocks 124 of the game data 126. In this manner, deleting the blocks 124 does not pose any problem, for example, if the user 102 is currently playing a video game (or a different video game). It should be appreciated that the remaining blocks 124 of the game data 126 remain in the non-volatile memory after the deletion of the unused blocks 124. Thus, local memory resources 132 may be freed by discarding the blocks 124 of the game data 126 that are unlikely to be accessed in the future. In an exemplary use case, a user 102 may install video game X on his or her client machine 104, and since installation, the user 102 has only ever played video game X online, meaning that the user 102 has never previously played video game X in single player mode. From the access data 110 reported by the client machine 104 to the remote system 106, the remote system 106 may determine that the user 102 has not accessed block 124 of game data 126 for single player mode of video game X over a period of several weeks and / or over a number of game sessions since video game X was installed on the client machine 104. In this case, the remote system 104 may send an instruction 118 to discard the single-player game data 126 (by identifying one or more blocks 124 that correspond to that game data 126), the client machine 104 may receive the instruction, and the client machine 104 may delete those blocks 124 to free up space in the client machine 104's non-volatile memory (e.g., the first memory 132(1)).

[0069] After deletion, the video game may run normally, and read operations performed by the game executable file 122 continue to occur. In the unlikely event that the game executable file 122 requests to read blocks 124 of the game data 126 that were deleted from the non-volatile memory of the client machine 104, the file system proxy component 218 may retrieve such blocks on demand from the remote system 106. In some embodiments, if the deleted blocks 124 are requested to be read by the game executable file 122, such blocks 124 may be re-downloaded to the non-volatile memory of the client machine 104. Implementations of the process 700, in conjunction with other processes and / or techniques described herein, may reclaim valuable disk space (e.g., on the order of tens of gigabytes of disk space) on the client machine 104.

[0070] 8 is a flow diagram of an example process 800 for executing a video game on a client machine 104 before the game download is complete. The process 800 may be referred to herein as an "instant play" 128 feature because it may allow a user 102 to play a video game upon acquisition of the video game without waiting for the game data 126 to be downloaded to the client machine 104.

[0071] At 802, a client machine 104 may send a request 120 to a remote system 106 to acquire (e.g., purchase, rent, lease, etc.) a video game. As indicated by subblock 804, the request 120 may include configuration of the client machine 104 such that the remote system 106 retrieves the correct download sequence data 114 for the client system configuration.

[0072] At 806, the client machine 104 may receive from the remote system 106 a game executable file 122 of the video game, such as executable code (e.g., one or more files) that is executable by its processor 202 to play the video game on the client machine 104. As indicated by sub-block 808, the client machine 104 may also receive download sequence data 114 associated with a configuration of the client machine 104. This download sequence data 114 may specify a sequence of blocks 124 of game data 126 of the video game.

[0073] At 810, the client machine 104 may begin downloading blocks 124 of game data 126 of the video game according to a sequence specified in the download sequence data 114 to a non-volatile memory of the client machine 104 (e.g., a first memory 132(1)).

[0074] At 812, the client machine 104 may execute the game executable file 122 to start the video game. It should be understood that the user 102 may begin playing the video game, and the game executable file 122 may begin execution, even before the first block 124 of the game data 126 has completed downloading. The execution of the game executable file may occur in response to a user input detected by the client machine 104 to start the video game. For example, a user of the client machine 104 may select a user interface element of the video game client 212 to start a video game that the user just obtained via the remote system 106. As mentioned, in some embodiments, the remote system 106 may send data to the client machine 104 for outputting a recommendation to the user 102 via the client machine 104, such as by displaying a recommendation stating, "For the best user experience, we recommend that you wait T minutes after starting the download of [video game X] before playing." In some embodiments, the video game client 212 may prevent the execution of the game executable file 122 until a threshold period of time has elapsed and / or until a threshold number of blocks 124 have completed downloading in order to provide an optimal user experience. Alternatively, if the video game is particularly well suited for the instant play 128 feature, the remote system 106 may instruct the client machine 104 to output a notification stating "This game is ready for instant play so you can start playing right away. Have fun!" and / or the video game client 212 may not impose any constraints on when the user 102 can begin playing the video game. In practice, this may be preferable for some players who do not mind a short wait at the beginning of the video game (e.g., to explore the world and set up settings) to begin playing immediately and perhaps before any game data 126 download is complete.

[0075] At 814, the file system proxy component 218 of the client machine 104 may receive a first read operation made by the game executable file 122 to the file system 220 of the client machine 104. This first read operation may request to read a first block 124(1) of game data 126 of a video game. Because a download of the game data 126 is in progress (assuming a sizable video game) at the time the read operation is received at block 814, it is possible that the game executable file 122 may request to read an unrealized block 124 of the game data 126, where "unrealized" means that the block 124 of game data has not yet been downloaded to the non-volatile memory (e.g., the first memory 132(1)) of the client machine 104. In some embodiments, the file system proxy component 218 may temporarily (e.g., for a short period of time) block the read operation in order to make a determination as to whether the requested block 124 is realized in non-volatile memory or if the block 124 still requires a download (e.g., completion of the download).

[0076] Thus, at 816, the file system proxy component 218 may determine whether the first block 124(1) of game data 126 has been downloaded to non-volatile memory (NVM) of the client machine 104 (i.e., whether the first block 124(1) is “embodied” in non-volatile memory). If the first block 124(1) of game data 126 is embodied in non-volatile memory of the client machine 104, then upon receiving the read operation at block 814, process 800 may follow the “yes” route from block 816 to block 818.

[0077] At 718, file system proxy component 218 of client machine 104 may unblock the read operation, and file system 220 may be used to read first block 124(1) of game data 126 from local memory resource 132. If, by chance, first block 124(1) was realized and prefetched by caching in second memory 132(2) or third memory 132(3) that offers faster read access speeds than first memory 132(1), first block 124(1) may be read from the faster memory 132(2) / (3) in which it is cached. At block 816, if the first block 124(1) of game data 126 has not been realized in the non-volatile memory of client machine 104, meaning that the first block 124(1) has not completed downloading to the non-volatile memory (e.g., first memory 132(1)), process 800 may follow the “No” route from block 816 to block 820.

[0078] At 820, the client machine 104 may send a second request for the first block 124(1) of the game data 126 to the remote system 106. As mentioned, the file system proxy component 218 may intercept and block the read operation. In some embodiments, the call associated with the read operation may be intercepted and blocked within the kernel of the client machine 104, and the file system proxy component 218 may make a callback to the video game client 212 to download the first block 124(1) if it determines that the first block 124(1) has not been realized.

[0079] At 822, the client machine 104 may receive the first block 124(1) of the game data 126 from the remote system 106 over the computer network 108. Following receipt of the first block 124(1) of the game data 126, the first block 124(1) of the game data 126 may be read using the file system 220. Thus, the file system proxy component 218 may temporarily block read operations for at least the unrealized block 124 of the game data 126 until the block 124 is received from the remote system 106. While this may add latency in reading the unrealized block 124 as compared to the latency of reading a block 124 that is already realized in the non-volatile memory of the client machine 104, this configuration nevertheless allows for the playing of a video game without downloading all of the game data 126 of the video game. In effect, it allows for the playing of a video game without storing any of the game data 126 on the client machine 104. However, because latency is added by retrieving blocks 124 of game data 126 through the computer network 108, downloading the game data 126 in parallel with the execution of the game ensures that at least some, if not all, of the blocks 124 of game data 126 are realized in non-volatile memory by the time the game executable file 122 requests to read the blocks 124, thereby reducing latency. That is, because the remote system 106 intelligently determines the download sequence based on the access data 110 received from other client machines 104 with the same client system configuration, the likelihood of receiving a read operation requesting to read an unrealized block 124 of game data 126 is relatively low, and even if possible, is not expected to occur frequently.Instead, by the time a read operation for a given block 124 is performed by the game executable file 122, the given block 124 may already have been downloaded and implemented in non-volatile memory, and thus the game executable file 122 may be able to read the block 124 from the local memory resources 132 of the client machine 104 with less latency than would be involved in retrieving the same block 124 from the remote system 106 over the computer network 108.

[0080] At 824, a determination is made whether the game session of the video game should be terminated. For example, if the user 102 quits the video game, the process 800 may follow the “Yes” route from block 824 to block 826, and the video game client 212 may stop execution of the game executable file 122. If the game session should not be terminated at block 824 (e.g., if the user 102 continues to play the game), the process 800 may follow the “No” route from block 824 to block 814, and an additional read operation may be received. As the user 102 continues to play the game, portions of the process 800 may be repeated in this manner, with unrealized blocks 124 of the game data 126 being retrieved from the remote system 106 on demand, if necessary. Using this technique of the file system proxy component 218 “lying” to the video game about the blocks 124 available in non-volatile memory, it can be understood that from the video game's frame of reference, the game's content appears to be stored in the first memory 132(1). The video game may expect game data 126 to be available from local memory resources 132, and may have varying read access speeds between client machines 104 and client systems 104 based on various factors (e.g., resources consumed by other running processes, etc.), or there may be variations in read access speeds at a single client machine 104. All this means that the approach of process 800 will not crash the video game, even though it may perhaps be a bit slower due to searching for unrealized blocks 124 of game data 124 across the wide area network 108.

[0081] Using process 800, a user 102 can begin playing a video game as soon as desired after the user acquires the game. Additionally, the technique of process 800 is game agnostic, which means that no work needs to be done by game developers to enable the instant play 128 feature, but rather enhances the value of all games on a video game distribution platform that distributes video games to a heterogeneous population of client system configurations.

[0082] FIG. 9 is a flow diagram of an example process 900 for pre-fetching blocks 124 of game data 126 to reduce latency during game play.

[0083] At 902, the client machine 104 may receive block dependency data 116 associated with a configuration of the client machine 104 from the remote system 106. This block dependency data 116 may specify individual associations between two or more blocks 124 of game data 126 of a video game.

[0084] At 904, the client machine 104 may execute a game executable file 122 of the video game to start the video game on the client machine 104. The game executable file 122 may already be available on the client machine 104 because the video game is installed on the client machine 104. The execution of the game executable file 122 allows the user 102 of the client machine 104 to begin playing the game. Furthermore, the execution of the game executable file 122 occurs in response to a user input to start the video game detected by the client machine 104. For example, the user 102 of the client machine 104 may select a user interface element of the video game client 212 to start the video game.

[0085] At 906, a determination may be made as to whether a capacity above a threshold exists in a “prefetch cache.” “Prefetch cache,” as used herein, refers to a cache allocated (or reserved) for prefetched blocks 124 of game data 126. As described herein, second memory 132(2) and / or third memory 132(3)—which provide faster read access speeds than first memory 132(1)—may provide the prefetch cache, and either or both of local memories 132(2) / (3) may be configured for any suitable amount of data, such as 100 megabytes. In this example, as much as 100 megabytes of game data 126 may be prefetched during a game session before game executable file 122 requests that the prefetched game data 126 be read. 100 megabytes is merely an example, and the prefetch cache may be configured for a lesser or greater amount of data. Thus, in block 906, the prefetch cache may be monitored to determine how full the prefetch cache is, and if the cache capacity meets or exceeds a threshold amount, additional prefetching of game data 126 may be triggered. This threshold capacity of the prefetch cache, evaluated in block 906, may be set to any suitable amount. For example, if the size of each block 124 of game data 126 is 4096 bytes, the threshold capacity may be set to a capacity of only 4096 bytes, which is enough space to prefetch the block 124 of game data 126. However, the threshold capacity may be set to a larger number of bytes / megabytes to ensure that multiple blocks 124 can be prefetched during a run through the prefetch algorithm.

[0086] In an exemplary use case, a user 102 of a client machine 104 may navigate to a library page of a game, and a set of blocks 124 of game data 126 may be prefetched to fill a 100 megabyte prefetch cache in a second memory 132(2) and / or a third memory 132(3) of the client machine 104. As the user 102 continues to play the video game, the file system 220 may receive calls associated with read operations made by the game executable file 122 to read one or more of the prefetched blocks 124. Instead of accessing the first memory 132(1) of the client machine 104 to retrieve the blocks 124, the file system 220 may access at least one of the second memory 132(2) or the third memory 132(3), where the prefetched blocks 132 are cached, such that the capacity of the prefetch cache begins to increase. If the capacity of the prefetch cache meets or exceeds a threshold, additional prefetching may be triggered to fill the prefetch cache. Thus, at block 906, if there is capacity in the prefetch cache that exceeds the threshold, process 900 may follow the “yes” route from block 906 to block 908.

[0087] At 908, logic on the client machine 104 may detect an event that is used to determine what blocks 124 of the game data 126 to prefetch. For example, at sub-block 910, the detected event may be a context cue (e.g., a user navigating to a library page of a video game). As another example, at sub-block 912, the detected event may be the file system proxy component 218 receiving a read operation made by the game executable file 122 to read a particular block 124 of the game data 126.

[0088] At 914, logic at the client machine 104 may use the block dependency data 116 to identify one or more blocks 124 of the game data 126 associated with the detected event. For example, if the event detected at block 908 is the game executable file 122 requesting to read block A of the game data 126, and if the block dependency data 116 indicates that block B is likely to be accessed by the game executable file 122 within a threshold period of time from accessing block A, the logic may identify block B at block 914.

[0089] At 916, the identified block 124 may be cached in a local memory 132 that provides faster read access speeds than the first memory 132(1) (e.g., a non-volatile memory such as an HDD, an SD card, etc.), while the game data 126 remains on the client machine 104. Thus, the identified block 124 may be cached in at least one of a second memory 132(2) (e.g., an additional non-volatile memory such as an SSD) or a third memory 132(3) (e.g., a volatile working memory such as a RAM). As indicated by sub-block 918, if multiple blocks 124 of the game data 126 were identified at 914, the blocks 124 may be cached in multiple different pre-fetch caches, such as by caching the second block 124(2) in the second memory 132(2), caching the third block 124(3) in the third memory 132(3), etc. In this manner, blocks 124 of prefetched game data 126 may be distributed across multiple prefetch caches of multiple local memory resources 132 using load balancing techniques such that some game data 126 is cached in the second memory 132(2) and an approximately equal amount of game data 126 is cached in the third memory 132(3), even though the third memory 132(3) offers faster read access speeds than the second memory 132(2). In this manner, the prefetched game data 126 may be load balanced to improve the overall throughput of the system in that game data 126 may be accessed in parallel from any and all local memory resources 132 during game play. In this load balancing scheme, it may be the case that 1% of read operations are predicted to access game data 126 from the first memory 132(1), 9% of read operations are predicted to access game data 126 from the second memory 132(2), and 90% of read operations are predicted to access game data 126 from the third memory 132(3).

[0090] At 920, the file system proxy component 218 of the client machine 104 may receive a read operation made to the file system 220 by the game executable file 122, the read operation requesting to read a particular block 124 of the game data 126 of the video game.

[0091] At 922, a determination may be made as to whether the requested block 124 (e.g., by file system 220) is cached in a prefetch cache of a local memory resource (e.g., second memory 132(2) or third memory 132(3)) that offers relatively fast read access speeds. If block 124 is cached in the prefetch cache, process 900 may follow the “yes” route from block 922 to block 924, and block 124 may be read from the prefetch cache. For example, game executable file 122 may read block 124 of game data 126 from second memory 132(2) or third memory 132(3), depending on where block 124 is cached. If block 124 is not cached in the prefetch cache, process 900 may follow the “No” route from block 922 to block 926, where block 124 may be read from the first memory 132(1), and the game data 126 may remain on the client machine 104.

[0092] At 928, a determination is made as to whether the game session of the video game should be ended. For example, if the user 102 quits the video game, process 900 may follow the “Yes” route from block 928 to block 930, and the video game client 212 may stop execution of the game executable file. In some embodiments, if the user 102 restarts the game session and the client machine 104, the game data 126 that was prefetched to the second memory 132(2) may remain stored in the prefetch cache of the second memory 132(2) upon restart if the second memory 132(2) represents additional non-volatile memory (e.g., SSD). In this way, if the user 102 initiates another game session after the restart, the blocks of game data 126 that remain cached in the second memory 132(2) can be retrieved therefrom if the blocks 124 are required by the game executable file 122 during the subsequent game session. If at block 928 the game session should not have ended (e.g., the user 102 continues to play the game), process 900 may follow the "No" route from block 928 to block 906, where the capacity of the prefetch cache is evaluated again for a portion of process 900 repeating starting from block 906. If at 906 there is no capacity in the prefetch cache above the threshold (e.g., the prefetch cache is deemed over-filled with prefetched game data 126), process 900 may follow the "No" route directly from block 906 to block 920, where the read operation is received by the file system proxy component 218 without prefetching the game data 126 in the prefetch cache.

[0093] Process 900 can reduce loading times during game execution by reducing overall latency compared to accessing game data 126 exclusively from first memory 132(1), where game data 126 remains on client machine 104. In this manner, a relatively large video game can be stored in first memory 132(1) (e.g., HDD, SD card, etc.), and yet by the time game executable file 122 requests to read block 124 of game data 126, game data 126 can be intelligently pre-fetched by caching block 124 of game data 126 in third memory 132(2) (e.g., working memory such as RAM, non-volatile memory) and / or in second memory 132(2) (e.g., SSD) in advance of when block 124 is requested by game executable file 122, so that block 124 is likely already cached in a pre-fetch cache to reduce read access times.

[0094] Although the present subject matter has been described in language specific to structural features, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features described. Rather, the specific features are disclosed as example forms of implementing the claims.

Claims

1. A client machine, one or more processors; A non-transitory computer-readable medium storing computer-executable instructions, the instructions, when executed by the one or more processors, causing the one or more processors to: executing a game executable file of the video game to play the video game on the client machine; determining a first read operation and a second read operation performed by the game executable file to a file system of the client machine, the first read operation requesting to read a first block of game data of the video game and the second read operation requesting to read a second block of game data; generating access data based at least in part on the first read operation and the second read operation, the access data comprising: A first identifier for the first block of game data; a first time during execution of the game executable file at which the first block of the game data was accessed based at least in part on the first read operation; a second identifier for the second block of game data; and generating a second time during the execution of the game executable file at which the second block of the game data was accessed based at least in part on the second read operation; and a non-transitory computer readable medium that causes a remote system to transmit the access data, an identifier of the video game, and a configuration of the client machine.

2. The client machine of claim 1 , wherein the configuration of the client machine specifies a type, version, or characteristics of hardware, software, or firmware associated with the client machine.

3. and a non-volatile memory, wherein the video game is a first video game, the game executable file is a first game executable file of the first video game, and the game data is first game data of the first video game, and the computer-executable instructions, when executed by the one or more processors, cause the one or more processors to: sending a request to the remote system to obtain a second video game, the request including the configuration of the client machine; From the remote system, a second game executable file for the second video game; and receiving download sequence data associated with the configuration of the client machine, the download sequence data specifying a sequence of blocks of second game data of the second video game; initiating downloading of the blocks of the second game data into the non-volatile memory according to the sequence specified in the download sequence data; 2. The client machine of claim 1, further comprising: executing said second game execution file for playing said second video game on said client machine.

4. The computer-executable instructions, when executed by the one or more processors, cause the one or more processors to: receiving a third read operation performed by the second game executable file to the file system, the third read operation requesting to read a block of the second game data; determining that the block of the second game data has been downloaded to the non-volatile memory; 4. The client machine of claim 3, further comprising: reading said block of said second game data using said file system.

5. The computer-executable instructions, when executed by the one or more processors, cause the one or more processors to: receiving a third read operation performed by the second game executable file to the file system, the third read operation requesting to read a block of the second game data; determining that the download of the block of the second game data to the non-volatile memory is not complete; sending a second request for the block of the second game data to the remote system; receiving the block of the second game data from the remote system; 4. The client machine of claim 3, further comprising: reading said block of said second game data using said file system.

6. a non-volatile memory configured to store the game data, the plurality of first blocks of game data including at least the first block of game data and the second block of game data, and the computer-executable instructions, when executed by the one or more processors, cause the one or more processors to: receiving instructions from the remote system to delete one or more second blocks of the game data from the non-volatile memory, the one or more second blocks of the game data representing unused blocks of the game data that have not been accessed by the game executable file on the client machine for a threshold period of time or a threshold number of game sessions; 2. The client machine of claim 1, further comprising: deleting the one or more second blocks of the game data from the non-volatile memory.

7. a first memory configured to provide read access at a first rate, the first memory storing the game data; a second memory configured to provide read access at a second rate that is faster than the first rate; The computer-executable instructions, when executed by the one or more processors, cause the one or more processors to: receiving, from the remote system, block dependency data associated with the configuration of the client machine, the block dependency data specifying individual associations between two or more blocks of the game data; Detecting an event; and caching in the second memory at least one of the first block of game data or the second block of game data that is specified in the block dependency data as being associated with the event; receiving at least one of the first read operation or the second read operation; 2. The client machine of claim 1, further comprising: reading at least one of the first block of game data or the second block of game data from the second memory.

8. a first non-volatile memory configured to provide read access at a first rate, the first non-volatile memory storing the game data; a second non-volatile memory configured to provide read access at a second rate that is faster than the first rate; a volatile memory configured to provide read access at a third rate that is faster than the second rate; The computer-executable instructions, when executed by the one or more processors, cause the one or more processors to: receiving, from the remote system, block dependency data associated with the configuration of the client machine, the block dependency data specifying individual associations between two or more blocks of the game data; Detecting an event; and caching in the second non-volatile memory the first block of the game data that is specified in the block dependency data as being associated with the event; caching in the volatile memory the second block of the game data that is specified in the block dependency data as being associated with the event; receiving the first read operation; reading the first block of the game data from the second non-volatile memory; receiving the second read operation; and 2. The client machine of claim 1, further comprising: reading the second block of the game data from the volatile memory.

9. 1. A method comprising: executing, by a processor of a client machine, a game executable file of the video game for playing the video game on the client machine; determining, by the processor, a first read operation and a second read operation performed by the game executable file to a file system of the client machine, the first read operation requesting to read a first block of game data of the video game and the second read operation requesting to read a second block of game data; generating, by the processor, access data based at least in part on the first read operation and the second read operation, the access data comprising: A first identifier for the first block of game data; a first time during execution of the game executable file at which the first block of the game data was accessed based at least in part on the first read operation; a second identifier for the second block of game data; and generating a second time during the execution of the game executable file at which the second block of the game data was accessed based at least in part on the second read operation; transmitting to a remote system the access data, an identifier of the video game, and a configuration of the client machine.

10. The plurality of first blocks of game data includes at least the first block of game data and the second block of game data, and the method further comprises: receiving instructions from the remote system to delete one or more second blocks of the game data from a non-volatile memory of the client machine, the one or more second blocks of the game data representing unused blocks of the game data that have not been accessed by the game executable file on the client machine for a threshold period of time or a threshold number of game sessions; 10. The method of claim 9, further comprising deleting the one or more second blocks of the game data from the non-volatile memory.

11. the video game is a first video game, the game execution file is a first game execution file of the first video game, the game data is first game data of the first video game, and the method comprises: sending a request to the remote system to obtain a second video game, the request including the configuration of the client machine; From the remote system, a second game executable file for the second video game; and receiving download sequence data associated with the configuration of the client machine, the download sequence data specifying a sequence of blocks of second game data of the second video game; commencing downloading of the blocks of the second game data into a non-volatile memory of the client machine according to the sequence specified in the download sequence data; 10. The method of claim 9, further comprising executing, by the processor, the second game executable file for playing the second video game on the client machine.

12. receiving, by the processor, a third read operation performed by the second game executable file to the file system, the third read operation requesting to read a block of the second game data; determining that the block of the second game data has been downloaded to the non-volatile memory; The method of claim 11 , further comprising: reading, by the processor, the block of the second game data using the file system.

13. receiving, by the processor, a third read operation performed by the second game executable file to the file system, the third read operation requesting to read a block of the second game data; determining that the block of the second game data has not completed downloading to the non-volatile memory; sending a second request for the block of the second game data to the remote system; receiving the block of the second game data from the remote system; The method of claim 11 , further comprising: reading, by the processor, the block of the second game data using the file system.

14. The game data is stored in a first memory of the client machine, the first memory configured to provide read access at a first rate, the method comprising: receiving, from the remote system, block dependency data associated with the configuration of the client machine, the block dependency data specifying individual associations between two or more blocks of the game data; Detecting, by the processor, an event; caching at least one of the first block of game data or the second block of game data, which is specified in the block dependency data as being associated with the event, in a second memory of the client machine configured to provide read access at a second rate faster than the first rate; receiving, by the processor, at least one of the first read operation or the second read operation; 10. The method of claim 9, further comprising reading, by the processor, at least one of the first block of game data or the second block of game data from the second memory.

15. 15. The method of claim 14, wherein the detecting the event includes detecting that the game executable file has requested to read the first block of the game data, and wherein the caching includes caching the second block of the game data in the second memory based at least in part on the block dependency data that specifies the second block of the game data as being associated with the first block of the game data.

16. 1. A method comprising: receiving, by a remote system, access data associated with a video game from a plurality of client machines having a common client system configuration, the access data including, for each of the plurality of client machines, at least a first identifier for a first block of game data of the video game accessed by the game executable file of the video game during execution of the game executable file on a respective client machine; a first time during the execution of the game executable file on the respective client machine that the first block of game data was accessed by the game executable file; a second identifier for a second block of the game data accessed by the game executable file during the execution of the game executable file on the respective client machine; and receiving, specifying a second time during the execution of the game executable file on the respective client machine at which the second block of game data was accessed by the game executable file; analyzing said access data; generating data by a processor of the remote system and based at least in part on the analyzing the access data, the data comprising: download sequence data that specifies the sequence in which at least the first block of game data and the second block of game data are downloaded to a client machine having the client system configuration; or generating at least one of block dependency data specifying an association between the first block of game data and the second block of game data, or an association between the first block of game data or the second block of game data and an event; transmitting, by the remote system, the data to one or more client machines having the client system configuration.

17. the data includes the download sequence data, and the method further comprises: receiving a request by the remote system and from a client machine having the client system configuration to obtain the video game; transmitting, by the remote system, the game executable file of the video game to the client machine; 17. The method of claim 16, further comprising downloading to the client machine at least the first block of game data and the second block of game data according to the sequence specified in the download sequence data.

18. the data includes the download sequence data, and analyzing the access data includes: calculating a first statistic associated with the first block of game data and a second statistic associated with the second block of game data; and determining the sequence based at least in part on the first statistic and the second statistic.

19. the data includes the block dependency data, and analyzing the access data comprises: determining an association between the first block of game data and the second block of game data; or 20. The method of claim 16, comprising at least one of: determining an association between a contextual cue and at least one of the first block of game data or the second block of game data.

20. determining, based at least in part on the access data received from one of the plurality of client machines, that one or more blocks of the game data have not been accessed by the game executable file on one of the plurality of client machines for a threshold time period or a threshold number of game sessions; 17. The method of claim 16, further comprising: transmitting, by the remote system, instructions to one of the plurality of client machines to delete the one or more blocks of the game data from non-volatile memory of the one of the plurality of client machines.

Images