U.S. patent application number 11/786566 was filed with the patent office on 2007-11-15 for team-based networked video gaming and automatic event management.
Invention is credited to Gabriel Law, Sean R. Mackay, Andy Yi-Min Wang.
Application Number | 20070265043 11/786566 |
Document ID | / |
Family ID | 38610165 |
Filed Date | 2007-11-15 |
United States Patent
Application |
20070265043 |
Kind Code |
A1 |
Wang; Andy Yi-Min ; et
al. |
November 15, 2007 |
Team-based networked video gaming and automatic event
management
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.
Inventors: |
Wang; Andy Yi-Min; (Walnut,
CA) ; Law; Gabriel; (Pasadena, CA) ; Mackay;
Sean R.; (Chino Hills, CA) |
Correspondence
Address: |
STOUT, UXA, BUYAN & MULLINS LLP
4 VENTURE, SUITE 300
IRVINE
CA
92618
US
|
Family ID: |
38610165 |
Appl. No.: |
11/786566 |
Filed: |
April 11, 2007 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60791750 |
Apr 12, 2006 |
|
|
|
Current U.S.
Class: |
463/2 ;
463/30 |
Current CPC
Class: |
A63F 2300/407 20130101;
A63F 2300/408 20130101; A63F 2300/63 20130101; A63F 2300/556
20130101; A63F 13/34 20140902; A63F 13/12 20130101; A63F 13/812
20140902 |
Class at
Publication: |
463/002 ;
463/030 |
International
Class: |
A63F 9/02 20060101
A63F009/02 |
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.RTM..
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.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] 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
[0002] 1. Field of the Invention
[0003] The present invention relates generally to video gaming and,
more particularly, to video games played by teams on networked
computers.
[0004] 2. Description of Related Art
[0005] Video gaming, which may have started with development of
PONG.RTM., 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.
[0006] 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.
[0007] 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
[0008] 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.
[0009] An aspect of the present invention further comprises
estimating a value for the time delay information.
[0010] 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.
[0011] 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.
[0012] 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.
[0013] 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
[0014] 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;
[0015] 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;
[0016] FIG. 3 is a flow diagram illustrating one possible
implementation of a method for estimating latency between two
computers;
[0017] 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;
[0018] 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;
[0019] FIG. 6 is a pictorial diagram illustrating an effect of
transmitting data packets according to the implementation shown in
FIG. 4;
[0020] FIG. 7 is a pictorial diagram presenting a result of
applying the implementation of FIG. 5 to a portion of a video
baseball game;
[0021] FIG. 8 is a flow diagram of one implementation of a method
of accounting for character attributes in a team-based networked
video game;
[0022] 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;
[0023] 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;
[0024] 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;
[0025] 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;
[0026] FIG. 13 is a pictorial diagram summarizing a
single-elimination tournament involving eight teams with seven
scheduled games;
[0027] FIG. 14 shows two charts including portions of records from
a typical scenario of a game included in the tournament of FIG. 13;
and
[0028] 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
[0029] 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.
[0030] 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.
[0031] The following description employs terminology that may be
better understood in terms of the following definitions: [0032]
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. [0033] Player: A
player is a human participant in a game. The human participant
typically controls a character, defined infra. [0034] 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. [0035] 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. [0036] 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. [0037] 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. [0038] 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. [0039] 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. [0040] 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. [0041] 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. [0042] 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.RTM. and the like.
[0043] 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.
[0044] 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.
[0045] 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.
[0046] 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.
[0047] 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.
[0048] 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.
[0049] 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.
[0050] 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.
[0051] 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.
[0052] 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.
[0053] 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.
[0054] One possible situation in which the implementation of the
method summarized in FIG. 4 occur when, for example, a player
P.sub.1 in a team-based networked video game may initiate an action
of a corresponding character C.sub.1. For example, C.sub.1 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.sub.1 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.sub.1 steps
to the right at substantially the same time.
[0055] A specific example involving four computers at which play
four players P.sub.1, P.sub.2, P.sub.3, and P.sub.4, 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.sub.1 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.sub.2, P.sub.3, and P.sub.4. 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.sub.1 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.sub.2, P.sub.3, and P.sub.4. Pings transmitted by
P.sub.1 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.sub.2 is received at a time 2.times.t.sub.2. Similarly,
replies to the pings to P.sub.3 and P.sub.4 are received at
respective times 2.times.t.sub.3 and 2.times.t.sub.4. In the
illustrated example, the longest latency is t.sub.4 associated with
the computer at which player P.sub.4 plays. Accordingly, in order
to assure that each player sees the scene at substantially the same
time, P.sub.1 transmits at Stage 2 (cf. step 150 in FIG. 4) data
packets to P.sub.2, P.sub.3, and P.sub.4, the data packets
comprising time delay information according to the respective
computer to which each data packet is addressed. Specifically,
P.sub.1 transmits is a data packet shown as arrow 250 addressed to
P.sub.2, the data packet 250 comprising information according to
the scene as well as a time delay value of (t.sub.4-t.sub.2).
Similarly, P.sub.1 transmits a data packet shown as arrow 255
addressed to P.sub.3, the data packet 255 comprising the same scene
information but including a time delay value of (t.sub.4-t.sub.3).
A data packet shown as arrow 260 comprising the same scene
information is further transmitted to P.sub.4, the data packet 260
further comprising a time delay value of zero. Upon receiving the
data packet 250, P.sub.2 waits for a time interval of
(t.sub.4-t.sub.2) represented by arrow 265and then displays the
scene. Similarly, when P.sub.3 receives data packet 255, P.sub.3
waits for a time interval of (t.sub.4-t.sub.3) represented by arrow
270 and then displays the scene. Computer P.sub.4, when it receives
data packet 260 displays the scene essentially immediately. It will
be understood that P.sub.2, P.sub.3, and P.sub.4 display the scene
at substantially the same time, i.e., a time t.sub.4 after
transmission of the data packets 250, 255, and 260 by the first
computer. The substantially simultaneous display of the scene on
computers P.sub.2, P.sub.3, and P.sub.4, may essentially remove any
effect of variable latency among the computers represented.
[0056] 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.
[0057] 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.
[0058] 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.
[0059] 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.
[0060] 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 .DELTA..sub.1
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
.DELTA..sub.1 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 .DELTA..sub.2, 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,
.DELTA..sub.3, 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, .DELTA..sub.4, 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, .DELTA..sub.5, 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.
[0061] 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.sub.x and C.sub.y.
C.sub.x, for example may be on a same team as the passer; character
C.sub.y may be on an opposing team. Both characters may wish to
receive the ball for different reasons: character C.sub.x in order
to advance his team's goals, character C.sub.y may wish to
intercept the pass in order to thwart intentions of the other team.
Character C.sub.x may be located, for example, five feet on a first
side of a trajectory of the pass; C.sub.y may be located seven feet
on an opposite side of the trajectory of the pass. Character
C.sub.x may start running toward the trajectory. Success of C.sub.x
may be determined primarily, or at least in part, by certain
factors, which may include, for example, (a) an in-game physical
attribute of C.sub.x (i.e., C.sub.x may be endowed with fast
speed), (b) a virtual physical limitation of having an effect on
the outcome (e.g., virtual distance of C.sub.x away from the
trajectory(, (c) an ability of C.sub.x to receive the ball, (d) an
ability of C.sub.x to retain the ball upon reception, (e) actual
game rules, which may affect eligibility of C.sub.x to 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.sub.y to 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.sub.x is closer to the path,
C.sub.y may enjoy a better in-game attribute, in this case speed.
If C.sub.x and C.sub.y are 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.sub.y has ownership because his
superior speed more than compensates for his relative farther
distance than that of C.sub.x.
[0062] As one illustrative example, C.sub.x and C.sub.y, both with
latency of 120 ms, may be running at a same time to a ball
trajectory, with C.sub.x being closer but C.sub.y being faster. In
this example, suppose that the game includes one character with a
worst latency, around 170 ms. This means both C.sub.x and C.sub.y
therefore 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.sub.y is to determined to be the most qualified
character, his computer will immediately send a data packet to
C.sub.y without 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.
[0063] 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.
[0064] 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.
[0065] 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.
[0066] 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.
[0067] 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.
[0068] 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.
[0069] 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.
[0070] Considering another example involving a potential
interceptor of a pass, FIG. 9 is a pictorial diagram describing
interactions among four characters, T.sub.1C.sub.1, T.sub.1C.sub.2,
T.sub.2C.sub.1 and T.sub.2C.sub.2 (T.sub.iC.sub.j refers to the
j.sup.th character on the i.sup.th team 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.sub.1C.sub.1 has possession of the
ball, and a player having T.sub.1C.sub.1 as a character would like
to pass the ball to teammate T.sub.1C.sub.2. T.sub.1C.sub.1 then
commits to pass the ball (or, in other examples, the following
analysis occurs even before T.sub.1C.sub.1 commits to pass the
ball). In a vicinity of a trajectory of the ball stands
T.sub.2C.sub.1, 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.sub.2C.sub.1 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.sub.2C.sub.1 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.sub.2C.sub.2, teammate of T.sub.2C.sub.1, is afar observing the
event.
[0071] Considering data packet 490 in FIG. 9, although
T.sub.1C.sub.1 is passing the ball intentionally to T.sub.1C.sub.2,
the implementation of FIG. 5 identifies T.sub.2C.sub.1 as a
potential interceptor. After taking into account latency,
T.sub.1C.sub.1 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.sub.2C.sub.1. Upon receiving data
packet 490 (and instantly displaying a corresponding result on a
monitor of the computer of the T.sub.2C.sub.1 character),
T.sub.2C.sub.1 successfully intercepts the ball. Immediately, the
computer of T.sub.2C.sub.1 sends out data packets 495 and 505 to
notify the rest of the players of his interception (the computer of
T.sub.2C.sub.1 may also notify T.sub.1C.sub.1 as well, but that
notification is immaterial in this discussion and, as such, is not
shown in FIG. 9). As far as T.sub.1C.sub.2 is concerned, the data
packet 495 would arrive at t.sub.3+t.sub.5.
[0072] In contrast, consider a scenario wherein the computer of the
T.sub.1C.sub.1 character were also to notify T.sub.1C.sub.2 (the
intended recipient of the ball) at the same time (starting at t=0).
In that case, the computer of the T.sub.1C.sub.2 character receives
the data packet at t=t.sub.2, thereby eliminating any chance for
T.sub.2C.sub.1 to intercept the ball (or the player having
T.sub.2C.sub.1 as a character would think that he had intercepted,
while the rest of the players would see the T.sub.1C.sub.2
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.sub.1C.sub.1
character to the computer of the T.sub.1C.sub.2 character, i.e.
data packet 500 does not go out till t.sub.3+t.sub.5-t.sub.2.
[0073] 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.
[0074] 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.
[0075] 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.
[0076] 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.
[0077] 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.
[0078] 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.
[0079] 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.
[0080] 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.
[0081] 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.
[0082] 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.
[0083] 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.
[0084] 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.
[0085] 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.
[0086] 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.
[0087] 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.
[0088] 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.
[0089] 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.
[0090] 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.
[0091] 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.
[0092] 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.
[0093] 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.
[0094] 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.
[0095] 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.
[0096] 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.
[0097] 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.
[0098] 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.
[0099] 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.
[0100] 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.
[0101] 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.
[0102] 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.
[0103] 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
[0104] 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.
[0105] 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.
[0106] 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.
[0107] 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: [0108] Game 1: Team 1 vs. Team 8 [0109] Game 2: Team 4
vs. Team 5 [0110] Game 3: Team 3 vs. Team 6 [0111] Game 4: Team 2
vs. Team 7 These schedule types are consistent with usual methods
of tournament generation.
[0112] 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).
[0113] 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.
[0114] 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.
[0115] 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.
[0116] 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.
[0117] 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.
[0118] 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.
* * * * *