U.S. Pat. No. 11,123,634

DETAILED DESCRIPTION

A video game distribution platform may allow users to acquire video games, download digital copies of the video games to their respective client machines, and execute the video games using an installed client application. As the users play a video game on their client machines, game executables of the video game running on each client machine may continually request to read blocks of game data for the video game using the files systems of the client machines. A “game executable,” as used herein, means executable code (e.g., one or more executable files) of a video game that, when executed, allow a user to play the video game on a client machine by rendering frames based on user input provided via an input device(s) of the client machine. “Game data,” as used herein, means data that is read by the game executable during execution of the game executable for the video game over a series of frames. Game data can be used for, among other things, rendering the graphics for the video game, computing gameplay logic, and/or computing the physics for the video game. Examples of game data include, without limitation, textures, virtual objects, maps, game characters, parameters and other features of virtual objects and/or a virtual game world, etc. Such game data can be stored in memory by partitioning the game data into a number of blocks (e.g., uniformly-sized blocks), and a file system of a client machine is configured to control how these blocks of game data are stored and retrieved in and from local memory of the client machine. As a video game is played on a client machine, each request, made by the game executable(s) of the video game, to read a block(s) of game data is referred to herein as a “read operation.” Accordingly, a game executable of a video game can make a series of read operations to the file system throughout a game session.

The techniques, devices, and systems described herein pertain to using a file system proxy component of a client machine to track read operations made by a game executable of a video game during a game session, to generate access data based on the tracked read operations, and to report the access data to a remote system. An example process to be implemented by a client machine may include executing a game executable of a video game for playing the video game on the client machine, determining read operations made by the game executable to a file system of the client machine, generating access data based at least in part on the read operations, and sending, to a remote system, the access data, an identifier of the video game, and a configuration of the client machine. The read operations made by the game executable may request to read blocks of game data for the video game. Accordingly, the access data generated by the client machine may specify: (i) identifiers of the blocks of the game data that were accessed during the game session, and (ii) times, during execution of the game executable, at which the blocks of the game data were accessed based at least in part on the read operations.

This telemetry approach allows the remote system to collect access data reported by multiple client machines, to catalogue the access data according to client system configuration, and to analyze the access data to generate data that is usable by client machines to implement various game-related features including, without limitation, “instant play” of video games, discarding of unused blocks of game data to free up local memory resources, and/or local prefetching of game data for reducing latency during gameplay. An example process to be implemented by a remote system may include receiving, from multiple client machines having a client system configuration in common, access data associated a video game, analyzing the access data, generating data based at least in part on the analyzing of the access data, and sending the data to one or more client machines having the client system configuration. The access data received by the remote system may specify, for individual ones of the client machines: (i) identifiers of blocks of game data for the video game that were accessed by a game executable of the video game during execution of the game executable on an individual client machine, and (ii) times, during the execution of the game executable, at which the blocks of the game data were accessed by the game executable. Furthermore, the data generated by the remote system based at least in part on the analyzing of the access data may comprise at least one of: (i) download-sequence data specifying a sequence in which at least some of the blocks of the game data are to be downloaded to client machines having the client system configuration, or (ii) block-dependency data specifying individual associations between two or more blocks of the game data.

As mentioned, one example 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 start playing the video game upon acquiring the video game, and before game data is finished downloading to the user's client machine. Accordingly, a user does not have to wait for a video game to finish downloading before starting a game session of the video game. To enable the instant play feature, a remote system may receive, from multiple client machines, access data (as described herein) relating to a particular video game, and the remote system may generate, based on the access data, download-sequence data that specifies a sequence of blocks of game data for the video game. This sequence may position the blocks that are more likely to be accessed first towards the start of the sequence, and the blocks that are less likely to be accessed first towards the end of the sequence. In this manner, as the blocks of game data start downloading to the client machine, the blocks of game data that are most likely to be accessed early during the game session are stored in non-volatile memory of the client machine before downloading other blocks of game data that are less likely to be accessed early during the game session. This allows a user can start playing the video game upon acquiring the video game, even while blocks of game data are still being downloaded to non-volatile memory of the client machine. In fact, the techniques and systems described herein allow a user to start playing a video game even before a first block of game data is finished downloading to the client machine of the user. This is at least partly enabled by use of the file system proxy component on the client machine, which is configured to receive read operations made by the game executable, and to determine whether a requested block of game data has been downloaded to non-volatile memory or if the block still needs to finish downloading. If the block is “realized” in non-volatile memory, meaning that the block of game data has finished downloading to the non-volatile memory, the game executable can read the block of game data using the file system. If the block happens to have not finished downloading to non-volatile memory, the file system proxy component may intercept the read operation, request the unrealized block of game data from the remote system, and, once the block is received from the remote system, the block can be read using the file system. Although there may be a brief pause in the execution of the video game while an unrealized block of game data is retrieved from the remote system, the chances of this occurring frequently, or at all, are low assuming that the downloading of game data begins upon acquiring 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 accesses the blocks of data during the game session.

Another example game-related feature that can be enabled is freeing up local memory resources on a client machine by discarding unused blocks of game data. By freeing up local memory resources, the client machine can reclaim valuable storage capacity, which can be utilized for game data of other video games, and/or other data in general. To enable client-side discarding of game data, a client machine—with game data of a video game stored in non-volatile memory—may execute a game executable of the video game, and may generate access data over one or more game sessions as read operations are made by the game executable to a file system of the client machine. This access data may specify a first subset of blocks of the game data that were accessed over the course of one or more game sessions, as well as times at which those blocks were accessed during the game session(s). A remote system may receive the access data from the client machine, and the remote system may determine, based on the access data, one or more second blocks of the game data that can be classified as “unused” blocks based on the blocks having not been accessed by the game executable on the client machine for at least a threshold period of time 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 the one or more second blocks of the game data from non-volatile memory. When the client machine deletes these unused blocks from non-volatile memory, storage capacity on the client machine can be increased. Furthermore, if the game executable were to request to read a block of game data that has been deleted, the file system proxy component of the client machine can request the block of game data from the remote system in an on-demand fashion, with some added latency as compared to having the block stored on local memory.

Another example game-related feature that can be enabled is local prefetching of blocks of game data to decrease latency when loading the game data during a game session. To enable the local prefetching feature, a remote system may receive, from multiple client machines, access data (as described herein) relating to a particular video game, and the remote system may generate, based on the access data, block-dependency data that specifies individual associations between two or more blocks of the game 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 is typically accessed within a threshold time period. In this manner, the block-dependency data may describe inter-block relationships between sets of two or more blocks based on access patterns that are exhibited in the access data received at the remote system. The remote system can send the block-dependency data to a client machine with the video game installed thereon, and when the client machine executes a game executable of the video game, the client machine can prefetch blocks of game data by caching the blocks in local memory that provides a faster read access speed than the memory on which the game data is persistently stored (e.g., non-volatile memory, such as a HDD, a SD card, etc.). This local prefetching can reduce the latency in load times when the game executable requests to read blocks of game data.

The techniques and systems described herein may improve the gameplay functionality of a client machine without having to change the way that game developers make video games today. For example, implementing a client-side component, such as the file system proxy component described herein, allows a user of the client machine to play a video game upon acquiring the video game, which means that the user does not have to wait (potentially hours) for the game to download before starting a game session. It also allows game data to be downloaded intelligently in a sequence of blocks that positions those blocks most likely to be accessed first at the start of the sequence, which helps to reduce latency during gameplay while the download of game data is in-progress. The gameplay functionality of a client machine may additionally, or alternatively, be improved by prefetching game data during game session in accordance with block-dependency data. This is because the client machine is able to predict which blocks of game data are likely to be accessed next in a series of read operations made by the game executable of the video game, and those blocks can be cached in local memory that provides faster read access speed (e.g., volatile memory, such as Random Access Memory (RAM)) than the non-volatile memory on which the game data is persisted. This “primes” the game data for quick access when the video game requests the game data.

