US20070265043A1

US20070265043A1 - Team-based networked video gaming and automatic event management

Info

Publication number: US20070265043A1
Application number: US11/786,566
Authority: US
Inventors: Andy Wang; Gabriel Law; Sean Mackay
Original assignee: Individual
Current assignee: Individual
Priority date: 2006-04-12
Filing date: 2007-04-11
Publication date: 2007-11-15
Also published as: WO2007120741A2; WO2007120741A3; TW200821021A

Abstract

An integrated on-line networked video game system is disclosed. Effects of variable latency are mitigated dynamically to assure that all players see game displays consistent with actual game actions. Games are organized into events that allow dynamic enhancement of character capabilities during play.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No. 60/791,750, filed Apr. 12, 2006, the entire contents of which are hereby incorporated by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention
The present invention relates generally to video gaming and, more particularly, to video games played by teams on networked computers.
2. Description of Related Art
Video gaming, which may have started with development of PONG®, a simple electronic tennis game, has evolved to support teams of players, who may be widely dispersed geographically, who engage in simulated sports games such as football, soccer, and the like using facilities of a computer network, typically the Internet. Not surprisingly, near-real-time simulated games in such an environment may offer a less than totally satisfactory experience for players of the games.
Network latency may have a strong negative effect on real-time actions such as hitting a baseball in a baseball game or attempting to score a goal in a soccer game. Players in various geographic locations may see actions on computer monitors at different times, and, in reacting to those actions, may generate game states that are ambiguous, inaccurate, confusing, frustrating and, worst of all, may lead to a wrong and uncorrectable game outcome. Nevertheless, video gaming has its adherents who continue to play in spite of difficulties that may arise.
A need exists in the prior art for video games that support teams of players without attendant problems introduced by network latency.

SUMMARY OF THE INVENTION

The present invention addresses this need by providing a method of displaying a scene on a monitor of a first computer According to the invention herein disclosed, the first computer may receive a data packet from a second computer, the data packet comprising information about the scene and further comprising time delay information. After receiving the data packet, the first computer may wait for an amount of time according to the time delay information and then may display the scene.
An aspect of the present invention further comprises estimating a value for the time delay information.
One particular implementation estimates the value for the time delay information by transmitting a test packet from the second computer to the first computer, the test packet comprising a request for an immediate reply. The first computer may then receive a reply according to the request and then may determine an elapsed time between the transmitting and the receiving.
Another implementation further comprises transmitting the test packet from the second computer to a plurality of computers and receiving a plurality of replies according to the request. A plurality of elapsed times between the transmitting and the receiving is determined, and a plurality of data packets including a plurality of time delay values according to the plurality of elapsed times are transmitted. Display of the scene on monitors of the plurality of computers is delayed according to the plurality of time-delay values, thereby displaying the scene essentially simultaneously on the monitors of the plurality of computers.
While the apparatus and method has or will be described for the sake of grammatical fluidity with functional explanations, it is to be expressly understood that the claims, unless expressly formulated under 35 USC 112, are not to be construed as necessarily limited in any way by the construction of “means” or “steps” limitations, but are to be accorded the full scope of the meaning and equivalents of the definition provided by the claims under the judicial doctrine of equivalents, and in the case where the claims are expressly formulated under 35 USC 112 to be accorded full statutory equivalents under 35 USC 112.
Any feature or combination of features described herein are included within the scope of the present invention provided that the features included in any such combination are not mutually inconsistent as will be apparent from the context, this specification, and the knowledge of one skilled in the art. For purposes of summarizing the present invention, certain aspects, advantages and novel features of the present invention are described herein. Of course, it is to be understood that not necessarily all such aspects, advantages or features will be embodied in any particular embodiment of the present invention. Additional advantages and aspects of the present invention are apparent in the following detailed description and claims that follow.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a pictorial diagram indicating one possible arrangement of several computers that may be used by players involved in a team-based networked video game;
FIG. 2 is a flow diagram describing one particular implementation of a method of reducing effects of variable latency in a team-based networked video game;
FIG. 3 is a flow diagram illustrating one possible implementation of a method for estimating latency between two computers;
FIG. 4 is a flow diagram showing an implementation of an extension of the implementations of FIGS. 2 and 3 that may support team-based networked video gaming;
FIG. 5 is a flow diagram describing one possible implementation of a method of compensating for unacceptable delays regarding a central critical object of a team-based networked video game;
FIG. 6 is a pictorial diagram illustrating an effect of transmitting data packets according to the implementation shown in FIG. 4;
FIG. 7 is a pictorial diagram presenting a result of applying the implementation of FIG. 5 to a portion of a video baseball game;
FIG. 8 is a flow diagram of one implementation of a method of accounting for character attributes in a team-based networked video game;
FIG. 9 is a pictorial diagram illustrating an effect of applying the implementation of FIG. 5 to passing of a ball in a team-based networked video game;
FIG. 10 is a flow chart showing one particular implementation of a method of changing character attributes during play in a team-based networked video game;
FIG. 11 is a flow diagram describing one implementation of a method of allowing a player to enhance skill levels of a character in a team-based networked video game;
FIG. 12 is a pictorial diagram of one possible embodiment of a system adapted to perform a hosting function for online team-sport video games and events;
FIG. 13 is a pictorial diagram summarizing a single-elimination tournament involving eight teams with seven scheduled games;
FIG. 14 shows two charts including portions of records from a typical scenario of a game included in the tournament of FIG. 13; and
FIGS. 15-19 is a set of flow diagrams illustrating one implementation of a method of managing a tournament.

DETAILED DESCRIPTION OF THE PRESENTLY PREFERRED EMBODIMENTS

Reference will now be made in detail to the presently preferred embodiments of the invention, examples of which are illustrated in the accompanying drawings. Wherever possible, the same or similar reference numbers are used in the drawings and the description to refer to the same or like parts. It should be noted that the drawings are in simplified form and are not to precise scale. In reference to the disclosure herein, for purposes of convenience and clarity only, directional terms, such as, top, bottom, left, right, up, down, over, above, below, beneath, rear, and front, are used with respect to the accompanying drawings. Such directional terms should not be construed to limit the scope of the invention in any manner.
Although the disclosure herein refers to certain illustrated embodiments, it is to be understood that these embodiments are presented by way of example and not by way of limitation. The intent of the following detailed description, although discussing exemplary embodiments and implementations, is to be construed to cover all modifications, alternatives, and equivalents of the embodiments as may fall within the spirit and scope of the invention as defined by the appended claims. The present invention has applicability in the field of video gaming in general. For illustrative purposes, however, the following description pertains methods and apparatus adapted to playing team-based sports over networked computers.
The following description employs terminology that may be better understood in terms of the following definitions:

Game: A game is a competitive activity performed on one or more computers involving skill, chance, and/or endurance by two or more participants who play according to a set of rules.
Player: A player is a human participant in a game. The human participant typically controls a character, defined infra.
Character: A character is a computer-generated entity (e.g., a basketball player, football quarterback or the like) represented as an image that may appear in a scene displaying a game layout on a computer monitor. Two types of characters may be distinguished. In the context of the present application, a P-character may be a character controlled, at least in part, by a player who controls a computer input such as a keyboard, mouse, joystick, or the like. Another type of character may be generated by a computer executing artificial intelligence (Al) game software. Such a character will be referred to as an “AI-character” in the sequel. Terms of “character” or “avatar” character may be used to refer to either type of character.
Character attribute: A character attribute is a property of a character that, at least in part, controls an ability of the character to perform functions of a game. For example, a baseball pitcher character may have an attribute of being able to throw a fast ball at 100 miles per hour; a football halfback may have an attribute of being able to run 40 yards in 4.4 seconds.
Team-based game: A team-based game (also referred to as “team sports”) is defined as any game dedicated to a central critical object (defined infra) in which members of each of a first team (more than 3 participants per team) must cooperate with each other to compete with members of a second team, each team attempting to achieve a successful outcome (e.g., a win) of a game.
Character enhancement: Character enhancement is defined as changes in a character's attributes that are awarded to characters through point allocation based on in-game successes and failures.
Database: A database is a central record keeping and processing server that dynamically receives and communicates information both to and from a game client instigated on a player's computer. Data contained in the database may be manifested through a dedicated website.
Event: An event is defined as any form of league, tournament, contest, or other competition including one or more games involving more than two teams and/or players and having a goal of declaring one team to be a winner within a specified period of time.
Event progression: Event progression_occurs when the database dynamically accumulates all game actions and results to update subsequent steps in the event. Examples of event progression include: team rankings in a league, seeding for tournaments, moving from round to round within events, awarding championships to participating members of winning teams, and coordinating final results for individual events for compounding event creations.
Game state: A game state is a set of descriptors that define a condition of all objects in a game at a specified instant of time. Objects may include, for example, characters, which may have, for example, a position, a speed, and a direction in addition to other attributes. Objects further may include sports equipment (e.g., a baseball bat, a tennis racket, a golf club, or the like), which may have descriptors associated therewith related to a function of the sports equipment. Objects further may include a central critical object, defined infra.
Central critical object: A central critical object refers to a single, most important object in a game, control of which directly determines an outcome of the game. In many cases, the central critical object in a game is a ball. For example, a baseball is the central critical object in a baseball game, a football is the central critical object in a football game, a basketball is the central critical object in a basketball game, and so on. Other examples of central critical objects may include a hockey puck, a badminton bird, a FRISBEE® and the like.

