U.S. Pat. No. 10,722,788

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The elements illustrated in the Figures interoperate as explained in more detail below. Before setting forth the detailed explanation, however, it is noted that all of the discussion below, regardless of the particular implementation being described, is exemplary in nature, rather than limiting. For example, although selected aspects, features, or components of the implementations are depicted as being stored in memories, all or part of systems and methods consistent with the latency management system architecture may be stored on, distributed across, or read from other machine-readable media, for example, secondary storage devices such as hard disks, floppy disks, and CD-ROMs; a signal received from a network; other forms of ROM or RAM either currently known or later developed; and the like.

Furthermore, although specific components of the communications architecture will be described, methods, systems, and articles of manufacture consistent with the latency management system architecture may include additional or different components. For example, a processor may be implemented as a microprocessor, microcontroller, application specific integrated circuit (ASIC), discrete logic, or a combination of other type of circuits or logic. Similarly, memories may be DRAM, SRAM, Flash or any other type of memory. Flags, data, databases, tables, and other data structures may be separately stored and managed, may be incorporated into a single memory or database, may be distributed, or may be logically and physically organized in many different ways, including unstructured data. Programs may be parts of a single program, separate programs, or distributed across several memories and processors. Systems may be implemented in hardware, software, or a combination of hardware and software in one processing system or distributed across multiple processing systems. As another example, some or all of the functionality of the latency management server40may be incorporated into the game clients20a-n, the game servers50a-n, or both.

1.0 Latency Management System Overview

As shown inFIG. 1, an exemplary architecture10for a system for managing latency in networked competitive multiplayer gaming is shown. One or more players at client devices may run game client applications20a-nwhich may communicate with one or more game servers50a-nto enable the players to participate in a networked competitive multiplayer game. The game client applications20a-nand/or the game servers50a-nmay communicate with a latency management server40via a communications network30. The game client applications20a-nand/or servers50a-nmay communicate network connectivity data, game data, user profile data, and the like with the latency management server40. The latency management server40may analyze the connectivity and/or game data and manage communications between the game clients20a-nand game servers50a-nbased on the data. The latency management server40also may store information in one or more data storage devices45.

The latency management server40may manage the latency between the game client applications20a-nand the game servers50a-nin a variety of ways. In some embodiments, the latency management server40may reduce and/or eliminate latency advantages or disadvantages across players in a game so that each player has approximately the same latency. This may be accomplished, for example, by determining the player with the highest latency and increasing the latency of the remaining players accordingly. Players may be notified if their latency is adjusted and, in some embodiments, the system may persistently display the latency of each player to the player and/or to other players. By managing the latency as disclosed herein, the latency management server40is able to eliminate the technical problem of needing all teams and/or players to be in the same physical location, greatly increasing competition opportunities. For example, teams may compete against one another from different venues, each of which may be customized to their liking, filled with their own fans, and the like.

Alternatively, or additionally, the latency management server40may control latency among players to provide an advantage to one or more players. For example, the latency management server40may create “home” and “away” teams, similar to traditional sports, in which one team may be given a “home team” advantage by providing lower latency for players on the team while the “away team” may compensate for higher latency. Other latency management methodologies also may be used.

In some embodiments, the latency management server40may manage latency individually for each player in a game. For example, each player may have an associated target latency. This may allow the latency management server40to customize the game for each player's skill level, such as providing low latency for new or lower skilled players and providing higher latency for higher skilled players, forcing the higher skill player to adjust their gameplay to compensate for the latency disadvantage. As another example, each game may have a target latency and each player's individual latency may be adjusted to match the game's target latency. Alternatively, or additionally, the latency management server40may manage overall team latency. As an example, each team may have a target latency and the latency management server40may manage latency so that each team's players match the target latency for the team. Other methodologies also may be used.

In still further embodiments, latency management server40also may implement data collection features, scoring features, and handicap features. The data collection features may track in-game actions, such as kills in a first person shooter game (FPS). The scoring features may assign point values to each tracked action (or some of the tracked actions). The scoring may be standard for each player, or may be weighted based on a variety of factors, such as latency, statistical differences, player skill, and the like. Handicapping features may include weighting scoring, adjusting latency based on the collected data, and the like.