The techniques and systems described herein may additionally, or alternatively, allow 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 the unused blocks of game data can free up local memory resources on the client machine. For example, if a client machine, and/or the remote system, determines, from access data pertaining to tracked file system read operations, that a user never plays a game in single player mode, and always plays the game in multi-player mode, the single-player game data for the video game can be deleted from non-volatile memory of the client machine based on a determination that those blocks have not been used for at least a threshold period of time or a threshold number of game sessions.

FIG. 1is a diagram illustrating an example environment100that includes a video game distribution platform configured to implement the techniques described herein. Users102(sometimes referred to as “customers”) of a community may be associated with one or more client machines104. Accordingly, the client machines104(1)-(N) shown inFIG. 1represent computing devices that can be utilized by a user community (or customer base) to execute programs thereon, such as video games. The client machines104can be implemented as any suitable type of computing device configured to process and render graphics on an associated display and to send/receive data over a network(s), including, without limitation, a PC, a desktop computer, a laptop computer, a mobile phone (e.g., a smart phone), a tablet computer, a portable digital assistant (PDA), a wearable computer (e.g., virtual reality (VR) headset, augmented reality (AR) headset, smart glasses, etc.), an in-vehicle (e.g., in-car) computer, a television (smart television), a set-top-box (STB), a game console, and/or any similar computing device.

The configurations of the client machines104may vary. For example, a subset of the client machines104may each use particular types, versions, or characteristics of hardware (e.g., central processing unit (CPU) model, graphics processing unit (GPU) model, etc.), and/or particular types, versions, or characteristics of firmware and/or software (e.g., a version of a graphics driver, downloadable content (DLC) package used for an install script, a language in which a video game client is running, etc.). These and other aspects of hardware, firmware, and/or software of the client machine104constitute a “configuration” of the client machine104, as used herein, which is sometimes referred to as a “client system configuration,” and they may dictate a finite set of depots that are used to download game data (partitioned into blocks of data) for a video game on the video game distribution platform. Accordingly, subsets of the client machines104may share a common client system configuration, and client system configurations may differ between these subsets of client machines104. Client machines104that differ in terms of their client system configurations may download, store, and/or access blocks of game data differently, even for the same video game. Determining whether a pair of client machines104have a client system configuration in common may be based on the machines104sharing a threshold number of common types, versions, or characteristics of hardware, software, or firmware. For example, if two client machines104at least use the same DLC package for an install script, they may be considered to have the same client system configuration, notwithstanding some differences in other aspects (e.g., different GPU models, etc.).

With reference again toFIG. 1, the client machines104may communicate with a remote computing system106(sometimes shortened to “remote system106”) over a computer network108. The computer network108may represent and/or include, without limitation, the Internet, other types of data and/or voice networks, a wired infrastructure (e.g., coaxial cable, fiber optic cable, etc.), a wireless infrastructure (e.g., radio frequencies (RF), cellular, satellite, etc.), and/or other connection technologies. The remote system106may, in some instances be part of a network-accessible computing platform that is maintained and accessible via the computer network108. Network-accessible computing platforms such as this may be referred to using terms such as “on-demand computing”, “software as a service (SaaS)”, “platform computing”, “network-accessible platform”, “cloud services”, “data centers”, and so forth. In general, the remote system106is configured to collect access data110from the client machines104, and is configured to catalogue (e.g., organize, categorize, classify, etc.) the access data110it receives within a data store112. The remote system106may also be configured to analyze the access data110to generate data that is usable by the client machines104for implementing the various game-related features described herein. For example, the remote system106may be configured to generate download-sequence data114and/or block-dependency data116, and the remote system106can distribute this data to client machines104, as described herein. The remote system106may additionally, or alternatively, be configured to analyze the access data110to determine unused blocks of game data on one or more client machines104, and may send, to the client machine(s)104, instructions118to delete the unused blocks of game data in order to free up local memory resources on the client machine(s)104.

In some embodiments, the remote system106acts as, or has access to, a distribution service to distribute (e.g., download) programs (and data) to the client machines104. In an example, the client machines104may install a client application thereon. The client application, which may be a video game client (e.g., gaming software to play video games), may be configured to execute programs, such as video games, on the client machine104on which the client application is installed. With the client application installed, a client machine104may then have the ability to download programs (e.g., video games) from the remote system106over the computer network108. Any type of content-distribution model can be utilized for this purpose, such as a direct purchase model where programs (e.g., video games) are individually purchasable for download and execution on a client machine104, a subscription-based model, a content-distribution model where programs are rented or leased for a period of time, and so on. Accordingly, an individual client machine104may include one or more installed video games that are executable by loading the client application, and these video games may render graphics on a display during execution. In an example, a user102may choose to play one of multiple video games they have acquired (e.g., purchased, rented, leased, etc.) and downloaded from the remote system106, such as by loading the video game client and selecting the desired video game to start execution of the video game.

Consider an example ofFIG. 1where some of the users102play a video game that is made available to those users102by the remote system106. As the video game is played on respective client machines104of the users102, game executables running on each client machine104may continually request a file system to read blocks of game data for the video game. The read operations made by a game executable may be tracked by a file system proxy component of the client machine104to generate access data110. For example, a game executable running on a client machine104(1) can issue requests to the file system of the client machine104(1) during game execution to read blocks of game data from one or more local memory resources of the client machine104(1), 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 the client machine104(1). Accordingly, a game executable for the video game executing on a client machine104(1) can make a series of read operations to the file system throughout a game session, and the file system proxy component of the client machine104(1) may track the read operations to generate access data110.

The access data110may specify: (i) block identifiers that identify accessed blocks of the game data for a video game (e.g., the blocks that were accessed by the game executable during a game session), as well as (ii) times, during execution of the game executable, at which the accessed blocks of the game data were accessed by virtue of the game executable making the read operations. As mentioned, game data for a video game may comprise textures, virtual objects, maps, game characters, and the like. In some embodiments, the game data may be stored across sectors of non-volatile memory (e.g., sectors of a HDD, SD card, etc.) and organized in blocks of game data within the sectors. Using blocks is a flexible way of handling files of varying sizes while avoiding the need to store every file using contiguous storage space in the 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 machine104may perform read, write, and/or other storage operations as directed by one or more device drivers. In some embodiments, the client machine104may create a mapping between blocks of game data and sectors of non-volatile memory in order to determine which blocks were accessed and where (e.g., what sectors) they were accessed from, based on the read operations made by the game executable during gameplay. For example, if the game executable makes a read operation to access game data stored in a first sector of non-volatile memory, an identifier(s) of the particular block(s) of game data that is/are stored in the first sector may be specified in the access data110. Moreover, the access times specified in the access data110may allow for determining an 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, and so on and so forth), as well as 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.).

The access data110received by the remote system106may be catalogued in the data store112according to a unique client system configuration, and/or according to the video game ID of the corresponding video game. The access data110may additionally be stored in association with a user account of a user who is logged into a video game client executing on the client machine104that sent the access data110.FIG. 1shows a data store112maintained by the remote system106for storing, cataloguing, or otherwise organizing, the access data110it receives from the client machines104. The data store112may organize the access data110into groups (or buckets) that are each associated with a unique combination of client system configuration and video game ID. In other words, each bucket of access data110in the data store112may be tied to a particular program (e.g., video game) and to a particular client system configuration, as described herein.

FIG. 1shows a client machine104(N) sending a request120to acquire (e.g., purchase, rent, lease, etc.) a video game from the remote system106. For example, a user of the client machine104(N) who is logged into his/her user account via an installed video game client, may conduct a transaction via the remote system106to purchase the video game. In response to the request120, the client machine104(N) may receive, from the remote system106, a game executable122of the video game, and the client machine104may also receive download-sequence data114and/or block-dependency data116for the acquired video game and for the specific client system configuration of the client machine104. Accordingly, it is to be appreciated that the request120may include the configuration of the client machine104(N), which tells the remote system106to look for download-sequence data114and block-dependency data116that may be available for that particular client system configuration.

