U.S. Pat. No. 11,420,119

DETAILED DESCRIPTION OF THE INVENTION

The invention described herein relates to a system and method for providing continuous gameplay in a multiplayer video game through an UGS. The UGS may be initiated based on matched players, and may run continuously until all players have exited (or been removed from) the UGS.

Exemplary System Architecture

FIGS. 1A and 1Beach depict an exemplary architecture of a system which may include one or more computer systems110, one or more servers150, one or more databases160, and/or other components.FIG. 1Aillustrates an implementation in which server(s)150function as a host computer that hosts gameplay between other devices, such as computer system(s)110.FIG. 1Billustrates an implementation in which a given computer system110functions as a host computer that hosts gameplay between (or with) other devices, such as other computer system(s)110. Unless specifically stated otherwise, the description of various system components may refer to either or both ofFIGS. 1A and 1B.

Computer System110

Computer system110may be configured as a gaming console, a handheld gaming device, a personal computer (e.g., a desktop computer, a laptop computer, etc.), a smartphone, a tablet computing device, and/or other device that can be used to interact with an instance of a video game.

Referring toFIG. 1B, computer system110may include one or more processors112(also interchangeably referred to herein as processors112, processor(s)112, or processor112for convenience), one or more storage devices114(which may store an unbounded gameplay application120), one or more peripherals140, and/or other components. Processors112may be programmed by one or more computer program instructions. For example, processors112may be programmed by unbounded gameplay application120and/or other instructions (such as gaming instructions used to instantiate the game).

Depending on the system configuration, unbounded gameplay application120(or portions thereof) may be part of a game application, which creates a game instance to facilitate gameplay. Alternatively or additionally, unbounded gameplay application120may run on a device such as a server150.

Unbounded gameplay application120may include instructions that program computer system110. The instructions may include, without limitation, a matchmaking engine122, a gameplay session engine124, a scoring engine126, a game adjustment engine128, and/or other instructions130that program computer system110to perform various operations, each of which are described in greater detail herein. As used herein, for convenience, the various instructions will be described as performing an operation, when, in fact, the various instructions program the processors112(and therefore computer system110) to perform the operation.

Peripherals140

Peripherals140may be used to obtain an input (e.g., direct input, measured input, etc.) from a player. Peripherals140may include, without limitation, a game controller, a gamepad, a keyboard, a mouse, an imaging device such as a camera, a motion sensing device, a light sensor, a biometric sensor, and/or other peripheral device that can obtain an input from a player. Peripherals140may be coupled to a corresponding computer system110via a wired and/or wireless connection.

Server150

Server150may include one or more computing devices.

Referring toFIG. 1A, Server150may include one or more physical processors152(also interchangeably referred to herein as processors152, processor(s)152, or processor152for convenience) programmed by computer program instructions, one or more storage devices154(which may store a customization application120), and/or other components. Processors152may be programmed by one or more computer program instructions. For example, processors152may be programmed by gaming instructions used to instantiate the game.

Depending on the system configuration, customization application120(or portions thereof) may be part of a game application, which creates a game instance to facilitate gameplay. Alternatively or additionally, portions or all of customization application120may run on computer system110or server150.

Customization application120may include instructions that program server150. The instructions may include, without limitation, a scoring engine122, an analytics and feedback engine124, a pipelining engine126, a microtransaction engine128, a User Interface (“UI”) engine130, and/or other instructions that program server150to perform various operations, each of which are described in greater detail herein.

As used herein, for convenience, the various instructions will be described as performing an operation, when, in fact, the various instructions program the processors152(and therefore server150) to perform the operation.

Although illustrated inFIG. 1as a single component, computer system110and server150may each include a plurality of individual components (e.g., computer devices) each programmed with at least some of the functions described herein. In this manner, some components of computer system110and/or server150may perform some functions while other components may perform other functions, as would be appreciated. Thus, either or both server150and computer system100may function as a host computer programmed by customization application120. The one or more processors (112,152) may each include one or more physical processors that are programmed by computer program instructions. The various instructions described herein are exemplary only. Other configurations and numbers of instructions may be used, so long as the processor(s) (112,152) are programmed to perform the functions described herein.