Team-based networked video games employ computers networked together whereby players engage in activity intended to simulate important aspects of sports games normally played on a playground or on a special field designed for a purpose of playing a specific game. For example, a baseball field is designed for playing baseball, a football field is designed for playing football, a tennis court is designed for playing tennis, and so on. In an actual game, a central critical object, e.g., a ball, provides a focus around which the gaming activity or organized. For example, in a baseball game, absent a baseball in play, virtually nothing of interest occurs, save conversations between a pitcher and a manager, players changing position in an outfield, and the like. Enter a baseball in play, however, and the baseball game virtually comes alive. A baseball can, for example, be pitched by a pitcher, hit by a batter, caught by a fielder or used to tag a base runner.
In order to produce a realistic simulation of so-called real games, team-based networked video games necessarily focus on the central critical object, often a ball. Simulated team-based games played on networked computers have particular difficulty in dealing with the central critical object because of an issue of latency. Suppose, for example, that a simulated batter, i.e., a batter character, which may be either a P-character or an Al-character, hits a baseball in a simulated baseball game. Hitting of a baseball occurs in a fraction of a second, and such an occasion must, somehow, be conveyed to all players both quickly and in a manner that makes it clear to all players what has just happened. Indeed, if the hit represents a line drive to a shortstop character, then it is critical that a player whose character is the shortstop be aware as soon as possible that the ball is headed in the direction of the shortstop character. At the same time, it may be important that a player whose character plays left field be ready to go after the ball in case the shortstop muffs the play.
These and other time-critical aspects related to the central critical object may be adversely affected by a latency associated with transmission of data among computers. Typically, data is transmitted among computers in a form of data packets, a data packet containing information about a current state of objects in a game. If, as suggested above, a batter hits a line drive in a direction of a shortstop character, then it is important that the shortstop be given an opportunity to react to the hit rather than, for example, receiving a data packet regarding the hit after (due to latency) a similar data packet has been received by, say, a right fielder character not directly involved in activity related to the hit. Video games traditionally have employed a “time difference” buffer in an attempt to mitigate effects of latency. A prior-art time difference buffer, however, generally fails to account for each unique situation. For example, when the ball is controlled by a character connected to the game with a computer having a particularly low connection speed (i.e., bad latency), the buffer required may be completely different from that required in a situation where the connection speed is high.
The present invention addresses this issue by dynamically estimating an optimum buffer time. By way of introduction, consider FIG. 1, which is a pictorial diagram indicating one possible arrangement of several computers that may be used by players involved in a team-based networked video game. This diagram includes a wide variety of possibilities, many of which can affect latency associated with communication between pairs of computers. For example, computers 20 and 25 may be located in Los Angeles connected to a computer network 15 with a digital subscriber line (DSL) modem that transmits at 300 kbit/s and receives at 1.5 Mbit/s. Computer 30 may be located in Philadelphia connected to the computer network 15 with a dial-up modem that transmits at 7200 bit/s and receives at 28 kbit/s. Computer 35 may be located in Miami and connected to the computer network 15 with a cable modem that transmits at 256 kbit/s and receives at 4 Mbit/s. Each of these data rates as well as data rates associated with other computers involved in a game may be variable, depending upon a time of day and other factors that may be difficult, if not impossible, to predict. Additionally, the computer network 15, itself, may introduce variable delays giving rise to variable latency, these variable delays depending upon a volume of traffic that may vary through out a day.
Considering an effect of variable latency on an outcome of a game, prime consideration must be given to the central critical game object in the game, e.g., a ball. In, for example, a baseball game, whoever has possession of the ball can alter the outcome of the game (or at least a typical sequence in the game). Instances may arise, because of effects of latency, when more than one player may think that his or her character has possession of the ball. Alternatively, the ball may appear in two locations, or the ball may appears with one character, then suddenly disappear and re-appear with another character). For example, a batter character may have relatively bad latency. In such a case, a pitcher character pitches, and while the batter character makes contact, his packet of data does not reach (and thereby inform) the rest of the players before a catcher character has received the ball in his mitt and has sent out packets. In this case, players would see the catcher character catching the ball, would see the runners returning to bases, and then suddenly would see the ball flying toward the outfield. The whole point of overcoming latency is to make sure that all players in a game see the same location or possession.
The present invention involves a mechanism to determine in real time how to resolve these potential conflicts. One approach involves compensating an optimized time buffer, so that a character who is identified to have an opportunity to affect an outcome is sequenced as the first one to receive a data packet relating to an action (i.e., to allow the character's player see the action first, before any other players). The rest of the players would receive the packet at a later (e.g., immediately following) time.
It should be emphasized that variable latency among computers, not simply network latency, itself, creates problems with simulation of realistic games in real time. Indeed, if network latency were constant between all possible pairs of computers, then all computers would receive information about, for example, a batter hitting a baseball at the same time, which, although delayed, would provide each player with an identical opportunity to respond to the hit.
FIG. 2 is a flow diagram describing one particular implementation of a method of reducing effects of variable latency in a team-based networked video game. The illustrated implementation provides a method of controlling a time at which a scene representing, for example, a state of a team-based networked video game at a particular instant of time is displayed on a remote computer. According to the implementation, a first computer receives at step 70 a data packet from a second computer, the data packet including information regarding the scene and further including time delay information. The second computer waits for an amount of time according to the time delay information at step 75 and then displays the scene at step 80. In this way, the first computer may be able to control a time at which the scene is displayed on the second computer.
The time delay information referenced in FIG. 2 may be related, for example, to perceived latency involved in transmitting the data packet from the second computer to the first computer. One possible implementation of a method for estimating the latency between the first and second computers is described in a flow diagram shown in FIG. 3. In this implementation the first computer transmits a test data packet at step 100, the test data packet including a request for an immediate reply (such a test data packet may be referred to as a “ping”). A reply to the ping is received at step 105, and an elapsed time, i.e., a time interval between transmission of the ping and reception of the reply to the ping, is determined at step 110. The elapsed time represents a round-trip time delay required to transmit a data packet from the first computer, receive the data packet in the second computer, transmit a reply from the second computer, and receive the reply in the first computer. The elapsed time therefore may be substantially equal to twice a time delay associated with one-way transmission from the first computer to the second computer, which time delay may be identified as a latency associated with the one-way transmission.
The implementations of methods described in FIGS. 2 and 3 may be extended to support team-based networked video gaming using a method, one particular implementation of which is described in FIG. 4. The implementation of FIG. 4 may apply to a case where an action occurs on a first computer involved in a team-based networked video game, and where it is desirable to display a scene according to that action on a plurality of other computers involved in the game. In this case, the first computer may transmit a ping addressed to the plurality of other computers at step 130 and may receive a plurality of replies to the pings at step 135. At step 140 the first computer may determine a plurality of round-trip times according to the plurality of replies. For example, the first computer may start a timer when the ping is transmitted and then may interrogate the timer as each of the plurality of replies is received to determine a round-trip time associated with each reply. At step 145 the first computer may determine a plurality of time delay values (i.e., latency values) according to the plurality of replies by dividing each of the round-trip times by two. A plurality of data packets then may be transmitted at step 150 addressed to the plurality of other computers, each data packet including information regarding the scene to be displayed along with a time delay value according to the latency value determined for each computer. Each of the plurality of other computers may receive a data packet containing the scene information and the time delay value. Each of those computers, then, waits for an amount of time according to the time delay value before displaying the scene at step 155. In this way, all of the plurality of other computers may display the scene at substantially the same time.
It should be noted that delay between any two computers in a network might change with time. Further, each computer can ping other computers on the network essentially continuously (i.e., at times when other data packets are not being transmitted) during a session of a game. Consequently, at any given moment, any computer in the network can know the delay associated with communicating with any other computer on the network.
One possible situation in which the implementation of the method summarized in FIG. 4 occur when, for example, a player P₁in a team-based networked video game may initiate an action of a corresponding character C₁. For example, C₁may step to his right by one pace. Before sending a data packet communicating this action to computers of other players, the computer at which P₁plays may first ping the other computers, determining how long it will take to send the data packet to each computer. After the determination, each packet is transmitted along with a unique delay instruction for each computer so that each receiving computer will take delivery of the packet but will also delay the execution of the packet by an amount according to the delay instruction. In this way all players see that C₁steps to the right at substantially the same time.
A specific example involving four computers at which play four players P₁, P₂, P₃, and P₄, is illustrated diagrammatically in FIG. 6. The diagram shows time on a horizontal axis, and a vertical axis may represent, for example, a virtual distance between computers, the virtual distance corresponding to a time required for a data packet to travel between the computers. For purposes of this example, it may be assumed that a first computer, e.g., the computer at which player P₁plays, needs to send a data packet comprising a scene related to action in a team-based networked video game to computers represented in the diagram by P₂, P₃, and P₄. Further, it may be important that each player receives a display of scene at substantially the same time. According to the implementation described in FIG. 4, the first computer (represented by P₁in the diagram) pings each of the remaining computers at Stage 1 (cf. steps 130-145 in FIG. 4) in order to estimate a time delay value (i.e., a latency value) for each of the computers represented in the diagram by P₂, P₃, and P₄. Pings transmitted by P₁are shown as arrows 220, 230, and C05; respective replies to the pings are shown as arrows 225, 235, and 240. The pings are transmitted essentially simultaneously at t=0, and a reply to the ping to P₂is received at a time 2×t₂. Similarly, replies to the pings to P₃and P₄are received at respective times 2×t₃and 2×t₄. In the illustrated example, the longest latency is t₄associated with the computer at which player P₄plays. Accordingly, in order to assure that each player sees the scene at substantially the same time, P₁transmits at Stage 2 (cf. step 150 in FIG. 4) data packets to P₂, P₃, and P₄, the data packets comprising time delay information according to the respective computer to which each data packet is addressed. Specifically, P₁transmits is a data packet shown as arrow 250 addressed to P₂, the data packet 250 comprising information according to the scene as well as a time delay value of (t₄−t₂). Similarly, P₁transmits a data packet shown as arrow 255 addressed to P₃, the data packet 255 comprising the same scene information but including a time delay value of (t₄−t₃). A data packet shown as arrow 260 comprising the same scene information is further transmitted to P₄, the data packet 260 further comprising a time delay value of zero. Upon receiving the data packet 250, P₂waits for a time interval of (t₄−t₂) represented by arrow 265and then displays the scene. Similarly, when P₃receives data packet 255, P₃waits for a time interval of (t₄−t₃) represented by arrow 270 and then displays the scene. Computer P₄, when it receives data packet 260 displays the scene essentially immediately. It will be understood that P₂, P₃, and P₄display the scene at substantially the same time, i.e., a time t₄after transmission of the data packets 250, 255, and 260 by the first computer. The substantially simultaneous display of the scene on computers P₂, P₃, and P₄, may essentially remove any effect of variable latency among the computers represented.
As discussed supra, the implementation described in FIG. 4 may apply to a situation where, for example, a character in a team-based networked video game steps to his right. However, stepping to the right is a relatively simple action, possibly inconsequential relative to an outcome of a game, and a slight delay on the arrival of its associated packet of data may not cause a game to go into an inconsistent state. In many games, however, especially those requiring a fast reaction (i.e., a sport game), coordination among players (i.e., a team game) or both, even slight delays may cause irreparable and irreversible problems.
Moreover, if the outcome of game or the outcome of part of the game hinges on a central critical object in a game, e.g. a soccer ball in a soccer match, then special attention must be paid to ensure that the central critical object is treated with primacy. Data packets concerning the object must not delay in arrival, or else the outcome of the game can be challenged.
One possible implementation of a method of compensating for unacceptable delays regarding the central critical object of a team-based networked video game is summarized as a flow diagram in FIG. 5. Transmission of data packets in this implementation is controlled in part by a determination of which character in a game is most likely to have an immediate and consequential effect on an action occurring in the game. According to the illustrated implementation, a game state is received at step 175, and an action is received at step 180. An action may comprise, for example, a pitcher character pitching a central critical object, e.g., a baseball, in a baseball game, a basketball player character passing a central critical object, e.g., a basketball, in a direction of another basketball player character in a basketball game, a runner fumbling a central critical object, e.g., a football, in a football and the like. A ranking of characters in a game may received at step 185, the ranking being formed according to a likelihood of characters having an immediate and consequential effect on a result of a play in a game as a result of the action. A top-ranked character may be selected at step 190. For example, a batter character may be identified as a top-ranked character, i.e., determined to be a character most likely to have an immediate and consequential effect on a baseball game immediately after a pitcher character releases a baseball as part of a pitch. That is, the batter character may swing and make contact with the ball, swing and fail to make contact with the ball, or not swing in response to the pitch. In any case, any action of the batter character can be expected to have a critical effect on a subsequent state of the game. Further, possible batter character actions may take place very quickly, thereby enhancing a detrimental effect of latency associated with communicating action of the batter character to other players in the game. With the top-ranked character selected, a data packet according to the action is transmitted first to a computer associated with the top-ranked character at step 195. The data packet is transmitted to a remainder of computers at step 200, but after transmission to the computer of the top-ranked character.
Continuing with the baseball example, a computer associated with the pitcher character may transmit a data packet to a computer associated with the batter character immediately upon release of the baseball in a pitching motion. As the pitcher character delivers, a player at a computer representing the batter character (the top-ranked character according to a current state of the game) sees the baseball (i.e., the pitch) speeding across a playing field and is able to decide whether to swing at the pitch or not. At a point of swinging (or not swinging), a remainder of players involved in the game do not see the swing (or non-swing) yet. Instead, they see the central game object, i.e., the baseball still traveling in mid-air. Further, failure by non-batter players to see certain details of the batter's actions may not be critical in a certain current game state. In scenarios, seemingly inconsequential actions of a batter character may be important. For example, a likelihood of a base runner attempting to steal a base may be determined, in part, by a stance of the batter. Immediately after any action (i.e., swing or non-swing) by the batter character, a new game state is received, and a new ranking of characters determined. In the present case, a catcher character may be top-ranked.
More specifically, the baseball example just introduced may be described pictorially in a diagram appearing in FIG. 7. As before, a Stage 1 step may be included to determine latencies at various points in a game, although only one such determination involving pings/replies 290/295, 300/305 and 310/315, is shown in FIG. 7. At a moment of a pitch from the pitcher character, the batter character may be selected, according to a ranking procedure carried out according to the implementation of FIG. 5, as the character most likely to have an immediate and consequential effect concerning the central critical object. No other players in the game at this point see the pitch on their computer monitors. Accordingly, in Stage 2 a data packet 320 may be transmitted at t=0 representing delivery of a pitch from a pitcher character to a computer of a batter character. At a brief time Δ₁later, data packets 325 and 330 may be transmitted, respectively, to a computer of a catcher character and to a computer of a character representing a runner stealing. The brief time delay Δ₁may not cause a problem because actions of the stealing runner character and the catcher character are not deemed to have an immediate and consequential effect regarding the central critical object at this time in the game. Upon arrival of packet 320 at the computer of the batter character, the batter character performs some action (e.g., swing/not swing) and a new ranking determines the catcher character as the top-ranked character. Therefore a result of the batter character's action is essentially immediately transmitted to the computer of the catcher character in data packet 335. After a brief delay of Δ₂, a data packet 340 containing information regarding the batter character's action is transmitted to a computer of the stealing runner character. Meanwhile, immediately upon reception of data packet 335 at the computer of the catcher character, a new ranking determines the stealing runner character to be the top-ranked character, and a data packet 350 regarding action of the catcher character is transmitted from the computer of the catcher character to a computer of the stealing runner character. After a delay of, say, Δ₃, a similar data packet 355 is transmitted from the computer of the catcher character to the computer of the batter character. Further, after a delay of, say, Δ₄, a similar data packet 360 is also transmitted to the computer of the pitcher character. The computer of the batter character also may, after some time delay of, say, Δ₅, transmit a data packet 345 to the computer of the pitcher character, data packet 345 containing information essentially similar to that sent to the computer of the catcher character in data packet 335. The computer of the batter character, further, may send similar data packets (not shown) to other characters such as fielders according to their ranking.
The implementation of the method described in FIG. 4 refers to a ranking of characters in a team-based networked video game according to an immediate and consequential effect that a character may have on an outcome of a game. In some instances, the immediate and consequential effect of a character may depend upon attributes of the character. As one particular example, consider a game state where a character (a passer) passes the central critical object, e.g., a ball, between two other characters, C_xand C_y. C_x, for example may be on a same team as the passer; character C_ymay be on an opposing team. Both characters may wish to receive the ball for different reasons: character C_xin order to advance his team's goals, character C_ymay wish to intercept the pass in order to thwart intentions of the other team. Character C_xmay be located, for example, five feet on a first side of a trajectory of the pass; C_ymay be located seven feet on an opposite side of the trajectory of the pass. Character C_xmay start running toward the trajectory. Success of C_xmay be determined primarily, or at least in part, by certain factors, which may include, for example, (a) an in-game physical attribute of C_x(i.e., C_xmay be endowed with fast speed), (b) a virtual physical limitation of having an effect on the outcome (e.g., virtual distance of C_xaway from the trajectory(, (c) an ability of C_xto receive the ball, (d) an ability of C_xto retain the ball upon reception, (e) actual game rules, which may affect eligibility of C_xto receive the ball, and (f) any other factors that may affect an outcome of an action under non real-time constraint. Non real-time constraints may refer to decisions made that may affect a character's predisposition to be more likely to succeed (or fail) in certain situations. For example, a parameter called Catching Range may be particularly important. Players, in a manner more particularly described infra with reference to FIG. 11, may be given a choice of assigning points to boost Catching Range, which points, once assigned, may be unable to be redistributed. A decision to assign points to boosting a capability in a certain area may occur outside the game and therefore may be a non real-time issue. The factors to be considered may be ranked in order according to a game state. Of course, a similar collection of factors may affect an ability of character C_yto intercept the pass. In general, the factors pertaining to the two characters may result in a conflict, making it unclear who should be allowed to receive the pass in a specific situation. For example, while C_xis closer to the path, C_ymay enjoy a better in-game attribute, in this case speed. If C_xand C_yare allowed to attempt to receive the ball on its trajectory, the game risks having a brief moment when both characters can claim to have the ball. This is because network latency prohibits a real-time determination as to rightful possession. It is only after-the-fact that some logic may be able to decide that, for example, C_yhas ownership because his superior speed more than compensates for his relative farther distance than that of C_x.
As one illustrative example, C_xand C_y, both with latency of 120 ms, may be running at a same time to a ball trajectory, with C_xbeing closer but C_ybeing faster. In this example, suppose that the game includes one character with a worst latency, around 170 ms. This means both C_xand C_ytherefore would send data packets to each other with a 170 ms−120 ms=50 ms delay instruction according to the implementation described in FIG. 4. If, according to the implementation described in FIG. 5, say, C_yis to determined to be the most qualified character, his computer will immediately send a data packet to C_ywithout any delay instruction, thus saving 50 ms and helping to avoid both players appearing to have possession of the ball. It is noteworthy to mention that most such scenarios will appear too quickly on the computer screen for players to discern which character actually has possession of or catches the ball. A fair and logical system to assign the ball in the virtual world can thus enhance system performance and operability.
It remains to describe a mechanism to resolve the conflicts in real time and to ensure that normal game sequences, take place without interruption caused by latency.
When considering special attention (e.g., latency displaying different realities to different players) to the central critical object in a game (e.g., a ball), architecture or design of the game must also consider other factors that may affect position, momentum, reaction time and other parameters of the central critical object. For example, by stepping to the right, a player may be able to intercept the central critical object (e.g., the ball), if his in-game character allows him to stretch for extra inches in order to reach the ball.
As such, the present invention concerns flow of data packets in a peer-to-peer networked environment and how the flow and extra steps may resolve issues arising from network latency.
The present disclosure, in addition to addressing the latency issue as described supra with reference to FIGS. 2, 3, 4, 6 and 7, also determines in real time how to resolve other latency-related conflicts.
In order to take character attributes (e.g., virtual capabilities) into account, an implementation of a method described in a flow diagram of FIG. 8 may be applied. In the illustrated implementation a game state is received at step 380, the game state including locations for characters involved in a team-based networked video game. A trajectory of a central critical object is received at step 385, and in-game speed attributes are received for each character in the game at step 390. Virtual distances from the trajectory for each character are received at step 395. According to one implementation, a virtual distance from a character to a trajectory is calculated as a minimum distance between a location of the character to a point on the trajectory. An indication of each character's ability to receive the central critical object is received at step 400 as is an indication of each character's ability to retain the central critical object if the character does receive the central critical object at step 405. An indication of each character's eligibility to receive the central critical object according to rules of the game is received at step 410. For each character, a likelihood that the character will receive the central critical object (CCO) is calculated at step 415. Likelihoods may be calculated by combining, for example, factors mentioned supra including in-game physical attributes of characters, virtual physical limitations of characters, and so on. Depending upon, for example, rules of a game (e.g., baseball game rules), a level of a character (e.g., with a higher level demanding more skill), a type of game (e.g., a casual pick-up game or a competitive league game), different factors may be given different weight in calculating the likelihoods. The likelihoods are ranked at step 420. Generally, a character having a likelihood no lower than likelihoods of all other characters may receive the central critical object.
The example just cited takes many factors into account in order to calculate a likelihood for each player. Other factors also may come into play such as, for example, an ability to jump to a relatively high level or to reach for a relatively long distance. In a basketball game, for example, a seven-foot character may have attributes relative to jumping and reaching that exceed those of, say, a five-foot character. Consequently, if a game state relates to retrieving a rebound with a seven-foot character located three feet from the central critical object and a five-foot character located two feet from the central critical object, then calculated likelihoods that take jumping ability and reach into account may favor the seven-foot player. Alternatively, if a game state relates to diving onto a floor to retrieve a loose ball, then a five-foot character, who may be more agile than a seven-foot player, may be favored. Other in-game attributes related to other game states will occur to one skilled in the art.
For example, in a soccer game where one of twenty-two players may be determined to have the most likely immediate and consequential effect on the central critical game object (in this case the soccer ball), the implementation of FIG. 8 may then determine a ranking of the rest of the characters. That is, an implementation based upon FIG. 8 may determine which character should next be allowed to see action on a computer monitor after a player having a potential interceptor as a character sees the action. Considerations around the implementation of FIG. 8 may propel, for example, an apparently inferior character over an apparently top-ranked character to claim possession of the central critical object.
Considering another example involving a potential interceptor of a pass, FIG. 9 is a pictorial diagram describing interactions among four characters, T₁C₁, T₁C₂, T₂C₁and T₂C₂(T_iC_jrefers to the j^thcharacter on the i^thteam for i=1,2; j=1,2) involved in a team-based networked video game. As described supra with reference to FIG. 6, at stage 1, time required to send a packet of data to and back from one computer to other is measured (often called ping time or latency) represented by pairs of arrows 440/445, 450/455, 460/465, 470/475, and 480/485. This step, while preferred, may be omitted. T₁C₁has possession of the ball, and a player having T₁C₁as a character would like to pass the ball to teammate T₁C₂. T₁C₁then commits to pass the ball (or, in other examples, the following analysis occurs even before T₁C₁commits to pass the ball). In a vicinity of a trajectory of the ball stands T₂C₁, who may be identified according to an implementation of method described supra with reference to FIG. 5 as a character who may be able to intercept the ball. That is, in this example, T₂C₁is identified to (b) be at a relatively close virtual distance from the trajectory of the ball, to (a) possess an in-game physical attribute (e.g., running speed) sufficient to allow T₂C₁to possibly move to and intercept the trajectory of the ball in time to contact the ball, and to (c) be eligible according to actual game rules to intercept. T₂C₂, teammate of T₂C₁, is afar observing the event.
Considering data packet 490 in FIG. 9, although T₁C₁is passing the ball intentionally to T₁C₂, the implementation of FIG. 5 identifies T₂C₁as a potential interceptor. After taking into account latency, T₁C₁may be instructed, again, according to the implementation of FIG. 5, to first send data packet 490 regarding passing of the ball only to T₂C₁. Upon receiving data packet 490 (and instantly displaying a corresponding result on a monitor of the computer of the T₂C₁character), T₂C₁successfully intercepts the ball. Immediately, the computer of T₂C₁sends out data packets 495 and 505 to notify the rest of the players of his interception (the computer of T₂C₁may also notify T₁C₁as well, but that notification is immaterial in this discussion and, as such, is not shown in FIG. 9). As far as T₁C₂is concerned, the data packet 495 would arrive at t₃+t₅.
In contrast, consider a scenario wherein the computer of the T₁C₁character were also to notify T₁C₂(the intended recipient of the ball) at the same time (starting at t=0). In that case, the computer of the T₁C₂character receives the data packet at t=t₂, thereby eliminating any chance for T₂C₁to intercept the ball (or the player having T₂C₁as a character would think that he had intercepted, while the rest of the players would see the T₁C₂character as having possession). The current invention dynamically calculates buffer time required to compensate all such situations. In this case, the packet from the computer of the T₁C₁character to the computer of the T₁C₂character, i.e. data packet 500 does not go out till t₃+t₅−t₂.
As far as data packet 510 is concerned, in extreme cases, a computer of a player may need to notify a computer of another player before t=0. However, according to the present invention, the notification can still occur at t=0 (shifting 510 to 515) if receipt of the data packet is deemed to not to have an immediate and consequential effect upon the outcome of the game.
As another example, a pitcher character may pitch a baseball by throwing the ball in a direction of a batter character and a catcher character. In that case, the batter may be designated as a primary potential interceptor of the central critical object; the catcher may be designated as a secondary potential interceptor. The throwing, i.e., pitching, of the ball by the pitcher amounts to a change of possession of the central critical object, and, according to the present invention, such a situation may be termed a “singularity.” Upon occurrence of a singularity, buffer delays may be recalculated according to latencies determined between a computer corresponding to the character who recently took possession of the central critical object and all other computers involved in the game.
Continuing, if the batter, for example, hits the ball, say, between shortstop and second base characters, then the discussion supra relative to FIGS. 4 and 8 may determine which of the shortstop and second base characters should be determined to be the primary potential interceptor. Again, buffer delays may be recalculated (a procedure that may be referred to as “dynamic resequencing”) between the computer of the primary potential interceptor and all other computers, and the game may continue as already described. If a character were to act on the central critical object in the game in an absence of dynamic resequencing, his action may not show on a computer screen of other players until after an appreciable delay. For a sports game, such a delay, generally, is unacceptable, as it may destroy any illusion of realism and may have a significant adverse effect on an outcome of the game.
In certain circumstances, e.g., when it may be desired to reward players who participate in team-based networked video games or to provide an incentive for players to continue to play, characters may be allowed to evolve to higher levels of ability by changing character attributes during play of one or more games. One particular implementation of a method of changing character attributes during play is shown as a flow chart in FIG. 10. According to the illustrated implementation, a roster of characters is received at step 535. Typically, more than one roster is received, a roster comprising characters who play on a single team. A collection of in-game attributes is received at step 540 for each character. In-game attributes may comprise, for example, speed, agility, reach, and the like. A history of games played is received at step 545. Generally, any character can be expected to evolve to higher levels by playing in more games. A game then may be played, and in-game attributes may be modified dynamically during the game at step 550 according to experience of the character in the game.
Team-based networked video games may be organized into various events that provide special opportunities for character enhancement. For example, a league may be formed, the league comprising a collection of teams that compete with each other in some organized way. For example, teams in a league may compete on a round-robin basis wherein each team plays each other team in the league for a given number of times. Each team may play each other team twice, for example. A league may exist for a season, at an end of which playoffs may be organized. A playoff may be one form of a tournament, which may be single-elimination, double-elimination, and so on. In order to facilitate execution of events, a hosting function may be required. One example of a hosting function may comprise a website that may provide an administrative interface for players who wish to participate in events. The hosting function, further, may comprise a server that may maintain a database comprising information about structures of teams, rosters of players, team records (e.g., win/loss records), character records (e.g., baseball batting averages, basketball field goal percentages, and the like), the character records normally being related to a player who participates in events through one or more characters.
FIG. 12 is a pictorial diagram of one possible embodiment of a system adapted to perform a hosting function for online team-sport video games and events. In the sequel, this online team-sport video game hosting system may be simply referred to as a hosting system or as a hands-free event hosting system. The illustrated embodiment comprises a website, which for purposes of illustration, may reside on a web computer 615 adapted to intercommunicate with computers on a computer network 610. The embodiment further may comprise a server, which may be implemented on another computer 625 and which may comprise a database 630, may also be adapted to communicate with computers on the computer network 610. In particular, web computer 615 and computer 625 may intercommunicate with each other and may, thereby, provide a service to other computers on the computer network 610 including, for example, computers 635-655 in the illustrated embodiment. In general, no limit to a number of computers that can be served by the server and the website is contemplated. As another aspect of the service provided by the website and the server, a player may login through a game client executing on a computer on the computer network 610, in particular, any of the computers 635-655, and the server may determine whether an update to the game client is necessary.
The embodiment of a hosting system illustrated in FIG. 12 may offer services that include, for example, providing a gaming platform in a form of peer-to-peer online, team-based sports games as described herein. Additional services may include offering interactive event hosting in a form of automated leagues, tournaments and contests. Still more services may include allowing players to enhance skill levels of their characters through performance- and achievement-based point systems while participating in events and/or games hosted by the system. FIGS. 15-19 illustrate one implementation of a method of managing a tournament, the method comprising receiving registration information, organizing teams, handling billing, and the like.
One implementation of a method of allowing a player to enhance skill levels of a character is shown in FIG. 11. The implementation comprises maintaining an accumulation of experience points at step 570. An accumulation of parameter points is maintained at step 575, and an accumulation of skill points is maintained at step 580. In one particular example, parameter points in a baseball game include several parameters such as body strength (for batting power), speed (for fielding), quickness (for stealing), catching range (for fielding), arm strength (for pitching a fast ball and also for fielding), and throwing accuracy (for curve ball pitching and also for fielding). During a game, a character may perform an action, e.g., earning a run, that may allow the character to receive an allocation of points that can be assigned to, for example, any of the several just-mentioned parameters. In this way, a player may increase a skill level of the character. For example, a character may hit four home runs in a baseball game and thus be recognized in having greater skill as a hitter. The action may be received at step 585, and the accumulations maintained at steps 570-580 may be modified at step 590. The accumulations may be maintained, for example, on a database in a server (e.g., server 620 described supra relative to FIG. 12) that communicates from time to time (or essentially in real time) with a game client on a computer where the player plays in order that the database reflect up-to-date information about a character's actions in games.
The website/server system described supra with reference to FIG. 12 may provide additional services to players regarding, for example, the system may create events such as tournaments, league games, contests, and the like that are hosted by the system. The system may provide services including registration, wherein players may access the website and follow instructions to signup characters for certain events. The server computer 625, for example, may store registration information, in the database 630. Events may be generated through the database 630 according to player registration for particular game and a particular website dedicated to the game. After successful player registration for the event as described during event creation, event games may be automatically created only for those players who are found on the event list in the database server. The system, further, may generate a schedule of games according to an event. For example, a tournament event may comprise several games that are played in a sequence according to seeding of teams that participate in the tournament. The system still further may create games according to the event. A game may be created to involve players/characters who have registered for the event. Creating a game may comprise, for example, creating a website dedicated to the game. Players may access the website in a well-known manner in order to participate in the game. Record keeping, schedule maintenance and updating, and results display services also may be provided by the system.
A character (and therefore, directly, a player associated with a character) may undergo character enhancement while participating in games/events hosted by embodiments of the host system illustrated in FIG. 12. In particular, team-based networked video games and events may be offered by the host system, which may maintain statistical records and actions based on team-sport models that are in common use in actual professional and amateur sporting organizations at many levels.
Achievements can be personal or team-based (e.g., batting average for baseball, points scored for basketball, rushing yards for football, assists for soccer, team win/loss records for all team sports). These statistical records may be assigned values in a form of distributable points that may be redeemed by a player in order to customize his or her individual character. Players can increase physical attributes for their characters for any characteristic (including speed, strength, agility, stamina, range, successful percentage chance, and the like). These enhancements are a direct result of player achievements during game play within the peer-to-peer online team sports video game model.
The embodiment of the hosting system illustrated in FIG. 12 may provide character enhancement services through successful participation by players in events hosted by the system. As described herein, player enhancement via in-game actions may be accumulated throughout an entire progression of an event by utilizing a central database maintained by the hosting system.
Players permitted to participate in event games through the database may be rewarded not only with event participation and statistical record keeping in a form of event progression (rounds, rankings, etc.), but also may be rewarded with character enhancements during the event itself. Each action in the online sports team event (e.g., stealing a ball, striking out, kicking a field goal, and the like) may be assigned a point value that may be materialized in a form of character enhancements. Points may be accumulated dynamically by a character during event games and may be sent to the database. The database typically processes the point information and assigns enhancements back to the character abilities in real time, so that the character's capabilities and attributes are almost immediately changed based upon his performance. Characteristics like speed, power, range, stamina, and the like may be increased or decreased based on character success (or failure) within the game.
Character achievements and corresponding point values may be accumulated during games and/or events in which a player (through his/her character) participates. Character enhancements achieved as a result of in-game performance are not only materialized or used during the events themselves, but also throughout all other game-play options (e.g., pick up games, practice modes, and the like) that may be offered by the hosting system.
In contrast, the present invention records character actions for event progression purposes simultaneously with individual character enhancement. For example, a player whose character hits a homerun for the player's team may positively affect the player's team's progression within the event. Simultaneously, distributable points rewarded by the action (e.g., the homerun) may be sent to the database so that the player may enhance his character's batting strength.
The present invention, therefore, offers a unique capability to enhance a player's character's real-time performance within a game at the same time as hosting the event created through the hosting system, which may comprise a central database server. The prior art would not appear to allow all of the functionalities just outlined. No prior art sports game offers multiplayer (i.e., more than 2 players per team) events where players can enhance performance of their characters' performance while participating in a game or event. Rather, prior art systems may use the events, themselves, as a draw. While a tournament offering prizes has been the draw for players in prior art systems, the present invention allows players to enhance their characters during the events themselves as well as offering marketing prizes for the tournaments/leagues/contests/etc.
Utilizing a central database to record all event game actions allows each action to carry a value independent of the statistical records being kept. For example, if a player's character in a baseball game were to get three hits in four at bats, his or her batting average would be 0.750 for that game. The statistic is a result of actions as determined by the latency issues discussed supra with reference to FIGS. 2, 3, 4, 5 and 6 in peer-to-peer networks for online team-sports games. For example, when a pitcher character throws a 95 miles per hour fastball to home plate (i.e., a pitch), a player controlling a batter character has less than one second to react to the pitch. When a reaction of the player's batter character is signaled and is deemed to have made contact in the game, that reaction must be sent to all other players in the game. The reaction of the player's batter character to the central object (i.e., the baseball) in this scenario is then turned into an action for other players (i.e., defensive players) to react to. Once the player's batter character reaches base safely, further actions of the player's batter character (and reactions by the defensive players) dictate that a statistic is recorded. The statistic then may be sent to the database where it may be stored and processed into a point value for character enhancement purposes.
According to one exemplary mode of operation, the database processes, stores, and assigns point values to all statistical records kept in team sports games in a form of distributable points as described supra with regard to character enhancement. For example, points can be earned for hitting a double, catching a pop fly, scoring a touchdown, getting struck out, winning a time of possession comparison with another team, etc. These points, which may be assigned by the hosting system, may equate to physical values/properties/attributes assigned to players' characters. According to another mode operation, the hosting system may allow a player to choose aspects of his or her character that the player wishes to enhance. Other point values may pre-determined for the player. For example, points may be accumulated to a certain level, after which they can be redeemed or traded in for upgrades in any one (or more, in one implementation) character attribute. In one implementation of this example, the player may choose to upgrade his character's speed rather than some other attribute like body strength. The player may alternatively, or in addition, choose to increase a percentage chance of success rate for a specific skill like catching a ball or hitting off-speed pitches (i.e., curve ball, changeup, slider, etc). In other scenarios, when a character of one player strikes out three opponents in a row, he may experience a character enhancement in arm strength right away as a result of his in-game performance.
Throughout the course of a match or game during an event, players' characters may gain and lose distributable points dynamically. For example (cf. discussion infra with reference to FIG. 14) in a game in which a character of Player 1 hits safely four (4) times out of five (5) chances, his or her point value may be enhanced due to the hits, but may be penalized during one time when he or she failed to hit during the game. This point accrual through the database allows each game within the event to update dynamically in real-time. For example, if a player has a stamina performance of 20/99, his ability to run at maximum speed for an entire game of football may dynamically lower per quarter of the game played. Conversely, if the runner gains 10 yards and records a first down, his on-the-field action could award him with a boost of 2 stamina points, thus enhancing his performance during the game as part of an overall event.
As can be understood from the foregoing, the description provided herein relates to team sports video games that utilize a database and create events that provide opportunities for character growth through separate game point accumulation. For purposes of this disclosure, a team sports video game may be any sports video game comprising a central critical object (e.g., a ball), teams having at least three members. The centralized database may be used for storing, processing, and assigning point values to all statistical records kept during all game play options based on positive and negative real-life sports game scenarios such as scoring a touchdown in football (positive) or getting caught stealing a base (negative). The information in the database may be used to host, run, and manipulate all game information including event hosting, statistical record keeping, character progression and enhancement, player recognition and management, and the like. The events created may comprise any competition-based experience including more than two teams and/or players with a goal of declaring an overall winner. Event creation based on these criteria is crucial for all team-based sports games because the nature of team-based sports is to define leaders and/or winners for more than just two teams playing at any given time.
According to the present invention, events for online sports teams may be created through a central database as part of an overall video game experience. In the context of the following, for example, an event can be a tournament created for a peer-to-peer online baseball team-sport video game.
It will be appreciated that the present invention incorporates unique features of peer-to-peer team-sports connectivity and player enhancement along with virtual event hosting. Events may be generated as described supra that cater to individual player capabilities as defined by a combined team experience point level.
Event progressions are updated automatically according to an accumulation of all individual actions within the games, as described supra, on both an individual and a team level. Team and individual actions dictate a following step in an event process and may, for example, decide an outcome of an event round progression.
FIG. 13 provides an outline of one example of how individual and team-level actions can influence an outcome of an event, in this case, a single-elimination tournament involving eight teams with seven scheduled games. For example, in Game 1 between Team A and Team B, Player 1 (or, equivalently, Character 1 corresponding to Player 1 in this example, and using a similar reference for other players/characters) for Team A may hit a two-run homerun, scoring his teammate, Player 2 for Team A, in the last inning against Player 3 (e.g., a pitcher) for Team B. Player 3 for Team B is awarded a loss in the game. Team A advances to the next round of the event (i.e., Game 5) automatically as a direct result of the individual actions of the members of Team A.
The present invention contemplates connecting all possible actions with multiple games in multiple progression scenarios in one event. For example, in a single event, one team could win a game due to a member of the team hitting a last inning homerun. At the same time in a different game connected to the same event, another player may throw out a runner at home plate to end a game, thus advancing his team through the event progression. In yet a third game, a game outcome could be decided by a pitcher who strikes out a final batter to advance his team to a playoff round. Continuing, in a fourth game of the same event, an outfielder could make a diving catch to record the final out of his game to advance. While the games are singular in existence, the database connects the players and teams to the same event and places them in the correct locations for event progression.
According to another scenario and with continuing reference to FIG. 13, Player 2 for Team C may be on third base, and Player 1 on Team C may hit a groundball to Player 3 at shortstop for Team D. Player 3 may throw to Player 4 for Team D at home plate to tag out Player 2 for Team C before he can score to tie the game. Team D may win on the play and may automatically advance to Game 5 due to the combination of individual actions.
All individual records may be kept throughout the game, and the database may instruct winning teams to advance to a subsequent level in the event progression until an overall winner is determined. In the present example, a winner of Game 1 advances to Game 5 to play a winner of Game 2. A winner of Game 5 advances to Game 7 to play a winner of Game 6. A winner of Game 7 is determined to be the winner of the event. Schedules for games are generated automatically according to an event schedule, which may be created, for example, by a developer of a video game software. Each individual action of the tournament effects the outcome of the overall event, where multiple teams compete for a single championship. Each action is recorded and processed in the database and reflected both in the game through round progression and on the website via statistical and result information.
Continuing with the example presented with reference to FIG. 13, portions of records from a typical game scenario are shown in FIG. 14. Two charts are presented in FIG. 14, one for players on each of two teams, Team A and Team B, as a result of Teams A and B having competed in Game 1 (FIG. 13). For example, Team A may have a roster of 9 players, each with individual records that are stored in the database. The database updates the distributable points assigned to each statistic in real time and resends character enhancement changes to a game client dynamically. In this way, players may have their characters enhanced in near-real time, even during a game. According to one particular example, a character of Player 1 on Team A may be awarded a distributable point value of +5, corresponding, for example, to a 10% increase in running speed, which enhancement may improve performance of the character of Player 1 in subsequent games. Player 2 on Team A may receive a distributable point value of +3 for generating one hit, but may receive negative distributable point values of −1 for each out, thereby being awarded no net change in distributable points in the example of FIG. 14. Conversely, Player 1 with four hits in five at bats may receive distributable point values equivalent to a +2.5% increase in body strength.
Team B also may have a roster of 9 players and also may receive character enhancement changes throughout a game according to in-game performances or failures of individual characters. For example, a character of Player 1 for Team B generated one hit in five at bats, and so may accrue +3 distributable points for the hit but may receive, for example, −5 distributable points for being put out five times. Player 1 for Team B, therefore, may be awarded −2 distributable points representing, for example, a −0.10% decrease in body strength.
Prior art team-based networked video games, generally, offer platforms that players may use to participate in. Third parties may offer events for players, but the players are never able to enhance their skill levels of their characters. As disclosed herein, the present invention 1) creates a gaming platform in the form of the peer-to-peer online, team-based, sports games; 2) offers interactive event hosting in the form of automated leagues, tournaments, and contests; and 3) allows a player to enhance skill levels of his or her character through a performance and achievement based point system.
Real-world team-based sports are frequently organized around events (i.e., leagues, tournaments, contests and the like). Events organized by leagues of professional sports are well known, and amateur sports often are similarly organized. For example, college and high school sports teams typically organize events around conference memberships, and even neighborhoods or municipalities may organize, for example, softball leagues including playoff tournaments for amateur players. The present invention extends a concept events to apply to team-based networked video games in which players are dynamically allowed to enhance physical performance of their characters during events using point values assigned to characteristics like speed, power, range, agility and the like. It is important to realize that the present invention, further, permits players to enhance their characters' performance even while participating in an event
As described supra in discussion related to FIG. 11, in-game character development through accumulation of Experience Points (EP), Parameter Points (PP), and Skill Points (SP) may be supported by a dynamic event system (e.g., a hosting system, an embodiment of which is illustrated in FIG. 12). While the website, server database, and game client may continually communicate among one another, implementing, according to one exemplary embodiment, steps described supra with reference to FIG. 11, an automated event service may be provided for players via the website. In this scenario, a game developer or managing party may be responsible for event creation through a secured website. At a point of execution of the event creation, the hosting system may fully manage an entire event process including; (a) registration, (b) schedule generation, (c) game creation, (d) record keeping, (e) schedule maintenance and updating, and (f) results display.
The entire event process is dynamically in charge of accessing updated character skill levels either by setting registration restrictions based on skill, seeding requirements for teams based on cumulative skill levels, or for accumulation of EP, PP, and SP from experience gained during the event, itself.
Registration (e.g., Hands-Free Event Registration) may require that, upon event creation, limitations set during the creation of a particular event may govern allowance or refusal of player participation. During event creation, a managing party may select, for example, among options such as (a) Event Type (i.e. Tournament, League, Contest, etc), (b) Event Style (i.e. single elimination, double elimination, round robin, etc), (c) Event Schedule (to include dates of registration, execution, and time), (d) Minimum and Maximum Player Requirements per event, (e) Individual Player Requirements (i.e. Open to all, specified for specific levels of skill, etc.), (f) Team Requirements (i.e. limits and minimums for combined team skill levels), (g) Game Length (i.e. inning length, time per half, length per quarter, etc.), and (h) Cost/Benefits per event (i.e. cost per entry, prize announcing, etc). Players, or qualified members of a game community, can then browse events in which they may wish to participate on the website. Once a player chooses his/her preferred event, he/she can then register for the event as long as the requirements of the event do not refuse his/her submitted character. Each registration in essence sends a request of data to the game client from the website to check player availability based on skill level and schedule conflicts due to other events.
Schedules may be dynamically created upon arrival of pre-determined registration dates. Scheduling for events, which may be carried out, for example, on the server in the host system, may be decided by event type, and teams may be dynamically scheduled based on a cumulative skill level for the teams. According to one embodiment, a cumulative skill level for a team comprises a sum of skill levels for players on a team roster. The schedule may pre-rank teams according to specified tournament and league rules specific to the sporting event in question. For example, in an 8-team tournament where teams are broken down from highest EP level to lowest EP level (1-8), the schedule may create the following matchups:

- Game 1: Team 1 vs. Team 8
- Game 2: Team 4 vs. Team 5
- Game 3: Team 3 vs. Team 6
- Game 4: Team 2 vs. Team 7
  These schedule types are consistent with usual methods of tournament generation.

The present invention may dynamically filter point accumulation for players' characters through successful game play and, further may accumulate data specific to event hosting. For example, for the above 8-team tournament example, Team A may register with a combined point value of 100. Team B registers with 80. Team C with 70. Team D with 90. Team E with 40. Team F with 50. Team G with 20. Team H with 30. The point totals are automatically filtered to come up with the rankings shown above where Team A plays against Team G (or 1 vs. 8). Team D plays team H (or 2 vs. 7). Team B plays against Team E (or 3 vs. 6). And finally, Team C plays Team F (or 4 vs. 5).
In accordance with the pre-determined schedule received during event creation, the game client may periodically request all event data, such as event schedules, from the database server. For example, a request may be made once in every 24-hour period, more often, or less often. Event games scheduled during each day may be automatically be created in pre-destined game rooms without any player involvement. Players scheduled to play in events may be given warnings and notifications in the game client through pre-populated communication techniques (i.e. audio, text, etc). For instance, all players found on an event team roster may receive a 15-minute notice of their event game start time throughout the various game client servers (all servers hosting games for the particular sport). They may all see, for example, a text message displaying; “Your game for the UBO 2006 Tournament is going to start in 15 minutes, please go to the Tournament Clubhouse to join your team.” At a precise time, according to the schedule, games may start (i.e., initiate) automatically. All players present, typically, will begin at the prescribed game start time. Players not present, but on the official rosters submitted through the website, may be able to enter the games as substitutes to play. Again, the present invention provides dynamic interaction among the game clients, database server, and website in order to provide the level of event customization just described. For example, players may have to register through the website to submit their rosters for an event. The database may collect the data, process it, and send it to the game client (video game). The game client then may search for players in the game and may notify them of their game. Only members on the list may be allowed to participate in the event.
Event record keeping may take place in several ways. First, individual record keeping may be continually (e.g., in real-time) updated and reflected in the game client. Statistics for individuals consistent with sports record keeping may be kept (e.g., batting average for baseball, rushing yards per game for football, field goal percentage for basketball). All individual event records may be kept separate from other game play modes (i.e., Practice, Pick Up Game, Mini-Game Modes) so that players can view their event records. Point accruals during events may, however, be added to a player's unique character capabilities within a game. In a scenario where a player reaches a certain achievement level in a game (like moving from a level 3 character to a level 4 character), his or her character can then enhance his or her character capability for areas like speed, power, quickness, etc. to perform at a higher skill level. All records and/or achievements may be displayed in real time, after a database processing of statistics being kept, both in the game client and on various locations of the website dedicated to the game. The website may offer displays for personal page use where players can view their own characteristics and achievements, and community leaderboards may be used for comparison among top performers. Statistics-only pages, primarily utilized for recruitment purposes, may be provided and may include searchable options for customized searching. All information is kept in real time as the database receives data, processes the statistics and updates calculations.
A second group of records kept for events may be team-based. Team records (e.g., win/loss record, team averages and totals, etc.) also may be generated dynamically during a course of an event game. Team records may be viewable both in the game and on the website and may be generated based on cumulative actions of players in event games.
Automated schedule maintenance and updating, according to the present invention, further develops a process of hands free event hosting wherein the game client may send game outcomes to the database server, which may pass the game outcomes to the website for display. The website, thereby, may receive information in real-time as it arrives and then may process all information in order to advance appropriate teams to a following stage of a particular event. The hands free event hosting system schedules teams according to normal event progression schedules as described herein and may advance teams that may or may not have a scheduled bye. A “scheduled bye” results when, for example, an odd number of teams participate in an event. In that case, one team may move on without playing anyone during a portion of the event. Teams who fail to record game outcomes may be assigned forfeits, and opponents of forfeiting teams, assuming the opponents do appear to play at a scheduled time, are awarded with an automatic win due to the aforementioned forfeits.
Event results may be displayed on the website at the completion of an event. Player and team records (statistics) may be displayed for public view in real-time throughout the entire duration of the event, dynamically updating leaders for statistical categories and team records for updates to team standings. All information may be sent automatically through the database server from the game client to the website and stored in order to display game and event winners. Event information status on the website may be changed from being an event that is currently running to an event that has finished upon completion of an event.
In view of the foregoing, it will be understood by those skilled in the art that the methods of the present invention can facilitate formation of realistic team-based networked video gaming and participation in on-line sports events. The above-described embodiments have been provided by way of example, and the present invention is not limited to these examples. Multiple variations and modification to the disclosed embodiments will occur, to the extent not mutually exclusive, to those skilled in the art upon consideration of the foregoing description. Additionally, other combinations, omissions, substitutions and modifications will be apparent to the skilled artisan in view of the disclosure herein. Accordingly, the present invention is not intended to be limited by the disclosed embodiments, but is to be defined by reference to the appended claims.

