ASYNCHRONOUS GAMEPLAY WITH RIVAL DISPLAY

Abstract

A user request to select a rival to play against asynchronously for an event is received. In response to the user request, a rival selector user interface is displayed. The rival selector UI includes an identification of one or more users that can be selected and one or more filter criteria that can be selected to change which users are identified in the rival selector UI. The user selects one of the identified users that is used as the rival to play against asynchronously for the event. Game data for the rival for the event is obtained, the game data including both a performance of the rival in the event and data indicating a manner in which an object of the rival is customized by the rival. While the user is playing the event, the object as customized by the rival is played back based on the performance data.

Description

RELATED APPLICATIONS

This application claims priority to U.S. Provisional Application Ser. No. 61/542,256, filed Oct. 2, 2011, entitled “Asynchronous Gameplay with Rival Display”, to Jonathan P. Knoles, et al., the disclosure of which is hereby incorporated by reference herein in its entirety.

BACKGROUND

Online gaming services allow users to play games by themselves, or to play games together with one or more other users. The online gaming services typically maintain a leader board that ranks the various users of a game based on the users' scores obtained while playing a game. Although such leader boards are useful to know how a user ranks against other users in a game, they are not without their problems. One such problem is that if a user desires to try to beat another user by obtaining a higher score for a game, the user is typically presented with simply the score to beat. This creates an impersonal situation for the user, providing an experience for the user that is more of individual gameplay rather than playing the game with another user.

SUMMARY

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

In accordance with one or more aspects, a user request to select a rival to play against asynchronously for an event is received. In response to the user request, a rival selector user interface is displayed. The rival selector user interface includes an identification of one or more users that can be selected. A user selection of one of the one or more users is received, and the selected user is used as the rival to play against asynchronously for the event.

In accordance with one or more aspects, a user request to play against a rival asynchronously for an event is received. Game data for the rival for the event is obtained, the game data including both a performance of the rival in the event and data indicating a manner in which an object of the rival is customized by the rival. While the user is playing the event, the object as customized by the rival is played back based on the performance data.

BRIEF DESCRIPTION OF THE DRAWINGS

The same numbers are used throughout the drawings to reference like features.

FIG. 1 illustrates an example system implementing the asynchronous gameplay with rival display in accordance with one or more embodiments.

FIG. 2 illustrates an example gaming device and display in additional detail in accordance with one or more embodiments.

FIG. 3 illustrates an example system implementing the asynchronous gameplay with rival display in accordance with one or more embodiments.

FIGS. 4 and 5 illustrate example user interfaces allowing a user to select a rival to play an event against asynchronously in accordance with one or more embodiments.

FIGS. 6 and 7 illustrate an example of the changing of transparency of an object representing a rival in accordance with one or more embodiments.

FIG. 8 is a flowchart illustrating an example process for implementing the asynchronous gameplay with rival display in accordance with one or more embodiments.

FIG. 9 is a flowchart illustrating another example process for implementing the asynchronous gameplay with rival display in accordance with one or more embodiments.

FIG. 10 is a flowchart illustrating an example process for using notifications in accordance with one or more embodiments.

FIG. 11 illustrates an example computing device that can be configured to implement the asynchronous gameplay with rival display in accordance with one or more embodiments.

DETAILED DESCRIPTION

Asynchronous gameplay with rival display is discussed herein. When a user plays an event in a game, data regarding the user's performance in that event is stored. A particular user can select another user (a rival) to play against asynchronously in the event. A list identifying various other users that have played the event can be displayed to the particular user, and the list can be filtered in various manners (e.g., based on friends of the particular user, scores of the users, and so forth). The particular user selects another user in the list as a rival, and an object representing the rival (e.g., the rival's vehicle) is displayed while the particular user plays the event. The object representing the rival is displayed with the rival's performance in the event, providing the particular user with the experience of playing the event with the rival even though the rival actually played the event at an earlier time. The object representing the rival is displayed with customizations made by the rival (e.g., particular paint colors or designs for a vehicle, particular stickers added to a vehicle, and so forth). If the particular user beats the score of the rival in the event, then a currency or other credit is awarded to the particular user. The currency or credit awarded is based on the particular user's performance and the score of the rival in the event. Additionally, if the particular user beats the score of the rival in the event, then a notification can be provided to the rival notifying him or her that he or she has been beaten in the event by the particular user. The notification includes a link that can be selected by the rival to jump to the event, and to play the event again in an attempt to obtain a better score than the particular user.

FIG. 1 illustrates an example system 100 implementing the asynchronous gameplay with rival display in accordance with one or more embodiments. System 100 includes multiple (x) gaming devices 102 and an online gaming service 104 that can communicate with one another via a network 106. Network 106 can be a variety of different networks, including the Internet, a local area network (LAN), a wide area network (WAN), a personal area network (PAN), a phone network, an intranet, other public and/or proprietary networks, combinations thereof, and so forth.

Each gaming device 102 can be a variety of different types of devices that allow users to play games (such as racing games, sports games, strategy games, adventure games, simulation games, and so forth). Different ones of gaming devices 102 can be the same or different types of devices. For example, a gaming device 102 can be a game console, a cellular or other wireless phone, a television or other display device, a set-top box communicatively coupled to a display device, a desktop computer, a laptop or netbook computer, a tablet or notepad computer, a mobile station, an entertainment appliance, an automotive computer, and so forth.

Online gaming service 104 facilitates playing of one or more different games by users of gaming devices 102. Gaming service 104 is referred to as being an online service due to gaming devices 102 accessing service 104 (and/or other gaming devices 102) via network 106. Online gaming service 104 includes an account access service 110, a gameplay service 112, and optionally a matchmaking service 114, each of which can communicate with one another. Services 110, 112, and 114 can communicate with one another within online gaming service 104 and/or via gaming devices 102.

Account access service 110 provides various functionality supporting user accounts of online gaming service 104. Different users and/or gaming devices 102 typically have different accounts with online gaming service 104, and can log into their accounts via account access service 110. A user or gaming device 102 logs into an account providing credential information, such as an id (e.g., user name, email address, gamer tag, etc.) and password, a digital certificate or other data from a smartcard, and so forth. Account access service 110 verifies or authenticates the credential information, allowing a user or gaming device 102 to access the account if the credential information is verified or authenticated, and prohibiting the user or gaming device 102 from accessing the account if the credential information is not verified or is not authenticated. Once a user's credential information is authenticated, the user can use the other services provided by online gamine service 104. Account access service 110 can also provide various additional account management functionality, such as permitting changes to the credential information, establishing new accounts, removing accounts, and so forth.