Although references will now be made to specific components of the system performing specific features, it should be apparent to one of ordinary skill in the art that such references are exemplary and are not intended to limit the scope of the claims in any way; furthermore, the functionalities described herein may be implemented in a virtually unlimited number of configurations. For example, the server40may be implemented as a single server configured to provide all of the systems functionalities, or the functionalities may be implemented across multiple servers. As a specific example, although data collection features, scoring features and handicapping features are described as being performed by the latency management server40, each of these features may be implement by separate hardware, each of which may include one or more servers and data storage mechanisms.

1.1 Exemplary Game Client Applications

Game client applications20a-nmay provide a user interface for the system and may communicate content selection information, user profile information, game data and other information with latency management server40via communications network30. The game client applications20a-nalso may communicate with one another. In one embodiment, game client applications20a-nmay comprise stand-alone applications which may be either platform dependent or platform independent. For example, game client applications20a-nmay be stand-alone applications for a mobile phone configured to run on a mobile operating system such as the iOS™ operating system from Apple Inc. located in Cupertino, Calif., the Android™ operating system from Google, Inc. located in Mountain View, Calif., or the like. Alternatively, or additionally, client applications20a-nmay connect to the game servers50a-nvia the Internet using a standard browser application. Alternatively, or additionally, one or more of the game client applications20a-nmay be an application configured to run on a mobile computer such as a laptop computer, handheld computer, tablet, mobile messaging device, gaming system or the like which may all utilize different hardware and/or software packages. Other methods may be used to implement the client devices20a-n.

1.2 Exemplary Communications Networks30

Communications network30may be any type of private or public communication network, such as the Internet, and may include one or more communications networks. In some embodiments, the communications network30may be a cellular network such as, for example, a Code Division Multiple Access (CDMA) network, Global System for Mobiles (GSM) network, General Packet Radio Service (GPRS) network, cdmaOne network, CDMA2000 network, Evolution-Data Optimized (EV-DO) network, Enhanced Data Rates for GSM Evolution (EDGE) network, Universal Mobile Telecommunications System (UMTS) network, Digital Enhanced Cordless Telecommunications (DECT) network, Digital AMPS (IS-136/TDMA), Integrated Digital Enhanced Network (iDEN), Long-Term Evolution (LTE) and the like.

1.3 Exemplary Latency Management Server40

Latency management server40may receive network connectivity data, game data, user profile information and the like from the game clients20a-nand game servers50a-n, may store the some or all of the same in a data storage device45, and the like. As should be apparent to one of ordinary skill in the art from the disclosure herein, other related services may also be provided.

1.4 Exemplary Data Storage Device45

Data storage device45may store a variety of information, including user profile information, user preference information, content data, and the like. Although illustrated as a database, the specific storage mechanism implemented by data storage device45may take a variety of forms, such as one or more instances of a Heroku Dyno hosted on the Heroku platform, utilizing one or more of the following storage mechanisms: Amazon Simple Storage Service™ (Amazon S3™) Dropbox (via API integration), PostgreSQL relational database system, queuing services such as Amazon Simple Queue Service™ (Amazon SQS™) or alternatives such as RabbitMQ, Redis, Sidekiq, or cron; and/or other storage mechanisms. Other technologies also may be used. In some embodiments, all information stored in the data storage device45is encrypted.

1.5 Exemplary Game Servers50a-n

Game servers50a-nmay host games played by players using the game clients20a-n, calculate some or all game updates, communicate network connectivity data, game data, user profile information and the like with the game clients20a-nand/or the latency management server40, and the like. Other functionality also may be implemented by game servers50a-n. In some embodiments, game servers50a-nand latency management server40may be owned by different entities.

2.0 Exemplary eSports Event Latency Management

Although reference will now be made to certain embodiments described herein with reference to eSports competitions, the principles presented herein may be used for other networked completive multiplayer games and the like. The embodiments illustrated herein should therefore not be interpreted to be exclusive or limiting, but rather exemplary or illustrative.

2.1 Exemplary Latency Management By Funneling Network Traffic Through Latency Management Server40

Referring toFIG. 2a, an exemplary flow chart for a process200for managing latency in a networked competitive multiplayer competition is shown. In the exemplary process200shown inFIG. 2a, network communications between the game clients20a-nand the game servers50a-nis funneled through the latency management server40. In other words, the game clients20a-nand the game servers50a-ndo not communicate directly, but instead communicate through the latency management server40. The latency management server40may (1) route all traffic from the game clients20a-nto a single server50a(as shown inFIG. 3a), (2) route all traffic from a group of game clients20a-n(team one) to a single server50aand all traffic from a second group of game clients20a-nto another server50b(team two) (as shown inFIG. 3b), (3) route traffic from individual game clients20a-nto individual servers50a-n(as shown inFIG. 3c), and the like. Other architectures also may be used.

