Fantasy sports leagues have become a hugely popular form of recreation and competition for sports enthusiasts. In general, fantasy sports leagues contain a number of fantasy teams, each team managed by a fantasy team owner. The role of an owner is to manage a virtual team of real life professional sports players and decide which players to sit, start, drop, add, and trade with other teams. The goal is to have the starting players on the fantasy team accumulate the most positive statistics (“stats”) in their real-life games. These accumulated stats are directly converted to fantasy points using a rotisserie-style scoring algorithm. The team with the most points at the end of the season is declared the winner of the league.
Rotisserie style scoring is accomplished by ranking all teams from 1 to N, where N is number of teams in league, for each stat category. For any given stat category (e.g. home runs (HRs), hits (H) and stolen bases (SB) for non-pitchers, or strikeouts (K) and wins (W) for pitchers in a fantasy baseball league), the first place team will get N points. The second place team will get N-1 points. This continues for each team in the league and is repeated for each stat category. The team points in most scoring systems are simply the sum of the team points in all stat categories combined.
To successfully manage a fantasy team, an owner must constantly examine different players and evaluate how they can contribute to the stats earned by the fantasy team. There are many different ways that owners try to value players. An owner can read news and notes, view player stats, and consume expert advice. There are also many types of player rankings that attempt to value players. Player rankings can be compiled programmatically by looking at historical stats and/or running simulations, or manually crafted by domain experts. These rankings are either general for all fantasy leagues, or customizable for a specific fantasy league, because each league may have different rules and a different scoring methodology or configuration. Additionally, these rankings usually have some subjective way to evaluate player performance (e.g. stats earned) and create a single ranking order. A typical process for making managerial decisions might be: (1) examine the rankings of players that are available but not currently on the team, (2) examine the rankings for players currently on the team and in the starting lineup, and (3) change the starting lineup to optimize the rankings of players in the lineup.
One problem with this approach is that fielding a team of players with optimal player rankings is not always the best way to try to win a rotisserie style fantasy league. The generic player rankings only provide a ranking of players based on the moment in time that the rankings are published, and rank players either according to position or according to selected stat categories. These rankings do not provide the owner or manager with rankings based on the ultimate criteria, points, and do not provide an assessment of how a particular player being considered for the team will affect the team's overall point totals. For example, suppose an owner's team is leading in HRs and expects to lead the league in HRs by a wide margin, but is close to other teams in SBs. When deciding whether to add player A and drop player B, the owner needs to understand that if adding player A causes HR totals to drop somewhat, but the team will still lead the league in HRs, no points are lost. However, if adding player A causes the team to add enough SBs to leapfrog other teams, points are gained. Thus, overall it makes sense to add player A and drop player B. In other words, because fantasy teams are ranked according to points only, it would be preferable for a fantasy owner to get an idea of how many points a player is expected to contribute to the team over the full season.
Therefore, it would be advantageous to provide a fantasy team owner with a tool for evaluating a player being contemplated for addition to a fantasy team in accordance with how that player is expected to affect the team's point total at the end of a season, which is the ultimate fantasy league measure of team success.
Embodiments of the invention concern the evaluation of players in the context of a fantasy sports league. A player value, personalized for a specific fantasy team, is generated for a particular player being contemplated for addition to the starting lineup of that team. This value informs a team owner how that player is expected to affect the fantasy points earned by the team at the end of a season, and allows the owner to make managerial decisions optimized for earning the most fantasy points and winning the fantasy league.
For example, at any point in a current season, in order to evaluate whether a fantasy team owner should add one player to the starting lineup of the team and drop another, player stat predictions are first used to predict end-of-season stats for the current starting lineup of a team. Historical and/or current league stat/point functions may then be used to determine how many points the team is expected to earn during the course of a full season based on the predicted end-of-season stats. The historical and current league stats may be utilized in accordance with a blending function, which gives more weight to historical league stats early in the current season, and more weight to current league stats later in the season. Next, projected stats for the player under consideration for being dropped may be subtracted from the current team predicted end-of-season stats, and the projected stats of the player under consideration for being added to the current team may be added to the current team predicted end-of-season stats. These revised team stat totals may once again be applied to the historical and current league stat/point functions to determine how many points the revised team is expected to earn during the course of a full season. The projected point totals for the original team may be subtracted from the projected point totals of the revised team to determine a difference or delta. This delta is the value of this specific transaction to this specific team. This calculation can easily be performed for all combinations of players available to be added or dropped to locate the highest value roster changes available. Similar calculations could be used to determine which players to start and which to put on the bench.
Trade values could be calculated in much the same way. Because a quantitative resulting trade value can be computed for each team involved in the trade, it can help identify good or bad trades for an owner. It can also identify trades that are either even, or at least benefit all teams involved.
This methodology is also applicable to drafting of players prior to the start of a fantasy league. When drafting, each player has some value to each team, and that value changes with each pick, in accordance with the players already picked for that team, and the remaining pool of players from which a player may be selected. In some embodiments, the algorithm may assume that a particular owner's team is populated with a lineup of average players with average statistics in each stat category for each position. The so-called average player for a particular position may be determined by averaging the statistics of all the players at that position that are expected to be drafted. The algorithm will then evaluate, for a possible draftee, how that draftee is predicted to impact the end of year points for the team. This may be accomplished by using the possible draftee's predicted stats along with the predicted stats for the average players on the team, which can be assumed to perform in an average manner throughout the season. As players are actually drafted, that player's stat predictions are used along with the stats of the remaining average players (the average player's stats are changed to reflect the average stats of all those players remaining that are expected to be drafted), and new average stats (and points) for the team are recomputed.
a illustrates exemplary current league stat and points data for a particular stat category at a particular point in the season according to embodiments of the invention.
b illustrates exemplary current league stats and points data for a particular stat category extrapolated out to a full season according to embodiments of the invention.
Embodiments of the invention are directed to the evaluation of players in the context of a fantasy sports league. A player value, personalized for a specific fantasy team, is generated for a particular player being contemplated for addition to the starting lineup of that team. This value informs a team owner how that player is expected to affect the fantasy points earned by the team at the end of a season, and allows the owner to make managerial decisions optimized for earning the most fantasy points and winning the fantasy league.
The present invention is applicable to so-called “draft and trade” game types and rotisserie scoring types. More generally, embodiments of the invention are applicable to any scoring system that is not a stat modifier scoring type.
The “other players” block 308 is comprised of the pool of available players from which a team owner can select to insert a player into the starting lineup. The pool of available players can be players on the team but not in the starting lineup (“on the bench”), players on other teams (that the owner can trade for), or free agents (players not on any team).
Block 310 represents the players on the owner's team that have been selected for the starting lineup. Because only players in a team's starting lineup can accumulate stats, a fantasy team owner must consider how each of these players is contributing to the stat totals of the team.
When considering whether to add a player from the “other players” block 308 to the players in the current starting lineup (block 310), the projected stat totals for the prospective player and the players that would remain in the starting lineup must be considered for the remainder of the season. The player stat predictions block 304 provides the projected stats for these players. A player's projected stats may be calculated using any number of methodologies, and provided along with some measure of the predictions' expected accuracy (e.g. an accuracy range between an upper and lower bound). This may be accomplished using standard deviations or other well-known methodologies. It should be understood that even the method of generating stats (automated equations, hand editing, etc.) may affect the accuracy.
Player stat projections may be based on the length of time for which the projection is needed. For example, stat projections may be needed for an entire season, in which case their expected accuracy may be low as compared to stat projections needed for the remainder of an ongoing season, in which case the projections are likely to become more accurate as actual stats are accrued and the end of the season draws near.
Some stat projection algorithms may receive as input a database of player statistics from the past, and consider factors such as each player's trends over the course of a season, who that player is playing, whether the game is a day or night game, whether the pitcher is right or left handed, and/or whether the game will be played on real or artificial grass, etc., and generate predicted stats for that player for one or more games or the remainder of the season. Another method for generating stat projections is to run simulation engines, taking into account the factors mentioned above, simulate one or more games many times and compute average stats for the games. One example of a source for baseball player stat predictions is The Bill James Handbook 2007, ACTA Sports 2007, ISBN: 0879463112.
In the revised lineup block 312, one or more players in the current starting lineup of a team (block 310) may be replaced with a new player selected from the pool of free players in the “other players” block 308. Each potential unique combination of players that form the revised lineup will produce a different projected stat total for the team at the end of the season. The team stat totals for each stat category are calculated by adding the current team stat totals to the projected stats for the players in the revised lineup.
The key question to be evaluated when choosing a player to add to the starting lineup of a team is which combination of players (resulting in different team stat totals) will maximize the number of fantasy points earned by the team at the end of the season. To answer this question, team points must be optimized according to an optimization function of the form:
team points=func(stat1 total, stat2 total, stat3 total, . . . )
where stat1 total, stat2 total, stat3 total, etc. are the projected team star totals for various stat categories as established by fantasy league rules. The result is the total team points projected to be earned by the team at the end of the season. The function may weight every stat category equally, in which case the team points may be computed as:
team points=points for stat1 total+points for stat2 total+points for stat3 total
In another embodiment, more weight may be assigned to one stat category as compared to another, in which case the team points may be computed as:
team points=A(points for stat1 total)+B(points for stat2 total)+C(points for stat3 total)
where A, B, C etc. are weighting factors. These functions are defined based on fantasy league rules.
In order to compute these projected team point totals, embodiments of the invention may utilize historical trends and/or current league standings. As mentioned above, a database of historical league stats and points for teams is provided at block 300. This database may contain stats and points for teams in the same league during one or more previous seasons, or may contain stats and points for teams in different leagues operated by the same fantasy league management provider (e.g. Yahoo!) during one or more previous seasons, and may even contain stats and points for teams in other leagues operated by different fantasy league management providers during one or more previous seasons.
In some embodiments, data may be collected from past leagues with scoring rules similar to those in the target league. Data for the number of points and the totals for each stat category for each team from all of the reference leagues may be compiled. For a specific stat category, this data should resemble an “S” curve when plotted as team points earned on the vertical axis, and team stat totals on the horizontal axis. Polynomial regression may be use to create an approximation function for the data.
In addition to historical league stats, a database of the current league's stats and points for each team may be provided (see block 302 in
After the optimization function is created, the team points equation is established, and projected player stats are made available, the historical and extrapolated current league stats may be used to determine exactly how many points any given player is expected to contribute to a specific team. The historical and extrapolated current league stats may be blended to optimize their accuracy.
Before the current season starts, there will be no data for the current league stat and point charts. In other words, there will be no data and no step function of current league stats and points for any stat category. In that case, in some embodiments of the invention the historical league stat and points data will be used. Thus, for example, if an owner has chosen his starters for his lineup but is now considering revising the lineup, only
Of course, the historical league stats represent data from previous seasons or different leagues, and do not represent how the current league's teams and players are performing, and how each team's performance is actually translating into points. As noted above, as the season progresses, the extrapolated current league stat and point charts become more like an S curve and may become a more accurate predictor of how stats will translate to points at the end of the season. Therefore, as the season progresses, in some embodiments of the invention more and more weight may be given to the extrapolated current league stats and points charts, and less and less weight should be given to the historical league stats and points charts. Eventually, by the last game of the season, most or all of the weight should be given the extrapolated current league stats and points charts, and little or no weight should be given to the historical league stats and points charts. During the middle part of the season, the historical and extrapolated current league stats and points charts may be used about equally. The ratio of usage of historical and extrapolated current league stats may be referred to herein as the blending function. In one embodiment, the ratio or percentage of usage of historical league data varies linearly from 100% to 0% as the season progresses from beginning to end, while the ratio of usage of extrapolated current league data varies linearly from 0% to 100% as the season progresses from beginning to end.
In addition to this linear weighting, weighting can be modified based on the accuracy of the stat predictions, if the accuracy can be determined. In other words, if the stat predictions were 100% accurate, then at any point in the season, the current league stats and points may be used exclusively. The formula might be: team points=(100-prediction accuracy)ƒhistorical stats(stats)+(prediction accuracy)ƒcurrent stats(stats), where prediction accuracy ranges from 0 to 100 and is a function of at least the percent of the season completed, ƒhistorical stats(stats) is a function representing historical team points as a function of stats for all stat categories, and ƒcurrent stats(stats) is a function representing current team points as a function of stats for all stat categories.
In other embodiments of the invention, however, only the historical league stats and points data may be used to predict the total team points at the end of the season.
With player stat predictions, historical league stats and points, and extrapolated current league stats and points data available, embodiments of the invention may be utilized to evaluate whether a fantasy team owner should add one or more players to the starting lineup of the team and drop one or more other players. To do this, player stat predictions are first used to predict end-of-season stats for the current starting lineup of a team. Historical and/or extrapolated current league stat/point functions (generally referred to herein as stats-to-points conversion data) may then be used to determine how many points the team is expected to earn during the course of a full season based on the predicted end-of-season stats. The historical and extrapolated current league stats may be utilized in accordance with a blending function, which gives more weight to historical league stats early in the current season, and more weight to extrapolated current league stats later in the season. Next, projected stats for the player or players under consideration for being dropped may be subtracted from the current team predicted end-of-season stats, and the projected stats of the player or players under consideration for being added to the current team may be added to the current team predicted end-of-season stats. These revised team stat totals may once again be applied to the historical and extrapolated current league stat/point functions to determine how many points the revised team is expected to earn during the course of a full season. The projected point totals for the original team may be subtracted from the projected point totals of the revised team to determine a difference or delta. This delta is the value of this specific transaction to this specific team. This calculation can easily be performed for all combinations of players available to be added or dropped to locate the highest value roster changes available. Similar calculations could be used to determine which players to start and which to put on the bench.
Trade values could be calculated in much the same way. Because a quantitative resulting trade value can be computed for each team involved in the trade, it can help identify good or bad trades for an owner. It can also identify trades that are either even, or at least benefit all teams involved.
Embodiments of the invention are also applicable to drafting of players prior to the start of a fantasy league. When drafting, each player has some value to each team, and that value changes with each pick, in accordance with the players already picked for that team, and the remaining pool of players from which a player may be selected. In some embodiments, the algorithm may assume that a particular owner's team is populated with a lineup of average players with average statistics in each stat category for each position. The so-called average player for a particular position is determined by averaging the statistics of all the players at that position that are eligible to be drafted. The algorithm will then evaluate, for a possible draftee, how that draftee is predicted to impact the end of year points for the team. This may be accomplished by using the possible draftee's predicted stats along with the predicted stats for the average players on the team, which can be assumed to perform in an average manner throughout the season. As players are actually drafted, that player's stat predictions are used along with the stats of the remaining average players (the average player's stats are changed to reflect the average stats of all those players remaining that are eligible to be drafted), and new average stats (and points) for the team are recomputed.
In
While embodiments of the invention have been described in terms of particular embodiments and illustrative figures, those of ordinary skill in the art will recognize that the embodiments of the invention are not limited to the embodiments or figures described. Although embodiments of the invention are described, in some instances, in the context of fantasy baseball, those skilled in the art will recognize that such terms are also used in a generic sense herein, and that embodiments of the invention are not limited to such systems.
Those skilled in the art will recognize that the operations of the various embodiments may be implemented using hardware, software, firmware, or combinations thereof, as appropriate, or in some embodiments may be implemented all or in part by a user performing the operations manually. For example, some processes can be carried out using processors or other digital circuitry under the control of software, firmware, or hard-wired logic. (The term “logic” herein refers to fixed hardware, programmable logic and/or an appropriate combination thereof, as would be recognized by one skilled in the art to carry out the recited functions.) Software and firmware can be stored on computer-readable media. Some other processes can be implemented using analog circuitry, as is well known to one of ordinary skill in the art. Additionally, memory or other storage, as well as communication components, may be employed in embodiments of the invention.
Computing system 700 can also include a main memory 708, such as random access memory (RAM) or other dynamic memory, for storing information and instructions to be executed by processor 704. Main memory 708 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 704. Computing system 700 may likewise include a read only memory (ROM) or other static storage device coupled to bus 702 for storing static information and instructions for processor 704.
The computing system 700 may also include information storage system 710, which may include, for example, a media drive 712 and a removable storage interface 720. The media drive 712 may include a drive or other mechanism to support fixed or removable storage media, such as a hard disk drive, a floppy disk drive, a magnetic tape drive, an optical disk drive, a compact disk (CD) or digital versatile disk (DVD) drive (R or RW), or other removable or fixed media drive. Storage media 718, may include, for example, a hard disk, floppy disk, magnetic tape, optical disk, CD or DVD, or other fixed or removable medium that is read by and written to by media drive 714. As these examples illustrate, the storage media 718 may include a computer-readable storage medium having stored therein particular computer software or data.
In alternative embodiments, information storage system 710 may include other similar components for allowing computer programs or other instructions or data to be loaded into computing system 700. Such components may include, for example, a removable storage unit 722 and an interface 720, such as a program cartridge and cartridge interface, a removable memory (for example, a flash memory or other removable memory module) and memory slot, and other removable storage units 722 and interfaces 720 that allow software and data to be transferred from the removable storage unit 718 to computing system 700.
Computing system 700 can also include a communications interface 724. Communications interface 724 can be used to allow software and data to be transferred between computing system 700 and external devices. Examples of communications interface 724 can include a modem, a network interface (such as an Ethernet or other network interface card (NIC)), a communications port (such as for example, a USB port), a PCMCIA slot and card, etc. Software and data transferred via communications interface 724 are in the form of signals which can be electronic, electromagnetic, optical or other signals capable of being received by communications interface 724. These signals are provided to communications interface 724 via a channel 728. This channel 728 may carry signals and may be implemented using a wireless medium, wire or cable, fiber optics, or other communications medium. Some examples of a channel include a phone line, a cellular phone link, an RF link, a network interface, a local or wide area network, and other communications channels.
In this document, the terms “computer program product,” “computer-readable medium” and the like may be used generally to refer to media such as, for example, memory 708, storage device 718, or storage unit 722. These and other forms of computer-readable media may store one or more instructions for use by processor 704, to cause the processor to perform specified operations. Such instructions, generally referred to as “computer program code” (which may be grouped in the form of computer programs or other groupings), when executed, enable the computing system 700 to perform functions of embodiments of the invention. Note that the code may directly cause the processor to perform specified operations, be compiled to do so, and/or be combined with other software, hardware, and/or firmware elements (e.g., libraries for performing standard functions) to do so.
In an embodiment where the elements are implemented using software, the software may be stored in a computer-readable medium and loaded into computing system 700 using, for example, removable storage drive 714, drive 712 or communications interface 724. The control logic (in this example, software instructions or computer program code), when executed by the processor 704, causes the processor 704 to perform the functions of embodiments of the invention as described herein.
It will be appreciated that, for clarity purposes, the above description has described embodiments of the invention with reference to different functional units and processors. However, it will be apparent that any suitable distribution of functionality between different functional units, processors or domains may be used without detracting from embodiments of the invention. For example, functionality illustrated to be performed by separate processors or controllers may be performed by the same processor or controller. Hence, references to specific functional units are only to be seen as references to suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organization.
Although embodiments of the invention have been described in connection with some particular embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope of embodiments of the invention is limited only by the claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognize that various features of the described embodiments may be combined in accordance with embodiments of the invention.
Furthermore, although individually listed, a plurality of means, elements or method steps may be implemented by, for example, a single unit or processor. Additionally, although individual features may be included in different claims, these may possibly be advantageously combined, and the inclusion in different claims does not imply that a combination of features is not feasible and/or advantageous. Also, the inclusion of a feature in one category of claims does not imply a limitation to this category, but rather the feature may be equally applicable to other claim categories, as appropriate.