FIG. 1also depicts the remote system106starting to download blocks124of game data126for the acquired video game in accordance with a sequence of blocks specified in the download-sequence data114.FIG. 1shows an example where a first block124(1) is downloaded, followed by a second block124(2), which is followed by a third block124(3), and so on and so forth. Although three blocks124are depicted inFIG. 1as being downloaded to the client machine104(N), it is to be appreciated that the download sequence may include any number of blocks124, including additional blocks that are downloaded after block124(3). The client machine104(N) may download the blocks124to non-volatile memory of the client machine104(N), such as to a HDD, a SD card, or the like.

As shown inFIG. 1, the client machine104(N) may implement an instant play128feature where the client machine104(N) may start executing the game executable122for the acquired video game before or during the download of the blocks124of game data126. For example, the client machine104(N) may start executing the game executable122before the first block124(1) of game data is even downloaded. The game executable122may start in response to user input received by the client machine104(N), such as a user102providing a user using a mouse and/or keyboard, a game controller, etc., to launch the newly acquired video game. In this sense, there may be no restrictions placed upon the user102as to when the user102can start playing the video game. As a consequence, the user102may start playing the game, and the game executable122may start executing before the first block124(1) of game data is downloaded to the client machine104(N). If the user102chooses to wait a period of time after acquiring the video game, the game executable122may start executing after at least one block124(1) of game data126has been downloaded to the client machine104(N).

In some embodiments, a video game client running on the client machine104(N) may be configured to prevent the game executable122from starting until a predetermined time has lapsed since starting the download of blocks124, or until a predetermined event occurs (e.g., by waiting until a threshold number of blocks124have been downloaded before allowing the user102to start playing the game). The predetermined time or event may be determined by the remote system106based on how well-suited the video game is for the instant play128feature, and the remote system106may send instructions to the video game client upon acquisition of the video game to wait for the predetermined period of time to lapse and/or to wait for the occurrence of the predetermined event before allowing the game executable122to run on the client machine104(N). In some embodiments, the remote system106may send data to the client machine104(N) for outputting a recommendation to the user102via the client machine104(N), such as by displaying a recommendation that states “For the best user experience, we recommend waiting 5 minutes after starting the download to play [Video Game X]”. In one example, if the video game is well-suited for the instant play128feature, the remote system106may instruct the client machine104(N) to output a notification that states “This game is ready for instant play, so you can start playing right now. Enjoy!”.

As shown inFIG. 1, another client machine104(2) may implement a local prefetching130feature where the client machine104(2) may prefetch one or more realized block124of game data126to reduce latency during gameplay. For example, game data126for a video game may be stored in first memory132(1) that provides read access at a first speed. This first memory132(1) may represent non-volatile memory, such as a HDD, SD card, etc., where the game data126is persisted. The client machine104(2) may also include second memory132(2) that provides read access at a second speed faster than the first speed. This second memory132(2) might be additional non-volatile memory (e.g., a SSD), or it may be volatile memory (e.g., working memory, such as RAM). In any case, the block-dependency data116can be used by the client machine104(2) to determine whether a block(s)124is likely to be read next by the game executable122, and if so, the block(s)124can be cached in the second memory132(2) so that, when the game executable122eventually requests to read the block(s)124, the block(s)124can be quickly accessed from the second memory132(2), rather than accessing the block(s)124from the relatively slower first memory132(1). As will be described in more detail below, multiple different local memory resources132can be utilized to cache blocks124of game data126as part of the local prefetching130feature, which can improve the overall bandwidth and reduce latency even more than caching blocks124exclusively in, say, working memory. This is based on the notion that the game executable122can read from the different local storage resources132, including the first memory132(1), in parallel to improve the overall bandwidth and reduce latency by an even greater amount.

As shown inFIG. 1, yet another client machine104(1) may implement a delete unused game data134feature where the client machine104(1) receives an instruction118from the remote system106to delete one or more blocks124of game data126stored in non-volatile memory of the client machine104(1), and, in response, the client machine104(1) can delete the one or more blocks124to free up local memory on the client machine104(1). For example, the remote system106may determine, from the access data110received from the client machine104(1), that the user102of the client machine104(1) has never played a single-player mode of a video game, and, as a consequence, the blocks124of game data126for the video game that are usable to play the video game in the single-player mode have not been accessed by the game executable122for a threshold period of time or a threshold number of game sessions. Accordingly, the remote system106may send instructions118to one or more client machines104, such as the client machine104(1), instructing the client machine(s)104to delete, from non-volatile memory thereon, one or more unused blocks124of the game data126that were previously downloaded to the client machine(s)104and determined to be classifiable as “unused” blocks124. The instructions118may specify identifiers of the unused blocks124so that the client machine104(1) can delete the correct blocks124of game data126, thereby freeing up local memory capacity without compromising the user experience of playing the game on the client machine104(1).

FIG. 2shows a block diagram illustrating example components of a client machine104and a flow diagram of an example process200for tracking file system read operations to generate access data110, and for sending the access data110to a remote system106. In the illustrated implementation, the client machine104includes, among other components, one or more processors202, such as a central processing unit(s) (CPU), a graphics processing unit(s) (GPU), etc., one or more input devices204, one or more output devices206, non-transitory computer-readable media208, local memory132, and a communications interface(s)210.

The non-transitory computer-readable media208may include volatile and nonvolatile memory, removable and non-removable media implemented in any method or technology for storage of information, such as computer-readable instructions, data structures, program modules, or other logic and/or data. Such memory includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, RAID storage systems, or any other medium which can be used to store the desired information and which can be accessed by a computing device. The computer-readable media208may be implemented as computer-readable storage media (“CRSM”), which may be any available physical media accessible by the processor(s)202to execute instructions stored on the computer-readable media208. In one basic implementation, CRSM may include random access memory (“RAM”) and Flash memory. In other implementations, CRSM may include, but is not limited to, read-only memory (“ROM”), electrically erasable programmable read-only memory (“EEPROM”), or any other tangible medium which can be used to store the desired information and which can be accessed by the processor(s)202. Furthermore, although the local memory132is shown as being separate from the computer-readable media208, it is to be appreciated that the computer-readable media208and any one or more of the local memories132(1),132(2), and/or132(3) may represent the same memory, or at least portions of the same memory, in some implementations.

Reference is now made to the process200shown inFIG. 2. The processes described herein are illustrated as a collection of blocks in a logical flow graph, which represent a sequence of operations that can be implemented in hardware, software, firmware, or a combination thereof (sometimes referred to as “logic” herein). 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, and the like 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 number of the described blocks can be combined in any order and/or in parallel to implement the processes.

For discussion purposes, it is assumed that the client machine104performing the process200has previously installed a video game client212, which represents a client application that is stored in the computer-readable media208and is configured to execute a game executable122for a video game. A user102of the client machine104may acquire (e.g., purchase, rent, lease, etc.) video games, which, upon acquisition, may be installed (e.g., downloaded from the remote system106) and maintained non-volatile memory. In some embodiments, the first local memory132(1) (sometimes referred to as “first memory132(1)”) may represent non-volatile memory (e.g., a HDD, SD card, etc.), and the first memory132(1) may provide read access at a first speed. When blocks124of game data126are downloaded from the remote system106, the blocks124of game data126may be downloaded to the first memory132(1). Meanwhile, the second memory132(2) may represent additional non-volatile memory (e.g., a solid-state drive (SSD)), and the second memory132(2) may provide read access at a second speed faster than the first speed provided by the first memory132(1). Additionally, the third memory132(3) may represent volatile memory (e.g., working memory, such as RAM), and the third memory1320(3) may provide read access at a third speed faster than the second speed. It is to be appreciated that the client machine104may implement fewer local memory132resources than those shown inFIG. 2(e.g., by omitting the second memory132(2)), or additional local memory132resources.