Initially, the latency management server40may receive network connectivity information from the game client applications20a-nand/or the game servers50at step202. Alternatively, or additionally, the server40may receive geographic distance information between the game clients20a-nand the game servers50a-n, as distance may correlate with network response times in some cases. For example, the latency management server40may receive latency information between a game client20aand one or more servers50a-n. As another example, the latency management server40may receive information about response times, also referred to as ping times or ping information, between the game clients20a-nand the latency management server40as well as ping information between the game servers50a-nand the latency management server40. Table 1.0 below shows an exemplary set of latency information indicating ping times between four client applications20a-dand the latency management server40.

TABLE 1.0Exemplary Ping Times - Client 20a-d to Server 40Client NameLatency Management Server 40Client 20a100 msClient 20b50 msClient 20c10 msClient 20d50 ms

Next, the latency management server40may determine one or more target latencies at step204. As noted above, a target latency may be set in many ways. For example, a single target latency may be set for all players in the game and each individual player's latency may be adjusted accordingly. The target latency may be set by determining the fastest of the slowest response times for each client. For example, using the exemplary ping times shown in Table 1.0, the latency management server40may determine a target latency of 100 ms because each client20a-nis able to achieve a response time to the latency management server40of 100 ms or faster. Other methodologies also may be used.

Next, the latency management server40may determine latency adjustments at step206. Latency adjustments may be additional time (or wait times) added to communications between particular clients20a-nand game server50b, such as additional time to make the latency between a particular game client20aand a particular server50bequal to the target latency. In the example set forth in Table 1.0 and a target latency of 100 ms, the latency management server40may determine a latency adjustment of 50 ms for client20b,90 ms for client20c,50 ms for client20d, and no latency adjustment for client20a. Other methodologies may be applied to determine latency adjustments.

During gameplay, the latency management server40may receive network communication from the game clients20a-nand the game servers50a-nat step208, such as player inputs from game clients20a-nand game state updates from the game servers50a-n. The server40may apply any latency adjustments to the communications at step210and transmit the communication to the appropriate game client20a-nor game server50a-nat step212.

The server40also may continue to monitor network connectivity and determine if latency has changed at step214, and, if so, may recalculate target latency(ies) and latency adjustment(s) at steps204and206. Target latency(ies) and/or latency adjustment(s) may be updated periodically, such as once every game, once every set of games, at certain set points within a game, continuously within a game, and the like. In some embodiments, updated target latency(ies) and/or latency adjustment(s) may only be determined if the change in latency is more than a predetermined threshold. Exemplary thresholds may be between about 1 ms and about 100 ms, preferably between about 5 ms and about 50 ms, more preferably between about 5 ms and about 25 ms and in some embodiments about 10 ms. Referring again to the example shown in Table 1.0, updated target latency(ies) and latency adjustment(s) may be determined if the ping time between game client20aand game server50bincreases to 125 ms.

As noted above, in some embodiments target latency(ies) and latency adjustments may be applied to provide an advantage to a particular player or team in a game. The “advantage” may be either positive or negative, i.e. an increase or decrease in latency for a particular player or team, depending on the particular game. For example, in first person shooter games (FPS) such as COUNTER STRIKE: GLOBAL OFFENSIVE provided by Valve Corporation of Bellevue, Wash., a player with longer latency times may have an advantage over a player with shorter latency times.

In some embodiments, a “home team” or “home field” latency advantage may be provided for a particular team of players. Exemplary latency advantages may be between about 1 ms and about 500 ms, preferably between about 5 ms and about 100 ms, even more preferably between about 10 ms and about 50 ms and in some embodiments about 25 ms. Other values also may be used.

In some embodiments, two teams may compete against one another in a series of games, such as a best-of-seven series. Latency may be adjusted differently for each game in the series. For example, latency advantages may be provided to teams in alternating games, so that team 1 has a “home” game with a latency advantage in games 1, 3, 5 and 7 in the series while and team 2 is provided a latency advantage in games 2, 4 and 6. Other series formats, such as a 2-2-1-1-1 format, a 2-3-2 format, and the like also may be used.

