Patent Application
20100285885
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
Continuing with
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Turning to
Turning to
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.
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.