Gameplay service 112 provides various functionality supporting playing of one or more different games by users of gaming devices 102. Different game titles can be supported by gameplay service 112 (e.g., one or more different racing game titles, one or more different sports game titles, one or more different strategy game titles, and so forth). A game title refers to a particular set of instructions that implement a game when executed (e.g., a set of instructions for a racing game from a particular vendor, a set of instructions for a particular tennis game from a particular vendor, etc.). A particular running of a game title is also referred to as a game. Multiple games of the same game title can be played concurrently by different users, each game being a separate running of the game title. Games can be run and played as single-player games in which a single user of a gaming device 102 is playing the game and controlling one or more characters or other objects in the game, with other characters or objects in the game being controlled by the game itself. Games can also be run and played as multi-player games in which multiple users of one or more gaming devices 102 are playing the same game and each user is controlling one or more characters or other objects in the game. In multi-player games one or more additional characters or other objects can also be controlled by the game itself.

A game is typically run by executing one or more programs. The programs that are executed to run these games can be run on gaming devices 102 and/or gameplay service 112. Gaming devices 102 can execute one or more programs for the game, communicating with gameplay service 112 to facilitate communication between users of gaming devices 102 while playing games and/or to provide or obtain additional data (and/or programs) for playing the game. Alternatively (or additionally), gameplay service 112 can execute one or more programs for the game, receiving inputs from users of gaming devices 102 and returning data indicating outputs to be generated for display or other presentation to the users of gaming devices 102.

In one or more embodiments, games are programs executed on gaming devices 102 and gameplay service 112 manages communication between different gaming devices 102. In other embodiments, games are programs executed on gaming devices 102 and gameplay service 112 facilitates establishing communication between different gaming devices 102. After communication between two gaming devices 102 is established, communication can be made between those two gaming devices 102 without involving gameplay service 112.

Gameplay service 112 includes an asynchronous gameplay coordination module 120. While playing a game, there is an object in the game that represents the user. This object can vary based on the type of game, such as being a vehicle (e.g., a car, plane, boat, spaceship, etc.) in a racing game, being a graphical representation of a character (e.g., a human, alien, monster, etc.) in a shooting game, and so forth. Asynchronous gameplay coordination module 120 facilitates allowing users to play events of games against one another asynchronously. Users playing events of games against one another asynchronously refers to the users playing the events of the games at different times. One user (e.g., user A) plays an event in a game and user A's performance in the event is recorded. The other user (e.g., user B) can play that same event at a later time, playing against the recording of user A's performance. Thus, both users play the same event, but do so at different times. The users can be both logged in to online gaming service 110 but play an event of a game at different times and/or one user can play an event of a game when the other user is not logged into online gaming service 110. Although illustrated as being included as part of gameplay service 112, asynchronous gameplay coordination module 120 can alternatively be implemented at least in part in gaming devices 102.

Matchmaking service 114, when included in online gaming service 104, provides various functionality facilitating the finding of other users with which a user of gaming device 102 can play a game. Matchmaking service 114 identifies other users with which a particular user can play a game in a variety of different manners, such as based on physical locations of the gaming devices 102, skill levels of the users of gaming devices 102, and/or other characteristics of gaming devices 102 and/or the users of gaming devices 102. Matchmaking service 114 can identify other users based on user accounts that account access service 110 is aware of, based on users logged into their accounts at a particular time (e.g., as indicated by account access service 110), based on accounts from other services (e.g., social networking services that matchmaking service 114 can communicate with), and so forth. Matchmaking service 114 can identify other users with which a user of gaming device 102 can play a game across the same and/or different types of gaming devices 102 (e.g., one or more users of a desktop computer and one or more users of a game console, one or more users of a phone and one or more users of a game console, etc.). Similarly, matchmaking service 114 can identify other users with which a user of gaming device 102 can play a game across the same and/or different services (e.g., one or more users of gameplay service 112 and one or more users of another service of online gaming service 104). Asynchronous gameplay coordination module 120 can also facilitate the finding of other users with which a user of gaming device 102 can play an event of a game asynchronously as discussed in more detail below. Any finding of other users by matchmaking service 114 is in addition to asynchronous gameplay coordination module 120 finding other users.

Each of services 110, 112, and 114 can be implemented using one or more computing devices. Typically these computing devices are server computers, but any of a variety of different types of computing devices can alternatively be used (e.g., any of the types of devices discussed above with reference to gaming device 102). Each of services 110, 112, and 114 can be implemented using different computing devices, or alternatively one or more of services 110, 112, and 114 can be implemented using the same computing device.

Additionally, although services 110, 112, and 114 are illustrated as separate services, alternatively one or more of these services can be implemented as a single service. For example, gameplay service 112 and matchmaking service 114 can be implemented as a single service. Furthermore, the functionality of one or more of services 110, 112, and 114 can be separated into multiple services. In addition, the functionality of online gaming service 104 can be separated into multiple services. For example, online gaming service 104 may include account access service 110 and gameplay service 112, and a different service (e.g., a social networking service) can include matchmaking service 114.

FIG. 2 illustrates an example gaming device and display in additional detail in accordance with one or more embodiments. FIG. 2 illustrates a gaming device 202, which can be a gaming device 102 of FIG. 1, coupled to a display device 204 (e.g., a television). Gaming device 202 and display device 204 can communicate via a wired and/or wireless connection. Gaming device 202 includes an asynchronous gameplay coordination module 212 and an input/output (I/O) module 214. Asynchronous gameplay coordination module 212 is analogous to asynchronous gameplay coordination module 120 of FIG. 1, although is illustrated as implemented in gaming device 202 rather than in an online gaming service.

Input/output module 214 provides functionality relating to recognition of inputs and/or provision of (e.g., display or other presentation of) outputs by gaming device 202. For example, input/output module 214 can be configured to receive inputs from a keyboard or mouse, to identify gestures and cause operations to be performed that correspond to the gestures, and so forth. The inputs can be detected by input/output module 214 in a variety of different ways.