At214, the video game client212may execute a game executable122of a video game on the client machine104. For example, a user102of the client machine104may load the video game client212, and the loaded video game client212may provide the user102with the ability to execute a previously downloaded video game (via execution of the game executable122), and/or acquire a new video game from the remote system106. The game executable122may be loaded into working memory, such as the third memory132(3) where it executes to, among other things, render graphics on the display of the client machine104. There may be a startup phase and a playtime phase during a game session. During a game session, the game executable122may be configured to receive input data from the input device(s)204(e.g., a mouse and/or keyboard, game controller(s), head-mounted display (HMD), microphone(s), etc.), and may determine blocks124of game data126to access for rendering a next frame of video game content on a display(s) (i.e., an output device(s)206) of the client machine104. For example, the game executable122may be configured to determine which portions of the game world to render in an upcoming frame, as well as which objects and/or textures to render in the upcoming frame, and may issue read operations to read the corresponding blocks124of game data126for presenting the upcoming frame.

At216, a file system proxy component218executing on the client machine104may determine (e.g., receive, monitor, intercept, etc.) read operations (e.g., a first read operation, a second read operation, etc.) made by the game executable122to a file system220of the client machine104. The file system220may be configured to control how data, including blocks124of game data126for the video game, is stored and retrieved. Whether all of the game data126for the video game is realized in a local memory resource, such as the first memory132(1) or not, the file system proxy component218may be configured to “lie” to the video game about what blocks124(e.g., files) of game data126exist on non-volatile memory of the client machine104(e.g., on the HDD, SD card, etc.). For example, the video game client212, via the file system proxy component218, may know, based on the identifier of the video game, the 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 where the game files are to be stored. This makes the video game (e.g., the game executable122) think that all blocks124of the game data126for the video game are stored in the first memory132(1), for example. The file system proxy component218may be an extension of the file system220in order to fabricate this information, if necessary, and surface it to the game executable122. In any case, consider an example where all blocks124of the game data126for the video game are stored in, and accessible from, the first memory132(1) of the client machine104. In this example, the file system proxy component218may act as a pass-through that merely monitors the read operations made by the game executable122to the file system220. As described in more detail herein, particular blocks124of game data126may be prefetched from the first memory132(1) and cached in at least one of the second memory132(2) or the third memory132(3), both of which provide faster read access speed than the read access speed provided by the first memory132(1). The file system220can keep track of where blocks124of game data126are stored at any given moment and may access the blocks124of game data126from the appropriate memory resources132to serve the read operations made by the game executable122during a game session.

At222, the file system proxy component218may generate access data110based at least in part on the read operations it receives from the game executable122. As described elsewhere herein, this access data110may specify: (i) identifiers of the blocks124of the game data126that were accessed by the game executable122during the game session, and (ii) times, during the execution of the game executable122, at which the accessed blocks124of the game data126were accessed by the game executable122. For example, with respect to two blocks124of game data126, the access data110may specify: (i) a first identifier of the first block of the game data, (ii) a first time, during execution of the game executable, at which the first block of the game data was accessed based at least in part on the first read operation, (iii) a second identifier of the second block of the game data, and (iv) a second time, during the execution of the game executable, at which the second block of the game data was accessed based at least in part on the second read operation. In some embodiments, the access time for each accessed block124may be expressed in the access data110as a time that is measured from a start of the game session (e.g., Block A was accessed 4 minutes after starting the game session, Block D was accessed 13 minutes after starting the game session, etc.).

At224, the client machine104may send the access data110to a remote system106, such as via the communications interface(s)210and over a computer network108. The communication interface(s)210may implement multiple types of wired and/or wireless or radio technologies. For example, the communication interface(s)210may implement a radio such as a Bluetooth Low Energy (BLE) radio, a Wi-Fi radio, and/or a cellular radio, and so on. It is to be appreciated that the communication interface(s)210may further include physical ports to facilitate a wired connection to a network, a connected peripheral device, or a plug-in network device that communicates with other wireless networks.

As shown in the sub-block226, the access data110may be sent at224along with a configuration of the client machine104and an identifier of the video game. Furthermore, the access data110may be sent at any suitable time(s) to the remote system106, such as in real-time, or substantially real-time, by streaming the access data110to the remote system106as the access data110is generated, and/or in response to events (e.g., periodically, during idle times where processing resource consumption is relatively low, such as below a threshold percentage of resource consumption, when network connectivity resumes (e.g., after playing the game offline), after the client machine104stops execution of the game executable122(e.g., after the user102ends the game session by exiting the video game), etc.). The access data110can also be sent in any suitable format for transmitting metadata resulting from the tracked read operations on the client machines104, such as by sending the access data110to the remote system106as artifacts. The process200represents a “telemetry” approach for collecting access data110at the remote system106. Considering that a large number of client machines104may be performing the process200, the remote system106may collect the access data110that is sent (e.g., uploaded, reported, etc.) at block224from a vast number of client machines104having different client system configurations.

FIG. 3shows a block diagram illustrating example components of a remote system106and a flow diagram of an example process300for receiving access data110from client machines104, and for analyzing the access data110across one or more users102for implementing the techniques described herein. In the illustrated implementation, the remote system106includes, among other components, one or more processors302, memory304(or non-transitory computer-readable media304), and a communications interface(s)306. The memory304(or non-transitory computer-readable media304) may include volatile and nonvolatile memory, removable and non-removable media implemented in any method or technology for storage of information, such as computer-readable instructions, data structures, program modules, or other data. Such memory includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, RAID storage systems, or any other medium which can be used to store the desired information and which can be accessed by a computing device. The computer-readable media304may be implemented as computer-readable storage media (“CRSM”), which may be any available physical media accessible by the processor(s)302to execute instructions stored on the memory304. In one basic implementation, CRSM may include random access memory (“RAM”) and Flash memory. In other implementations, CRSM may include, but is not limited to, read-only memory (“ROM”), electrically erasable programmable read-only memory (“EEPROM”), or any other tangible medium which can be used to store the desired information and which can be accessed by the processor(s)302. A download sequence component308, a block-dependency component310, and/or a game data usage component312may represent instructions stored in the memory304that, when executed by the processor(s)302, cause the remote system106to perform the techniques and operations described herein. For example, the download sequence component308may be configured to generate download-sequence data114based on access data110, as described herein. The block-dependency component310may be configured to generate block-dependency data116based on the access data110, as described herein. The game data usage component312may be configured to determine unused blocks124of game data126on a per-user or per-client machine104basis, as described herein.

The communication interface(s)306may implement multiple types of wired and/or wireless or radio technologies. For example, the communication interface(s)306may implement a radio such as a Bluetooth Low Energy (BLE) radio, a Wi-Fi radio, and/or a cellular radio, and so on. It is to be appreciated that the communication interface(s)306may further include physical ports to facilitate a wired connection to a network, a connected peripheral device, or a plug-in network device that communicates with other wireless networks.

Reference is now made to the process300shown inFIG. 3. At314, the remote system106may receive access data110from client machines114(e.g., as part of a “telemetry” approach using the process200, described above). The received access data110may specify, for a particular client machine104, identifiers of the blocks124of game data126for a video game that were accessed on the particular client machine104by the game executable112of the video game, and the times at which the blocks124were accessed during a game session (e.g., during execution of a game executable(s)122of the video game). As shown by sub-block316, the access data110may be received along with a configuration of the particular client machine104, and along with an identifier of the video game that was executed during generation of the access data110.