The latency advantage may be the same in each of the games, such as a 30 ms advantage for the “home” team, or may vary from game to game. For example, latency advantages may be larger in the first game or games and may be smaller in later games in the series. In some embodiments, latency advantages may be progressively smaller for each “home” game for the team such that each team's first “home” game has a first latency advantage, each team's second “home” game has second latency advantage, and so on. In some embodiments, a series may include “neutral site” games in which neither team is provided a latency advantage, such as game seven of a seven game series.

2.2 Exemplary Latency Management By Pairing Specific Game Clients20a-nWith Specific Game Servers50a-n

Referring toFIG. 2b, another exemplary flow chart for a process250for managing latency in a networked competitive multiplayer competition is shown. In the exemplary process250, the game clients20a-ncommunicate directly with game servers50a-nthat are assigned by the latency management server40. Once again, the latency management server40may (1) route all traffic from the game clients20a-nto a single server50a(as shown inFIG. 3d), (2) route all traffic from a group of game clients20a-n(team one) to a single server50aand all traffic from a second group of game clients20a-nto another server50b(team two) (as shown inFIG. 3e), (3) route traffic from individual game clients20a-nto individual servers50a-n(as shown inFIG. 3f), and the like. Other architectures also may be used.

Initially, the latency management server40may receive network connectivity information from the game client applications20a-nand/or the game servers50at step220. Alternatively, or additionally, the server40may receive geographic distance information between the game clients20a-nand the game servers50a-n, as distance may correlate with network response times in some cases. For example, the latency management server40may receive latency information between a game client20aand one or more servers50a-n. As another example, the latency management server40may receive ping information between the game clients20a-nand the latency management server40as well as ping information between the game servers50a-nand the latency management server40. Table 2.0 below shows an exemplary set of latency information indicating ping times between four client applications20a-dand two game servers50a-b.

TABLE 2.0Exemplary Ping Times - Client to ServerClient NameServer 50aServer 50bServer 50cClient 20a10 ms100 ms160 msClient 20b10 ms50 ms165 msClient 20c100 ms10 ms170 msClient 20d200 ms50 ms155 ms

Next, the latency management server40may determine one or more target latencies at step222. As noted above, a target latency may be set in many ways. For example, a single target latency may be set for all players in the game and each individual player's latency may be adjusted accordingly. The target latency may be set by determining the fastest of the slowest response times for each client. For example, using the exemplary ping times shown in Table 2.0, the latency management server40may determine a target latency of 100 ms because each client20a-nis able to achieve a response time to game server50bof 100 ms or faster. Alternatively, or additionally, the server40may select a target time based on the slowest of the fastest times achievable by a given client20a-n. Again referring to the example in Table 2.0, the server40may select a target latency of 50 ms because all of the clients20a-nmay achieve a response time of 50 ms or less with at least one of the servers50a-b.

As noted above, a target latency may be set in many ways. For example, a single target latency may be set for all players in the game. The target latency may be set, for example, by determining the fastest of the slowest response times for each client20a-namong the servers50a-n. For example, using the exemplary ping times shown in Table 2.0, the latency management server40may determine a target latency of 100 ms because each client20a-nis able to achieve a response time to game server50bof 100 ms or faster. Alternatively, or additionally, the server40may select a target time based on the slowest of the fastest times achievable by a given client20a-n. Again referring to the example in Table 2.0, the server40may select a target latency of 50 ms because all of the clients20a-nmay achieve a response time of 50 ms or less with at least one of the server50a-50b.

Next, the latency management server40may determine appropriate servers50a-nfor particular game clients20a-nat step224and direct communications to occur over those channels at step226. Servers50a-nmay be selected so that each client20a-nhas a response time with the selected server50a-nabout the same as the target latency. In the example set forth in Table 2.0, the latency management server40may determine that clients20aand20b(team one) communicate with server50aand that clients20cand20d(team two) communicate with server50b.

As another example, the target latency may be set by determining the server50a-nthat has the nearest response times for all players. Referring to the example shown in Table 2.0, the latency management server40may select game server50cbecause each of the client applications20a-nhave similar response times. Other methodologies may be applied to determine latency adjustments.

During gameplay, the latency management server40may continue to monitor latency at step228and determine if latency has changed at step230, and, if so, may recalculate target latency(ies) and server selections at step222and224. Target latency(ies) and/or latency adjustment(s) may be updated periodically, such as once every game, once every set of games, at certain set points within a game, continuously within a game, and the like. In some embodiments, updated target latency(ies) and/or latency adjustment(s) may only be determined if the change in latency is more than a predetermined threshold. Exemplary thresholds may be between about 1 ms and about 100 ms, preferably between about 5 ms and about 50 ms, more preferably between about 5 ms and about 25 ms and in some embodiments about 10 ms. Referring again to the example shown in Table 2.0, updated target latency(ies) and latency adjustment(s) may be determined if the ping time between game client20aand game server50bincreases to 125 ms.