Furthermore, it should be appreciated that although the various instructions are illustrated inFIG. 1as being co-located within a single processing unit, in implementations in which processor(s) (112,152) includes multiple processing units, one or more instructions may be executed remotely from the other instructions.

The description of the functionality provided by the different instructions described herein is for illustrative purposes, and is not intended to be limiting, as any of instructions may provide more or less functionality than is described. For example, one or more of the instructions may be eliminated, and some or all of its functionality may be provided by other ones of the instructions. As another example, processor(s) (112,152) may be programmed by one or more additional instructions that may perform some or all of the functionality attributed herein to one of the instructions.

Storage Devices114

The various instructions described herein may be stored in one or more storage devices, such as storage device (114,154). Storage device (114,154) may comprise random access memory (RAM), read only memory (ROM), and/or other memory. The storage device may store the computer program instructions (e.g., the aforementioned instructions) to be executed by processor (112,152) as well as data that may be manipulated by processor (112,152). The storage device may comprise floppy disks, hard disks, optical disks, tapes, or other storage media for storing computer-executable instructions and/or data.

Network102

The various components illustrated inFIG. 1may be coupled to at least one other component via a network102, which may include any one or more of, for instance, the Internet, an intranet, a PAN (Personal Area Network), a LAN (Local Area Network), a WAN (Wide Area Network), a SAN (Storage Area Network), a MAN (Metropolitan Area Network), a wireless network, a cellular communications network, a Public Switched Telephone Network, and/or other network.

InFIG. 1, as well as in other drawing Figures, different numbers of entities than those depicted may be used. Furthermore, according to various implementations, the components described herein may be implemented in hardware and/or software that configure hardware.

Databases160

The various databases160described herein may be, include, or interface to, for example, an Oracle™ relational database sold commercially by Oracle Corporation. Other databases, such as Informix™, DB2 (Database 2) or other data storage, including file-based, or query formats, platforms, or resources such as OLAP (On Line Analytical Processing), SQL (Structured Query Language), a SAN (storage area network), Microsoft Access™ or others may also be used, incorporated, or accessed. The database may comprise one or more such databases that reside in one or more physical devices and in one or more physical locations. The database may store a plurality of types of data and/or files and associated data or file descriptions, administrative information, or any other data.

The foregoing system architecture is exemplary only and should not be viewed as limiting. Other system configurations may be used as well, as would be appreciated by those having skill in the art.

Exemplary Multiplayer System Configurations

Multiplayer video games have exploded in popularity due, in part, to services such as Microsoft's Xbox LIVE® and Sony's PlayStation Network® which enable gamers all over the world to play with or against one another. Generally, as noted above, a multiplayer video game is a video game in which two or more players play in a gameplay session in a cooperative or adversarial relationship. Typically, when a player logs in to a game system or platform to play a multiplayer video game, the player may engage in a gameplay session in which he or she is matched with other players to play together (on the same team or as opponents).

FIG. 2Aillustrates an exemplary system configuration200A in which a server hosts a plurality of computer devices to facilitate a multiplayer game, according to an implementation of the invention. In one implementation, one or more servers150may host a number of computer systems110(illustrated as computer systems110A,110B, . . . ,110N) via a network102. Each computer system110may include one or more peripherals (illustrated as peripherals140A,140B, . . . ,140N). In this manner, one or more servers150may facilitate the gameplay of different players using different computer systems110and/or otherwise provide one or more operations of unbounded gameplay application120(illustrated inFIG. 1).

In some instances, a given server150may be associated with a proprietary gameplay network system, such as, without limitation, Microsoft's Xbox LIVE® and Sony's PlayStation Network®, and/or another type of gameplay network system. In this implementation, a given computer system110may be associated with a particular type of gaming console. Other types of computer systems110using other types of gameplay networks may be used as well.

