U.S. patent application number 12/437324 was filed with the patent office on 2010-11-11 for massively multiplayer game message scheduling.
This patent application is currently assigned to MICROSOFT CORPORATION. Invention is credited to Felix Livni, Lowell N. Manners, Michael Scavezze, Hardik Shah, Jay Thaler.
Application Number | 20100285885 12/437324 |
Document ID | / |
Family ID | 43062660 |
Filed Date | 2010-11-11 |
United States Patent
Application |
20100285885 |
Kind Code |
A1 |
Livni; Felix ; et
al. |
November 11, 2010 |
MASSIVELY MULTIPLAYER GAME MESSAGE SCHEDULING
Abstract
A massively multiplayer game management service includes a
scheduling module that establishes a message receiving period and a
game data aggregation period. The massively multiplayer game
management service further includes a message receiving module
that, during the message receiving period that overlaps at least
part of the game data aggregation period, receives a message from a
player client. The message may include an identifier and an
execution time that follows the game data aggregation period. The
massively multiplayer game management service further includes a
message sending module that sends game data, aggregated in a game
space location corresponding to the identifier, to the player
clients upon occurrence of the execution time.
Inventors: |
Livni; Felix; (Seattle,
WA) ; Manners; Lowell N.; (Kirkland, WA) ;
Scavezze; Michael; (Bellevue, WA) ; Shah; Hardik;
(Bellevue, WA) ; Thaler; Jay; (Kirkland,
WA) |
Correspondence
Address: |
MICROSOFT CORPORATION
ONE MICROSOFT WAY
REDMOND
WA
98052
US
|
Assignee: |
MICROSOFT CORPORATION
Redmond
WA
|
Family ID: |
43062660 |
Appl. No.: |
12/437324 |
Filed: |
May 7, 2009 |
Current U.S.
Class: |
463/42 |
Current CPC
Class: |
A63F 2300/5593 20130101;
A63F 13/44 20140902; A63F 2300/807 20130101; A63F 13/358
20140902 |
Class at
Publication: |
463/42 |
International
Class: |
A63F 9/24 20060101
A63F009/24 |
Claims
1. A massively multiplayer game management service comprising: a
scheduling module configured to establish a message receiving
period and a game data aggregation period; a message receiving
module configured to, during the message receiving period that
overlaps at least part of the game data aggregation period, receive
a message from one or more of a plurality of player clients, the
message including a game space location identifier and an execution
time that follows the game data aggregation period; and a message
sending module configured to send game data, aggregated in a game
space location corresponding to the game space location identifier,
to the one or more of the plurality of player clients upon
occurrence of the execution time specified in the message.
2. The service of claim 1, further comprising an aggregating module
configured to, during the game data aggregation period, aggregate
player data received from the plurality of player clients, for each
of the plurality of player clients the player data including a
selected game space location identifier, and the player data being
aggregated to a game space location corresponding to the selected
game space location identifier to generate game data.
3. The service of claim 1, wherein the message receiving module is
further configured to, at any time not during the message receiving
period, reject the message received from the one or more of the
plurality of player clients.
4. The service of claim 1, wherein the scheduling module is
configured to establish the message receiving period and the game
data aggregation period based on game logic.
5. The service of claim 4, wherein the game logic is driven by one
or more messages received from a selected player client.
6. The service of claim 5, wherein the execution time varies based
on content of the one or more messages received from the selected
player client by the message receiving module.
7. The service of claim 5, wherein the scheduling module is
configured to establish the message receiving period and the game
data aggregation period based on content of the one or more
messages received from the selected player client.
8. The service of claim 4, wherein the game logic is driven by one
or more messages received from a plurality of player clients.
9. The service of claim 1, wherein the message receiving period,
the game data aggregation period, and the execution time are set
relative to a start time of a massively multiplayer game.
10. The service of claim 1, wherein the message receiving period,
the game data aggregation period, and the execution time are set
relative to a start time of a massively multiplayer game only
during a game mode where a selected player client does not drive
game logic.
11. A method for scheduled execution of messages to drive a
massively multiplayer game comprising, at a game management
service: establishing a message receiving period and a game data
aggregation period; during the message receiving period that
overlaps at least part of the game data aggregation period,
receiving a message from one or more of a plurality of player
clients, the message including a game space location identifier and
an execution time that follows the game data aggregation period;
and sending game data aggregated in a game space location
corresponding to the game space location identifier to the one or
more of the plurality of player clients upon occurrence of the
execution time specified in the message.
12. The method of claim 11, further comprising: at any time not
during the message receiving period, rejecting the message received
from the one or more of the plurality of player clients.
13. The method of claim 11, wherein the message receiving period
and the game data aggregation period are established based on game
logic.
14. The method of claim 13, wherein the game logic is driven by one
or more messages received from a selected player client.
15. The method of claim 14, wherein establishing comprises
establishing the message receiving period and the game data
aggregation period based on content of the one or more messages
received from the selected player client.
16. The method of claim 13, wherein game logic is driven by one or
more messages received from a plurality of player clients.
17. The method of claim 11, wherein the message receiving period,
the game data aggregation period, and the execution time are set
relative to a start time of a massively multiplayer game.
18. The method of claim 11, wherein the message receiving period,
the game data aggregation period, and the execution time are set
relative to a start time of a massively multiplayer game only
during a game mode where a selected player client does not drive
game logic.
19. A method for scheduled execution of messages to drive a
massively multiplayer computer game comprising, at a game
management service: establishing a game data aggregation period and
a request message receiving period; sending a question message to a
plurality of player clients, the question message including a
plurality of selectable game space location identifiers; receiving
an answer message from at least some of the plurality of player
clients, each answer message including a selected game space
location identifier of the plurality of selectable game space
location identifiers; during the game data aggregation period,
aggregating the selected game space location identifiers received
from the at least some of the plurality of player clients to game
space locations corresponding to the selected game space location
identifiers to generate game data; during a request message
receiving period that overlaps at least part of the game data
aggregation period, receiving a request message from one or more
player clients, the request message including a requested game
space location identifier and an execution time that follows the
game data aggregation period; and sending game data aggregated in a
game space location corresponding to the requested game space
location identifier to the one or more player clients upon
occurrence of the execution time specified in the request
message.
20. The method of claim 19, wherein establishing comprises
establishing the game data aggregation period and the request
message receiving period based on game logic that is driven by one
or more messages received from a selected player client, and the
execution time varies based on content of the one or more messages
received from the selected player client.
Description
BACKGROUND
[0001] A massively multiplayer game may have a large number of
players that interact remotely via a client-sever network. During
game play, a server system may send messages that include game data
to each of the clients. The game data may be used by the clients to
execute the game. In a massively multiplayer game where all players
see the same game view, all clients must consume the same game
data, otherwise players will have incongruent views of what is
happening in the game, which may result in the game
splintering.
[0002] In order to achieve a congruent game view for all players,
specific times when the clients may attempt to read/write data can
be established. However, these time restrictions may inflate delays
associated with sending/receiving message that are due to the large
number of clients in communication with the server system. The
inflation of such delays may create a fastest possible game pacing
that is considered too slow. Slow game pacing may cause players to
become disinterested and stop playing the game.
SUMMARY
[0003] Accordingly, various embodiments are disclosed herein that
relate to scheduling messages so as to increase the game pacing
without creating a splintered game view. For example, one
embodiment provides a massively multiplayer game management
service. The massively multiplayer game management service
comprises a scheduling module that establishes a message receiving
period and a game data aggregation period. The massively
multiplayer game management service further comprises a message
receiving module that, during the message receiving period that
overlaps at least part of the game data aggregation period,
receives a message from player clients. The message may comprise a
game space location identifier and an execution time that follows
the game data aggregation period. The massively multiplayer game
management service further comprises a message sending module that
sends game data, aggregated in a game space location corresponding
to the game space location identifier, to the player clients upon
occurrence of the execution time specified in the message.
[0004] 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. Furthermore, the claimed subject matter is not
limited to implementations that solve any or all disadvantages
noted in any part of this disclosure.
BRIEF DESCRIPTION OF THE DRAWINGS
[0005] FIG. 1 is a schematic diagram of an embodiment of a
computing system in which a massively multiplayer game may be
implemented.
[0006] FIG. 2 is a timing diagram showing message passing between a
massively multiplayer game management service and player
clients.
[0007] FIG. 3 is a flow diagram of an embodiment of a method for
scheduled execution of messages to drive a massively multiplayer
game.
[0008] FIGS. 4A-4B are timing diagrams of messages that may be sent
to a massively multiplayer game management service.
DETAILED DESCRIPTION
[0009] The present disclosure is directed to scheduling execution
of messages in a massively multiplayer game so as to reduce delays
associated with message latency as well as to prevent splintering
of a player's game view as a result of receiving incongruent game
data. This may be achieved by providing player clients with the
ability to request game data as it exists at a specific time. In
other words, the present disclosure is directed to enabling
messages to be received and held for execution at a specified time
after the game data is aggregated. By allowing the messages to be
received before the time at which the game data is aggregated, game
pacing need not be slowed to account for delays associated with
messaging latency upon or after game data aggregation. Furthermore,
by sending the game data to player clients upon occurrence of the
specified execution time after the game data is aggregated, all
player clients may consume the same congruent game data and
consequently each player may have the same view of what is
happening in the game.
[0010] The present disclosure is broadly applicable, although the
examples discussed herein are primarily directed to a multiplayer
game that involves a large number of participants (e.g., 200,000
participants). Many of the examples used herein will be explained
in terms of a massively multiplayer, round based, trivia game such
as the game 1 vs 100. However, the herein described execution can
be applied to a variety of different games without departing from
the spirit of this disclosure.
[0011] In one implementation, 1 vs 100 may include a game mode
where a player (i.e., "The One") that is selected from a total
group of players competes against a group of players (i.e., "The
Mob") that is selected from the total group of players to answer
trivia questions in a round. In one implementation, the Mob
comprises one hundred players. Further, players not selected from
the total group of players (i.e., "The Crowd") may selectively
participate in the round based on actions of the One. Otherwise,
the crowd may play along without affecting the outcome of the
round. In this game mode, actions of the One drive the game play of
the round. For example, if the One answers a question incorrectly
the round ends. As another example, if the One selects a prize
instead of answering the current trivia question the round ends. As
another example, if the One requests help from the Crowd, the Crowd
may selectively participate in the round (e.g., provide an answer
to a question).
[0012] In another game mode, no player is selected from the group
of total players to act as the One and a group of players are
selected from the total group of players to act as the Mob and
compete against one another to answer trivia questions in a round.
In this game mode, players not selected from the total group of
players to act as the Mob are placed in the Crowd. The number of
players selected to act as the Mob may be the same or different
than the other game mode. Further, the players in the Crowd may
play along without affecting the outcome of the round. In this game
mode, game play may be set according to a predefined schedule that
may be based on the start time of the round.
[0013] Note that in each round a different player may be selected
from the group of total players to act as the One and a different
group of players may be selected from the total group of players to
acts as the Mob.
[0014] In each round of the game, the One and the Mob are provided
with trivia questions. If a member of the Mob answers a trivia
question incorrectly that member is eliminated from the Mob. The
round ends when the One answers a trivia question incorrectly, all
of the members of the Mob are eliminated, the One chooses a prize
instead of answering a trivia question, or a predetermined time
limit is reached.
[0015] Other games that use the herein described execution
scheduling may not include game mechanics that include the One, the
Mob, and/or the Crowd. It is to be understood that execution
scheduling can be used with a variety of different games played by
virtually any number of players. The herein described execution
scheduling is particularly well suited for massively multiplayer
games in which message latency and/or game splintering pose serious
challenges.
[0016] FIG. 1 is a schematic diagram of a computing system 100 in
which a massively multiplayer game such as 1 vs 100 may be
implemented. The computing system 100 may comprise a plurality of
player clients 102. The massively multiplayer game may be executed
locally at each player client based on game data that is received
from a massively multiplayer game management service 118. The
plurality of player clients 102 may comprise the total group of
players that play the massively multiplayer game. As discussed
above, in some game modes, the plurality of player clients 102 may
comprise a player client that is selected from the plurality of
player clients to act as the One 104, a group of player clients
selected from the plurality of player clients 102 to act as the Mob
106, and a group of player clients selected from the plurality of
player clients 102 to act as the Crowd 108. In a given round of the
game, the One 104 may comprise a player client 104A, the Mob 106
may comprise a group of player clients comprising a player client
106A, a player client 106B, through a player client 106N, and the
Crowd 108 may comprise a player client 108A, a player client 108B,
through a player client 108N. It is to be understood that each
player client may join the game via a network 110, and thus each
player client may be remotely located relative to game management
service 118 and/or other player clients.
[0017] Note in each round, the plurality of player clients 102 may
be grouped differently or the same. For example, in a first round,
player client 106A may be selected to be in the Mob and in a second
round, player client 106A may be selected to be in the Crowd.
Further in each round, the Mob 106 and the Crowd 108 each may
comprise a different number or the same number of player clients.
For example, in a first round, the Mob may comprise one hundred
player clients and in a second round the Mob may comprise five
hundred player clients. The number of player clients selected to be
in the Mob may differ based on the game mode and/or the total
number of player clients playing the game.
[0018] Continuing with FIG. 1, computing system 100 may comprise a
massively multiplayer game management service 118 that may be
configured to communicate with each of the plurality of player
clients 102 via a network 110. For purposes of simplicity network
links only connecting the different groups of the plurality of
player clients 102 are shown, although it will be appreciated that
each player client may be linked to massively multiplayer game
management service 118. The network 110 may be virtually any
suitable network that facilitates communication between computing
devices. For example, network 110 may comprise a wide area network
(WAN), such as the Internet.
[0019] The massively multiplayer game management service 118 may be
configured to manage game flow so that each player client receives
game data that results in each player having the same view of what
is going on in the game. More particularly, massively multiplayer
game management service 118 may be configured to schedule execution
of messages received from the plurality of player clients 102 that
drive the game flow. A message 112 may comprise player data 113
that may be generated as a result of game play. In some
embodiments, the player data 113 may comprise a game space location
identifier 114 that corresponds to a game space location 130 of
game space 128. The game space location identifier may be used to
store the player data in a game space corresponding to the game
space location identifier. It is to be understood that a game space
and/or game space location, as used herein, is used to refer to any
suitable mechanism for organizing, storing, searching, and/or
retrieving game information. Furthermore, a game space location
identifier, as used herein, can be any suitable mechanism for
linking and/or referencing such game information, regardless of a
particular data structure or storage model used in a particular
embodiment. Further, message 112 may comprise an execution time 116
at which massively multiplayer game management service 118 is to
execute that message.
[0020] Each round of the game may comprise one or more question and
answer loops. In each question and answer loop, massively
multiplayer game management service 118 may send a question message
to each player client. The question message may comprise a
plurality of selectable answers. Each player may select one of the
plurality of selectable answers, which generates an answer message
including player data that comprises a game space location
identifier that corresponds to the selectable answer. The message
may further comprise an execution time at which the message is to
be executed (e.g., the time at which the player data is to be
aggregated to the game space location to generate game data). The
answer message may be sent to massively multiplayer game management
service 118. Further, upon aggregation of game data each of the
plurality of player clients 102 may send a request message to
massively multiplayer game management service 118 to request game
data. The request message may comprise a game space location
identifier for which game data is requested. Further, the request
message may comprise an execution time at which the request message
is to be executed. Note that a question and answer loop may
comprise one or more question messages, one or more answer
messages, and/or one or more request messages.
[0021] The game space 128 may act as a directory that is used to
organize game data 132 for each round of the game. The massively
multiplayer game management service and/or game space 128 may be
hosted by a server system (not shown) that may include one or more
servers. In some cases different servers may be designated for
store and serve different aspects of the game, and is some cases a
single server may store and serve the entire game. Examples of game
data 132 may comprise an aggregation of how many players selected a
particular answer, a selection of the One, a selection of a
specified player client, a score, a prize, a question, time
remaining in a round, etc.
[0022] The game space 128 may comprise a plurality of game space
locations 134. A game space location 130 may be a storage space or
virtual bucket in which game data is aggregated to and/or held. In
some cases, player data may be aggregated to a game space location
to generate game data. For example, a game space may hold a first
selectable answer to a question. Correspondingly, a request message
may request that game space location in order to find out how many
players selected the first selectable answer to the question. In
some cases, a game space location may comprise game data generated
from a message received from the One. For example, the game data
may correspond to the One's selection of a prize. Correspondingly,
a request message may request that game space location in order to
find out if the round is to continue or not based on the One's
selection.
[0023] As one particular example, a game space location identifier
is formatted as such: game1.round1.question1.answerA. The game
space identifier may be used to request game data corresponding to
how many players selected answer A for the first question of the
first round of the first game. Note that other identifier formats
may be used.
[0024] The massively multiplayer game management service 118 may
comprise a scheduling module 120, a message receiving module 122, a
message sending module 124, and an aggregating module 126.
[0025] The scheduling module 120 may be configured to establish a
message receiving period and a game data aggregation period based
on game logic. In some cases, the game logic is driven by one or
more messages received from a selected player client. For example,
in some game modes where a player is selected to act as the One,
messages received from the selected player client or actions of the
One may drive the timeline of the game. In other words, the One may
determine game logic such as when a round ends or when a question
is asked. The scheduling module 120 may be configured to establish
the message receiving period and the game data aggregation period
based on content of the one or more messages received from the
selected player client. For example, a message receiving period and
a game data aggregation period may be set differently based on
whether the One chooses to answer a question, ask for help to
answer a question, chooses to accept a prize instead of answering a
question, etc.
[0026] In some cases, the game logic is driven by one or more
messages received from a plurality of player clients. For example,
in some game modes where no player is selected to act as the One,
messages received from a plurality of player clients or actions
taken by members of the Mob may drive game logic such as messages
that cause players to be eliminated from the Mob, which may dictate
when a round ends, what prizes are awarded, etc. Further, in some
game modes where no player is selected to act as the One, the round
may be played for a predetermined period of time and the message
receiving period, the game data aggregation period, and the
execution time may be set relative to a start time of a round of
the massively multiplayer game. In some cases, a round may be
played for a predetermined period of time only during a game mode
where a selected player client (e.g., the One) does not drive game
logic. Accordingly, the message receiving period, the game data
aggregation period, and the execution time may be set relative to a
start time of a massively multiplayer game only during a game mode
where a selected player client does not drive game logic.
[0027] The message receiving module 122 may be configured to,
during the message receiving period that overlaps at least part of
the game data aggregation period, receive a message 112 from one or
more of a plurality of player clients 102. The message receiving
module 122 may be configured to, at any time not during the message
receiving period, reject a message received from the one or more of
the plurality of player clients. Accordingly, this helps avoid
player clients from receiving game data that is not fully
aggregated that would result in a player having a splintered view
of the game.
[0028] The message sending module 124 may be configured to send
game data to one or more requesting player clients at an execution
time specified in a message received by message sending module 122.
In some embodiments, game data may be aggregated in a game space
location corresponding to the game space location identifier in the
message. Although, it will be appreciated that game data may be
requested using mechanisms other than a game space location
identifier. The game data may be sent to one or more of a plurality
of player clients that request the game data upon occurrence of the
execution time specified in the message. Note that the requesting
player clients specify the execution time independently from the
time the message receiving module receives the message. However, if
a client does not specify an execution time, the server will
execute the message based on when it is received. In the game mode
where a selected player client drives the timeline, all clients
will use the content of messages (not the arrival time) to
determine which code to run, which messages to send, and therefore
which execution times to set. Further, note that all messages sent
to the massively multiplayer game management service may include a
client specified execution time.
[0029] The aggregating module 126 may be configured to, during the
game data aggregation period, aggregate player data received from
the plurality of player clients to generate game data. In some
embodiments, for each of the plurality of player clients the player
data may comprise a selected game space location identifier. The
player data may be aggregated to a game space location
corresponding to the selected game space location identifier to
generate game data.
[0030] FIG. 2 is a timing diagram 200 that shows messages that may
be sent and received between a massively multiplayer game
management service 118 and the One 104, the Mob 106, and the Crowd
108. Again, it is to be understood that while the 1 vs 100 game
mechanics are used as a platform for describing execution
scheduling, the herein described execution scheduling may be
applied to any number of different games or other massive
participation network events.
[0031] At 202, massively multiplayer game management service 118
sends a question message to the One 104, the Mob 106, and the Crowd
108 during a question message sending period 201. The question
message may comprise a plurality of selectable game space location
identifiers that correspond to answers stored in the game space.
Although the question messages are shown being sent by the
massively multiplayer game management service at different times
and received by the One, the Mob, and the Crowd at different times,
in some cases the question messages may be sent from the massively
multiplayer game management service at the same time and/or
received by the One, the Mob, and/or the Crowd at the same
time.
[0032] Upon sending of the question message, an answer receiving
message period 203 begins. At any time during the answer message
receiving period, an answer message may be received by massively
multiplayer game management service 118. The answer message may
comprise a selected game space location identifier of the plurality
of selectable game space location identifiers included in the
question message. Note that an instance of the question message may
be sent to every member of the Mob 106 and every member of the
Crowd 108, although a single message is shown for each group in
order to simplify the explanation.
[0033] At 204, an answer message is received from the One. An
answer message is also received from the Mob and the Crowd during
the answer message receiving period. Note that an answer message
may be received from any or all player clients that are members of
the Mob and/or the Crowd. Although the answer messages are shown
being sent from the One, the Mob, and the Crowd at different times
and received by the massively multiplayer game management service
at different times, in some cases the answer message may be sent
from the One, the Mob, and/or the Crowd at the same time and/or
received by the massively multiplayer game management service at
the same time. In some cases, a data aggregation period, a request
message receiving period, and/or an execution time may be
established based on content of the answer message from the One, as
indicated by dotted line 209. For example, different time periods
may be established based on whether the One selects an answer to
the question, asks for help to answer the question, or chooses to
accept a prize instead of answering the question.
[0034] Furthermore, the time at which the first answer message is
received may be the beginning of the game data aggregation period
205. During the game data aggregation period player data received
by the massively multiplayer game management service may be
aggregated in the corresponding game space location to generate
game data.
[0035] After sending the answer message, a player client may send a
request message to request game data that may correspond to the
question and answer loop or other game play factors. For example,
the request message may be used to request validation (e.g., was my
selected answer correct), help (e.g., what answer did the highest
ranked player choose), statistics (e.g., how many players selected
the second answer), game status (e.g., how many players remain in
the Mob), etc. As discussed herein, the response to many such
requests may be dependent on how game data exists at a particular
moment, and such game data may change responsive to the actions of
one or more of the many player clients. Accordingly, in order to
provide congruent responses to such requests, the requests can be
responded to in accordance with game data as the game data exists
at a scheduled execution time.
[0036] The request message may comprise a game space location
identifier corresponding to a game space location holding game data
requested by the player client. The request message may comprise an
execution time at which the game data is aggregated so that the
player client receives game data that does not result in a player
having a splintered view of what is going on in the game.
[0037] At 206, a request message is received by the massively
multiplayer game management service from the One prior to a request
message receiving period 207. Because the request message is
received prior to the request message receiving period, the message
is rejected by massively multiplayer game management service 118 in
order to prevent splintering of the game. The One receives an
indication that the request message has been rejected and resends
the request message. This time the request message is received
during the request message receiving period and is held until the
execution time. The Mob and the Crowd send request messages that
are received during the request message receiving period and thus
are held until the execution time. The request message receiving
period may overlap at least part of the game data aggregation
period so as to reduce the amount of time game play is slowed to
account for message collection latency after aggregation of the
game data. Although the request messages are shown being sent by
the One, the Mob, and the Crowd at different times and received by
the massively multiplayer game management service at different
times, in some cases the request messages sent by the One, the Mob,
and/or the Crowed may be sent at the same time and/or received by
the massively multiplayer game management service at the same time.
Note that a request message may be received from any or all player
clients that are members of the Mob and/or the Crowd.
[0038] At 208, the execution time occurs at a time following the
game data aggregation period when the game data has been
aggregated. Note that the clients specify the execution time in
each message independently from the time that the message receiving
module received the message. However, if a client does not specify
an execute time, the message may be executed based on the time it
is received. Thus, the massively multiplayer game management
service sends the requested game data to the player clients that
requested the game data (e.g., the One, requesting members of the
Mob, requesting members of the Crowd). All of the player clients
receive the same requested game data that has been aggregated so
that the players do not have a splintered view of what is going on
in the game.
[0039] The above described timing diagram shows one example of
message communications that may occur a plurality of times during a
round of a game. In some cases, the answer message receiving
period, the game data aggregation period, the request message
receiving period, and/or the execution time maybe predetermined
based on start time of the round. Note that although the above
described messages are labeled respectively as question, answer,
and request messages within the context of 1 vs 100, it will be
appreciated that message execution scheduling as described herein
may apply to virtually any suitable type of request/response
messaging communications.
[0040] FIG. 3 is a flow diagram of an embodiment of a method 300
for scheduled execution of messages to drive a massively
multiplayer computer game. The method 300 may be performed at
massively multiplayer game management service 118. At 302, the
method may comprise establishing a game data aggregation period and
a request message receiving period. The game data aggregation
period and the request message receiving period may be established
by scheduling module 120. In some embodiments, establishing may
comprise establishing the game data aggregation period and the
request message receiving period based on game logic that is driven
by one or more messages received from a selected player client. The
execution time may vary based on content of one or more messages
received from the selected player client. In some embodiments,
establishing may comprise establishing the message receiving period
and the game data aggregation period based on content of the one or
more messages received from the selected player client.
[0041] At 304, the method may comprise sending a question message
to a plurality of player clients. The question message may comprise
a plurality of selectable game space location identifiers. The
message sending module 124 may send the question message to the
plurality of player clients.
[0042] At 306, the method may comprise receiving an answer message
from at least some of the plurality of player clients. Each answer
message may comprise a selected game space location identifier of
the plurality of selectable game space location identifiers. The
message receiving module 122 may receive the answer message from
the at least some of the plurality of player clients.
[0043] At 308, the method may comprise, during the game data
aggregation period, aggregating the selected game space location
identifiers received from the at least some of the plurality of
player clients to game space locations corresponding to the
selected game space location identifiers to generate game data. The
aggregating module 126 may aggregate the selected game space
location identifiers to the corresponding game space locations.
[0044] At 310, the method may comprise, during a request message
receiving period that overlaps at least part of the game data
aggregation period, receiving a request message from one or more
player clients. The request message may comprise a requested game
space location identifier and an execution time that follows the
game data aggregation period. The message receiving module 122 may
receive the request message from the one or more player
clients.
[0045] At 312, the method may comprise sending game data aggregated
in a game space location corresponding to the requested game space
location identifier to the one or more player clients upon
occurrence of the execution time specified in the request message.
The message sending module 124 may send the request message to the
one or more player clients.
[0046] At 314, the method may comprise, at any time not during the
message receiving period, rejecting a message received from the one
or more of the plurality of player clients. The message receiving
module 122 may reject the message received at any time not during
the message receiving period.
[0047] The above described method may be performed one or more
times during a massively multiplayer game. The method enables
messages that request game data prior to a time at which the game
data is aggregated to be received and held for execution at a
specified time after the game data is aggregated. By allowing the
messages to be received before the time at which the game data is
aggregated, game pacing need not be slowed to account for message
receiving latency upon game data aggregation. Furthermore, by
sending the game data to player clients upon occurrence of the
specified execution time after the game data is aggregated as well
as rejecting messages received at any time outside of the message
receiving period, all player clients may consume the same data and
consequently each player may have the same view of what is
happening in the game.
[0048] Note that although the messages used in the above described
method are labeled respectively as question, answer, and request
messages within the context of 1 vs 100, it will be appreciated
that message execution scheduling as described herein may apply to
virtually any suitable type of request/response messaging
communications.
[0049] FIGS. 4A-4B are timing diagrams of an implementation of
messages that may be sent to a massively multiplayer game
management service during a question and answer loop that may occur
in a round of a game. The timing diagram is organized into messages
associated with the One, the Mob, the Crowd, and role agnostic
messages. The timing diagram may include ten different types of
server calls that are listed as 1-10 in the legend. 1 corresponds
to game flow type server calls, 2 corresponds to quality management
system (QMS) server calls, 3 corresponds to stats widget (team
stats) server call, 4 corresponds to stat break server calls, 5
corresponds to the One server calls, 6 corresponds to Mob player
server calls, 7 corresponds to Crowd player server calls, 8
corresponds to host tool server calls, 9 corresponds to per-user
cloud storage, and 10 corresponds to free room for server calls.
The timing diagram comprises instances of these message types shown
at a time/period at which they are sent/received. An instance of a
message may be labeled (X.X) with the number left of the period
corresponding to the message type and the number right of the
period corresponding to the instance of the message.
[0050] Turning to FIG. 4A, messages associated with the One may
include a get next question (2.1), a schedule get state (5.1), a
set state in which the One answers (5.2), a schedule get in which
the Mob answers (5.3), a set state of the question and answer
(5.4), a set available/used (2.4), a set the One stats (8.4), and a
get the One stats (8.5). Messages associated with the Mob may
include a get Top 3 Mob scores (6.1), a get Top Mob score (8.1), a
schedule get state (6.2), a Top 100 Mob answers (6.3), a Top 1 the
Brain (6.4), and a sum total correct/incorrect (6.5). Messages
associated with the Crowd may include get Top 3 Crowd score (7.1),
a get Top Crowd score (8.2), a schedule get state (7.3), a sum
Crowd choice 1, 2, 3 (7.4), and a sum total correct/incorrect
(7.6).
[0051] Turning to FIG. 4B, roll agnostic messages may include a get
next question (2.2), a sum total players (1.1), a Top 3 lifetime
score leader (3.1), a set per-user cloud storage (9.1), a sum
report total seen (2.3), a get total players (1.2), a get lifetime
score leader (3.2), a Top 3 number of achievements (7.2), a
schedule get state (1.3), a get number of achievements (8.3), a Top
3 fastest leader (3.3), a Top 3 accuracy leader (3.4), a Top 3
streak leader (3.5), a schedule get Mob answers (1.4), a get
fastest leader (3.6), a get accuracy leader (3.7), a get streak
leader (3.8), a Top 1 round score session leader (3.9), a Top 10
round score leader (3.10), a sum buckets (1-5) stat break stat:
correct or streak (4.1), a sum report total right/wrong (2.5), a
get total correct (8.4), a get total incorrect (8.5), a get session
leader (3.11), a get round score leader (3.12), a get 1 stat break
(4.2), a get 2 stat break (4.3), a get 3 stat break (4.4), a get 4
stat break (4.5), and a get 5 stat break (4.6)
[0052] It is to be understood that the configurations and/or
approaches described herein are exemplary in nature, and that these
specific embodiments or examples are not to be considered in a
limiting sense, because numerous variations are possible. The
specific routines or methods described herein may represent one or
more of any number of processing strategies. As such, various acts
illustrated may be performed in the sequence illustrated, in other
sequences, in parallel, or in some cases omitted. Likewise, the
order of the above-described processes may be changed.
[0053] The subject matter of the present disclosure includes all
novel and nonobvious combinations and subcombinations of the
various processes, systems and configurations, and other features,
functions, acts, and/or properties disclosed herein, as well as any
and all equivalents thereof.
* * * * *