Claims

1. A method of displaying a scene on a monitor of a first computer, the method comprising:

receiving a data packet from a second computer according to the scene, the data packet comprising time delay information; and

displaying the scene after a time delay according to the time delay information.

2. The method as set forth in claim 1, further comprising estimating a value for the time delay information.

3. The method as set forth in claim 2, wherein the estimating comprises:

transmitting a test packet from the second computer to the first computer, the test packet comprising a request for an immediate reply;

receiving a reply according to the request; and

determining an elapsed time between the transmitting and the receiving.

4. The method as set forth in claim 3, further comprising:

transmitting the test packet from the second computer to a plurality of computers;

receiving a plurality of replies according to the request;

determining a plurality of elapsed times between the transmitting and the receiving;

transmitting a plurality of data packets including a plurality of time delay values according to the plurality of elapsed times; and

delaying a display of the scene on monitors of the plurality of computers according to the plurality of time-delay values, thereby displaying the scene essentially simultaneously on the monitors of the plurality of computers.

5. A method of transmitting a data packet to a plurality of computers representing a plurality of characters in a team-based networked video game, the method comprising:

receiving a game state;

receiving an action;

receiving a ranking of the characters according to a likelihood of a character having an immediate and consequential effect according to the game state and the action;

selecting the top-ranked character according to the ranking; and