FIG. 2Billustrates an exemplary system configuration200B in which a plurality of computer systems110are networked together to facilitate a multiplayer game, according to an implementation of the invention. Any one or more of the computer devices110may serve as a host and/or otherwise provide one or more operations of unbounded gameplay application120(illustrated inFIG. 1).

FIG. 2Cillustrates an exemplary system configuration200C in which a computer system110is used by a plurality of users to facilitate a multiplayer game, according to an implementation of the invention. In an implementation, computer system110may be considered to host the multiplayer game and/or otherwise provide one or more operations of unbounded gameplay application120(illustrated inFIG. 1).

Referring toFIGS. 2A-2C, in an implementation, a host may facilitate the multiplayer game and/or perform other operations described herein. In an implementation, at least some of these operations may also or instead be performed by an individual computer system110. Furthermore, the illustrated system configurations are exemplary only and should not be viewed as limiting in any way. Other system configurations may be used as well, as would be appreciated by those having skill in the art.

Unbounded Gameplay Session (“UGS”)

According to an aspect of the invention, to initiate a UGS, one or more players that are waiting to be matched may be identified, such as players whose characters are waiting in a virtual game lobby to join a gameplay session. The gameplay session may comprise any type of gameplay session including, without limitation, a real gameplay session and/or a practice gameplay session (e.g., associated with a “practice mode” of a game).

Matchmaking Engine122

In one implementation, matchmaking engine122may generate one or more matches by grouping two or more of the identified players (either in an adversarial or cooperative capacity). The two or more players or may have elected to play together, or may be matched by matchmaking engine122.

In one example, players may be matched (based on one or more matchmaking factors) to play on a team against an opposing team. The opposing team may comprise a number of players who have likewise been similarly matched based on one or more matchmaking factors, a team of non-player characters, or a combination thereof. The matchmaking factors may indicate a compatibility of the matched players to provide for satisfying gameplay experience. For example, and without limitation, players may be matched based on a player skill level, a player style, a player preference to play with certain players, and/or other matchmaking factors. The matchmaking engine may use known or hereafter-developed matchmaking techniques to generate a match (e.g., interchangeably referred to herein as “matchmaking”) by grouping players in an effort to produce the most satisfying player experiences.

Gameplay Session Engine124

According to an aspect of the invention, once two or more players have been matched, gameplay session engine124may initiate a UGS. Once the UGS has been initiated, gameplay session engine124may add and/or remove players from the UGS. For instance, players may choose to exit (and later rejoin) a given UGS. New players may join (then later exit and rejoin) a given UGS. In this manner, even though a given UGS is a gameplay session that may have been initiated with a selection of original players, the set of players participating in a UGS may change over time. A given UGS may therefore continue indefinitely as long as at least one player wishes to continue to gameplay. When all players have exited (or been removed from) a UGS or otherwise when a number of players remaining falls below a threshold number of players, gameplay session engine124may terminate the UGS. The threshold number of players may be two such that the UGS is terminated when the session is no longer a player-versus-player session. As would be appreciated, other threshold number of players (including zero) may be used as well.

In some implementations of the invention, gameplay session engine124may determine whether to initiate a UGS or a BGS based on game logic, or a player selection (e.g., a player may elect to join either a UGS or a BGS). Alternatively or additionally, different game lobbies in which players wait to be matched may correspond to different types of gameplay sessions. For example, a first game lobby may serve as a waiting area to enter a UGS game, while a second game lobby may serve as a waiting area to enter a BGS game.

In an implementation, gameplay session engine124may initiate a BGS and, upon occurrence of a terminating condition (e.g., passage of an elapsed time or achievement of a game objective) or at some time during the BGS, query the players participating in the BGS whether an extension of the BGS is desired. In other words, players involved in a BGS may elect to extend gameplay. Such extension may be for an additional amount of time (e.g., an additional five minutes of gameplay) and/or achievement of an additional game objective (e.g., additional fifty kills). Upon passage of the additional amount of time and/or achievement of the additional game objective, the extended BGS may be further extended by the same or different amount of time/additional game objective or may terminate if no further extensions are desired. Any player electing to extend gameplay may continue to play, while other players not electing to extend gameplay may exit the BGS (e.g., when the BGS would normally terminate).