At318, the remote system106may catalogue the access data110it receives at block314by (or according to) client system configuration and game identifier. For example, the data store112may include multiple groups or buckets320(1)-(M) that are classified by a unique combination of game ID and client system configuration. Taking, for example, a first client machine104(1) with client system configuration “1”, when first access data110is received at block314from the first client machine104(1), the first access data110may be catalogued at block318into a first bucket320(1) (or group), and this bucket320(1) may be tagged with the game ID of a video game and the client system configuration of the first client machine104(1) received from the first client machine104(1) at sub-block316. Likewise, a second client machine104(2) may send second access data110, and this second access data110may be catalogued at block318into a second bucket320(2), which may be tagged with a game ID of a video game and a second client system configuration “2” of the second client machine104(2) received from the second client machine104(2) at sub-block316. This can continue for any number of “M” buckets, depending on the number of client machines104reporting access data110, depending on whether those client machines104have different client system configurations, and/or depending on how many different video games are being executed on those client machines104.

At322, the remote system106may perform analytics on the access data110received at block314to generate data (e.g., results of the analysis). This generated data may include, without limitation, download-sequence data114for one or more video games, block-dependency data116for one or more video games, and/or determinations of unused blocks124of game data126on a per-user/per-client machine basis.

At324, the remote system106may determine whether a trigger event(s) has occurred. Trigger events may vary, but may include, without limitation, receiving a request120from a client machine104to acquire (e.g., purchase, rent, lease, etc.) a video game, generating new download-sequence data114and/or new block-dependency data116for a video game, determining that there are unused blocks124of game data126on a client machine104that have not been access for a threshold period of time or a threshold number of game sessions, passage of a period of time, etc.

If the remote system106determines, at block324, that a trigger event has not occurred, the process300may follow the “NO” route from block324back to block314where the remote system106continues to collect/receive access data110from client machines104. If the remote system106determines, at block324, that a trigger event(s) has occurred, the process300may follow the “YES” route from block324to block326where the remote system106may send data to one or more client machines104. For example, if the trigger event comprises a client machine104acquiring a video game, the remote system106may retrieve download-sequence data114for the video game, and may send the download-sequence data114to the client machine104, along with a game executable122for the video game. Additionally, or alternatively, the remote system106may retrieve block-dependency data116for a video game, and may send the block-dependency data116to a client machine(s)104. As yet another example, if the trigger event comprises determining that there is/are an unused block(s)124of game data126on a client machine104, the remote system106may send instructions to delete the unused block(s) of game data.

It is to be appreciated that at least some of the components of the client machine104shown inFIG. 2may be implemented as a component(s) of the remote system106, in some embodiments. For example, the game executable122may execute on the remote system106(e.g., as part of a video game streaming service), and the game executable122may receive data over the network108from the client machine104indicative of user input while playing the video game. In this scenario, the game data126for the video game may be stored at the remote system106as well, and the file system proxy component218may be a component of the remote system106that receives read operations from the game executable122to monitor the blocks124of game data126accessed during gameplay. In this configuration, the client machine104may act as a thin-client, with most of the processing performed in the cloud during a video game session. In another example, the download sequence component308, the block dependency component310, and/or the game data usage component312may be components of the client machine104. In this example, the client machine104may receive access data110generated by other client machines104that has been collected by the remote system106, and the client machine104may perform analytics on its own access data110and/or access data110generated by other client machines104to determine download-sequence data114, block-dependency data116, and/or unused blocks124of game data126stored on the client machine104.

FIG. 4is a flow diagram of an example process400for generating, based on access data110received from multiple client machines104, download-sequence data114for use by client machines104to download blocks124of game data126in a particular sequence of blocks124.

At402, the remote system106may receive, from multiple client machines104, access data110associated a video game. The access data110received at block402may specify, for individual ones of the client machines104, (i) accessed blocks124of game data126associated with the video game that were accessed by a game executable122of the video game during execution of the game executable122on an individual client machine, and (ii) times, during the execution of the game executable122, at which the accessed blocks124of the game data126were accessed by the game executable122. As shown by sub-block404, the access data110may be received along with a configuration of the client machine104that sent the access data110, and/or a game identifier of a video game that executed on the client machine104when the access data110was generated.

At406, the remote system106may generate, based at least in part on the access data110, download-sequence data114associated with a client system configuration and a game identifier of a video game. The download-sequence data114may specify a sequence of blocks124of game data126for the video game, and this sequence may represent the order in which blocks124of the game data are to be downloaded to a client machine104having a particular client system configuration. The download sequence for a video game can be determined in any suitable manner. As shown by sub-blocks408and410, the generation of the download-sequence data114may include multiple sub-operations.

At408, statistics may be calculated for at least some blocks124of game data126for a video game based at least in part on when (e.g., a time, a position/order/rank, etc.) those blocks124were accessed (as specified in the access data110) over N game sessions of N corresponding users102who played the video game (“N” being any positive integer). For example, based on the access data110associated with N users102who played the video game, the remote system106may determine a statistic (e.g., an average value) based on the times at which those blocks124were accessed by each of the N users102during a game session (e.g., during an initial game session). The remote system106may determine, for instance, the average access time for block A was 30 minutes into an initial game session (e.g., based on multiple different times at which block A was accessed by the N different users), the average access time for block B was 45 minutes into the initial game session, the average access time for block C was 2 hours into the initial game session, and so on and so forth. The remote system106may additionally, or alternatively, determine that block A was the first block accessed by user A during the 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, and so on and so forth for N users, and then the remote system106may determine a statistic (e.g., an average position/order/rank) for block A based at least in part on this information about when the block was accessed by the N different users102. This can be repeated for other blocks124that were accessed during the game session. These analytics can be performed at least for an initial game session. The analytics can be performed for any subsequent game sessions, as well, to determine which blocks124of game data126are typically accessed during a game session(s).

At410, based on the calculated statistics, a download sequence can be determined for multiple blocks124of game data126for the video game. The blocks124specified in the download sequence may be some of the blocks124of game data (e.g., a fraction of the total number of blocks124), or the download sequence may include all of the blocks124of game data126. It is to be appreciated that, for a given video game, the ratio between the initial number of blocks124that are likely to be accessed during an initial period of playtime, and the duration of the initial period of playtime can be somewhat lopsided. In other words, 2 Gigabytes of game data126may provide an initial 6 hours of playtime for a particular video game, and the remainder of the game data126may be unlikely to be accessed during this initial play period. This means that certain games may be well suited for the “instant play”128feature, and they could be flagged as “good Instant Play games” that are well suited for Instant Play based on this ratio. In other words, certain games can be flagged if a relatively long initial play period can be supported by a relatively small amount of game data126. Single player games, by way of example, may be well-suited for the “instant play”128feature with little-to-no latency because new players may be required to play the same level first. This means that, for a single player game, the remote system106might determine that all, or almost all, players who play the game for the first time access the same blocks124within the first X hours of playtime, and this pattern may be substantially linear and consistent across a set of N players—e.g., all N players may access Block A, then Block H, the Block Q, and so on and so forth. While there may be a discrepancy in the exact times at which the blocks124are accessed, there might be a common order of blocks124accessed over an initial period of playtime for a given video game. By contrast, a multiplayer game may have an open game world with a giant map. For example, across N users, the N users may drop into the game initially at different locations in the open world, and each game executable122will have accessed different blocks124of game data126that correspond to the different locations in the open world where the matched players dropped into the game. This is an example of a game that is ill-suited for the instant play128feature.

Assuming a video game can support the instant play128feature, a download sequence may specify an ordering of Block A, Block D, Block G, Block C, Block F, Block E, etc. Accordingly, for any video game, and for any client system configuration, the remote system106can determine, at least for a period of playtime (e.g., the first 6 hours of playtime), the average user102is likely to exclusively access a particular subset of blocks124of the game data, and is likely to access those blocks124in a particular sequence during that period of playtime. It is to 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 user102and a second download sequence may be determined for a second user102, the second download sequence different than the first download sequence. This may be based on the unique access patterns exhibited in user-specific access data110.

At412, the remote system106may receive, from a client machine104, a request120to acquire the video game, the request120including a configuration of the client machine104. For example, a user102of the client machine104who is logged into his/her user account via the video game client212, may conduct a transaction via the remote system106to purchase the video game.