transmitting a data packet to the computer representing the top-ranked character according to the game state and the action before transmitting the data packet to any other of the plurality of computers.

6. The method as set forth in claim 5, further comprising transmitting the data packet to a remainder of the plurality of computers.

7. A method performed in a networked video game involving a game object, the method comprising:

receiving a game state comprising location information for each of a plurality of characters;

receiving information indicative of a motion of the game object;

receiving, for each character, an in-game movement attribute;

receiving, for each character, an indication of the character's eligibility to receive the game object according to rules of the networked video game; and

calculating, for each character, a likelihood that the character is able to receive the game object.

8. The method as set forth in claim 7, wherein the calculating of a likelihood that the character is able to receive the central critical game object is followed by ranking the plurality of characters.

9. The method as set forth in claim 8, wherein:

the receiving, for each character, of an in-game movement comprises receiving, for each character, an in-game speed attribute, and is followed by receiving, for each character, a virtual distance from the trajectory; and

the receiving, for each character, of an indication of the character's ability to interact with the game object comprises receiving, for each character, an indication of the character's ability to receive the game object, and is followed by: receiving, for each character, an indication of the character's ability to retain the game object when it is received; and receiving, for each character, an indication of the character's eligibility to receive the game object according to rules of the networked video game.

10. The method as set forth in claim 9, wherein the game object is a central game object, the information indicative of a motion is a trajectory, and the calculating of a likelihood that the character is able to receive the central critical game object is followed by ranking the plurality of characters.