In some instances, gameplay session engine124may convert a BGS into a UGS. For example, gameplay session engine124may query the players involved in a BGS whether conversion to a UGS is desired. If all (or a predetermined number of) players agree, the BGS may be converted to a UGS immediately. If only a subset of the players agree, the BGS may be converted to a UGS when the BGS would have normally terminated. Upon normal termination of the BGS, the subset of players that have elected to convert to a UGS may continue gameplay in the UGS (and any scoring from the BGS may be carried over to the UGS), while those not electing to convert to a UGS may simply exit the BGS. The converted BGS-to-UGS may continue indefinitely until no more players remain in the gameplay session. If none of the players agree, gameplay session engine124may not convert the BGS to a UGS.

In an implementation, gameplay session engine124may provide a UGS or extend a BGS by, for example and without limitation, extending a game map, such as disclosed in co-pending, and concurrently filed, U.S. patent application Ser. No. 14/712,417, entitled “System and Method for Providing Dynamically Variable Maps in a Video Game”, which is hereby incorporated by reference herein in its entirety.

Scoring Engine126

According to an aspect of the invention, scoring engine126may monitor player performance during a UGS. In order to facilitate a UGS in which players may join and exit at any time, and which can be continuous, scoring engine126may monitor player performance based on various time-based (or other) parameters. Such time-based (or other) parameters may enable a player to be scored in a manner that is not dependent on a total length of time in which the player played during a UGS (e.g., whether the player was an original player, a new player, or a player that previously exited and rejoined a UGS).

For instance, in a conventional BGS that spans a fixed time period (e.g., ten minutes), each player's score (based on achievement of some game objective) may be recorded. The player with the highest score may be judged to be the best player during the BGS because each player has played exactly ten minutes. In a UGS, however, reliance on a “highest score” alone may not likely be accurate, as some players may have participated in the UGS longer than other players.

Accordingly, in one implementation, a player's score may include a temporal aspect in the form of a time-based parameter. A time-based parameter may, for example, comprise a rate (e.g., a performance per unit of time), an interval (e.g., a performance within the last five minutes), or other time-based parameter.

As an example, in a First-Person-Shooter game, a player's score may be based (in whole or in part) on a rate of number of “kills” per minute (e.g., averaged over a given time window such as five minutes of play), a number of kills during a given interval (e.g., in the last five minutes), or using some other time-based parameter. In this manner, a fair scoring system is provided for players who may have been playing longer than other players in the UGS. Further, even if a UGS has been going on for hours as various players have come and gone, this type of “score trending” allows a given player to see how well he or she is doing (or others), just a short time after commencing gameplay. This can also be beneficial even in discrete, BGSs that might last for a long time (e.g., that may take 30 minutes or more to play), as players may want to know who is performing well in a recent time period (e.g., in the past 5 minutes).

Alternatively or additionally, scoring engine126may use other types of parameters to score players. For instance, scoring engine126may track a player's performance when different types of in-game items (e.g., weapons, clothing, accessories, etc.) are used. Continuing with the First-Person-Shooter video game example above, a player may wish to know that he or she is averaging more per kills per minute with a new weapon, suggesting that this weapon may be more effective for the player going forward.

In some instances, scoring engine126may track a player's performance based on the player's play style. For example, scoring engine126may determine a number of kills made by the player (whether through the entire UGS or portions thereof) while the player is playing in a “run-and-gun,” a “camping and sniping,” and/or other play styles. In this manner, scoring engine126allows a player or others to analyze which play styles are most effective for that player.