At414, the remote system106may send a game executable122of the video game to the client machine104. This game executable122may be executable code (e.g., a file(s)) executable by the processor(s)202of the client machine104to start playing the video game on the client machine104. As shown by sub-block416, the remote system106may send the download-sequence data114to the client machine104for the client machine104to start downloading blocks124of game data126for the acquired video game in the sequence specified by the download-sequence data114.

At418, the remote system106may download blocks124of the game data to the client machine104in accordance with the sequence specified in the download-sequence data114. This may take some time depending on the downlink data transfer rate achievable for the client machine104. Accordingly, because the sequence of blocks124being downloaded, the blocks124that are most likely to be accessed first are realized in local memory132of the client machine104before other blocks, and by the time the game executable122of the video game requests to read the other blocks, those blocks are likely to have finished downloading to the client machine104.

FIG. 5is a flow diagram of an example process500for generating, based on access data110received from multiple client machines104, block-dependency data116for use by client machines104to prefetch blocks124of game data126to reduce latency during gameplay.

At502, the remote system106may receive, from multiple client machines104, access data110associated a video game. The access data110received at block502may specify, for individual ones of the client machines104: (i) accessed blocks124of game data126associated with the video game that were accessed by a game executable122of the video game during execution of the game executable122on an individual client machine, and (ii) times, during the execution of the game executable122, at which the accessed blocks124of the game data126were accessed by the game executable122. As shown by sub-block504, the access data110may be received along with a configuration of the client machine104that sent the access data110, and/or a game identifier of a video game that executed on the client machine104when the access data110was generated.

At506, the remote system106may generate, based at least in part on the access data110, block-dependency data116associated with a client system configuration and a game identifier of a video game. The block-dependency data116may specify individual associations between two or more blocks124of the game data126for the video game. Said another way, the remote system106can predict one or more blocks124of game data126that will be accessed if a particular event occurs. In this manner, a map of dependencies (e.g., branching, tree-like dependencies) between blocks124of game data126and/or between blocks124and contextual cues can be built based on the access data110. As shown by sub-blocks508and510, the generation of the block-dependency data116may include one or more sub-operations.

At508, the remote system106may determine, based on access patterns (e.g., access times) exhibited in the access data110received from N users102that played a video game, associations between contextual cues and blocks124of game data126for the video game. For example, the remote system106may determine that whenever a particular contextual cue is detected (e.g., whenever the user102navigates to a library page of the video game), a particular block124of game data126is typically (e.g., averaged across the N users) accessed within a threshold time period. This type of correlation can be determined based at least in part on the access times specified in the access data. For example, if, across N users, Block A is the most accessed block within the first 15 seconds of the N users navigating to the library page of the video game, Block A may be associated with this type of contextual cue.

At510, the remote system106may determine, based on access patterns (e.g., access times) exhibited in the access data110received from N users102that played a video game, associations between pairs of blocks124of game data126for the video game. For example, the remote system106may determine, based on the access data110received from N users102that played a video game, whenever a first block124(1) of game data126is accessed during a game session, a second block124(2) of game data126is typically accessed within a threshold time period. In this manner, the remote system106may determine inter-block relationships between groups of two or more blocks124based on access patterns that are exhibited in the access data110.

It is to be appreciated that, in some embodiments, the block-dependency data116may 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 user102and a second map of block dependencies may be determined for a second user102, the second map different than the first map. This may be based on the unique access patterns exhibited in user-specific access data110.

At512, the remote system106may send the block-dependency data116to one or more client machines104. The block-dependency data116may be sent in response to various trigger events. For example, the remote system106may send block-dependency data116for a video game to a client machine104in response to a user102of the client machine104having acquired (e.g., purchased, rented, leased, etc.) the video game. As another example, the block-dependency data116generated at block506may represent new data (or updated data) relative to previous version of block-dependency data116for the video game, and, in response to generating the new/updated block-dependency data116at block506, the remote system106may send the block-dependency data116to client machines104known to be associated with owners of the video game. As yet another example, a user may opt-in to having a local prefetching feature implemented on his/her client machine104, and in response to opting-in, the remote system106may send the block-dependency data116to the client machine104of the opted-in user.

FIG. 6is a flow diagram of an example process600for determining, based on access data110received from a client machine104, unused blocks124of game data126, and instructing the client machine104to discard the unused blocks124of game data126.

At602, the remote system106may receive, from a client machine104, access data110associated a video game. The access data110received at block602may specify: (i) accessed blocks124of game data126associated with the video game that were accessed by a game executable122of the video game during execution of the game executable122on the client machine104, and (ii) times, during the execution of the game executable122, at which the accessed blocks124of the game data126were accessed by the game executable122. It is to be appreciated that the remote system106may have previously received access data110at some time(s) in the past from the same client machine104. Accordingly, the remote system106may have access to access data110generated over multiple game sessions played on the client machine104. As shown by sub-block604, the access data110may be received along with a configuration of the client machine104that sent the access data110, and/or a game identifier of a video game that executed on the client machine104when the access data110was generated.

At606, the remote system106may determine, based on the access data110(and possibly additional access data110received from the client machine104in the past), whether any blocks124of the game data126for the video game that are presently stored in non-volatile memory (e.g., the first memory132(1)) of the client machine104can be classified as “unused” blocks124of game data126. As shown by sub-block608, this determination may include determining whether individual blocks124have not been accessed by a game executable(s)122of the video game on the client machine104for a threshold period of time, or for a threshold number of game sessions. For example, if blocks X-Z of game data126have not been accessed for the past P game sessions (“P” being any suitable integer), or for the last Q weeks (“Q” being any suitable integer, such as the last 10 weeks), the determination may be that blocks X-Z are unused blocks.

In some embodiments, other factors are considered in classifying blocks124of game data126as unused blocks. For example, the remote system106may determine, across N users of a particular video game, that certain blocks124of game data126are accessed by the game executable122once and never again accessed afterwards, the remote system106may determine that particular blocks124have been already accessed once, and, if so, may designate the block(s)124as unused, regardless of how recently the block(s)124was/were accessed by the game executable122. Other heuristics can be used to determine unused blocks124as well.

If the determination at block606is that none of the blocks124of game data126stored in non-volatile memory (e.g., the first memory132(1)) of the client machine104can be classified as unused blocks124, the process600may follow the “NO” route from block606back to block602where the remote system106may receive (or wait to receive) additional access data110from the client machine104. If the determination at block606is that one or more blocks124of game data126stored in non-volatile memory of the client machine104can be classified as unused blocks124, the process600may follow the “YES” route from block606to block610.

At610, the remote system106may send, to the client machine104, instructions118to delete the unused block(s)124of game data126from non-volatile memory of the client machine104. These instructions118may include the identifiers of the to-be-deleted blocks124. Once deleted, the local memory resources132of the client machine104can be freed up to increase local memory capacity and potentially store other data thereon.

FIG. 7is a flow diagram of an example process700for discarding unused blocks of game data from non-volatile memory of a client machine104. As shown by the off-page reference “A” inFIGS. 2 and 7, the process700may continue from block224of the process200, after the client machine104has sent access data110to the remote system106.

At702, the client machine104may receive, from the remote system106, an instruction118to delete, from the non-volatile memory, one or more blocks124of game data126for a video game. The remote system106may have determined, from the access data110previously sent by the client machine, that the to-be-deleted block(s)124represent unused blocks124of the game data126that have not been accessed for a threshold period of time or a threshold number of game sessions.

