U.S. patent application number 11/965772 was filed with the patent office on 2009-07-02 for interactive scenario exploration for tournament-style gaming.
This patent application is currently assigned to Microsoft Corporation. Invention is credited to Joseph Yossi Azar, Eyal Lubetzky, Yuval Peres, Gregory R. Smith, Desney S. Tan.
Application Number | 20090170584 11/965772 |
Document ID | / |
Family ID | 40799155 |
Filed Date | 2009-07-02 |
United States Patent
Application |
20090170584 |
Kind Code |
A1 |
Tan; Desney S. ; et
al. |
July 2, 2009 |
INTERACTIVE SCENARIO EXPLORATION FOR TOURNAMENT-STYLE GAMING
Abstract
A tournament-style gaming scenario exploration system and method
for interactively exploring current and future scenarios of a
tournament and associated pick'em pool. The system and method
include a prediction module (including a game constraint
sub-module), and a key event detection module. Embodiments of the
prediction module include a binary integer that represents
tournament outcomes. The prediction module generates predictions of
tournament outcomes using an exhaustive or a sampling technique.
The sampling technique includes random sampling, where the
tournament bracket is randomly sampled, and a weighted sampling
technique, which sample portions of the tournament bracket more
densely than others areas. Embodiments of the game constraint
sub-module allow real-world results constraints and user-supplied
constraints to be imposed on the tournament outcomes. Embodiments
of the key event detection module identify key games in the
tournament that affect a user's placement in the pick'em pool, a
competitor's placement in the tournament standings, or both.
Inventors: |
Tan; Desney S.; (Kirkland,
WA) ; Smith; Gregory R.; (Bellevue, WA) ;
Peres; Yuval; (Redmond, WA) ; Azar; Joseph Yossi;
(Redmond, WA) ; Lubetzky; Eyal; (Bellevue,
WA) |
Correspondence
Address: |
MICROSOFT CORPORATION
ONE MICROSOFT WAY
REDMOND
WA
98052
US
|
Assignee: |
Microsoft Corporation
Redmond
WA
|
Family ID: |
40799155 |
Appl. No.: |
11/965772 |
Filed: |
December 28, 2007 |
Current U.S.
Class: |
463/16 ;
463/42 |
Current CPC
Class: |
G07F 17/32 20130101;
G07F 17/3276 20130101 |
Class at
Publication: |
463/16 ;
463/42 |
International
Class: |
A63F 9/24 20060101
A63F009/24 |
Claims
1. A method for projecting, predicting, and interactively exploring
a user's expected performance in a pick'em pool based on a
tournament having a plurality of games, comprising: inputting the
plurality of tournament games, real-world results, and tournament
odds for competitors in the tournament; generating brackets of a
plurality of outcomes of the tournament games to obtain a plurality
of possible results; scoring a user's picks based on the generated
brackets; and accumulating the scores in a manner that permits
statistical inferences to be made about expected player and game
outcomes.
2. The method of claim 1, further comprising generating brackets by
exhaustively generating and scoring each possible outcome of the
plurality of tournament games.
3. The method of claim 1, further comprising generating brackets by
calculating and scoring a sample of possible outcomes of the
plurality of tournament games.
4. The method of claim 3, further comprising selecting random
samples of possible outcomes of the plurality of tournament games
using a random number generator.
5. The method of claim 3, further comprising performing weighted
sampling of possible outcomes of the plurality of tournament games
by sampling some outcomes of the plurality of tournament games more
densely and sampling other outcomes of the plurality of tournament
games less densely.
6. The method of claim 5, further comprising: obtaining weighting
information corresponding to the likelihood of a game outcome as
provided by the plurality of tournament games, real-world results,
and tournament odds for competitors in the tournament; and
performing the weighted sampling based on the weighting
information.
7. The method of claim 1, further comprising: obtaining a scoring
scheme for the tournament, the generated brackets, and the user's
picks; and scoring the user's picks according to the scoring scheme
and prediction results of the generated brackets.
8. The method of claim 7, further comprising ranking the user
relative to other users according to what the user's score would be
if the generated bracket actually occurred.
9. The method of claim 1, further comprising: accumulating a
running total of statistics from the plurality of possible outcomes
of the generated brackets; if the prediction technique is a
weighted technique, then keeping an integer count of occurrences of
each user in a certain ranking; and otherwise, populating a table
of users and user positions with a sum of normalized
placements.
10. The method of claim 1, further comprising applying constraints
to the generated brackets to obtain constrained prediction
results.
11. The method of claim 10, further comprising: inputting
real-world results of the tournament; and applying a constraint
mask to the prediction results based on the real-world results to
obtain the constrained prediction results.
12. The method of claim 10, further comprising: inputting a
"desired game outcome" constraint supplied by the user; and
applying the "desired game outcome" constraint to the generated
brackets to obtain the constrained prediction results.
13. The method of claim 10, further comprising: inputting a
"desired placement outcome" supplied by the user that specifies
certain standings that are attained by certain users; and applying
the "desired placement outcome" constraint to the prediction
results to obtain the constrained prediction results.
14. The method of claim 1, further comprising: inputting tournament
outcomes, counters, and a schedule of upcoming tournament games;
examining the counters to find correlation between tournament
outcomes and user placements; identifying key games affecting user
placement using the correlation and the schedule of upcoming
tournament games; identifying key games that affect a user's
placement in final tournament standing by examining the tournament
outcomes and the counters; and notifying user of the key games.
15. The method of claim 1, further comprising representing each
tournament game by a N-bit bracket representation, where N is a
number of games in the tournament and N-bit bracket representation
is a Y-bit integer, where Y.gtoreq.N and at least some bits of the
Y-bit integer represent an outcome of a game in the tournament.
16. A computer-implemented process for predicting outcomes of
tournament-style gaming pool corresponding to a tournament,
comprising: inputting a binary integer representing games and an
outcome of the tournament; predicting tournament outcomes using the
binary integer to obtain prediction results; and displaying the
prediction results to a user.
17. The computer-implemented process of claim 16, further
comprising using an exhaustive prediction technique to obtain the
prediction results by predicting all possible tournament
outcomes.
18. The computer-implemented process of claim 16, further
comprising using a sampling prediction technique to obtain the
prediction results by sampling a portion of all possible tournament
outcomes.
19. The computer-implemented process of claim 16, further
comprising: applying constraints to the prediction results that
modify the prediction results to obtain constrained prediction
results; and identifying as key games those games in the tournament
that will impact a user's placement in a pick'em pool, a
competitor's placement in a final tournament standings, or
both.
20. A tournament-style gaming scenario exploration system having
computer-readable instructions encoded on computer-readable media
for interactively exploring current and future scenarios of a
tournament-style gaming pool corresponding to a tournament,
comprising: a tournament set-up module that inputs core information
about the tournament; a prediction module that calculates
predictions for different scenarios of the tournament, the
prediction module further comprising: a bracket generation
sub-module that computes the predictions using an exhaustive search
technique, a random sampling technique, or a weighted sampling
technique; a game constraint sub-module that applies game
constraints to the predictions; a scoring sub-module that scores
each user's picks according to a bracket outcome; a player
placement constraint sub-module that checks for and imposes
user-specified constraints on the predictions generated by the
bracket generation sub-module after scoring is performed; an
accumulator sub-module that keeps a running tally of statistics
from different possible brackets generated by the bracket
generation sub-module; and a key event detection module that
identifies events in the tournament that may be of interest to a
user because the events have an impact on the user's final ranking
in pick'em pool of the tournament.
Description
BACKGROUND
[0001] Fantasy games, in which groups of people compete to predict
outcomes in various types of competitions, is a large and rapidly
growing industry. A leading trade association reported that in 2006
that there were 15 to 18 million fantasy sports players within the
U.S. alone, with an expected growth rate of 7-10% per year.
Moreover, some reports estimate that, on average, each fantasy
sport player spends about $500 annually on magazines, online
information, contests, and leagues.
[0002] In general, fantasy sports games can be divided into two
basic genres. A first genre is manager leagues in which users
select, trade, and manage virtual teams of real-world players drawn
from a variety of real-world sports teams. Users compete against
each other based on points generated by the real-world statistics
of their team members. A second genre is pick'em pools, also known
as tournament or office pools. In pick'em pools, users predict
outcomes (or make picks) of real-world contests in tournament-style
competitions. By way of example, these tournament-style
competitions or games include the NCAA March Madness basketball
tournament, the Wimbledon tennis tournament, the NFL football
playoffs, and in some cases even television reality shows and
political races. Typically, users score some number of fantasy
points for each correct pick (or prediction) and the winner is the
user with the highest total score at the end of the tournament.
[0003] There are many different types of online systems or portals
that automate traditional paper-based versions of fantasy games. In
general, these systems automate the processes whereby a user
assembles, manages, and tracks games and teams. These systems make
it easy for a user to set up competitions, make picks online, and
track progress as real-world games unfold. As games are in progress
users are able to obtain real-time scoring results and statistics.
Moreover, some systems allow inter-user interactions such as
instant messenger (IM) or e-mail. These systems automate most of
the things that have to be done for the game but are tedious for a
human to do. Since these systems free users from the tedious tasks
of calculating, updating, and disseminating fantasy scores as
real-world outcomes are decided, they have lowered the barrier to
entry and led to growing participation.
[0004] One problem with current tournament-style gaming systems is
that they lack the ability to calculate and provide future
projections. For example, if there is a league of ten users in a
pick'em pool, at any given point in the tournament a user may want
to know what his odds are of winning. Current systems give the
current score of the pool, but they do not project into the future
and tell a user what the likely outcome will be after three more
games have been played in the tournament. A user also may want to
know what game outcomes need to happen in the tournament in order
for that user to win, or finish the tournament in a certain
position. This allows the user to know which teams to root for. For
example, if Tennessee beats New Orleans a user's odds of winning
may go way up, such that the user would want to root for Tennessee.
Or, in more complex scenarios, if Tennessee beats New Orleans and
Seattle beats Pittsburgh then the user's odds of winning go way up,
but if Tennessee loses then the user really wants Seattle to lose
as well. These are fairly complex interactions that current systems
lack the ability to analyze.
[0005] Making future projections is not trivial. Many users try to
do this manually, only to be frustrated with the amazing complexity
of the problem. In fact, these projections are often nearly
impossible to do manually because of the combinatorial nature of
the problem. Even if the simplest case is assumed that each team
has equal odds for beating any other team (i.e., each team has a
50-50 chance of winning), users typically do not start with an
equal probability of winning because of the way each of their picks
may overlap other users' picks. This is unintuitive and gets vastly
more complicated with more teams and players, and if the simple
assumptions are changed such that each team does not have a 50-50
chance of winning. Even with a computer and the ability to do many
calculations quickly, making exact future projections can be
lengthy or even intractable.
SUMMARY
[0006] This Summary is provided to introduce a selection of
concepts in a simplified form that are further described below in
the Detailed Description. This Summary is not intended to identify
key features or essential features of the claimed subject matter,
nor is it intended to be used to limit the scope of the claimed
subject matter.
[0007] Embodiments of the tournament-style gaming scenario
exploration system and method provide users with an estimate of
their projected odds of finishing at each place within the pool,
given other users' picks as well as real-world results. This can be
done either within an entire league or alternatively, between a
subset (e.g. two) users. Other embodiments automatically detect
interesting key events that users may be notified of, such as
particular games that may drastically affect their odds of winning.
Additionally, users can interactively explore complex `what-if`
scenarios by setting various constraints in the system, to examine
how various tournament outcomes will affect their odds or the odds
of other players.
[0008] It is crucial to note that because of the way picks overlap
with one another, the odds of various users winning often are not
simply derivable from the current state of the pool. For instance,
even before any real-world contests have been decided, users'
chances of winning the pool are typically not equal (even assuming
random real-world outcomes). As a further example, it is sometimes
the case that the current "leader" of the pool is not most likely
to be the winner at the end (and, in fact, in some cases may have
absolutely no chance of winning). The projection capability offered
by embodiments of the tournament-style gaming scenario exploration
system and method can provide users with their odds within the pool
as well as information on how each game affects overall pool
results. The user is not only informed about which games to
monitor, but also is provided with new common ground for social
interaction or "trash talk". In certain types of pools, having this
information at hand also could be helpful with making picks in the
first place.
[0009] At a high level, embodiments of the tournament-style gaming
scenario exploration system and method use various methods of
generating potential tournament outcomes, scoring player picks and
ranking players based on each of these possible outcomes, and
repeating this many times to get probabilistic statistics on the
likely outcomes. In some embodiments, constraints may be applied at
various phases of the computation to explore various key scenarios.
After these computations are done, embodiments of the system and
method also can automatically detect key scenarios and events that
may be of interest to users.
[0010] More concretely, embodiments of the tournament-style gaming
scenario exploration system and method include: (1) a tournament
setup module, which allows basic tournament properties such as
teams, structure, and scoring schemes to be set. This is usually
done once at the beginning of each tournament; (2) a prediction
module, which computes predictions of various tournament outcomes.
The prediction module can be broken down into: (2a) a bracket
generation sub-module, which generates a multitude of brackets for
scoring; (2b) a game constraint sub-module, which applies game
constraints to the generated brackets; (2c) a scoring sub-module,
which takes each generated bracket, scores each players' picks
according to the generated bracket, and then rank orders the
players by final score to determine final placements; (2d) a player
placement constraint sub-module, which checks for and applies
specific user-specified constraints after scoring is performed; and
(2e) an accumulator sub-module, which keeps running totals of the
various calculations. Various embodiments also include: (3) a key
event detection module, which identifies events, for example, that
have a significant impact on a user's or competitor's placement in
the pick'em pool.
[0011] Embodiments of the tournament setup module take input that
form the core characteristics of the tournament, including, but not
limited to: the tournament structure and rules, scoring system,
teams playing, prior probabilities of each match, player picks, and
so on. This is usually done only once per tournament because most
pick'em games do not permit changes after the tournament has
started, but nothing stops this information from being changed at
any point within the tournament.
[0012] Embodiments of the bracket generation sub-module include a
unique N-bit bracket representation that represents a tournament
outcome in a compact and efficient format. The N-bit bracket
representation is an integer where at least some bits of the
integer represent games in the tournament. In some embodiments,
each bit in the bitwise representation identifies who was the
winner of the game represented by that bit. A bracket is used to
visualize the game. If the bit value is a "1", the upper competitor
of the bracket won the game, while if the bit value is a "0" the
lower competitor of the bracket won the game.
[0013] Embodiments of the bracket generation sub-module generate
possible tournament outcomes. At least two types of generation
techniques are used by the bracket generation sub-module. One type
is an exhaustive prediction technique, which computes all possible
tournament outcomes. This can be done, for example, by using the
N-bit bracket representation and just incrementing the integer
through all possible combinations. However, when the tournament
includes a large number of competitors, the exhaustive prediction
technique quickly becomes intractable. In this situation, a
sampling prediction technique can be used. The sampling prediction
calculates only a sample of all possible tournament outcomes to
arrive at an estimate of a future projection. Generally, there are
two ways in which a sampling prediction can be performed: (1)
random sampling; and (2) weighted sampling. The random sampling
technique uses a random number generator to generate random integer
numbers for the N-bit bracket representation, each corresponding to
a random tournament outcome. A much more efficient technique, the
weighted sampling technique is biased towards certain tournament
outcomes and samples these areas of the bracket more densely than
other areas. For example, if no users picked a certain team to win
then no tournament outcomes are generated whereby that team is a
winner. A different scheme generates tournament outcomes based on
the distribution of prior probabilities of each game. This requires
that each game outcome be generated as a function of the prior
probability of that match-up, which makes it slightly more involved
than the purely random sampling scheme. However, this ensures that
the final tournament outcomes are generated in proportion to their
overall likelihood of occurring, which has useful statistical
properties, namely that it drastically reduces the number of sample
brackets that have to be generated and scored for a given level of
desired accuracy.
[0014] Embodiments of the game constraint sub-module allow
constraints to be imposed on the tournament outcomes generated.
There are at least two types of game constraints, (1) real-world
results, and (2) user-input constraints ("what if" scenarios).
Real-world results constraints are imposed on the tournament
outcome if some of the games in the tournament have already been
played. The game constraint sub-module makes these tournament
outcomes valid by imposing the real-world results on each generated
tournament outcome. Embodiments of the game constraint sub-module
achieve this by generating a constraint mask, where some bits have
a bit set ("constrained" bits) and some bits are undecided, and
applying this constraint mask to the N-bit bracket representation
of the tournament outcomes. There are situations where a user would
like to impose constraints on the tournament outcomes to see "what
would happen if?". This "what-if" scenario is achieved by
generating a user-supplied constraint mask and applying this mask
to every tournament outcome such that it is forced to match those
constraints. Alternatively, in the weighted sampling scheme, these
constraints are applied as a weighting of 1 (always happens) or 0
(never happens) as each game outcome is chosen during the course of
generating a bracket. Regardless, game constraints are always met
in the brackets that are then used in the scoring sub-module.
[0015] Embodiments of the scoring sub-module take each of the
brackets generated by the bracket generation sub-module and scores
each player's picks according to the outcome in the bracket. It
then rank orders the players according to what their scores would
be if that bracket were to happen. This scoring is based on the
scoring scheme specified in the tournament setup, which can vary
widely.
[0016] The player placement constraint sub-module is applied when a
user specifies that they would like to explore only scenarios in
which certain player placements have been specified and applies
filters to the above results. For example, a user may specify that
they would like to explore outcomes that would have to happen in
order for them to place 1.sup.st in the league, or for some other
player to place 3.sup.rd, or combinations of such placements. The
player-constraint sub-module compares the rankings generated by the
scoring sub-module to see if the player placement constraints are
satisfied. If they are, the ranks are kept and sent to the
accumulator sub-module, if not, they are discarded, and the process
returns to bracket generation sub-module.
[0017] Embodiments of the accumulator sub-module keep a running
total of the statistics from all different possible outcome
brackets generated. When the generator is in exhaustive or random
sampling mode, the accumulator sub-module populates a table of all
players and all positions with a sum of normalized (by the
probability of the occurrence of each outcome bracket) placements.
For embodiments that use the weighted generation schemes, the
accumulator sub-module often only has to keep integer counts of the
occurrences (e.g. how many brackets in which player A placed
1.sup.st, etc).
[0018] At some point, either based on processing time, or number of
brackets generated, the prediction module stops and one more
normalization is performed, either dividing by an accumulated
normalizer to bring the overall percentages back down to 100%, or
by number of brackets explored. This normalization is easier in the
weighted sampling because brackets were already generated in
proportion to their expected occurrence in the first place.
[0019] Embodiments of the key event detection module can identify
potentially interesting games or events in the tournament. These
games may be interesting to a user because they affect the user's
placement in the pick'em pool. In some embodiments of the key event
detection module, the module examines any correlation between
tournament outcomes and user placements. In other embodiments, the
key event detection module can identify key games affecting user
placement in the tournament given the schedule of upcoming
tournament games. Embodiments of the key event detection module
also can examine tournament outcomes and counters to identify key
events or games that will affect a competitor's placement in the
final tournament standing. Any key games found then can be reported
to the user.
[0020] Some embodiments of the system and method also calculate
pairwise player statistics as a subset of calculations within large
leagues. This allows closed-form (non-sampling) calculations in
order to determine how one specific player is doing against another
player. In one such embodiment, the system and method can determine
if one player is completely dominated by another player. The way
this is determined is by picking a point in the tournament that we
would like to query (e.g. the final outcome), and setting all the
picks that Player A can get correct still to be correct, thus
optimizing Player A's score. For all other picks, the system and
method sets Player B's picks to be incorrect, thus minimizing their
score. If Player A's maximum score is less than Player B's minimum
score, then Player A is said to be locked out, and cannot possibly
place higher than Player B at that particular point in the
tournament. If the system and method were to calculate all pairs of
such lock out statistics for a given player and finds that the
player is locked out by all other players, then it can be concluded
that they are definitely locked out of first place. If they lock
all other players out, then they are guaranteed to win. However,
the inverse conclusions cannot be drawn. In other words, if a
player locks some out and not others, nothing concrete can be said
about their odds of first place and other techniques will have to
be used.
[0021] In alternative embodiments, by using dynamic programming
techniques, the system can compute the probabilities of each
possible difference in final score between any two players. The
system begins by computing a matrix for each upcoming game
containing the probabilities of each difference in score between
Player A and Player B caused by the two possible outcomes of the
game and the two players' picks for that game. For example, if the
two players have the same pick for that game the score difference
will be zero no matter the outcome, whereas if the player's picks
are not the same the difference will be a positive or negative
constant (which depends on the scoring system). At each game of the
tournament after this first round, a new matrix can be calculated
by calculating the probability of the differences in score produced
by the new game, and then accumulating them with the weighted
values of the matrices for each lead-in game. If this algorithm is
performed for each game in the tournament, the matrix for the final
game contains the probabilities for each possible difference in
final score between Player A and Player B. By then summing all the
probabilities for positive score differences, for example, the
system can report the probability of Player A beating Player B
(i.e., having a larger final score).
[0022] It should be noted that alternative embodiments are
possible, and that steps and elements discussed herein may be
changed, added, or eliminated, depending on the particular
embodiment. These alternative embodiments include alternative steps
and alternative elements that may be used, and structural changes
that may be made, without departing from the scope of the
invention.
DRAWINGS DESCRIPTION
[0023] Referring now to the drawings in which like reference
numbers represent corresponding parts throughout:
[0024] FIG. 1 illustrates a simplified traditional tournament
bracket used to represent games in a tournament.
[0025] FIG. 2 is a block diagram illustrating an embodiment of the
tournament-style gaming scenario exploration system and method
disclosed herein implemented in a tournament-style gaming
environment.
[0026] FIG. 3 is a flow diagram illustrating the general operation
of the method used in the tournament-style gaming scenario
exploration system shown in FIG. 2.
[0027] FIG. 4 is a flow diagram illustrating the detailed operation
of the tournament setup module shown in FIG. 2.
[0028] FIG. 5 is a detailed flow diagram illustrating the
generation of an N-bit bracket representation.
[0029] FIG. 6 illustrates an exemplary example of the N-bit bracket
representation for the bracket shown in FIG. 1.
[0030] FIG. 7 is a flow diagram illustrating the detailed operation
of the bracket generation sub-module shown in FIG. 2.
[0031] FIG. 8 is a flow diagram illustrating the detailed operation
of the game constraint sub-module shown in FIG. 2.
[0032] FIG. 9 is a block diagram illustrating an example of a
real-world result constraint applied to a predicted tournament
outcome.
[0033] FIG. 10 is a flow diagram illustrating the detailed
operation of the scoring sub-module shown in FIG. 2.
[0034] FIG. 11 is a flow diagram illustrating the detailed
operation of the accumulator sub-module shown in FIG. 2.
[0035] FIG. 12 is a flow diagram illustrating the detailed
operation of the key event detection module shown in FIG. 2.
[0036] FIG. 13 illustrates an example of a suitable computing
system environment in which the tournament-style gaming scenario
exploration system and method shown in FIGS. 2-12 may be
implemented.
DETAILED DESCRIPTION
[0037] In the following description of embodiments of the
tournament-style gaming scenario exploration system and method
reference is made to the accompanying drawings, which form a part
thereof, and in which is shown by way of illustration a specific
example whereby embodiments of the tournament-style gaming scenario
exploration system and method may be practiced. It is to be
understood that other embodiments may be utilized and structural
changes may be made without departing from the scope of the claimed
subject matter.
I. Basic Terminology
[0038] A few basic terms that will be used in this document will
now be defined. A "tournament", a "tournament-style game", or
"tournament-style gaming" refers to a number of competitors from
some domain of competition (such as sports) vying to be the overall
champion. Depending on the tournament, a competitor can refer to a
single person (an athlete), or a group of people (a team). Each
tournament consists of a sequence of head-to-head contests or games
(sometimes called matches, ties, fixtures, or heats) between
competitors that lead to some result. In most tournaments, this
means that one competitor is the winner of the tournament.
[0039] The basic goal of a tournament is to winnow multiple
competitors down to a single champion. This often makes a tree (or
hierarchy) a useful visual representation. In a single elimination
tournament (also known as a knockout or sudden-death tournament),
competitors who lose a match are immediately eliminated from the
tournament (or at least from winning the tournament), and only
winning competitors move on and vie to be the champion. For the
purpose of simplifying discussion, the document uses the term
"tournament" as if the tournament is a single elimination
tournament. However, it should be noted that there exist other
types of tournaments, including double elimination tournaments (in
which competitors can lose a single game and still vie for the
championship), or round robin tournaments (in which all competitors
play all other teams). Adapting embodiments of the tournament-style
gaming scenario exploration system and method to handle these types
of tournaments is a straightforward extension that will not be
explicitly discussed.
[0040] A bracket is the common term for a tree-based tournament
visualization. The structure of the bracket defines how and when
competitors will play each other as they progress through the
tournament towards the championship. FIG. 1 illustrates a
simplified traditional tournament bracket 100. This bracket
structure 100 contains a series of match-ups, which, as shown in
FIG. 1, has competitors (in this case, teams) playing each other
connected by a vertical line. Each team is matched up against
another team and the structure of the bracket 100 is well defined
such that there is a fixed progression of teams throughout the
bracket 100. As shown in FIG. 1, the bracket 100 includes 3 rounds
starting with "Round 1" and progressing to the "Winner."
[0041] The winner of each match-up progresses to the next round and
their name is filled in on a result line, which comes out of the
match-up. This forms a new match-up with another team, and this
process continues until there is only one team left (the tournament
winner). By way of example and not limitation, the bracket 100
shown in FIG. 1 illustrates that Seattle has played and beat
Carolina in Game 0 of Round 1. This means that Seattle's name is
placed on the result line of the Finals round. In addition, Denver
has played and beat Pittsburgh in Game 1 of Round 1, so that
Pittsburgh's name is placed on the result line of the Finals round.
This creates a match-up between Seattle and Pittsburgh in Game 2 of
the Finals round. This process continues until a winner is
determined. As can be seen from FIG. 1, in this particular example,
Seattle has won the tournament and this result is illustrated in
the "Winner" round on the far right of FIG. 1. It should be
appreciated that there exist many variants of the bracket
visualizations, but in general these basic properties hold.
[0042] The following terms are used in this document to refer to
elements of the fantasy games themselves. In particular, the term
"user" or "player" refers to a person who is taking part in the
fantasy competition. In other words, the user is a person who has
completed a set of contest predictions. These tournament contest
predictions are called picks. Most pick'em pools require that users
pick all outcomes within the entire bracket. Alternatively, it is a
straightforward extension for embodiments of the tournament-style
gaming scenario exploration system and method to be applied to
tournaments in which users only make a subset of picks. Multiple
users who are competing against each other in the pick'em game form
a pool or league. While pools can comprise just two users, or
thousands, most typically include less than 50 users. For the
purpose of simplifying discussion in this document, it is assumed
that users only fill out a single bracket for a single pool.
However, it should be noted that nothing precludes a user from
using multiple instantiations of embodiments of the
tournament-style gaming scenario exploration system and method to
track multiple brackets in multiple pools.
II. System and Operational Overview
[0043] FIG. 2 is a block diagram illustrating an embodiment of the
tournament-style gaming scenario exploration system and method
disclosed herein implemented in a tournament-style gaming
environment. It should be noted that the implementation shown in
FIG. 2 is only one of many implementations that are possible.
Referring to FIG. 2, tournament-style gaming scenario exploration
system 200 is shown in a tournament-style gaming environment 210.
The tournament-style gaming scenario exploration system 200 resides
on a computing device 220. It should be noted that the computing
device 220 may include a single processor (such as a desktop or
laptop computer) or several processors and computers connected to
each other.
[0044] The tournament-style gaming scenario exploration system 200
includes a tournament setup module 230, a prediction module 240,
and a key event detection module 250. The prediction module 240
includes a number of sub-modules, including a bracket generation
sub-module 255, a game constraint sub-module 258, a scoring
sub-module 260, a player placement constraint sub-module 265, and
an accumulator sub-module 270. The tournament setup module 230
inputs core information about the tournament into the system 200.
The prediction module 240 is a key component in the system 200 and
calculates predictions for different scenarios of a tournament. As
explained below, in some embodiments of the bracket generation
sub-module 255, these predictions use a novel N-bit bracket
representation and compute predictions using a random sampling
technique, a weighted sampling technique, or both. The game
constraint sub-module 258 applies game constraints to the
predictions or generated brackets. These game constraints include
real-world results and "what-if" scenarios proposed by a user. The
scoring sub-module 260 scores each player's picks according to a
bracket outcome. The player placement constraint sub-module 265 is
an optional sub-module, as denoted by the dashed line in FIG. 2.
The player placement constraint sub-module 265 imposes player
placement constraints on the predictions calculated by the bracket
generation module 255. The accumulator sub-module 270 keeps a
running tally of statistics from different possible outcome
brackets generated by the bracket generation sub-module 255. The
key event detection module 250 identifies events that are of
interest to a user because the events have a major impact on a
user's final ranking.
[0045] A user 275 interacts with the tournament-style gaming
scenario exploration system 200 through a display device 280 and an
input device 290 that are connected to the computing device 220.
Information from the tournament-style gaming scenario exploration
system 200 is displayed to the user 275 on the display device 280.
The user 275 is able to input information and requests to the
tournament-style gaming scenario exploration system 200 through the
input device 290 (such as a keyboard or pointing device). It should
be noted there may be one or more display devices and one or more
input devices connected to the computing device 220. In addition,
the computing device 220, display device 280, and input device 290
may be integrated into a single device.
[0046] FIG. 3 is a flow diagram illustrating the general operation
of the method used in the tournament-style gaming scenario
exploration system shown in FIG. 2. In general, the
tournament-style gaming scenario exploration method inputs a
bracket containing games for a tournament and allows exploration of
various scenarios as to the outcome of the tournament. In addition,
the tournament-style gaming scenario exploration method allows a
user to examine the user's picks to explore various outcomes of
picks in relation to other users' picks.
[0047] As shown in FIG. 3, the tournament-style gaming scenario
exploration method begins by inputting the game schedule of the
tournament, any real-world results of games in the tournament that
have already been played, user picks for the tournament, and
tournament odds for the tournament competitors (box 300). The game
schedule governs what player or team is matched up against another
player or teams during the tournament. Of course, if the tournament
has not yet started then the outcome of the games is unknown, and
only the first round games will be input. On the other hand, if
games of the tournament have been played, then the current game
schedule as well as game results will be input. As explained in
detail below, in some embodiments the game constraint sub-module
258 uses the real-world game results to impose constraints on the
predictions.
[0048] Some embodiments of the tournament-style gaming scenario
exploration method represent each game in the tournament in an
N-bit bracket representation (box 310). This representation, which
is discussed in detail below, represents each game in the
tournament as a binary integer. The method then computes
predictions of a plurality of outcomes of the games of the
tournament using the internal representation to obtain prediction
results (box 320). In some embodiments of the tournament-style
gaming scenario exploration method, constraints are applied to the
prediction results to obtain constrained prediction results (box
330). These constraints may be game constraints imposed on the
results such as real-world constraints, which include the outcomes
of games that have already been played, or user-supplied
constraints, such as what will happen if this team wins the game
and where the user will rank based on his picks. These constraints
may also include player placement constraints.
[0049] In some embodiments the tournament-style gaming scenario
exploration method identifies key events or games in the tournament
that will impact a final ranking of one or more users (box 340).
For example, there may key games that will affect a user's ranking
in the pick'em pool, while other games may have less of an impact.
The method uses the predictions to identify these key games.
Finally, the method displayed the constrained prediction results,
the key games, and corresponding information to the user (box
350).
III. Tournament-Style Gaming Scenario Exploration Details
[0050] Embodiments of the tournament-style gaming scenario
exploration system and method include several components, modules,
and sub-modules. The details of each of these items now will be
discussed.
III.A. Tournament Setup Module
[0051] The tournament setup module 230 allows basic tournament
properties such as teams, structure, scoring schemes, and so forth,
to be input to the system 200. Typically, this is performed once at
the beginning of each tournament. However, the tournament setup
module 230 does allow changes to be made to this information.
[0052] FIG. 4 is a flow diagram illustrating the detailed operation
of the tournament setup module 230 shown in FIG. 2. The operation
begins by inputting initial core characteristics of the tournament
(box 400). By way of example and not limitation, these initial core
characteristics include the tournament structure, tournament rules,
scoring system, teams playing, prior probabilities of each match,
player picks, and so forth
[0053] The module then determines whether any information needs to
change (box 410). This change may come from a user. The initial
core characteristics usually do not change during the tournament
because most pick'em games do not permit changes after the
tournament has started. However, nothing stops this information
from being changed at any point within the tournament. If the
initial core characteristics are to be changed, then the module 230
updates the core characteristics of the tournament that have
changed (box 420). Otherwise, the module 230 outputs the initial
core characteristics and any updated core characteristics of the
tournament (box 430).
[0054] As stated above, the core characteristics of the tournament
can include various types of information. For example, in order to
statistically calculate the future standings within the pick'em
pool, it is necessary to know not only the current score, the
number of potential points a user can score, and the likelihood
that they will score these, but also the overlap that their picks
have with other users' picks. As a trivial example, if everyone has
picked exactly the same results for some competitor throughout the
tournament, then the performance of this competitor is of little
importance in future projections as it has no differential impact
on the users' scores relative to one another. Embodiments of the
tournament setup module 230 include using several core pieces of
information to project future standings: (1) the basic tournament
bracket including the games in the tournament; (2) results of any
contests that have already been played (real-life game outcomes);
(3) all users' picks (of contests decided and yet to be decided)
that each user has made for the contests; and (4) prior
probabilities for the outcomes of each possible match-up in the
tournament. This is the odds of a tournament outcome actually
occurring.
[0055] Some embodiments of the tournament setup module 230 input
information that specifies how likely it is for any given
competitor to beat any other competitor. This is known as a prior
probability table, which specifies how likely it is that each
competitor will beat each other competitor. For example, if there
are K competitors in a tournament, a prior probability table
consists of K.times.(K-1) entries. There are many ways in which the
prediction module can estimate prior probabilities and populate
this prior probability table.
[0056] In some embodiments, the tournament setup module 230 can use
prior probabilities that infer nothing about the competitors and
assume that the likelihood of any competitor beating another is
chance (e.g., each team has a 50-50 chance of winning). Although
this may be the simplest case, it may not be the most accurate. In
another embodiment, the tournament setup module 230 uses
information about the competitors, such as tournament rankings,
previous performance, statistics, or popular opinion, in order to
derive prior probabilities. In some of these embodiments, the
tournament setup module 230 uses a linear mapping from rankings to
probabilities (e.g. a number one-ranked competitor is much more
likely to beat a number sixteen-ranked competitor than they are a
number two-ranked competitor). In another embodiment, the
tournament setup module can use popular opinion, either attained
through some explicit voting mechanism or through other users'
picks, in order to derive the probabilities (e.g. competitors that
are more often picked to win are more likely to win). In yet
another embodiment, the tournament setup module 230 can use odds
set by experts (or betting odds) to derive probabilities. In still
other embodiments, the tournament setup module 230 can start with
any of these probability schemes and allow the user to specify new
probabilities, either by using mathematical equations or computer
programs to combine statistics. These statistics can then be
collected from multiple sources or by manually changing individual
entries within the table.
[0057] Using the prior probability table and an assumption of
independence between contests the tournament setup module 230 then
can calculate the likelihood of any given set of contest outcomes
occurring. For example, if A plays B and C plays D, and if A has a
75% probability of beating B and C has a 30% of beating D, then the
probability of the particular set of brackets in which A beats B
and C beats D is 75% times 30% or 22.5%. By multiplying together
individual contest outcomes in this way, the tournament setup
module 230 can arrive at a single prior probability value for the
set of contest outcomes representing an entire bracket. Such a
fully specified set of outcomes is referred to as a tournament
outcome and the prior probability of this happening as the outcome
probability.
III.B. Prediction Module
[0058] The prediction module 240 calculates predictions for
different scenarios of a tournament to produce possible tournament
outcomes. The predicted outcomes are made using a N-bit bracket or
other internal representation and an exhaustive prediction
technique, a sampling prediction technique, or both. Details of the
sub-modules of the prediction module 240 now will be discussed.
a, Bracket Generation Sub-Module
[0059] Embodiments of the bracket generation sub-module 255 include
a unique N-bit bracket representation that allows every possible
outcome of the tournament to be represented in a compact and
efficient format by a single integer. FIG. 5 is a detailed flow
diagram illustrating the generation of an N-bit bracket
representation. In this representation, N is the number of games,
which for fully populated single elimination tournaments equals the
number of teams that start the tournament minus one. In addition,
each game is represented by a bracket having an upper competitor
versus a lower competitor on the bracket (box 500). This concept is
discussed in more detail below.
N-Bit Bracket Representation
[0060] The N-bit bracket representation is a Y-bit integer, where Y
is greater than or equal to N (Y.gtoreq.N) (box 510). Typically,
the Y-bit integer will be some power of 2 in order to simply
processing and random number generation. For example, the Y-bit
integer may be a 16-bit integer or a 64-bit integer. This is true
even if N is less than Y. For the case where N<Y, there will be
some unused bits in the Y-bit integer. Each used bit in the Y-bit
integer represents a game in the tournament (box 520). For example,
in some embodiments a single 64-bit integer is used to represent
possible outcomes of a tournament having up to 64 teams. A 64-bit
integer is used because it is a common primitive used in computer
programs. In theory, for a 64-team tournament only 63 bits are
necessary (N=63). However, a 64-bit integer is used because it is a
nice power of 2 binary number and is an easy number for which to
generate random numbers. Thus, for a 64-team tournament one bit
goes unused, while the other 63 bits are used bits. In alternate
embodiments, a 32-bit integer or a 16-bit integer may be used. In
some embodiments of the prediction module, an entire 64-bit integer
is used for a tournament even if it is a 16 team tournament because
using a 64-bit integer simplifies the computation.
[0061] Before any games in the tournament have been played, random
brackets are generated within the tournament space. By way of
example, refer to the brackets for the 4-team tournament shown in
FIG. 1. In order to simply the discussion, only a 4-team tournament
will be discussed to illustrate the principle behind the N-bit
bracket representation. Each used bit in the Y-bit integer is
defined as a "1" if the upper competitor in the bracket wins the
game (box 530). Conversely, each used bit is defined as a "0" if
the lower competitor in the bracket wins the game (box 540). The
output is the Y-bit integer representing an outcome of the
tournament (box 550)
[0062] In order to better illustrate the N-bit bracket
representation, FIG. 6 is an exemplary example of the N-bit bracket
representation for the bracket shown in FIG. 1. As shown in FIG. 6,
a 4-bit integer 600 is used to represent the possible outcomes of
the tournament shown by the bracket of FIG. 1. Each bit in the
4-bit integer 600 represents one of the 3 games in total that will
be played. Referring to FIGS. 1 and 6, and looking from left to
right, a first bit 610 represents an outcome of Game 0 (between
Seattle and Carolina), a second bit 620 represents an outcome of
Game 1 (between Denver and Pittsburgh), and a third bit 630
represents an outcome of Game 2 (between Seattle and Pittsburgh).
Note that because only 3 games are played in this tournament and
there are 4 bits, a fourth bit 640 is not needed and is not used.
Nevertheless, the 4-bit integer 600 is used because it is a power
of 2 and it is convenient to use.
[0063] Referring to FIG. 1, note that each bracket contains a top
team and a bottom team for the match-up, such that the top team
plays the bottom team. Specifically, for Game 0 the top team on the
bracket is Seattle and the bottom team is Carolina. Similarly, for
Game 1 the top team is Denver and the bottom team is Pittsburgh,
and for Game 2 the top team is Seattle and the bottom team is
Pittsburgh. For a specific game number, if the corresponding bit is
a "1" that means that the top team on the bracket won, whereas if
the corresponding bit is a "0" means that the bottom team on the
bracket won. In other words, for bit "B" representing a game being
played, if that bit is a "1" it means that the upper team (from the
upper half of the bracket) won the game. On the other hand, if that
bit is a "0", it means that the lower team (from the lower half of
the bracket) won the game.
[0064] Referring again to FIGS. 1 and 6, the 4-bit integer 600 has
a value of 1011". The first bit 610 representing Game 0 has a value
of "1", meaning that the top team in the bracket (i.e. Seattle) won
Game 0. The second bit 620 representing Game 1 has a value of "0",
meaning that the bottom team in the bracket (i.e. Pittsburgh) won
Game 1. The third bit 630 representing Game 2 has a value of "1",
meaning that the top team in the bracket (i.e. Seattle) won Game 2.
Note once again that the value of the unused fourth bit is of no
consequence, since there are only 3 games in the tournament.
[0065] The N-bit representation can be used to represent every
possible outcome of a tournament. In the 3-game example used above,
there are 8 possible outcomes (0-7) of the tournament (2.sup.3),
since the fourth bit 640 is not used. Specifically, the outcomes of
the 3-team tournament are as follows (again, the fourth bit 640 is
denoted as an "Z" since it is unused):
TABLE-US-00001 "000Z" Carolina won Game 0, Pittsburgh won Game 1,
Pittsburgh won Game 2 "100Z" Seattle won Game 0, Pittsburgh won
Game 1, Pittsburgh won Game 2 "010Z" Carolina won Game 0, Denver
won Game 1, Denver won Game 2 "110Z" Seattle won Game 0, Denver won
Game 1, Denver won Game 2 "001Z" Carolina won Game 0, Pittsburgh
won Game 1, Carolina won Game 2 "101Z" Seattle won Game 0,
Pittsburgh won Game 1, Seattle won Game 2 "011Z" Carolina won Game
0, Denver won Game 1, Carolina won Game 2 "111Z" Seattle won Game
0, Denver won Game 1, Seattle won Game 2
[0066] A random number generator can be used to generate random
4-bit integers, as discussed below. This yields random outcomes of
the tournament that are compactly represented with a single Y-bit
integer that can be used to specify any given outcome. Each of the
integers that the Y-bit integer can represent enumerates the entire
space of possible outcomes for an (N+1)-team tournament.
[0067] One advantage of the N-bit bracket representation is that
each Y-bit integer that is generated is a valid bracket. Many
current systems give each competitor in a tournament a unique
identification. This means it is sometimes quite difficult to
ensure that invalid brackets to not arise. For example, if Seattle
plays Carolina in the first round and Carolina loses, with some
current systems caution must be used to ensure that Carolina does
not show up in brackets after the first round, as these are invalid
brackets. However, with N-bit bracket representation, because only
position is used (top team vs. bottom team), then it follows that
every bit field is a valid bracket.
[0068] In addition, the N-bit bracket representation is a compact
representation. In other words, for an (N+1)-team tournament only N
bits are needed. There are at least two advantages to this
representation. First, it is a very compact representation of
brackets. Second, it is easily generated and implemented, since any
computer language has built-in primitives for generating random
numbers. This makes the N-bit bracket representation an efficient
generation scheme.
Prediction Calculation
[0069] In general, the approach used by embodiments of the bracket
generation sub-module 255 in statistically predicting future
standings is to generate as many possible tournament outcomes as it
can (e.g. based on some fixed amount of time it is provided to
perform the processing) and then to calculate how each user will do
in each of these outcomes. User performance in the pick'em pool for
each of these outcomes is weighted by the outcome probability.
These weighted scores are summed to create a prediction of the
probability of each user finishing in a certain place within the
pool. Embodiments of the bracket generation sub-module 255 can use
two types of prediction techniques. Namely, an exhaustive
prediction technique and a sampling prediction technique can be
used. Each of these techniques is discussed in detail in the
following discussion.
[0070] FIG. 7 is a flow diagram illustrating the detailed operation
of the bracket generation sub-module 255 shown in FIG. 2. In
general, the module 255 uses the N-bit bracket representation to
compute various tournament outcomes. The operation begins by
inputting a N-bit bracket representation of the tournament (box
700). A determination then is made whether to use an exhaustive
prediction technique (box 710).
Exhaustive Prediction
[0071] The most basic way of predicting outcomes of a tournament is
to perform an exhaustive prediction. The exhaustive prediction
exhaustively generates and scores all possible tournament outcomes
(box 720). This is done using the N-bit bracket representation
discussed above. The 4-team tournament example discussed above was
an example of an exhaustive prediction, where each of 8 possible
outcomes of the tournament was found.
[0072] There are limits, however, to the exhaustive prediction. In
particular, the number of possible tournament outcomes is 2.sup.X,
where X is the number of games or contests remaining in the
tournament. Given the current processing capability of modern PCs
(e.g. a 3.3 GHz machine with 1 GB of RAM), it is feasible to
perform an exhaustive prediction for brackets of up to about 16
remaining contests (where there are roughly 64,000 outcomes) if
interactive performance is desired. However, since the outcome
space is exponential with the number of contests, exploring all
outcomes for a larger bracket by performing an exhaustive
prediction is not feasible. For example, at the beginning of a 64
team tournament (which has 63 games), there are 2.sup.63 (or about
9 million trillion) possible outcomes, which would take roughly 4.5
million processing years to generate fully at the above-mentioned
rate. Thus, it is an intractable problem to perform an exhaustive
prediction of this magnitude.
Sampling Prediction
[0073] When an exhaustive prediction is intractable, embodiments of
the bracket generation sub-module 255 can use sampling prediction.
The sampling prediction calculates only a sample of all possible
tournament outcomes to arrive at an estimate of a future
projection. Generally, there are two ways in which a sampling
prediction can be performed: (1) random sampling; and (2) weighted
sampling. Referring to FIG. 7, the operation of the bracket
generation sub-module 255 makes a determination whether random
sampling will be used (box 730).
[0074] If so, random sampling is performed by selecting results at
random from within the tournament space by using a random number
generator (box 740). Next, the module 255 generates valid brackets
from within the space and then re-normalizes these results after
generation of a bracket, given how likely that bracket would be to
come out.
[0075] Embodiments of the bracket generation sub-module 255 also
can use weighted sampling. Weighted sampling performs sampling more
densely in certain areas of the outcome space and less densely in
other areas. The module 255 obtains weighting information (box
750). The module 255 then samples more densely at certain areas of
the tournament bracket based on the weighting information (box
760).
[0076] One example of weighting information is user picks. In this
situation, the bracket generation sub-module 255 can sample more
densely around areas of the tournament bracket based on users'
picks. For example, in some embodiments overlapping points of
users' picks are identified and sampling occurs more densely around
those points. By way of further example, referring to FIG. 1,
assume that no user picked Seattle to win in the first round game
(Game 0). In this case, then the module 255 would not generate any
brackets in which Seattle won the first round game. And if most
users picked one of the teams to win a round and only one user
picked another team to win in that round, the module 255 could
sample that space less densely as it would be less differentiating
between the brackets.
[0077] In some embodiments, the weighting information is game odds
(i.e. prior prediction probabilities). In this case, the areas of
the tournament bracket in which to sample more or less densely can
be driven by the prior odds of a team beating another team. For
example, using the example of FIG. 1, if going into a tournament
Seattle was a great team and had a 90% chance of beating Carolina
in the Round 1, the bracket generation module 255 may sample more
brackets with Seattle in the Finals than with Carolina in Finals.
In fact, in one embodiment, the module 255 would sample at exactly
the probability of the outcome (i.e. about 90% of brackets
generated would be expected to have Seattle win that game).
[0078] For tournaments with a large number of games, once a
sufficient number of games have been played, the predictions can be
performed using the exhaustive prediction. For example, in a
64-team tournament, the weighed sampling can be used until there
are about 16 games remaining, which corresponds to about 65,000
outcomes. At this stage of the tournament outcomes can be computed
using the exhaustive prediction technique. The Y-bit binary integer
representing a tournament outcome then is output from the
prediction module (box 770).
b, Game Constraint Sub-Module
[0079] There will be situations when the tournament outcomes
computed by the bracket generation sub-module 255 may not be valid
(because some games in the tournament have already been played) or
when a user may want to impose certain constraints on predictions
(such as what happens if Competitor A wins Game 2?). The game
constraint sub-module 258 allows these game constraints to be
imposed on the tournament outcomes calculated by the bracket
generation sub-module 255. There are at least two types of game
constraints, (1) real-world results, and (2) user-input constraints
(or "what if" scenarios).
[0080] FIG. 8 is a flow diagram illustrating the detailed operation
of the game constraint sub-module 258 shown in FIG. 2. In general,
the game constraint sub-module 258 applies to a tournament outcome
either real-world result constraints, "what-if" constraints, or
both. In particular, the operation of the game constraint
sub-module 258 begins by inputting a predicted tournament outcome
represented by a N-bit bracket or other suitable representation
(box 800). Next, a determination is made as to whether any games of
the tournament have been played (box 810). If so, the real-world
results constraints are used.
Real-World Result Constraints
[0081] After some games of the tournament have been played, the
tournament outcomes may be partially incorrect for the games that
have already been played. The game constraint sub-module 258 makes
these tournament outcomes valid by imposing the real-world results
on each generated tournament outcome. Referring to FIG. 8, the
sub-module 258 inputs the real-world results from the tournament
(box 820).
[0082] Embodiments of the game constraint sub-module 258 express a
set of pre-decided outcomes as a bitmask (or a "constraint mask")
where some bits have a bit set ("constrained" bits) and some bits
are undecided. The sub-module 258 applies a constraint mask based
on the real-world results constraints to the N-bit bracket
representation (box 830). In the case where games have already been
played, the sub-module 258 keeps a partial bit field representing
the current state of the tournament. This means that some of the
games are meaningless, since they represent games that have not
been played. But some of the bits will have 0's and 1's in them. In
other words, the sub-module 258 generates a random bracket and then
replaces in that random bracket each of the bits that have already
been specified by games that have already been played. Each of the
bits representing games that have not yet been played is left
unchanged.
[0083] Using the example given above, if contests 1, 2, and 4 had
already been played, the corresponding constraint mask would be
00X0XXX, where X represents contests yet to be decided. After a
full random tournament outcome number is generated, it is modified
by replacing some of its bits with the corresponding constrained
bits in the constraint mask.
[0084] FIG. 9 is a block diagram illustrating an example of a
real-world result constraint applied to a predicted tournament
outcome. This example uses the 4-team tournament example given
above. In this example, if Seattle has already played Carolina and
Seattle has won, then generating equally random 3-bit fields makes
no sense because one of the games has already been played. This is
shown at the top of FIG. 9, where in Game 0 Seattle has beaten
Carolina in Round 1 and has advanced to the Finals. A corresponding
constraint mask would be 1XXZ, where X represents games yet to be
decided and Z is an unused bit. However, in FIG. 9 the bracket
generation sub-module 255 generated a random full 4-bit number,
"001Z", which is the predicted tournament outcome. In this case,
the predicted tournament outcome is invalid, since Game 0 has
already been decided. Instead, the game constraint sub-module 258
applies the constraint mask to the predicted tournament outcome by
replacing the first bit (representing the game between Seattle and
Carolina) with a "1", since the top team in the bracket (Seattle)
won. This produces a valid constrained tournament outcome, "100Z".
Another way of looking at this is that after a predicted tournament
outcome binary integer has been generated it is modified by
replacing some of its bits with the corresponding constrained bits
in the constraint mask. In the example of FIG. 9, the random
integer generated would have its first bit changed to a "1", and
the remainder of the bits would be left unchanged. This produces a
valid possible outcome taking into consideration that Game 0 has
already been decided.
"What-if" Scenario Constraints
[0085] Referring back to FIG. 8, a determination then is made as to
whether a user has supplied any "what-if" constraints (box 840). If
so, then the game constraint sub-module 258 inputs the
user-supplied "what-if" constraints (box 850). There are situations
where a user would like to impose constraints on the tournament
outcomes to see "what would happen if?". This "what-if" scenario is
handled similar to imposing real-world results on the tournament
outcomes. In particular, the sub-module 258 applies the "what-if"
constraints to the N-bit bracket representation (box 860). User
constraints are used to set certain bits within the N-bit bracket
representation to a specific value, and every tournament outcome
that is generated by the bracket generation sub-module 255 is
forced to match those constraints. The output of the game
constraint sub-module 258 is constrained tournament outcomes, or
tournament (box 870).
[0086] The game constraint sub-module 258 allows users to specify
an "alternate reality", typically by interacting with the bracket
visualization. In doing this, the user can either change real-world
events that have already happened, or, more likely, add real-world
events that have not yet happened. For example, a user might be
interested to see what would happen to standing probabilities if a
specific competitor (or set of competitors) won the next round, or
if they continued to win several more rounds. When the user does
this, the game constraint sub-module 258 augments its calculations
to include only brackets that satisfy the imposed constraints in
order to obtain its estimates.
c. Scoring Sub-Module
[0087] Embodiments of the scoring sub-module 260 include scoring
each players' picks according to each generated bracket, and then
ranking the players based on the scores as if the generated bracket
actually occurred. FIG. 10 is a flow diagram illustrating the
detailed operation of the scoring sub-module 260 shown in FIG. 2.
The operation begins by inputting the scoring scheme for the
tournament, the brackets generated by the bracket generation
sub-module 255, and the players' picks (box 1000). It should be
noted that the scoring scheme can vary widely between tournament
pools.
[0088] Once a tournament outcome has been generated, it is compared
to the user's picks and a score is produced. The scoring sub-module
260 scores each player's picks according the scoring scheme and
based on the outcome of the generated brackets (box 1010). A
typical scoring scheme involves a certain number of points for each
correct prediction, with correct predictions, for example, in later
stages being more valuable than those in earlier stages. The
tournament outcome and an individual user's outcome are each mapped
into a representation that makes for efficient scoring
calculations. The sub-module 260 then ranks players according to
what their score would be if the generated bracket actually
occurred (box 1020). One example would be to map an outcome into an
ordered list of winning competitors at each stage. The tournament
list and the user's list are compared to count the number of
matching entries, and this count is multiplied by the appropriate
point factor to get the total user score for each stage. The users
are all scored and their scores are sorted, resulting in a list of
standings. The sub-module 260 outputs the players rankings based on
the generated bracket (box 1030).
d. Player Placement Constraint Sub-Module
[0089] Embodiments of the optional player placement constraint
sub-module 265 are applied when a user specifies that they would
like to explore only scenarios in which certain player placements
have been specified and applies filters to the above results. The
player placement constraint sub-module 265 allows users to specify
a "desired placement outcome", typically by interacting with the
standing probabilities visualization. In doing this, the user
specifies that they care about exploring the scenarios in which
certain standings are attained by certain users. For example, a
user might be interested in seeing what game outcomes have to
happen in order for them to place first in the pick'em pool, or for
them to place second while another user places fourth. When the
user does this, the player placement constraint sub-module 265
looks through the set of generated tournament outcomes in order to
match these constraints and sums the individual contest outcomes
that satisfy this standing constraint. In some embodiments of the
player placement constraint sub-module 255, this is displayed as
weighted counts of each competitor reaching a certain round. By
looking at these counts, the user can derive the contest outcomes
that will most likely lead to the specified standing constraints.
Perhaps more importantly, the user will be able to see what
outcomes cannot possibly satisfy these constraints. They would, for
example, be able to tell that if a certain competitor goes past a
certain round, they will not be able to win the pick'em pool.
[0090] In some embodiments of the game constraint sub-module 258
and the player placement constraint sub-module 265, the user
interface is a dialog box that presents any constraints that the
user has imposed so that they can explore scenarios of interest.
The user interface must be crafted correctly such that only one
constraint at a time, so as to make sure that the constraints never
collide. In some embodiments, the constraint can be formulated as a
simple English sentence (such as "what if Competitor A were to beat
Competitor B" or "what if Competitor A were to make it to the third
round of the tournament" or "what would have to happen if I wanted
to finish as pool champion"). This interface allows the user not
only to see the constraints they have placed on the system, but
also to toggle them on and off, or to remove them from the
calculations completely. The constraints are also available on the
main visualizations (such as the interactive bracket or standings
probability) in a distinct fashion, such as a red outline, or
presented with dimmed out and faded colors.
e. Accumulator Sub-Module
[0091] Embodiments of the accumulator sub-module 270 compute and
keep a running total of statistics relating to the generated
brackets. FIG. 11 is a flow diagram illustrating the detailed
operation of the accumulator sub-module 270 shown in FIG. 2. The
operation of the accumulator sub-module 270 begins by inputting
player rankings computed by the scoring sub-module 260 (box 1100).
Next, a running total is kept of statistics from all possible
outcomes of the generated brackets (box 1110).
[0092] One use for the accumulated statistics is to predict what
order the users will place in their tournament picks. For example,
if every tournament outcome generated by the bracket generation
sub-module 255 has User 3 coming in first, then the total
probability for User 3 placing first in the pick'em pool is 100%.
Moreover, if the module 255 never generates a tournament outcome in
which User 4 comes in first, then that counter stays at zero, and
everything else is in between. Note that while 100% and 0% mean
that the prediction is a certainty (either to happen or not) in the
exhaustive scheme, this is not true with sampling schemes, which
can only present estimations and not certainties.
[0093] These counters for user placements are a P.times.P table,
where P is the number of users. So, User 1 has a counter for coming
in 1.sup.st, 2.sup.nd, 3.sup.rd, etc., and User 2 has similar
counters. Each time the bracket generation sub-module 255 computes
an outcome probability for a given tournament outcome, the module
255 examines the corresponding counters and adds to them as
dictated by the outcome. These counters are basically accumulators
for the probabilities that these users are coming in these
placements.
[0094] Other accumulators are maintained in a similar manner for
other features of the explored bracket space that might be run
through the key event detection module and found to be interesting
to the user. For example, accumulators for certain teams reaching
certain rounds of the tournament, or accumulators for player
placements when a certain team wins or loses.
[0095] A determination is made as to whether the bracket generation
technique is a weighted generation scheme (box 1120). If not, this
implies that the generation technique is an exhaustive scheme or a
random sampling scheme. In this case, the accumulator sub-module
270 populates its tables with a sum of normalized placements (box
1130). The normalization is performed using the probability of the
occurrence of each outcome bracket. For embodiments that use the
weighted generation schemes, the accumulator sub-module 270 keeps
integer counts of the occurrences of each player in a certain
ranking (box 1140). In other words, how many brackets in which
player A placed first, how many brackets in which player B placed
third, and so forth. The operation of the sub-module 270 then
outputs the accumulated statistics (box 1150). The process works
identically for other accumulation tables.
III.C. Key Event Detection Module
[0096] For users that do not wish to interact with the optional
player placement constraint sub-module 265, the above "what-if"
scenario generation can be performed in an automated fashion to
select a small set of potentially interesting games. These key
events then are displayed to the user, such as in a bracket
visualization. In some embodiments of the key event detection
module 250, heuristics are used to determine if the outcome of a
particular contest drastically affects the standing probabilities
of the user. For example, regardless of what a user picked, if
their probability of a given standing rises or drops by a
significant amount with the outcome of a certain upcoming contest,
the key event detection module 250 will call this out in the
bracket visualization.
[0097] It should be noted that there are unintuitive instances in
which users would like to explicitly root against competitors that
they have picked because of how this affects other users within the
pick'em pool. The user then may wish to pay more attention to the
particular contest, or to discuss this further with pool-mates.
Similarly, a contest outcome that leads to the user being locked
out of certain standing positions (such as if Competitor A wins
their next contest, the user cannot place higher than 3.sup.rd in
the pool) is an interesting piece of information and one which the
key event detection module 250 also points out. Using this, the key
event detection module 250 is also able to provide interesting
information about outcomes that do not affect the current user
(such as drastically changes the rankings of other users
independently or in relation to one another).
[0098] FIG. 12 is a flow diagram illustrating the detailed
operation of the key event detection module 250 shown in FIG. 2. In
general, the key event detection module 250 identifies events that
are of interest to a user because the events have a major impact on
a user's placement or on a competitor's placement at the end of the
tournament. In particular, operation of the key event detection
module 250 begins by inputting tournament outcomes, counters, and a
schedule of upcoming games in the tournament (box 1200).
[0099] In some embodiments of the key event detection module 250,
the module 250 examines the counters and tries to find correlation
between tournament outcomes and user placements (box 1210). For
example, assume that the key event detection module 250 finds that
several tournament outcomes have User 1 coming in first in the
pool. Assume further that the module 250 examines these tournament
outcomes further and discovers that in all the outcomes where User
1 comes in first, Florida never wins its 2.sup.nd round game. The
key event detection module 250 then reports this information to the
user as an interesting thing to know. In this example, the module
250 would tell User 1 that in all the cases where you come in first
Florida loses by the 2.sup.nd round.
[0100] In other embodiments, the key event detection module 250 can
identify key games affecting user placement in the tournament user
correlation and the schedule of upcoming tournament games (box
1220). This is done by tracking piecewise probabilities and knowing
the set of upcoming games. The module 250 then can look at those
games and report to the user important games. For example, assume
that in instances where Illinois wins a Round 1 game a User 1's
chance of coming in first is 52%, while in all the ones where
Illinois loses this game User 1's chances are 26%. This is an
important game for User 1, and the key event detection module 250
reports this to User 1. In certain situations, the module 250 may
find that whether a team wins or loses the game does not affect a
user's odds of finishing at a certain position. But sometimes a
particular game is important and does make a difference to a user's
placement in the pool. In these situations the games are reported
to the user as key games.
[0101] The key event detection module 250 can examine tournament
outcomes and counters to identify key events or games that will
affect a competitor's placement in the final tournament standing
(box 1230). Using the same set of calculations, the module 250
accumulates the probabilities for competitors in rounds the exact
way the module 250 does for user placements on the pool. Thus, for
any given tournament outcome there is a final ranking or placement
of the competitors. The key event detection module 250 uses
counters to accumulate the probabilities that the competitors will
finish at a certain placement when the tournament is finished. Key
games then are reported to the user (box 1240).
III.D. Other Embodiments
[0102] There are several core pieces of information that have to be
exchanged between users and updated throughout the course of the
tournament. For example, user picks have to be shared. This usually
only has to occur once at the beginning of each tournament, since
most pick'em games do not allow users to change the picks once the
tournament has started. However, some embodiments of the
tournament-style gaming scenario exploration system 200 and method
allow users to spend some number of their current fantasy points in
order to change a certain number of picks, and this data would have
to be exchanged again each time a change is made. Also, users may
wish to save and exchange scenarios that they have constructed
using the what-if scenario explorer so that other users may quickly
replicate and explore outcomes around this scenario. Furthermore,
the calculations and visualizations have to be updated with new
real-world information as data becomes available.
[0103] In some embodiments of the tournament-style gaming scenario
exploration system 200 and method, the system 200 and method are
entirely a server end application, with all calculations performed
on a server and visualization and interaction taking place in a
"thin-client" (such as in a web-browser). While this is a
convenient model, since the user does not have to download or
install any additional software, the load that is placed on the
server to perform calculations for many users (up to hundreds of
thousands) can be very high. This is especially true since users
tend to check and explore their brackets at quite well-defined
times, such as before and after real-world contests are played.
[0104] In other embodiments of the tournament-style gaming scenario
exploration system 200 and method, a peer-to-peer arrangement is
used. In these embodiments, users download and run software that
perform all calculations locally and are able to communicate
directly with each other. While this mitigates the server-side
problems, it creates the potential for clients to be out of sync
with each other since it is difficult to guarantee that a client
has all available information at all times.
[0105] Other embodiments of the tournament-style gaming scenario
exploration system 200 and method are a hybrid of the
above-mentioned embodiments. In particular, in these embodiments a
"rich client" is used that has to be downloaded and installed in
some manner. A server is used to hold the data that needs to be
exchanged and updated. This client-server model offloads the
processing to the local machine, where processing cycles are
usually abundant, while keeping the data assessable to all clients
on a server. This server could be infrastructure from or similar to
one of the existing fantasy sports sites, augmented to send the
data that our client needs when it authenticates. It could also be
a more generic data exchange server. One example of this is for a
client to programmatically set up and connect to an existing blog
page (such as spaces.live.com) and send or receive information from
looking at this page. This scheme has the added benefit that the
data is human readable and users can insert other content on the
site to augment their social interaction. In some embodiments of
the tournament-style gaming scenario exploration system 200 and
method, well-formed English text is inserted that provides
commentary of the state of the tournament as well as interesting
future scenarios. Real-world tournament updates can either be
automatically updated with data feeds from various data sources, or
they can be manually inserted by tournament organizers or even
individual users.
IV. Exemplary Operating Environment
[0106] Embodiments of the tournament-style gaming scenario
exploration system 200 and method is designed to operate in a
computing environment. The following discussion is intended to
provide a brief, general description of a suitable computing
environment in which the tournament-style gaming scenario
exploration system 200 and method may be implemented.
[0107] FIG. 13 illustrates an example of a suitable computing
system environment in which the tournament-style gaming scenario
exploration system 200 and method shown in FIGS. 2-12 may be
implemented. The computing system environment 1300 is only one
example of a suitable computing environment and is not intended to
suggest any limitation as to the scope of use or functionality of
the invention. Neither should the computing environment 1300 be
interpreted as having any dependency or requirement relating to any
one or combination of components illustrated in the exemplary
operating environment.
[0108] The tournament-style gaming scenario exploration system 200
and method is operational with numerous other general purpose or
special purpose computing system environments or configurations.
Examples of well known computing systems, environments, and/or
configurations that may be suitable for use with the
tournament-style gaming scenario exploration system 200 and method
include, but are not limited to, personal computers, server
computers, hand-held (including smartphones), laptop or mobile
computer or communications devices such as cell phones and PDA's,
multiprocessor systems, microprocessor-based systems, set top
boxes, programmable consumer electronics, network PCs,
minicomputers, mainframe computers, distributed computing
environments that include any of the above systems or devices, and
the like.
[0109] The tournament-style gaming scenario exploration system 200
and method may be described in the general context of
computer-executable instructions, such as program modules, being
executed by a computer. Generally, program modules include
routines, programs, objects, components, data structures, etc.,
that perform particular tasks or implement particular abstract data
types. The tournament-style gaming scenario exploration system 200
and method may also be practiced in distributed computing
environments where tasks are performed by remote processing devices
that are linked through a communications network. In a distributed
computing environment, program modules may be located in both local
and remote computer storage media including memory storage devices.
With reference to FIG. 13, an exemplary system for the
tournament-style gaming scenario exploration system 200 and method
includes a general-purpose computing device in the form of a
computer 1310.
[0110] Components of the computer 1310 may include, but are not
limited to, a processing unit 1320 (such as a central processing
unit, CPU), a system memory 1330, and a system bus 1321 that
couples various system components including the system memory to
the processing unit 1320. The system bus 1321 may be any of several
types of bus structures including a memory bus or memory
controller, a peripheral bus, and a local bus using any of a
variety of bus architectures. By way of example, and not
limitation, such architectures include Industry Standard
Architecture (ISA) bus, Micro Channel Architecture (MCA) bus,
Enhanced ISA (EISA) bus, Video Electronics Standards Association
(VESA) local bus, and Peripheral Component Interconnect (PCI) bus
also known as Mezzanine bus.
[0111] The computer 1310 typically includes a variety of computer
readable media. Computer readable media can be any available media
that can be accessed by the computer 1310 and includes both
volatile and nonvolatile media, removable and non-removable media.
By way of example, and not limitation, computer readable media may
comprise computer storage media and communication media. Computer
storage media includes volatile and nonvolatile removable and
non-removable media implemented in any method or technology for
storage of information such as computer readable instructions, data
structures, program modules or other data.
[0112] Computer storage media includes, but is not limited to, RAM,
ROM, EEPROM, flash memory or other memory technology, CD-ROM,
digital versatile disks (DVD) or other optical disk storage,
magnetic cassettes, magnetic tape, magnetic disk storage or other
magnetic storage devices, or any other medium which can be used to
store the desired information and which can be accessed by the
computer 1310. By way of example, and not limitation, communication
media includes wired media such as a wired network or direct-wired
connection, and wireless media such as acoustic, RF, infrared and
other wireless media. Combinations of any of the above should also
be included within the scope of computer readable media.
[0113] The system memory 1340 includes computer storage media in
the form of volatile and/or nonvolatile memory such as read only
memory (ROM) 1331 and random access memory (RAM) 1332. A basic
input/output system 1333 (BIOS), containing the basic routines that
help to transfer information between elements within the computer
1310, such as during start-up, is typically stored in ROM 1331. RAM
1332 typically contains data and/or program modules that are
immediately accessible to and/or presently being operated on by
processing unit 1320. By way of example, and not limitation, FIG.
13 illustrates operating system 1334, application programs 1335,
other program modules 1336, and program data 1337.
[0114] The computer 1310 may also include other
removable/non-removable, volatile/nonvolatile computer storage
media. By way of example only, FIG. 13 illustrates a hard disk
drive 1341 that reads from or writes to non-removable, nonvolatile
magnetic media, a magnetic disk drive 1351 that reads from or
writes to a removable, nonvolatile magnetic disk 1352, and an
optical disk drive 1355 that reads from or writes to a removable,
nonvolatile optical disk 1356 such as a CD ROM or other optical
media.
[0115] Other removable/non-removable, volatile/nonvolatile computer
storage media that can be used in the exemplary operating
environment include, but are not limited to, magnetic tape
cassettes, flash memory cards, digital versatile disks, digital
video tape, solid state RAM, solid state ROM, and the like. The
hard disk drive 1341 is typically connected to the system bus 1321
through a non-removable memory interface such as interface 1340,
and magnetic disk drive 1351 and optical disk drive 1355 are
typically connected to the system bus 1321 by a removable memory
interface, such as interface 1350.
[0116] The drives and their associated computer storage media
discussed above and illustrated in FIG. 13, provide storage of
computer readable instructions, data structures, program modules
and other data for the computer 1310. In FIG. 13, for example, hard
disk drive 1341 is illustrated as storing operating system 1344,
application programs 1345, other program modules 1346, and program
data 1347. Note that these components can either be the same as or
different from operating system 1334, application programs 1335,
other program modules 1336, and program data 1337. Operating system
1344, application programs 1345, other program modules 1346, and
program data 1347 are given different numbers here to illustrate
that, at a minimum, they are different copies. A user may enter
commands and information (or data) into the computer 1310 through
input devices such as a keyboard 1362, pointing device 1361,
commonly referred to as a mouse, trackball or touch pad, and a
touch panel or touch screen (not shown).
[0117] Other input devices (not shown) may include a microphone,
joystick, game pad, satellite dish, scanner, radio receiver, or a
television or broadcast video receiver, or the like. These and
other input devices are often connected to the processing unit 1320
through a user input interface 1360 that is coupled to the system
bus 1321, but may be connected by other interface and bus
structures, such as, for example, a parallel port, game port or a
universal serial bus (USB). A monitor 1391 or other type of display
device is also connected to the system bus 1321 via an interface,
such as a video interface 1390. In addition to the monitor,
computers may also include other peripheral output devices such as
speakers 1397 and printer 1396, which may be connected through an
output peripheral interface 1395.
[0118] The computer 1310 may operate in a networked environment
using logical connections to one or more remote computers, such as
a remote computer 1380. The remote computer 1380 may be a personal
computer, a server, a router, a network PC, a peer device or other
common network node, and typically includes many or all of the
elements described above relative to the computer 1310, although
only a memory storage device 1381 has been illustrated in FIG. 13.
The logical connections depicted in FIG. 13 include a local area
network (LAN) 1371 and a wide area network (WAN) 1373, but may also
include other networks. Such networking environments are
commonplace in offices, enterprise-wide computer networks,
intranets and the Internet.
[0119] When used in a LAN networking environment, the computer 1310
is connected to the LAN 1371 through a network interface or adapter
1370. When used in a WAN networking environment, the computer 1310
typically includes a modem 1372 or other means for establishing
communications over the WAN 1373, such as the Internet. The modem
1372, which may be internal or external, may be connected to the
system bus 1321 via the user input interface 1360, or other
appropriate mechanism. In a networked environment, program modules
depicted relative to the computer 1310, or portions thereof, may be
stored in the remote memory storage device. By way of example, and
not limitation, FIG. 13 illustrates remote application programs
1385 as residing on memory device 1381. It will be appreciated that
the network connections shown are exemplary and other means of
establishing a communications link between the computers may be
used.
[0120] The foregoing Detailed Description has been presented for
the purposes of illustration and description. Many modifications
and variations are possible in light of the above teaching. It is
not intended to be exhaustive or to limit the subject matter
described herein to the precise form disclosed. Although the
subject matter has been described in language specific to
structural features and/or methodological acts, it is to be
understood that the subject matter defined in the appended claims
is not necessarily limited to the specific features or acts
described above. Rather, the specific features and acts described
above are disclosed as example forms of implementing the claims
appended hereto.
* * * * *