In some instances, scoring engine126may track a player's performance based on the makeup of teammates and/or foes. For instance, scoring engine126may measure a player's performance based on a skill level, a played role, a play style, and/or other characteristic of a teammate (and/or foe) during a UGS. In this manner, scoring engine126allows a player or others to analyze which teammates should be sought when playing future games (and/or which foes should be avoided if possible).

Whether using a time-based or other parameter, scoring engine126may keep track of all the scores for a given UGS. For example, after a UGS has terminated, scoring engine126may rank players according to their scores. For instance, scoring engine126may rank players according to their number of kills per minute, highest number of kills in a given playing time window (e.g., any five minutes of playing time), highest number of kills per given weapon, highest number of kills per type of play style, and/or other score generated by scoring engine126. During a UGS, scoring engine126may provide real-time scores to players. For instance, a newly added player may obtain (e.g., by depressing a user interface member on peripheral140to request scores) his number of kills since joining the UGS (e.g., his score within the past five minutes). In some instances, a comparison of player scores during a UGS may be provided. For instance, a given player may be provided with a comparison of that player's score during a UGS with one or more other players' scores during the UGS. Other players may be provided with similar comparisons. As would be appreciated, the score comparison may related to a team of players as well (e.g., a comparison of team scores may be provided to one or all members of either or both teams).

Each ofFIGS. 6A, 6B, and 6Cdepict a gameplay session that begins at time T0and terminates at time Tn. Each ofFIGS. 6A, 6B, and 6Calso depicts a player602that started participating in the depicted gameplay session at time T0, a player604that started participating in the depicted gameplay session at time T1(i.e., after the gameplay session was initiated), and a player606that started participating in the depicted gameplay session at time T2(collectively referred to as “participating players”).FIGS. 6A, 6B, and 6Care used to illustrate various scoring mechanisms, which may be used by scoring engine126to monitor a player's performance and generate a score for the player based on the monitored performance.

For instance,FIG. 6Aillustrates a diagram600A that depicts an exemplary first scoring mechanism using a time-based parameter, according to an implementation of the invention. According to the first scoring mechanism depicted inFIG. 6A, each of the participating players may be scored based on an interval of time that begins at the same time for each player (illustrated as time T2) and ends at the same time for each player (illustrated as time T3) (e.g., within the last five minutes). In this manner each of the players may be scored using a common time-based parameter that allows an assessment of a player's performance with respect to other players and without respect to a total length of time that a given player has participated in a gameplay session. For instance, as illustrated, in the last n-minutes (or other time) of gameplay, player602has 10 kills, player604has 12 kills and player606has 3 kills. By this metric, player604has the “best” score within the last n-minutes.

FIG. 6Billustrates a diagram600B that depicts an exemplary second scoring mechanism using a time-based parameter, according to an implementation of the invention. According to the second scoring mechanism depicted inFIG. 6B, each of the participating players may be scored based on a common time-based characteristic, but based on player performance beginning at different times and ending at different times during the gameplay session. For instance, each of the participating players may be scored based on their respective first n-minutes of gameplay. This may allow for a common (and fair) scoring mechanism in which each player is scored by a metric that is common to all participating players. In particular, if a player606has been participating in the gameplay session for only two minutes, a score based on a performance of each of the players' first two minutes of gameplay may be generated for each player. For instance, as illustrated, player602had 2 kills in his first two minutes of gameplay, player604had 1 kill in his first two minutes of gameplay, and player606had 3 kills during his first two minutes of gameplay. According to this metric, player606has the “best” score.

FIG. 6Cillustrates a diagram600C that depicts an exemplary third scoring mechanism using a time-based parameter, according to an implementation of the invention. According to the third scoring mechanism depicted inFIG. 6C, each of the participating players may be scored based on a sliding time interval that is used to identify a “best” performance over a time interval for each player. For instance, a given time interval (e.g., 2 minutes, 5 minutes, etc.) may be selected (by the system and/or by players) to use to determine the best performance of each player over the selected time interval. In some instances, the given time interval may be no less than an amount of time that a given player has been participating in the gameplay session. In this manner, each player is guaranteed to have participated in the gameplay session for a duration that is equal to or greater than the selected time interval. When the time interval has been selected, the system may analyze the performance of each player over the sliding time interval to identify an interval in which the player achieved the highest performance. For instance, as illustrated, player602's best performance of 15 kills occurred between time T1and T3, player604's best performance of 13 kills occurred between time T1and T3, and player606's best performance of 3 kills occurred between time T2and T3. By this scoring metric, player602has the “best” score.