At704, the client machine104may delete, from the non-volatile memory (e.g., first memory132(1)), the one or more blocks124of the game data126based on the instruction118received from the remote system106. As shown by sub-block706, the client machine104may be configured to wait until the client machine104is rebooted before discarding the block(s)124of game data126. In this manner, deleting the block(s)124does not cause any issues if, for example, the user102is currently playing the video game (or a different video game). It is to be appreciated that remaining blocks124of game data126remain persisted in non-volatile memory after the deletion of the unused blocks124. Accordingly, local memory resources132may be freed up by discarding blocks124of game data126that are unlikely to be accessed in the future. In an example use case, a user102may have installed Video Game X on his/her client machine104, and since doing so, the user102has only ever played Video Game X online, meaning that the user102has never played Video Game X in single player mode. From the access data110reported by the client machine104to the remote system106, the remote system106may determine, since Video Game X was installed on the client machine104, and over a number of weeks and/or a number of game sessions, the user102has never accessed the blocks124of game data126for the single player mode of Video Game X. In this case, the remote system104may send, and the client machine104may receive, an instruction118to discard the single player game data126(by identifying one or more blocks124that correspond to this game data126), and the client machine104may delete these blocks124to free up space in the non-volatile memory (e.g., the first memory132(1)) of the client machine104.

