U.S. patent application number 13/280194 was filed with the patent office on 2013-04-04 for asynchronous gameplay with rival display.
This patent application is currently assigned to MICROSOFT CORPORATION. The applicant listed for this patent is Jonathan P. Knoles, Matthew J. Monson, Zachary A. Proffitt, Jun Taniguchi, Michael Paul Wright. Invention is credited to Jonathan P. Knoles, Matthew J. Monson, Zachary A. Proffitt, Jun Taniguchi, Michael Paul Wright.
Application Number | 20130084969 13/280194 |
Document ID | / |
Family ID | 47993103 |
Filed Date | 2013-04-04 |
United States Patent
Application |
20130084969 |
Kind Code |
A1 |
Knoles; Jonathan P. ; et
al. |
April 4, 2013 |
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.
Inventors: |
Knoles; Jonathan P.;
(Woodinville, WA) ; Monson; Matthew J.; (Kirkland,
WA) ; Wright; Michael Paul; (Redmond, WA) ;
Proffitt; Zachary A.; (Duvall, WA) ; Taniguchi;
Jun; (Redmond, WA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Knoles; Jonathan P.
Monson; Matthew J.
Wright; Michael Paul
Proffitt; Zachary A.
Taniguchi; Jun |
Woodinville
Kirkland
Redmond
Duvall
Redmond |
WA
WA
WA
WA
WA |
US
US
US
US
US |
|
|
Assignee: |
MICROSOFT CORPORATION
Redmond
WA
|
Family ID: |
47993103 |
Appl. No.: |
13/280194 |
Filed: |
October 24, 2011 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61542256 |
Oct 2, 2011 |
|
|
|
Current U.S.
Class: |
463/29 |
Current CPC
Class: |
A63F 13/795 20140902;
A63F 13/803 20140902; A63F 2300/57 20130101; A63F 13/798 20140902;
A63F 2300/636 20130101; A63F 13/497 20140902; A63F 2300/558
20130101; A63F 2300/5593 20130101; A63F 2300/634 20130101; A63F
2300/5546 20130101; A63F 2300/8017 20130101; A63F 2300/5566
20130101 |
Class at
Publication: |
463/29 |
International
Class: |
A63F 9/24 20060101
A63F009/24 |
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.
Description
RELATED APPLICATIONS
[0001] 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
[0002] 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
[0003] 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.
[0004] 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.
[0005] 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
[0006] The same numbers are used throughout the drawings to
reference like features.
[0007] FIG. 1 illustrates an example system implementing the
asynchronous gameplay with rival display in accordance with one or
more embodiments.
[0008] FIG. 2 illustrates an example gaming device and display in
additional detail in accordance with one or more embodiments.
[0009] FIG. 3 illustrates an example system implementing the
asynchronous gameplay with rival display in accordance with one or
more embodiments.
[0010] 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.
[0011] 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.
[0012] FIG. 8 is a flowchart illustrating an example process for
implementing the asynchronous gameplay with rival display in
accordance with one or more embodiments.
[0013] FIG. 9 is a flowchart illustrating another example process
for implementing the asynchronous gameplay with rival display in
accordance with one or more embodiments.
[0014] FIG. 10 is a flowchart illustrating an example process for
using notifications in accordance with one or more embodiments.
[0015] 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
[0016] 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.
[0017] 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.
[0018] 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.
[0019] 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.
[0020] 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.
[0021] 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.
[0022] 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.
[0023] 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.
[0024] 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.
[0025] 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.
[0026] 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.
[0027] 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.
[0028] 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.
[0029] 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.
[0030] 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.
[0031] 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.
[0032] 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.
[0033] 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.
[0034] 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.
[0035] 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.
[0036] 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).
[0037] 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,
[0038] 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.
[0039] 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.
[0040] 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.
[0041] 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.
[0042] 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.
[0043] 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.
[0044] 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.
[0045] 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.
[0046] 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.
[0047] 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.
[0048] 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.
[0049] 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.
[0050] 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.
[0051] 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.
[0052] 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.
[0053] 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.
[0054] 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.
[0055] 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.
[0056] 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.
[0057] 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.
[0058] 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.
[0059] 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.
[0060] 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.
[0061] 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.
[0062] 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).
[0063] 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.
[0064] 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.
[0065] 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).
[0066] 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.
[0067] 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.
[0068] 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.
[0069] 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.
[0070] 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.
[0071] 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.
[0072] 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.
[0073] 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.
[0074] 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).
[0075] 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.
[0076] 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.
[0077] 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.
[0078] 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.
[0079] 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.
[0080] 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.
[0081] 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.
[0082] 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.
[0083] 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.
[0084] 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.
[0085] 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.
[0086] 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.
[0087] 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.
[0088] 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.
[0089] 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.
[0090] 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.
[0091] 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.
[0092] 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.
[0093] 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.
[0094] 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.
[0095] 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).
[0096] 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.
[0097] 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.
[0098] 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."
[0099] "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.
[0100] "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.
[0101] 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.
[0102] 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.
* * * * *