11. The method as set forth in claim 10, wherein the ranking the plurality of characters comprises ranking the plurality of characters in descending order.

12. The method as set forth in claim 11, wherein the central critical game object is a ball.

13. The method as set forth in claim 12, wherein the ball is selected from a group consisting of a soccer ball, a baseball, a basketball, a football, a tennis ball and a table tennis ball.

14. The method as set forth in claim 11, wherein the central critical game object is a selected from a group consisting of a hockey puck, a badminton bird and a FRISBEE®.

15. A method of hosting a team-based networked video game, the method comprising:

receiving a roster of characters;

receiving, for each character, a set of in-game attributes;

receiving, for each character, a history of games played;

modifying, for each character, the set of in-game attributes and the history of games played according to an experience of the character in the networked video game.

16. The method as set forth in claim 15, wherein the set of in-game attributes comprises speed.

17. The method as set forth in claim 15, wherein the set of in-game attributes comprises power.

18. The method as set forth in claim 15, wherein the set of in-game attributes comprises range.

19. The method as set forth in claim 15, wherein the set of in-game attributes comprises agility.

20. A method of developing attributes of a character participating in a team-based networked video game, the method comprising:

maintaining an accumulation of experience points;

maintaining an accumulation of parameter points;

maintaining an accumulation of skill points;