Input/output module 214 can be configured to receive one or more inputs via touch interaction with a hardware device, such as a controller 216 as illustrated. Touch interaction may involve pressing a button, moving a joystick, movement across a track pad, use of a touch screen of display device 204 or controller 216 (e.g., detection of a finger of a user's hand or a stylus), other physical inputs recognized by a motion detection component (e.g., shaking a device, rotating a device, etc.), and so forth. Recognition of the touch inputs can be leveraged by input/output module 214 to interact with a user interface output by gaming device 202, such as to interact with a game, change one or more settings of gaming device 202, and so forth. A variety of other hardware devices are also contemplated that involve touch interaction with the device. Examples of such hardware devices include a cursor control device (e.g., a mouse), a remote control (e.g., a television remote control), a mobile communication device (e.g., a wireless phone configured to control one or more operations of gaming device 202), and other devices that involve touch on the part of a user or object.

Input/output module 214 can also be configured to receive one or more inputs in other manners that do not involve touch or physical contact. For example, input/output module 214 can be configured to receive audio inputs through use of a microphone (e.g., included as part of or coupled to gaming device 202). By way of another example, input/output module 214 can be configured to recognize gestures, presented objects, images, and so forth through the use of a camera 218. The images can also be leveraged by gaming device 202 to provide a variety of other functionality, such as techniques to identify particular users (e.g., through facial recognition), objects, and so on.

Gaming device 202 can also leverage camera 218 to perform skeletal mapping along with feature extraction of particular points of a human body (e.g., 48 skeletal points) to track one or more users (e.g., four users simultaneously) to perform motion analysis. For instance, camera 218 can capture images that are analyzed by input/output module 214 or a game running on gaming device 202 to recognize one or more motions made by a user, including what body part is used to make the motion as well as which user made the motion. The motions can be identified as gestures by input/output module 214 or the running game to initiate a corresponding operation.

FIG. 3 illustrates an example system 300 implementing the asynchronous gameplay with rival display in accordance with one or more embodiments. System 300 includes an asynchronous gameplay coordination module 302 (which can be an asynchronous gameplay coordination module 120 of FIG. 1 or an asynchronous gameplay coordination module 212 of FIG. 2), a game 304 and a game 306. System 300 can be implemented in a variety of different devices. For example, system 300 can be implemented in gaming devices 102 of FIG. 1, in online gaming service 104 of FIG. 1, or partly in gaming devices 102 and partly in online gaming service 104.

Game 304 includes one or more game modules 308, and game 306 includes one or more game modules 310. Games 304 and 306 are different games of the same game title (e.g., different games of the same car racing game title). The game modules 308 and 310 perform various functionality for the games 304 and 306, respectively, and the specific functionality performed by game modules 308 and 310 varies based at least in part on the particular game title.

In one or more embodiments asynchronous gameplay coordination module 302 is implemented separately from, and as part of a service made available to, games 304 and 306. Alternatively, asynchronous gameplay coordination module 302 can be implemented (at least in part) in games 304 and 306. Thus, for example, modules 308 and/or 310 can include one or more modules of asynchronous gameplay coordination module 302, or can implement at least part of the functionality discussed herein as performed by asynchronous gameplay coordination module 302.

Game 304 stores various game data in game data store 314, and game 306 stores various game data in game data store 316. During operation, various information regarding a user can be stored as game data, such as the user's performance in various events of the game, items or points accumulated by the user during gameplay, and so forth. Although illustrated as separate game data stores, it should be noted that game data store 314 and game data store 316 can be the same game data store (e.g., implemented by online gaming service 104).

Games 304 and 306 have one or more events that a user can play. An event is a particular part of a game that is played by a user. The nature of a particular event depends on the particular game. For example, an event of a racing game can be a particular track or course that is raced. By way of another example, an event of a shooting game can be a particular target shooting course. It should be noted that a game can have a single event,

As a user plays an event of a game 304, data regarding the performance of the user playing the event is recorded and stored as game data in game data store 314. Similarly, as a user plays an event of a game 306, data regarding the performance of the user playing the event is recorded and stored in game data store 316. The data regarding the performance of the user playing an event refers to data indicating how the user played the event, and can vary based on the particular game. The data regarding the performance of the user playing an event is sufficient to allow the playing of the event by the user to be played back (replayed) at a later time. For example, if the event is a track in a racing game, then the performance of the user playing the event can include information regarding the speed of the user's vehicle at various locations on the track, the direction the user's vehicle is pointing at various locations on the track, the position of the user's vehicle at various locations on the track, any obstacles hit by the user's vehicle, and so forth.

In one or more embodiments, data regarding performance of a user playing an event is recorded, and data regarding one performance of the user playing the event is maintained in game data store 314 or 316. If the user plays the event multiple times, the performance of the user that is deemed best by the game (or alternatively by the user) is the performance that is maintained. Which performance is deemed best can be determined in different manners, such as being the performance that resulted in the shortest time for the user for the event, the performance that resulted in the highest score for the user for the event, and so forth. Alternatively, data regarding any number of performances of the user playing the event can be maintained in game data store 314 or 316.

As discussed above, for a user playing a game 304 or 306 there is an object in the game that represents the user. A user can optionally have multiple objects that represent the user, and can select one or more of the multiple objects when playing a particular event of a game. This object can be, for example, a vehicle (e.g., a car, boat, tank, motorcycle, spaceship, etc.), a character (e.g., a human, alien, monster, etc.), an orb or other symbol, and so forth. A user can customize the object that represents the user in various manners. The customization of the object typically alters the appearance of the object, although various features or capabilities of the rival can also be altered by the customization (e.g., performance of a vehicle or character can be altered, weaponry or defensive characteristics of a vehicle or character can be altered, etc.). For example, a vehicle can be customized to have a particular paint job (e.g., colors, patterns, etc.), to have particular stickers or words written on the vehicle, to include particular components (e.g., chrome door handles, twin exhausts, particular wheels, etc.), and so forth. By way of another example, a character can be customized to have particular clothing, to have particular facial features (e.g., a beard, eyeglasses, etc.), to have particular items (e.g., a particular type of gun or other weapon), and so forth. Data indicating the manner in which the object representing a user is customized is stored as game data in game data store 314 or 316. This data can be subsequently retrieved, allowing the customized object that represents the user to be displayed at a later time.

Games 304 and 306 also support a currency (e.g., in-game currency) or credit that is awarded to users for various actions. This currency or credit can be used in different manners, such as to acquire additional customization options for the object representing the user (e.g., different components that can be added to a vehicle, different weapons), acquire additional objects representing the user (e.g., different vehicles), and so forth.

In addition to a currency or credit, games 304 and 306 can also support an experience point system that is awarded to users for playing the game. These experience points can be awarded based on an amount of time the user plays the game, the manner in which the user plays the game (e.g., which events the user plays), a distance covered in the game (e.g., how many miles of track the user has raced), and so forth.

Games 304 and 306 can also support various groups or clubs to which a user can belong. Which groups or clubs a user can join can be determined in different manners. For example, a user may be allowed to join any group or club that he or she desires, a particular user that creates a group or club may determine which other users can join that group or club, users that are already a member of a group or club can vote to determine whether another user can join the group or club, and so forth. The groups or clubs that a user is a member of can be stored in game data store 314 or 316.

It should be noted that various lists of users can be maintained by asynchronous gameplay coordination module 302 or other systems (e.g., gameplay service 112 of FIG. 1 or other services of or accessible to online gaming service 104 of FIG. 1). These lists can be maintained in game data store 314 or 316, or alternatively other data stores (e.g., implemented as part of or accessible to asynchronous gameplay coordination module 302). These lists of users can include, for example, for each particular user a list of other users that the particular user is a friend with. The particular user can provide various inputs identifying another user as a friend, and that other user can optionally confirm that he or she is a friend of the particular user before being added to the list of friends of the particular user. Friends of the particular user can also be identified in other manners, such as from a social networking service (e.g., accessible to online gaming service 104 of FIG. 1). These lists can also include, for example, for each particular user a list of favorites of the particular user. A favorite of a particular user refers to another user that the particular user has identified as a favorite (e.g., another users that the particular user has indicated he or she enjoys playing against or watching play games). The other user can optionally confirm that he or she can be a favorite of the particular user before being added to the list of favorites of the particular user.

Asynchronous gameplay coordination module 302 includes a game data sharing module 322, a rival selection module 324, and a notification module 326. Generally, asynchronous gameplay coordination module 302 allows a user to asynchronously play an event against another user. System 300 is discussed with reference to a user of game 304 playing an event asynchronously against a user of game 306. However, it should be noted that a user of game 306 can similarly play an event asynchronously against a user of game 304, that a user of game 304 can similarly play an event asynchronously against another user of game 304, or that a user of game 306 can similarly play an event asynchronously against another user of game 306.

Game data sharing module 322 facilitates sharing of game data for different users, allowing one user to play an event against a previously recorded playing of the event by another user. Rival selection module 324 facilitates allowing a user to select another user to play an event against asynchronously. Notification module 326 facilitates notifying a user when he or she has been beaten by another user from an asynchronously played event, and facilitates allowing the notified user to play the event again to respond to the challenge.

When a user desires to asynchronously play an event against another user (also referred to as a rival), the user provides an input requesting to select a rival. Asynchronous gameplay coordination module 302 maintains, for each event of a game, a list of users that have played the event as well as a score for the user playing the event. Module 302 can also maintain various additional information associated with the user, such as a date and/or time the user played the event, a location or position at which the object representing the user started and/or finished when playing the event, and so forth. This list of users can also include (explicitly or inherently) an indicator of the ranking of each user (e.g., a user with a higher score having a higher ranking than a user with a lower score) for the event. The score for a user can take various forms, such as a particular time taken to complete the event by the user, a number of points accumulated by the user when playing the event. In response to the user input requesting to select a rival for an event, rival selection module 324 accesses a list of identifiers of users that have played the event and their scores for the event.

In one or more embodiments, in response to the user input requesting to select a rival for an event, rival selection module 324 automatically selects a rival for the user to play against asynchronously. Rival selection module 324 can use various criteria to automatically select a rival. For example, another user that has the next higher score (e.g., the next faster time) than the requesting user can be automatically selected as the rival. By way of another example, another user that has a score a threshold amount higher than the requesting user (e.g., a time 2 seconds faster than the requesting user, a time that is 97% of the requesting user's time, etc.) is automatically selected as the rival.

In other embodiments, in response to the user input requesting to select a rival for an event, rival selection module 324 displays or otherwise presents at least a portion of the list of identifiers of users that have played the event (and optionally the scores of those users for the event). The full list of identifiers can be displayed, or the list of identifiers can be filtered based on various filter criteria so that the identifiers of users that satisfy the filter criteria are displayed. Any manner of grouping users supported by the game 304 or 306 can be used as a filter criteria. The requesting user can input a request to have the list of identifiers filtered based on different filter criteria. For example, the filter criteria can be users that are friends of the requesting user (e.g., identified to system 300 by the requesting user as a friend of the user, identified as friends by another service (e.g., a social networking service), and so forth), users that are members of a particular group (e.g., a particular car club, a particular fan club), users that the requesting user has identified as favorites, the users with the top scores for the event (e.g., the users with the top 10 or top 50 scores), the users with scores for the event that are at least a threshold amount higher than the requesting user (e.g., a time 2 seconds faster than the requesting user, a time that is 97% of the requesting user's time, etc.), the users with scores for the event that are near the score of the requesting user (e.g., the ten closest in score higher and/or lower than the requesting user, the users with scores that are within a threshold amount higher than the requesting user, etc.), and so forth. The requesting user can input a request to have the list of identifiers filtered based on different filter criteria in different manners, such as by selecting a button or other identifier of filter criteria displayed as part of a user interface, selecting one of multiple buttons on a controller with each button being associated with different filter criteria, selecting a button on a controller that cycles through different filter criteria, and so forth.

FIGS. 4 and 5 illustrate example user interfaces allowing a user to select a rival to play an event against asynchronously in accordance with one or more embodiments. FIG. 4 illustrates an example rival selection user interface (UI) 402 in which a rival has been automatically selected for the requesting user. The user having the next higher score is identified as “User G”, and the score (a time of 2:08:47, which refers to 2 minutes, 8 and 47/100 seconds (or alternatively other times, such as 2 hours, 8 minutes, and 47 seconds)) of that user is displayed. Alternatively, the identifier of that user can be displayed without the score of that user and/or displayed with various additional information associated with the user (e.g., the date and/or time the user played the event, a location or position at which the object representing the user started and/or finished when playing the event, etc.). The user can provide various user inputs to select User G, and begin playing the event against User G asynchronously. Rival selection UI 402 can also optionally display an identifier of the requesting user (e.g., identified as “User A”) and/or the score of the requesting user.

A change rival button 404 is also displayed as part of rival selection UI 402. The requesting user can select change rival button 404 to select a different rival (e.g., based on different filter criteria as discussed above). Although illustrated as a button 404, it should be noted that a user input requesting to select a different rival can be provided in a variety of different manners (e.g., pressing a particular button on a controller, providing a particular hand gesture, and so forth). In response to selection of the change rival button 404, rival selection UI 502 of FIG. 5 is displayed.

Rival selection UI 502 lists various users and their associated scores for the event. Alternatively, identifiers of the users can be displayed without the scores of those users and/or displayed with various additional information associated with the users (e.g., for each user the date and/or time the user played the event, a location or position at which the object representing the user started and/or finished when playing the event, etc.). The user can provide various user inputs to select one of the identified users, and begin playing the event against the identified user asynchronously. Rival selection UI 502 can also optionally display an identifier of the requesting user (e.g., identified as “User A”) and/or the score of the requesting user. The users in rival selection UI 502 satisfy one or more filter criteria, which is the friends filter criteria in the illustrated example. In one or more embodiments rival selection module 324 of FIG. 3 defaults to displaying the users that satisfy the friends filter criteria, although other rival selection module 324 can alternatively default to displaying the users that satisfy other filter criteria.

Rival selection UI 502 also displays a friends button 504, a top 10 button 506, a club 1 button 508, a near me button 510, a favorites button 512, and an automated button 514. Friends button 504 corresponds to friends filter criteria, and in response to user selection of button 504 rival selection UI 502 displays the users that are identified as friends of the requesting user. Friends button 504 is illustrated with cross-hatching to indicate that the friends filter criteria is currently selected.

Top 10 button 506 corresponds to filter criteria identifying the users with the top 10 scores for the event, and in response to user selection of button 510 rival selection UI 502 displays the users having the top 10 scores for the event. Club 1 button 508 corresponds to filter criteria identifying the users in a club or group identified as “Club 1”, and in response to user selection of button 508 rival selection UI 502 displays the users in the club or group identified as “Club 1”. Near me button 510 corresponds to filter criteria identifying the users with scores for the event that are near the score of the requesting user, and in response to user selection of button 510 rival selection UI 502 displays the users with scores for the event that are near the score of the requesting user. Favorites button 512 corresponds to filter criteria identifying favorites of the requesting user, and in response to user selection of button 512 rival selection UI 502 displays the users that are identified as favorites of the requesting user.

Automated button 514 corresponds to automatic selection of a rival. In response to user selection of button 514 rival selection UI 502 displays rival selector UI 402 of FIG. 4.

Although illustrated as separate buttons in the user interface that can be selected by a user, filter criteria can be selected in various other manners. For example, in response to repeated user selection of a button on a controller, UI 502 can cycle through displaying users based on different filter criteria (e.g., displaying the users having the top 10 scores for the event in response to a first selection of the button, displaying the users in the club or group identified as “Club 1” in response to the next selection of the button, and so forth). By way of another example, various hand gestures can be used to select a particular filter criteria, cycle through different filter criteria, and so forth.

Returning to FIG. 3, game data sharing module 322 facilitates sharing of game data for different users, allowing one user to play an event against a previously recorded playing of the event by another user. In response to a user of game 304 selecting a rival, rival selection module 324 communicates an indication of the rival to game data sharing module 322. Game data sharing module 322 in turn obtains the game data for the rival for the event (e.g., from game data store 316), and provides the game data for the rival for the event to game 304. The game data for the rival includes the performance of the rival for the event as well as data indicating the manner in which the object representing the rival is customized.

Game 304 proceeds to allow the user to play the event, controlling his or her object in the event as if he or she were playing by himself or herself (or in real time against another user). Game 304 also plays back, while the user is playing the event, the object representing the rival based on the performance data that is part of the obtained game data for the rival. Thus, the object representing the rival is displayed while the user is playing the game, providing an experience to the user that is as if the user were playing against the rival in real time even though a recording of the rival's performance is being played back (and the event is thus being played asynchronously). It should be noted that the behavior of the object representing the rival is based on the performance data that is part of the obtained game data for the rival, not a generic or other artificial intelligence (AI) generated behavior.

Additionally, the object representing the rival played back by game 304 for the event is the object as customized by the rival. Thus, rather than displaying a generic object as representing the rival, the object as customized by the rival is displayed as representing the rival. Thus, the user is provided with an experience of playing against the rival-specific object rather than some common or generic object.

For example, the event may be a particular track of a car racing game, and the user plays that event by racing his or her car on that particular track. The user can select a rival and have the car as customized by the rival displayed as another car that he or she races against on that track. The performance of the rival's customized car on the track is the performance of the car on the track when the rival previously raced on that track.

Furthermore, in addition to the object representing the rival, one or more additional objects that are game-controlled or are based on AI generated behavior can also be displayed. Continuing with the previous example, in addition to the rival's customized car, one or more additional cars can also be displayed, with the user racing against these one or more additional cars as well as against the rival's customized car.

In one or more embodiments, the object representing the rival changes appearance based on a proximity in the game between the object representing the rival and an object representing the user. As the objects are closer to one another the object representing the rival becomes more transparent, and as the objects are further away from one another the object representing the rival becomes less transparent (more opaque).

Various different criteria or algorithms can be used to determine the transparency of the object representing the rival. In one or more embodiments, if the object representing the rival is at least a threshold distance away from the object representing the user in the game (e.g., 50 feet on a racing track in the game, the length or size of some dimension of the object representing the user in the game, etc.), then the object representing the rival is opaque. If the object representing the rival is less than the threshold distance away from the object representing the user in the game, then the object representing the rival is transparent. The amount of transparency can be determined linearly (e.g., the transparency increases by 2% for each foot closer than 50 feet the object representing the rival is to the object representing the user in the game), or alternatively using other formulas. Thus, as the object representing the rival comes closer to the object representing the user, the object representing the rival becomes more transparent, and as the object representing the rival moves further from the object representing the user, the object representing the rival becomes less transparent (until the threshold distance is met at which point the object representing the rival becomes opaque). Alternatively, a single transparency setting (e.g., 80% transparent) may be used, with the object representing the rival being opaque if the object is at least a threshold distance away from the object representing the user in the game, and the object representing the rival being transparent (whatever the single transparency setting is) if the object is not at least the threshold distance away from the object representing the user in the game.

For example, the event may be a particular track of a car racing game, and the user plays that event by racing his or her car on that particular track. While playing the game asynchronously against a rival, as the rival's car gets closer to the user's car, the rival's car becomes more transparent, thus helping avoid confusion for the user on where his or her car is. However, as the rival's car gets further from the user's car, the rival's car becomes less transparent until a point where the rival's car becomes opaque. Thus, when the rival's car is opaque, it appears to the user that he or she is racing against the rival in real time.

Alternatively, other criteria or algorithms can be used to determine the transparency of the object representing the rival. For example, two threshold distances can be used, such as a close threshold distance (e.g., 20 feet on a racing track in the game), and a far threshold distance (e.g., 50 feet on a racking track game). If the object representing the rival is at least the far threshold distance away from the object representing the user in the game, then the object representing the rival is opaque. If the object representing the rival is less than the close threshold distance away from the object representing the user in the game, then the object representing the rival is at a particular transparency level (e.g., 90% transparent). And the transparency level varies between the far and close threshold distances (e.g., increasing linearly or according to some other calculation as the distance changes from being at the far threshold distance towards the close threshold distance).

It should be noted that, because game 304 plays back, while the user is playing the event, the object representing the rival based on the performance data that is part of the obtained game data for the rival, the object representing the user and the object representing the rival can overlap at times. For example, a car representing the user can be at a same location on a racing track as a car representing the rival, or the car representing the user can be close enough to the car representing the rival that the two cars overlap (e.g., the front end of one car is at the same location on the racing track as the back end of the other car). However, as the rival's car gets closer to the user's car the rival's car becomes more transparent as discussed above, thus helping avoid confusion for the user on where his or her car is.

It should also be noted that a user can play an event asynchronously against multiple rivals concurrently. A user can select multiple rivals, analogous to the selection of a rival as discussed above. Game data for each of the multiple rivals is obtained, and while the user is playing the event, for each of the multiple rivals the object representing the rival is played back based on the performance data that is part of the obtained game data for the rival. Thus, for example, the event may be a particular track of a car racing game, and the user plays that event by racing his or her car on that particular track. The user can select multiple rivals and have the cars as customized by the rivals displayed as other cars that he or she races against on that track. For each of the multiple rivals, the performance of the rival's customized car on the track is the performance of the car on the track when the rival previously raced on that track.

In one or more embodiments, additional information identifying the rival can be displayed to the user while playing the event asynchronously against the rival. This additional information can be provided to game 304 along with the game data for the rival. For example, an identifier of the rival (e.g., a gamer tag or other identifier) can be displayed to the user. This identifier can be displayed on or in close proximity to the object representing the rival (e.g., on or above the rival's vehicle), or alternatively elsewhere.

FIGS. 6 and 7 illustrate an example of the changing of transparency of an object representing a rival in accordance with one or more embodiments. FIG. 6 illustrates an example game UI 600 for a racing game including a car 602 representing the user of the game and a car 604 representing the rival. In game UI 600, the distance between cars 602 and 604 is at least a threshold amount, so car 604 is displayed as opaque. However, FIG. 7 illustrates an example game UI 700 for the race game including cars 602 and 604 in which the distance between cars 602 and 604 is not at least the threshold amount. Accordingly, car 604 is displayed as transparent.

Returning to FIG. 3, in one or more embodiments a user receives a bounty or reward based on his or her performance in playing the event and/or a rating of how difficult the rival is to beat. The bounty or reward is provided using the currency or other credit supported by the game. The user's performance in playing the event can be measured in different manners, such as based on simply whether the user beat the rival (e.g., finished an event in a shorter amount of time than the rival or otherwise obtained a higher score than the rival) against which the user is playing the event asynchronously. The user's performance can also be measured in other manners, such as based on by how much the user beat the rival (e.g., the difference in times or scores for the user and rival for the event), how close the user came to beating the rival (e.g., how close the user's time or score was to the rival's time or score for the event), based on particular actions during performance of the game (e.g., obstacles avoided), and so forth. The rating of how difficult the rival is to beat can be measured in different manners, such as a ranking of the rival, a difference in ranking between the user and the rival, and so forth.

The amount of the bounty or reward can vary, being based at least in part on the user's performance in playing the event and/or a rating of how difficult the rival is to beat. For example, a user may be given a bounty or reward of 50,000 credits if the rival had a ranking of 1, but a reward of only 1,000 credits if the rival had a ranking of 100. By way of another example, a user may be given a bounty or reward equal to the difference in rankings multiplied by 10 (e.g., if the user has a ranking of 900 and the rival has a ranking of 850, then the bounty or reward would be 500 credits (900−850=50, multiplied by 10 to get 500 credits)). By way of yet another example, a user may be given a bounty or reward of 50 credits if the user does not beat the rival, but finished the event in an amount of time or with a score that is within a threshold amount of the amount of time or score with which the rival finished the event.

In one or more embodiments, regardless of whether the user receives a bounty or reward for playing an event, the user is still awarded experience points for playing the event. The experience points can be awarded in different manners as discussed above, such as based on an amount of time the user played the event, a distance covered in playing the event, and so forth.

Additionally, asynchronous gameplay coordination module 302 includes notification module 326. When a user beats a rival in an event, notification module 326 sends a notification to the rival that he or has been beaten. Notification module 326 can determine when a rival has been beaten in various manners, such as receiving an indication from a game 304 or 306 that the user beat the rival, receiving an indication from a module of gameplay service 112 of FIG. 1 that the user beat the rival, and so forth. The notification sent by notification module 326 can be sent in various manners, such as using a messaging system provided by gameplay service 112, using a messaging system provided by game 304 or 306, using a messaging system provided by another service (e.g., a social networking service), and so forth. An indication of how to notify a particular user using a particular messaging system can be obtained in various manners, such as being provided by the user and maintained by account access service 110 of FIG. 1.

The notification sent by notification module 326 includes a user-selectable link (e.g., a hyperlink) to the event that the rival was beaten in, and the user (the rival) can provide various inputs to select the link. The link identifies a location or functionality of gameplay service 112 of FIG. 1 (e.g., of asynchronous gameplay coordination module 120), and an identifier of the event that the rival was beaten in is embedded in the link or otherwise associated with the linked-to location or functionality. In response to user selection of the link, gameplay service 112 notifies a game 304 or 306 to jump to the event that the rival was beaten in, beginning running the game 304 or 306 (or notifying a gaming device 102 of FIG. 1 to begin running the game 304 or 306) if the game is not already running. The rival can then play the event, attempting to better his or her score (e.g., obtain a higher score). The rival can play the event individually, or alternatively against one or more other users in real time or asynchronously (e.g., the rival can select another user as a rival with which to play the event asynchronously, another user (e.g., the user that beat the rival resulting in the notification being sent by notification module 326) that is to be a rival with which to play the event asynchronously can be automatically selected, and so forth).

The notification can optionally include various additional information in addition to the user-selectable link. For example, the notification can include an identifier of the user that beat the rival, an identifier of the event in which the user beat the rival, an indication of the score in the event obtained by the user that beat the rival, an indication of the score in the event obtained by the rival, and so forth.

For example, the event may be a particular track of a car racing game, and a user plays that event by racing his or her car on that particular track. In response to the user beating the rival (e.g., completing the track in a shorter amount of time than the rival), a notification is sent to the rival. The rival receives, at his or her gaming device, the notification that he or she has been beaten in the event. The notification includes a button or other link that the rival can select, in response to which his or her gaming device begins running the racing game and jumps to the event in which the rival was beaten. The rival can then begin playing the event himself or herself in an attempt to complete the track in a shorter amount of time. Thus, the notification can be displayed to the rival, and with simple selection of the button or link in the notification the rival can begin playing the event in which he or she was beaten.

Although the above discussions refer to sending a notification to the rival that the rival has been beaten, similar notifications can be sent at other times. For example, if a rival is almost beaten (e.g., the user comes within a threshold amount of time, score, etc. of beating the rival in the event), then a notification can be sent to the rival notifying the rival that he or she was almost beaten in the event and including a user-selectable link (e.g., a hyperlink) to the event that the rival was almost beaten in.

FIG. 8 is a flowchart illustrating an example process 800 for implementing the asynchronous gameplay with rival display in accordance with one or more embodiments. Process 800 is carried out by a system, such as system 300 of FIG. 3, and can be implemented in software, firmware, hardware, or combinations thereof. Process 800 is shown as a set of acts and is not limited to the order shown for performing the operations of the various acts. Process 800 is an example process for implementing the asynchronous gameplay with rival display; additional discussions of implementing the asynchronous gameplay with rival display are included herein with reference to different figures.

In process 800, a user request to select a rival to play against asynchronously for an event is received (act 802). The event can be an event of a variety of different types of games as discussed above.

In response to the user request, a rival selector user interface is displayed (act 804). The rival selector user interface includes an identification of one or more users that can be selected, and optionally one or more filter criteria that can be selected as discussed above. The rival selector user interface can display a user that has been automatically selected as a rival or alternatively one or more users that satisfy particular filter criteria as discussed above.

A user selection of one of the one or more users is received (act 806). The user selection is a selection of one of the users identified in the rival selector user interface as discussed above.

The selected user is used as the rival to play against asynchronously for the event (act 808). The user from which the user request is received in act 802 can play against the rival asynchronously for the event, with the previously recorded performance of the rival being played back as the user plays the event as discussed above.

FIG. 9 is a flowchart illustrating an example process 900 for implementing the asynchronous gameplay with rival display in accordance with one or more embodiments. Process 900 is carried out by a system, such as system 300 of FIG. 3, and can be implemented in software, firmware, hardware, or combinations thereof. Process 900 is shown as a set of acts and is not limited to the order shown for performing the operations of the various acts. Process 900 is an example process for implementing the asynchronous gameplay with rival display; additional discussions of implementing the asynchronous gameplay with rival display are included herein with reference to different figures.

In process 900, a user request to play against a rival asynchronously for an event is received (act 902). This user request can be, for example, user selection of a rival as discussed above.

Game data for the rival for the event is obtained (act 904). The game data can include both a performance of the rival in the event and data indicating a manner in which an object of the rival is customized by the rival as discussed above.

While the user is playing the event, an object representing the rival is played back based on the obtained game data (act 906). The object representing the rival is played back as customized by the rival, and based on the performance of the rival in the event as discussed above.

FIG. 10 is a flowchart illustrating an example process 1000 for using notifications in accordance with one or more embodiments. Process 1000 is carried out by a system, such as system 300 of FIG. 3, and can be implemented in software, firmware, hardware, or combinations thereof. Process 1000 is shown as a set of acts and is not limited to the order shown for performing the operations of the various acts. Process 1000 is an example process for using notifications; additional discussions of using notifications are included herein with reference to different figures.

In process 1000, a determination is made that a rival has been beaten in an event (act 1002). The determination can be made in various manners as discussed above.

In response to the determination being made in act 1002, a notification is sent to the rival including a link to the event (act 1004). The notification can be sent using various messaging systems as discussed above.

An indication that the link has been selected by the rival is received (act 1006). The indication can be received, for example, by a gaming device, by an asynchronous gameplay coordination module (or other module of a gameplay service) from a gaming device used by the rival, and so forth.

The event in which the rival was beaten is jumped to so that the rival can play the event (act 1008). Jumping to the event includes running the game (if not already running), and the game jumping to the event in which the rival was beaten as discussed above.

Various actions such as communicating, receiving, sending, recording, storing, generating, obtaining, and so forth performed by various modules are discussed herein. A particular module discussed herein as performing an action includes that particular module itself performing the action, or alternatively that particular module invoking or otherwise accessing another component or module that performs the action (or performs the action in conjunction with that particular module). Thus, a particular module performing an action includes that particular module itself performing the action and/or another module invoked or otherwise accessed by that particular module performing the action.

FIG. 11 illustrates an example computing device 1100 that can be configured to implement the asynchronous gameplay with rival display in accordance with one or more embodiments. Computing device 1100 can, for example, be a gaming device 102 of FIG. 1, implement at least part of online gaming service 104 of FIG. 1, be a gaming device 202 of FIG. 2, or implement at least part of system 300 of FIG. 3.

Computing device 1100 includes one or more processors or processing units 1102, one or more computer readable media 1104 which can include one or more memory and/or storage components 1106, one or more input/output (I/O) devices 1108, and a bus 1110 that allows the various components and devices to communicate with one another. Computer readable media 1104 and/or one or more I/O devices 1108 can be included as part of, or alternatively may be coupled to, computing device 1100. Processor 1102, computer readable media 1104, one or more of devices 1108, and/or bus 1110 can optionally be implemented as a single component or chip (e.g., a system on a chip). Bus 1110 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processor or local bus, and so forth using a variety of different bus architectures. Bus 1110 can include wired and/or wireless buses.

Memory/storage component 1106 represents one or more computer storage media. Component 1106 can include volatile media (such as random access memory (RAM)) and/or nonvolatile media (such as read only memory (ROM), Flash memory, optical disks, magnetic disks, and so forth). Component 1106 can include fixed media (e.g., RAM, ROM, a fixed hard drive, etc.) as well as removable media (e.g., a Flash memory drive, a removable hard drive, an optical disk, and so forth).

The techniques discussed herein can be implemented in software, with instructions being executed by one or more processing units 1102. It is to be appreciated that different instructions can be stored in different components of computing device 1100, such as in a processing unit 1102, in various cache memories of a processing unit 1102, in other cache memories of device 1100 (not shown), on other computer readable media, and so forth. Additionally, it is to be appreciated that the location where instructions are stored in computing device 1100 can change over time.

One or more input/output devices 1108 allow a user to enter commands and information to computing device 1100, and also allows information to be presented to the user and/or other components or devices. Examples of input devices include a keyboard, a cursor control device (e.g., a mouse), a microphone, a scanner, and so forth. Examples of output devices include a display device (e.g., a monitor or projector), speakers, a printer, a network card, and so forth.

Various techniques may be described herein in the general context of software or program modules. Generally, software includes routines, programs, applications, objects, components, data structures, and so forth that perform particular tasks or implement particular abstract data types. An implementation of these modules and techniques may be stored on or transmitted across some form of computer readable media. Computer readable media can be any available medium or media that can be accessed by a computing device. By way of example, and not limitation, computer readable media may comprise “computer storage media” and “communication media.”

“Computer storage media” include volatile and non-volatile, 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. Computer storage media include, but are 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, or any other medium which can be used to store the desired information and which can be accessed by a computer. Computer storage media refer to media for storage of information in contrast to mere signal transmission, carrier waves, or signals per se. Thus, computer storage media refers to non-signal bearing media, and is not communication media.

“Communication media” typically embody computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as carrier wave or other transport mechanism. Communication media also include any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media. Combinations of any of the above are also included within the scope of computer readable media.

Generally, any of the functions or techniques described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or a combination of these implementations. The terms “module” and “component” as used herein generally represent software, firmware, hardware, or combinations thereof. In the case of a software implementation, the module or component represents program code that performs specified tasks when executed on a processor (e.g., CPU or CPUs). The program code can be stored in one or more computer readable memory devices, further description of which may be found with reference to FIG. 11. In the case of hardware implementation, the module or component represents a functional block or other hardware that performs specified tasks. For example, in a hardware implementation the module or component can be an application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), complex programmable logic device (CPLD), and so forth. The features of the asynchronous gameplay with rival display techniques described herein are platform-independent, meaning that the techniques can be implemented on a variety of commercial computing platforms having a variety of processors.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A method comprising:

receiving a user request to select a rival to play against asynchronously for an event of a game;

displaying, in response to the user request, a rival selector user interface that includes an identification of one or more users that can be selected;

receiving, a user selection of one of the one or more users; and

using the selected user as the rival to play against asynchronously for the event.

2. A method as recited in claim 1, the displaying comprising displaying a first rival selection user interface in which an identifier of an automatically selected rival is displayed, and in response to a user input displaying a second rival selection user interface in which identifiers of multiple users that have played the event are displayed.

3. A method as recited in claim 2, the identifiers of the multiple users that have played the event being identifiers of users that have played the event filtered based on one or more filter criteria.

4. A method as recited in claim 3, the one or more filter criteria comprising friends of the user from which the user request is received, the multiple users comprising users that have been identified as friends of the user.

5. A method as recited in claim 1, further comprising providing the user from which the user request is received a reward in credit supported by the game based on a performance of the user in playing the event against the rival asynchronously.

6. A method as recited in claim 5, an amount of the reward being based on a ranking of the rival for the event.

7. A method as recited in claim 1, further comprising sending, if the user from which the user request is received beats the rival when playing against the rival asynchronously, a notification to the rival informing the rival that the rival has been beaten by the user in the event.

8. A method as recited in claim 7, further comprising including in the notification a user-selectable link, and notifying the game of the rival to jump to the event in response to a selection of the user-selectable link.

9. A method as recited in claim 1, the game comprising a racing game, and the event comprising a track of the racing game.

10. A method as recited in claim 1, the using further comprising, in response to user selection of one of the one or more users:

obtaining game data for the rival for the event, the game data including both a previously recorded performance of the rival in the event and data indicating a manner in which an object of the rival is customized by the rival; and

playing back, while the user is playing the event and based on the performance data, the object as customized by the rival.

11. A method as recited in claim 10, further comprising increasing, as the object as customized by the rival and an object representing the user become closer, a transparency of the object as customized by the rival.

12. One or more computer storage media having stored thereon multiple instructions that, when executed by one or more processors of a gaming device, cause the one or more processors to:

receive a user request to play against a rival asynchronously for an event of a game;

obtain game data for the rival for the event, the game data including both a previously recorded performance of the rival in the event and data indicating a manner in which an object of the rival is customized by the rival; and

play back, while the user is playing the event and based on the performance data, the object as customized by the rival.

13. One or more computer storage media as recited in claim 12, the multiple instructions further causing the one or more processors to increase, as the object as customized by the rival and an object representing the user become closer, a transparency of the object as customized by the rival.

14. One or more computer storage media as recited in claim 12, the game comprising a racing game, the object as customized by the rival comprising a vehicle, and the customization comprising an appearance of the vehicle as altered by the rival.

15. One or more computer storage media as recited in claim 12, the multiple instructions further causing the one or more processors to provide to the user a reward in credit supported by the game based on a performance of the user in playing the event.

16. One or more computer storage media as recited in claim 15, an amount of the reward being based on a ranking of the rival for the event.

17. One or more computer storage media as recited in claim 12, the multiple instructions further causing the one or more processors to send, if the user beats the rival when playing the event, a notification to the rival informing the rival that the rival has been beaten by the user in the event.

18. One or more computer storage media as recited in claim 17, the notification including a user-selectable link, and the multiple instructions further causing the one or more processors to notify a game of the rival to jump to the event in response to a selection of the user-selectable link.

19. One or more computer storage media as recited in claim 12, the user request including a user-selected rival from a set of identifiers of other users that have previously played the event.

20. A method comprising:

receiving a user request to select a rival to play against asynchronously for an event of a game, the game comprising a racing game and the event comprising a track of the racing game;

displaying, in response to the user request, a rival selector user interface that includes an identification of one or more users that can be selected and one or more filter criteria that can be selected;

receiving, a user selection of one of the one or more users to be the rival;

obtain game data for the rival for the event, the game data including both a previously recorded performance of the rival in the event and data indicating a manner in which an object of the rival is customized by the rival; and

play back, while the user is playing the event and based on the performance data, the object as customized by the rival, including increasing, as the object as customized by the rival and an object representing the user become closer in the game, a transparency of the object as customized by the rival.