2.3 Exemplary Latency Management by Routing Network Communications Between Game Clients20a-nwith Specific Game Servers50a-nUsing Predetermined Number of Hops

Referring toFIG. 2c, another exemplary flow chart for a process270for managing latency in a networked competitive multiplayer competition is shown. In the exemplary process270, the game clients20a-ncommunicate with one or more game servers50a-nby going through network communication paths that are assigned by the latency management server40. Once again, the latency management server40may (1) route all traffic from the game clients20a-nto a single server50a(as shown inFIG. 3d), (2) route all traffic from a group of game clients20a-n(team one) to a single server50aand all traffic from a second group of game clients20a-nto another server50b(team two) (as shown inFIG. 3e), (3) route traffic from individual game clients20a-nto individual servers50a-n(as shown inFIG. 3f), and the like. Other architectures also may be used. In these embodiments, one or more network communication devices60a-lmay be used as intermediate communication nodes between the game clients20a-nand the game servers50a-nto shape the latency of each player. In other words, communications between the clients20a-nand the servers50a-nmay hop from node to node to introduce delay in the communications. Network communications devices60a-lmay be any of a variety of devices for communicating over a network, such as relays, switches, servers and the like, or groups of such devices.

Initially, the latency management server40may receive network connectivity information from the game client applications20a-nand/or the game servers50at step280. Alternatively, or additionally, the server40may receive geographic distance information between the game clients20a-nand the game servers50a-n, as distance may correlate with network response times in some cases. For example, the latency management server40may receive latency information between a game client20aand one or more servers50a-n. As another example, the latency management server40may receive ping information between the game clients20a-nand the latency management server40as well as ping information between the game servers50a-nand the latency management server40. Table 3.0 below shows an exemplary set of latency information indicating ping times between four client applications20a-dand two game servers50a-b.

TABLE 3.0Exemplary Ping Times - Client to ServerClient NameServer 50aClient 20a10 msClient 20b100 ms

Next, the latency management server40may determine one or more target latencies at step282. As noted above, a target latency may be set in many ways. For example, a single target latency may be set for all players in the game and each individual player's latency may be adjusted accordingly. The target latency may be set by determining the fastest of the slowest response times for each client. For example, using the exemplary ping times shown in Table 3.0, the latency management server40may determine a target latency of 100 ms because each client20a-bis able to achieve a response time to game server50aof 100 ms or faster. Alternatively, or additionally, the server40may select a target time based on other factors and using other methodologies.

Next, the latency management server40may determine appropriate servers50a-nand/or network paths for particular game clients20a-nat step284and direct communications to occur over those channels at step286. Servers50a-nand/or network path(s) may be selected so that each client20a-nhas a response time with the selected server50a-nabout the same as the target latency. In the example set forth in Table 3.0, and as illustrated inFIG. 4, the latency management server40may determine that client20a(team one) communicates with server50athrough intermediate nodes60a-dand that client20b(team two) communicates with server50athrough nodes60e-601. In this manner, latency between the game clients20aand20bmay be managed.

During gameplay, the latency management server40may continue to monitor latency at step288and determine if latency has changed at step290, and, if so, may recalculate target latency(ies) and server/path selections at step282and284. Target latency(ies) and/or latency adjustment(s) may be updated periodically, such as once every game, once every set of games, at certain set points within a game, continuously within a game, and the like. In some embodiments, updated target latency(ies) and/or latency adjustment(s)/path(s) may only be determined if the change in latency is more than a predetermined threshold. Exemplary thresholds may be between about 1 ms and about 100 ms, preferably between about 5 ms and about 100 ms, more preferably between about 5 ms and about 50 ms, even more preferably between about 5 ms and about 25 ms, further more preferable between 5 ms and 15 ms, and in some embodiments about 10 ms. Referring again to the example shown in Table 1.0, updated target latency(ies) and latency adjustment(s) may be determined if the ping time between game client20aand game server50bincrease to 125 ms.

3.0 Exemplary Data Collection and Scoring Systems