receiving an action according to the game; and

modifying at least one of the accumulation of experience points, the accumulation of parameter points and the accumulation of skill points according to the action.

21. The method as set forth in claim 20, wherein modifying the accumulation of experience points comprises incrementing the accumulation of experience points.

22. A method of hosting an event comprising a plurality of team-based networked video games, the method comprising:

maintaining a registration database comprising:

a list of teams participating in the event; and

for each team, a roster of characters associated with the team;

generating a schedule of games;

creating the games;

maintaining a team performance database comprising a plurality of team records associated with a plurality of teams participating in the event;

maintaining a character performance database comprising a plurality of records associated with characters participating in the event; and

displaying results according to the games.

23. The method as set forth in claim 22, wherein a team record comprises information according to a plurality of records according to a plurality of characters associated with the team.

24. The method as set forth in claim 22, wherein the generating comprises:

receiving an event type;

receiving an event style;

receiving a record of points for characters on the roster of each team;

calculating composite points for each team;

ranking teams according to composite points; and

generating a schedule according to the ranking and the event style.

25. The method as set forth in claim 24, wherein the receiving of a record of points comprises receiving experience points.

26. The method as set forth in claim 24, wherein the receiving of a record of points comprises receiving parameter points.

27. The method as set forth in claim 24, wherein the receiving of a record of points comprises receiving skill points.

28. The method as set forth in claim 24, wherein the receiving of an event type comprises receiving one of a group consisting of a tournament, a league, and a contest.

29. The method as set forth in claim 24, wherein the receiving of an event style comprises receiving one of a group consisting of single elimination, double elimination, and round robin.

30. A system adapted to host an event comprising a plurality of team-based networked video games, the system comprising:

a server adapted to communicate with a plurality of player computers on a computer network;

a website comprising a software program residing on at least one web computer, the website being adapted to:

cause the at least one web computer to communicate with the server; and

cause the at least one web computer to communicate with the plurality of player computers; and

a game client comprising a software program residing on at least one player computer, the game client being adapted to:

cause the at least one player computer to permit a player to participate in a team-based network video game; and

communicate with the server according to actions occurring in the video game.

31. The system as set forth in claim 30, wherein the server is further adapted to:

maintain a database comprising records according to a plurality of players in a team-based networked video game;

receive actions occurring in the video game according to at least one player; and

modify at least one record according to the at least one player according to the received actions.