In some implementations, the system may normalize a given score based on a number of players participating at a relevant time. For instance, if ten players were participating during the first two minutes of player602's gameplay, but only five player were participating during the first two minutes of player604's gameplay, player602may have an advantage because there are more players during his first two minutes of gameplay (and therefore potentially more targets for which to obtain kills) than for player604. To account for such an advantage, the system may normalize each player's score based on a number of participating players. For instance, the system may generate a ratio by dividing the player's score by the number of participating players to obtain a ratio of score-to-player. Other ways to normalize a score based on number of participating players may be used as well.

The scoring mechanisms illustrated inFIGS. 6A, 6B, and 6Cmay be used to create separate scores for each player. In other words, a player's performance may be assessed using two or more of the scores illustrated inFIGS. 6A, 6B, and 6C. Furthermore, the various scores illustrated inFIGS. 6A, 6B, and 6Cmay be used to generate a composite score, in which each individual score may be weighted. Furthermore, the types of scoring mechanisms used to generate one or more scores for a given gameplay session may be selectable by a user at the onset of gameplay, determined on-demand during gameplay, generated after a gameplay session has been terminated, and/or at other times.

The scoring mechanisms illustrated inFIGS. 6A, 6B, and 6Cmay facilitate a UGS in which players may join and exit at any time, and which can be continuous. This is because such scoring mechanisms may be based on factors other than a total length of time that a given player has participated in a gameplay session. Thus, players may join, leave, and rejoin a gameplay session, while being scored in a manner that allows comparison to other players (who may have been participating in the gameplay session for a longer or shorter duration than a given player).

One or more of the scoring mechanisms illustrated inFIGS. 6A, 6B, and 6Cmay also be used to monitor and gauge player performance for other types of gameplay sessions (e.g., a BGS or continuous gameplay session) as well.

Game Adjustment Engine128

In an implementation, game adjustment engine128may monitor gameplay of a UGS (e.g., the performance of players or team of players or other characteristic of the UGS) to determine whether an adjustment associated with the UGS should be made. Such determination may be made based on an objective of the UGS (which may be a default objective set by a game developer or others and/or configurable). The objective may be to create an even match (e.g., in some instances to prevent lopsided matches), create an uneven match (e.g., in some instances to prevent a war of attrition), or other objectives.

To determine whether an objective is being achieved, game adjustment engine128may determine a performance gap between a first team of players matched against a second team of players. The performance gap may be determined by comparing a performance of the first team (e.g., number of kills by the first team) with the performance of the second team (e.g., number of kills by the second team). Based on the comparison, game adjustment engine128may determine whether the first team is outperforming the second team. For objectives associated with creating even gameplay, to an extent that gameplay may no longer be enjoyable (by either or both teams) game adjustment engine128may implement an adjustment feature for the first team and/or the second team. For example, the adjustment feature may include an advantage, such as an additional player, given to the second (losing team) and/or a disadvantage, such as reducing the effectiveness of equipment or providing fewer resources on parts of the map, to the first (winning) team. Because a UGS allows players to be added even after the gameplay session has been initiated, the system may reduce instances of lopsided gameplay (which may be undesirable to either or both teams) by adding a new player to a losing team, giving the losing team an advantage.

In some instances, game adjustment engine128may implement the adjustment feature only when the performance gap exceeds a predetermined threshold, which may be set by a game designer and/or set by the players themselves before entering the UGS. The performance gap may be specified in terms of absolute metrics (e.g., when a first team's kill count is greater than a second team's kill count by 50 or more) and/or relative metrics (e.g., when a first team has 125% of the number of kills as the second team).