Referring toFIG. 5, a flow chart for an exemplary process500for collecting in-game data in a networked competitive multiplayer game and implementing data collection features, scoring features and/or handicapping features is shown. In the exemplary process500, the game clients20a-nmay communicate with one or more game servers50a-nto play a particular game. Latency between the game clients20a-nand game servers50a-nalso may be determined and/or managed as described above. Alternatively, or additionally, latency may be managed solely through a weighted scoring feature, or through a combination of the methods described above and a weighted scoring feature.

At step502, the latency management server40may receive network communications between the game client(s)20a-nand game server(s)50a-n, as described above. The network communications may include gameplay data, latency data (ping rates and the like), or both. In some embodiments, the latency management server may determine latencies for each of the game clients20a-nat step504.

At step506, the latency management server40may track in-game actions and outcomes of the players. The in-game actions may be gameplay related actions, such as, for an FPS, kills, headshots, kill streaks, multi-kills, wins, damage, ability usage/kills, in-game objectives, kills with specific weapons, and the like. Other in-game actions also may be tracked. The tracked actions may be the same actions that are used for in-game scoring, or may be actions that are not used for in-game scoring. For example, an objective based game may require players to capture a specific zone or perform other in-game actions to win the round or game. In such a game, kills, headshots and other actions that do not directly determine the outcome of the game may be tracked in addition to those actions that directly determine the outcome of the game. The tracked actions may be stored in data storage device45or other storage mechanisms.

In some embodiments, the tracked actions may be used as part of a scoring system, a handicapping system, or both. For example, at step508, the system may use statistics and/or other data analysis methods (such as ELO rating systems and the like) to establish a baseline scoring framework across actions/outcomes, as well as weighting coefficients to be applied to the scoring framework in some embodiments. Alternatively, or additionally, the baseline scoring and/or weighted coefficients may be determined manually.

A baseline scoring may be a scoring framework that is applied equally to all players (i.e. non-weighted scoring). For example, each headshot (or other precision hit) may be assigned 100 points, each kill may be assigned 1000 points, wins 5000 points, and the like. Other values also may be used. Points for each player may be totaled and a winner/winning team may be determined based on the scoring, regardless of the objective of a particular game. A baseline scoring framework may be applied to the tracked data at step510.

In some embodiments, weighted scoring and/or handicapping features may be applied at step512. Weighted scoring may include applying one or more scoring coefficients to the baseline scoring framework. Scoring coefficients may be based on a variety of factors, such as latency, modeled using statistical baselines and differences from the data collection system, and the like. For example, in a game in which a first player is determined to have a 50 ms response time and a second player having a 100 ms response time, the second player's baseline score may be multiplied by a coefficient to accommodate the latency difference, such as such as a coefficient between about 1.05 and about 2.0, preferably between about 1.2 and about 1.7, and in some embodiments about 1.5. In other words, in this example, the first player may receive 100 points for a headshot while the second player may receive 150 points for a headshot. Other coefficients also may be used.

Latency-based scoring coefficients may be applied regardless of whether latency is managed by the latency management server40as described above in section2. In other words, latency management server40may manage latency directly by establishing target latencies or directing server usage (as described above), by manipulating scoring based on latencies, or both.

Handicapping features also may be implemented by the server40at step510. Handicapping features may include weighting scoring, as described above. Alternatively, or additionally, handicapping features may include determining target latency based on the collected data, scoring averages, player skill assessment based on tracked in-game actions, and the like. For example, players that average a high number of kills per game, headshot percentages, or the like may be determined to be higher skill than other players and scoring coefficients or latency may be adjusted accordingly to balance matches against lower skilled players, or any other desired balancing. Other implementations also may be used.

In some embodiments, handicapping features may include determining the number of players on each team based on latency, player skill, and the like. For example, a first team having a latency (or skill) advantage over a second team may be limited to a smaller number of players than a team at a latency (or skill) disadvantage. As a specific example, a team with a latency of 10 ms to a game server may have only 10 players while a team with 100 ms latency may include 100 players. The teams may switch in alternating rounds or games (as noted above), so that the second team is limited to 10 players with a latency (or skill) advantage and the first team includes 100 disadvantaged players. Team totals may be calculated after an even number of rounds to determine an overall winner. Other parameters also may be used.

While various embodiments of the invention have been described, it will be apparent to those of ordinary skill in the art that many more embodiments and implementations are possible within the scope of the invention. Accordingly, the invention is not to be restricted except in light of the attached claims and their equivalents.