INTERACTIVE SCENARIO EXPLORATION FOR TOURNAMENT-STYLE GAMING
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.
Latest Microsoft Patents:
- APPLICATION SINGLE SIGN-ON DETERMINATIONS BASED ON INTELLIGENT TRACES
- SCANNING ORDERS FOR NON-TRANSFORM CODING
- SUPPLEMENTAL ENHANCEMENT INFORMATION INCLUDING CONFIDENCE LEVEL AND MIXED CONTENT INFORMATION
- INTELLIGENT USER INTERFACE ELEMENT SELECTION USING EYE-GAZE
- NEURAL NETWORK ACTIVATION COMPRESSION WITH NON-UNIFORM MANTISSAS
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.
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.
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.
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.
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.
SUMMARYThis 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 1st in the league, or for some other player to place 3rd, 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.
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 1st, etc).
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.
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.
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.
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).
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.
Referring now to the drawings in which like reference numbers represent corresponding parts throughout:
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 TerminologyA 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.
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.
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.
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
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 OverviewThe 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
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.
As shown in
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.
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 DetailsEmbodiments 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 ModuleThe 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.
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).
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.
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×(K−1) entries. There are many ways in which the prediction module can estimate prior probabilities and populate this prior probability table.
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.
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 ModuleThe 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-ModuleEmbodiments 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.
The N-bit bracket representation is a Y-bit integer, where Y is greater than or equal to N (Y≧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.
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
In order to better illustrate the N-bit bracket representation,
Referring to
Referring again to
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 (23), 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):
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.
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.
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 CalculationIn 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.
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.
There are limits, however, to the exhaustive prediction. In particular, the number of possible tournament outcomes is 2X, 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 263 (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 PredictionWhen 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
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.
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).
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
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
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-ModuleThere 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).
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
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.
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.
Referring back to
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
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.
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
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.
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
Embodiments of the accumulator sub-module 270 compute and keep a running total of statistics relating to the generated brackets.
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.
These counters for user placements are a P×P table, where P is the number of users. So, User 1 has a counter for coming in 1st, 2nd, 3rd, 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.
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.
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 ModuleFor 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.
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 3rd 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).
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 2nd 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 2nd round.
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.
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 EmbodimentsThere 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.
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.
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.
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 EnvironmentEmbodiments 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.
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.
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
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.
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.
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.
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,
The computer 1310 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only,
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.
The drives and their associated computer storage media discussed above and illustrated in
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.
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
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,
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.
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≧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.
Type: Application
Filed: Dec 28, 2007
Publication Date: Jul 2, 2009
Applicant: Microsoft Corporation (Redmond, WA)
Inventors: Desney S. Tan (Kirkland, WA), Gregory R. Smith (Bellevue, WA), Yuval Peres (Redmond, WA), Joseph Yossi Azar (Redmond, WA), Eyal Lubetzky (Bellevue, WA)
Application Number: 11/965,772
International Classification: A63F 9/24 (20060101);