For objectives associated with creating an uneven match, game adjustment engine128may implement an adjustment feature when the performance gap is too small (e.g., when the performance gap is at or below a second predetermined (and/or configurable) threshold. In this manner, uneven gameplay may be encouraged, which may lead to an increased performance gap. Game adjustment engine128may periodically iterate the adjustments until the performance gap is sufficiently large (e.g., meets or exceeds the second predetermined threshold).

Game adjustment engine128may implement various types adjustment features, which may include advantages to a one team and/or disadvantages to another team. For example, and without limitation, an advantage may include adding a new player to a team, replacing a poor-performing player with a new player, providing a virtual item to a team, providing a power-up to a team, providing a positive handicap (e.g., adding a number of kills), and/or providing other benefits to a given team. A disadvantage may include, without limitation, removing a player from the other team, replacing a high-performing player with a new player, removing a virtual item from the other team, removing a power-up from the other team, providing a negative handicap (e.g., subtracting a number of kills), and/or providing other detriment to the other team. An advantage and/or disadvantage may be applied permanently throughout the entire UGS, may be applied temporarily for a predefined time, or may be applied temporarily until the performance gap no longer exists (for objectives associated with even gameplay) or until the performance gap is sufficiently large (for objectives associated with uneven gameplay).

Game adjustment engine128may implement such advantages and/or disadvantages periodically throughout the UGS (e.g., each time the performance gap exceeds a predetermined threshold) or on a one-time basis. In an implementation, the adjustment feature provided by game adjustment engine128may be controlled by a default setting (e.g., either default on or default off), which may be adjusted by players so they can choose whether to activate (or de-activate) this feature.

Exemplary Flowcharts

The various processing operations and/or data flows depicted in the exemplary flowcharts ofFIGS. 3-5are described in greater detail herein. The described operations may be accomplished using some or all of the system components described in detail above and, in some implementations, various operations may be performed in different sequences and various operations may be omitted. Additional operations may be performed along with some or all of the operations shown in the depicted flow diagrams. One or more operations may be performed simultaneously. Accordingly, the operations as illustrated (and described in greater detail below) are exemplary by nature and, as such, should not be viewed as limiting.

Exemplary Process For Providing Continuous Gameplay Through a UGS

FIG. 3depicts an exemplary process for providing continuous gameplay in a multiplayer video game through an UGS, according to an implementation of the invention.

In an operation302, a UGS may be initiated. For example, a set of players may be matched to play with and/or against one another.

In an operation304, players may be scored individually and/or as a team. For example, each player or team may be scored according to a time-based parameter that incorporates a temporal aspect. In a particular example, a player and/or team may be scored based on a performance per unit of time, an interval (e.g., a performance within the last five minutes), and/or temporal aspect. Other types of scores, such as based on a type of weapon used, a style of gameplay, and/or other aspects of gameplay may be assessed as well.

In an operation306, a determination of whether to add a player to the UGS may be made. For instance, a player may wish to join a gameplay session already in progress. The player may be added to the UGS, which may require acceptance by existing players in the UGS or may be automatic based on game rules. In some instances, for example, players may choose to participate in a UGS even with only11players even though12may be required. In this example, the UGS may be initiated and a twelfth player may be added when available. If a player should be added, processing may proceed to operation314, in which a new player is selected and added to the UGS. The new player may be selected based on selections from matchmaking engine122.

In an operation308, a determination of whether a player should be removed from the UGS may be made. A player should be removed from the UGS when, for example, the player voluntarily chooses to leave, when a disadvantage is to be imposed on a team (as described herein), when a network connection to the player has been lost, and/or when a player should otherwise no longer continue playing in the UGS. If a player should be removed, the player may be removed from the UGS in an operation310. If the player should not be removed, processing may return to operation304, in which players and/or teams are scored.

In an operation312a determination of whether the removed player should be replaced is made. A player should be replaced when, for example, the removed player voluntarily left the UGS, a network connection to the removed player was lost, and/or when the team from which the removed player should have a replacement player. If the removed player should be replaced, in an operation314, a new player may be selected and added to the UGS.

If a player should not be replaced, processing may proceed to an operation316, in which a determination of whether any players remain in the UGS may be made. If players remain in the UGS, processing may return to operation304. If no more players remain in the UGS (or no players have expressed interest in remaining in the UGS), the UGS may be terminated in an operation318. Terminating a UGS may include compiling scores for all players who participated in the UGS and communicating the scores to those players or otherwise making the scores available through one or more game interfaces.

Exemplary Process For Providing An Adjustment Feature

FIG. 4depicts an exemplary process for providing an adjustment feature to players in a mismatched gameplay session, according to an implementation of the invention.

In an operation402, a set of players may be matched for a UGS and the UGS may be initiated.

In an operation404, scores for one or more players may be determined during a UGS. For example, scores of individual players and/or team of players may be tallied and compared to an opposing player or opposing team of players. The scores may be measured based on one or more performance metrics (e.g., number of kills in a shooter game, lap times in a racing game, etc.).

In an operation406, a determination of whether a player and/or team are mismatched may be made. A mismatch may occur when a performance gap between the player and/or team and an opposing player and/or team exists. In some instances, a mismatch may be deemed to occur when the performance gap exceeds a threshold value. The performance gap may be determined based on a comparison of the scores for a player and/or team and an opposing player and/or team. If no mismatch exists, processing may return to operation404, where one or more players are scored.

If a mismatch exists, in an operation408, an adjustment feature may be identified. An adjustment feature may include an advantage provided to a losing player and/or team (e.g., a player and/or team having a lower score) and/or a disadvantage provided to a winning player and/or team (e.g., a player and/or team having a higher score).

In an operation410, the adjustment feature may be applied during a UGS. Processing may return to operation404, in which players are scored. In this manner, the leveling process may be iterative in that a performance gap and whether a mismatch occurs are periodically determined throughout the UGS. In other implementations, the adjustment feature may be applied only once during a given UGS.

Exemplary Process for Initiating and Extending a BGS

FIG. 5depicts an exemplary process for initiating and extending a BGS, according to an implementation of the invention.

In an operation502, a BGS may be initiated. A bounded gameplay session may be terminated after a predefined condition has occurred, such as a passage of a predefined time (e.g., a ten minute game session) or achievement of a predefined objective (e.g., a certain number of kills).

In an operation504, players may be scored individually and/or as a team. Such scoring may be cumulative for the BGS. For example, the score may include a cumulative number of kills made by a player during the entire BGS.

In an operation506, a determination of whether a BGS terminating event has occurred may be made. A BGS terminating event may include the passage of a predefined time or achievement of a predefined objective.

If a BGS terminating event has occurred, in an operation508, a determination of whether one or more players wish to continue the BGS may be made. For instance, each player playing in the BGS may be prompted to indicate whether they wish for the BGS to continue.

If at least one player wishes to continue playing, the BGS may be extended by a predefined time (e.g., continue gameplay for five more minutes) or by a predefined objective (e.g., continue gameplay until fifty more kills occur) in an operation510. Only those players wishing to extend gameplay may continue to play in the extended BGS. Processing may then return to operation504.

However, if not all players have elected to continue playing in the extended BGS, scoring may be switched to a UGS-style scoring mechanism, in which a time-based or other parameter is applied to player scores. When the extended BGS is terminated, separate scores may be reported for the standard (non-extended) BGS and for the extended BGS. In this manner, players in the standard BGS may be scored as usual, while players participating in the extended BGS may be separately scored according to a UGS-style scoring mechanism as well.

If too few players wish to continue playing, the BGS may be terminated in an operation512.

Other implementations, uses and advantages of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. The specification should be considered exemplary only, and the scope of the invention is accordingly intended to be limited only by the following claims.