After deletion, the video game may execute as normal, and the read operations made by the game executable122continue to be made. In the off-chance that the game executable122requests to read blocks124of game data126that have been deleted from non-volatile memory of the client machine104, the file system proxy component218may retrieve those blocks from the remote system106on-demand. In some embodiments, if deleted blocks124are requested to be read by the game executable122, those blocks124may be re-downloaded to the non-volatile memory of the client machine104. Implementation of the process700, along with other processes and/or techniques described herein, can reclaim valuable disk space on a client machine104(e.g., on the order of tens of Gigabytes of disk space.

FIG. 8is a flow diagram of an example process800for executing a video game on a client machine104before the game download is finished. This is sometimes referred to herein as an “instant play”128feature because the process800may allow a user102to play a video game upon acquisition of the video game, without waiting for game data126to be downloaded to the client machine104.

At802, a client machine104may send a request120to a remote system106to acquire (e.g., purchase, rent, lease, etc.) a video game. As shown by sub-block804, the request120may include a configuration of the client machine104so that the remote system106retrieves the correct download-sequence data114for the client system configuration.

At806, the client machine104may receive, from the remote system106, a game executable(s)122of the video game, such as executable code (e.g., one or more files) that is executable by the processor(s)202of the client machine104to play the video game thereon. As shown by sub-block808, the client machine104may also receive download-sequence data114associated with the configuration of the client machine104. This download-sequence data114may specify a sequence of blocks124of game data126for the video game.

At810, the client machine104may start downloading, to non-volatile memory (e.g., first memory132(1)) of the client machine104, the blocks124of the game data126for the video game in accordance with the sequence specified in the download-sequence data114.

At812, the client machine104may execute the game executable122to start the video game. It is to be appreciated that the user102may start playing the video game, and the game executable122may start executing even before the first block124of game data126is finished downloading. Execution of the game executable may occur in response to user input detected by the client machine104to start the video game. For example, the user of the client machine104may select a user interface element of the video game client212to start the video game that the user has just acquired via the remote system106. As mentioned, in some embodiments, the remote system106may send data to the client machine104for outputting a recommendation to the user102via the client machine104, such as by displaying a recommendation that states “For the best user experience, we recommend waiting T minutes after starting the download to play [Video Game X]”. In some embodiments, the video game client212may prevent execution of the game executable122until after a threshold period of time has lapsed, and/or until after a threshold number of blocks124have finished downloading to provide an optimal user experience. Alternatively, if the video game is particularly well-suited for the instant play128feature, the remote system106may instruct the client machine104to output a notification that states “This game is ready for instant play, so you can start playing right now. Enjoy!”, and/or the video game client212may not place any restrictions on when the user102can start playing the video game. In fact, it might be preferable for some players who aren't bothered by a little bit of latency in the beginning of a video game (e.g., when exploring a world and setting things up) to start playing immediately, and possibly before any game data126has finished downloading.

At814, the file system proxy component218of the client machine104may receive a first read operation made by the game executable122to a file system220of the client machine104. This first read operation may request to read a first block124(1) of the game data126for the video game. Because the download of the game data126is in-progress at the time the read operation(s) is received at block814(assuming a significantly large video game), there is a potential for the game executable122to request to read an unrealized block124of game data126, “unrealized” meaning that the block124of game data has not yet been downloaded to non-volatile memory (e.g., first memory132(1)) of the client machine104. In some embodiments, the file system proxy component218may temporarily (e.g., briefly) block the read operation to make a determination as to whether the requested block(s)124is realized in non-volatile memory, or if the block(s)124still needs to be downloaded (e.g., to finish downloading).

Accordingly, at816, the file system proxy component218may determine whether the first block124(1) of the game data126has been downloaded to the non-volatile memory (NVM) of the client machine104(i.e., if the first block124(1) has been “realized” in non-volatile memory). If the first block124(1) of the game data126is realized in non-volatile memory of the client machine104at a time of receiving the read operation at block814, the process800may follow the “YES” route from block816to block818.

At718, the file system proxy component218of the client machine104may unblock the read operation and the file system220may be used to read the first block124(1) of the game data126from a local memory resource132. If, by chance, the first block124(1) is realized and was prefetched by caching it in the second memory132(2) or the third memory132(3) that provides faster read access speed than the first memory132(1), then the first block124(1) may be read from the faster memory132(2)/(3) where it is cached. If, at block816, the first block124(1) of game data126is not realized in non-volatile memory of the client machine104, meaning that the first block124(1) has not finished downloading to the non-volatile memory (e.g., the first memory132(1)), the process800may follow the “NO” route from block816to block820.

At820, the client machine104may send, to the remote system106, a second request for the first block124(1) of the game data126. As mentioned, the file system proxy component218may 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 machine104, and the file system proxy component218may make a callback into the video game client212to download the first block124(1) if it determines that the first block124(1) is unrealized.

At822, the client machine104may receive the first block124(1) of the game data126from the remote system106over the computer network108. Following the receipt of the first block124(1) of game data126, the first block124(1) of the game data126may be read using the file system220. Thus, the file system proxy component218may temporarily block read operations, at least for unrealized blocks124of game data126until those blocks124are received from the remote system106. Although this may add latency in reading an unrealized block124, as compared to the latency of reading a block124that is already realized in non-volatile memory of the client machine104, this configuration nevertheless allows the video game to be played without having downloaded all of the game data126for the video game. In fact, it allows the video game to be played without any game data126being stored on the client machine104. However, since latency is added by retrieving blocks124of game data126over the computer network108, the act of downloading the game data126in parallel with game execution ensures that at least some, if not all, of the blocks124of game data126will be realized in non-volatile memory by the time the game executable122requests to read those blocks124, thereby reducing latency. That is, because the remote system106intelligently determines the download sequence based on the access data110it received from other client machines104with the same client system configuration, the likelihood of receiving a read operation requesting to read an unrealized block124of game data126is relatively low, and it is not expected to occur frequently, if at all. Instead, by the time a read operation for a given block124is made by the game executable122, it is likely that the given block124will have already been downloaded and realized in non-volatile memory such that the game executable122can read the block124from a local memory resource132of the client machine104with less latency than the latency involved in retrieving the same block124from the remote system106over the computer network108

At824, a determination is made as to whether the game session for the video game should be terminated. For example, if the user102quits the video game, the process800may follow the “YES” route from block824to block826where the video game client212may stop execution of the game executable122. If, at block824, the game session should not be terminated (e.g., if the user102continues playing the game), the process800may follow the “NO” route from block824to block814where an additional read operation may be received. A portion of the process800may iterate in this manner as the user102continues playing the game, with unrealized blocks124of game data126being retrieved from the remote system106on-demand, if necessary. Using this approach where the file system proxy component218“lies” to the video game about the blocks124available in non-volatile memory, it can be appreciated that, from the frame of reference of the video game, it looks like the contents of the game are stored in the first memory132(1). The video game may expect that the game data126is available from a local memory resource132, and it may be accustomed to variable read access speeds from client machine104to client system104, or there may be variability in read access speed on a single client machine104based on various factors (e.g., resources consumed by other running processes, etc.). This all means that the approach of the process800will not cause the video game to crash despite possibly being a little slow, at times, to retrieve unrealized blocks124of game data124over a wide area network108.

Using the process800, a user102can start playing a video game as soon as he/she wants to after acquiring the game. Furthermore, the technique of the process800is game agnostic, meaning that a game developer doesn't need to do any work to allow for the instant play128feature; rather, it is a value add for all games on a video game distribution platform that distributes video games to a heterogenous population of client system configurations.

FIG. 9is a flow diagram of an example process900for prefetching blocks124of game data126to reduce latency during gameplay.

At902, a client machine104may receive, from a remote system106, block-dependency data116associated with a configuration of the client machine104. This block-dependency data116may specify individual associations between two or more blocks124of game data126for a video game.

At904, the client machine104may execute a game executable122of the video game to start the video game on the client machine104. The game executable122may already be available on the client machine104due to the video game being installed on the client machine104. Execution of the game executable122allows a user102of the client machine104to start playing the game. Furthermore, execution of the game executable122may occur in response to user input detected by the client machine104to start the video game. For example, the user102of the client machine104may select a user interface element of the video game client212to start the video game.

At906, a determination may be made as to whether there is an above-threshold amount of capacity in “prefetch cache”. “Prefetch cache,” as used herein, means the cache allocated (or reserved) for prefetched blocks124of game data126. As described herein, the second memory132(2) and/or the third memory132(3)—which provide faster read access speeds than the first memory132(1)—may provide the prefetch cache, and the prefetch cache on either or both local memory132(2)/(3) can be set to any suitable amount of data, such as 100 Megabytes. In this example, as much as 100 Megabytes of game data126can be prefetched during a game session, before the game executable122requests to read that prefetched game data126. 100 Megabytes is merely an example, and the prefetch cache can be set to a lesser or greater amount of data. Accordingly, at block906, the prefetch cache(s) can be monitored to determine how full the prefetch cache(s) is/are, and if the cache capacity meets or exceeds a threshold amount, additional prefetching of game data126can be triggered. This threshold amount of capacity in the prefetch cache(s) that is evaluated at block906may be set to any suitable amount. If the size of an individual block124of game data126is 4096 bytes, for example, the threshold amount of capacity may be set to as few as 4096 bytes of capacity, which is enough room to prefetch a block124of game data126. However, the threshold amount of capacity may be set to a higher number of bytes/Megabytes to ensure that multiple blocks124can be prefetched during a run through the prefetch algorithm.

In an example use case, use case, a user102of the client machine104may have navigated to the game's library page, and a set of blocks124of game data126may have been prefetched to fill 100 Megabytes of prefetch cache in the second memory132(2) and/or the third memory132(3) of the client machine104. As the user102continues to play the video game, the file system220may receive calls associated with read operations made by the game executable122to read one or more of the prefetched blocks124. Instead of accessing the first memory132(1) of the client machine104to retrieve those blocks124, the file system220may access at least one of the second memory132(2) or the third memory132(3) where the prefetched blocks132are cached, and, as a result, the capacity in the prefetch cache(s) starts to increase. Once this capacity in the prefetch cache(s) meets or exceeds a threshold, additional prefetching may be triggered to fill the prefetch cache(s). Accordingly, if there is an above-threshold amount of capacity in the prefetch cache(s) at block906, the process900may follow the “YES” route from block906to block908.

At908, logic of the client machine104may detect an event(s) that is used to determine what block(s)124of game data126to prefetch. For example, at sub-block910, the event detected might be a contextual cue (e.g., a user navigating to a library page of the video game). As another example, at sub-block912, the event detected might be the file system proxy component218receiving a read operation made by the game executable122to read a particular block124of game data126.

At914, the logic of the client machine104may identify, using the block-dependency data116, one or more blocks124of game data126that are associated with the detected event. For example, if the event detected at block908is that the game executable122requested to read Block A of game data126, and if the block-dependency data116indicates that Block B is likely to be accessed by the game executable122within a threshold period of time from the accessing of Block A, the logic may identify Block B at block914.

At916, the identified block(s)124may be cached in local memory132that provides a faster read access speed than the first memory132(1) (e.g., non-volatile memory, such as a HDD, a SD card, etc.) where the game data126is persisted on the client machine104. Accordingly, the identified block(s)124can be cached in at least one of the second memory132(2) (e.g., additional non-volatile memory, such as a SSD) or the third memory132(3) (e.g., volatile, working memory, such as RAM). As shown by sub-block918, if multiple blocks124of game data126are identified at914, the blocks124can be cached in multiple different prefetch caches, such as by caching a second block124(2) in second memory132(2) and caching a third block124(3) in third memory132(3), and so on and so forth. In this manner, prefetched blocks124of game data126can be distributed across multiple prefetch caches of multiple local memory resources132using a load balancing technique where some game data126is cached in the second memory132(2) and a roughly equal amount of game data126is cached in the third memory132(3), notwithstanding the third memory132(3) providing a faster read access speed than the second memory132(2). In this manner, prefetched game data126can be load balanced to improve the overall throughput of the system in that game data126can be accessed from any and all local memory resources132in parallel during game play. It may be the case that 1% of read operations are predicted to access game data126from the first memory132(1), 9% of read operations are predicted to access game data126from the second memory132(2), and 90% of the read operations are predicted to access game data126from the third memory132(3) in this load balancing scheme.

At920, the file system proxy component218of the client machine104may receive a read operation made by the game executable122to the file system220, the read operation requesting to read a particular block124of game data126for the video game.

At922, a determination may be made (e.g., by the file system220) as to whether the requested block124is cached in the prefetch cache of a local memory resource (e.g., the second memory132(2) or the third memory132(3)) that provides relatively fast read access speed. If the block124is cached in prefetch cache, the process900may follow the “YES” route from block922to block924where the block124may be read from the prefetch cache. For example, the game executable122may read the block124of the game data126from the second memory132(2) or the third memory132(3), depending on where the block124is cached. If the block124is not cached in prefetch cache, the process900may follow the “NO” route from block922to block926where the block124may be read from the first memory132(1) where the game data126can be persisted on the client machine104.

At928, a determination is made as to whether the game session for the video game should be terminated. For example, if the user102quits the video game, the process900may follow the “YES” route from block928to block930where the video game client212may stop execution of the game executable. In some embodiments, if the user102a game session and reboots the client machine104, the game data126that was prefetched into the second memory132(2) may still be stored in the prefetch cache of the second memory132(2) upon reboot if the second memory132(2) represents additional non-volatile memory (e.g., a SSD). In this manner, if the user102starts another game session after reboot, blocks124of game data126that are still cached in the second memory132(2) can be retrieved therefrom, if and when they are requested by the game executable122during the subsequent game session. If, at block928, the game session should not be terminated (e.g., if the user102continues playing the game), the process900may follow the “NO” route from block928to block906where capacity of the prefetch cache(s) is evaluated again to iterate a portion of the process900starting from block906. At906, if there is not an above-threshold amount of capacity in the prefetch cache(s) (e.g., if the prefetch cache(s) is/are considered to be too full of prefetched game data126), the process900may follow the “NO” route from block906directly to block920where a read operation is received by the file system proxy component218without prefetching game data126in the prefetch cache(s).

The process900can decrease the loading times during game execution by reducing the overall latency as compared to accessing the game data126exclusively from the first memory132(1) where the game data126is persisted on the client machine104. In this manner, a relatively large video game can be stored in the first memory132(1) (e.g., a HDD, a SD card, etc.), yet, because game data126may be intelligently prefetched by caching blocks124of game data126in the third memory132(2) (e.g., working, non-volatile memory, such as RAM) and/or in the second memory132(2) (e.g., SSD) ahead of a time when those block124are requested by the game executable122, by the time the game executable122requests to read those blocks124of game data126, the blocks124are likely to have already been cached in prefetch cache to reduce the read access time.

Although the 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 illustrative forms of implementing the claims.