Interactive scenario exploration for tournament-style gaming

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.

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.

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 1^st in the league, or for some other player to place 3^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.

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^st, 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).