WO2015168749A1

WO2015168749A1 - Rtp management in skill based gaming

Info

Publication number: WO2015168749A1
Application number: PCT/AU2015/050229
Authority: WO
Inventors: Robert Fong; Lukie Ali
Original assignee: Royal Wins Pty Ltd
Priority date: 2014-05-08
Filing date: 2015-05-08
Publication date: 2015-11-12

Abstract

A method and system for managing RTP in a multiplayer, skill basing gambling system is disclosed. A target RTP is set. Based on periodic calculation of the actual RTP, game parameters are varied in order to make the actual RTP approach the target value.

Description

RTP MANAGEMENT IN SKILL BASED GAMING

Technical Field

[0001 ] The present invention relates to the management of the return to player in skill based gaming systems.

Background of the Invention

[0002] Skill based gaming is a form of electronic gaming, in which the return to players is based at least partly upon the skill of the player. This is in contrast to conventional slot games, in which the software is configured to ensure that no possible skill or technique used by the player influences the game outcome, only chance.

[0003] Skill based games may have a large or small component of skill. There may be reward of increased status, medals, features and the like in addition to the winnings from wagers placed by the player on the game outcome.

[0004] One particular difficulty faced by game designers and operators is that the return to player (RTP) may be very volatile. A large number of highly skilled players on a strongly skill based game may result in a very high average RTP, exceeding 100% of wagers. On the other hand, if a game is predominantly played by relatively low skilled players, the RTP may be very low. The latter is also not desirable, as players may become discouraged and not continue to play the game.

[0005] These issues are not faced by a purely chance driven game, as the game mathematics are known and fixed, and over time will return statistically at the planned level. In a skill based game, the designer can only estimate the difficulty, so that the same certainty of overall outcomes for the operator cannot be guaranteed with mathematics alone.

[0006] It is an object of the present invention to provide a skill based game in which average RTP volatility can be managed automatically.

Summary of the Invention

[0007] In a first broad form, the present invention provides a system in which a sample of game outcomes over time is assessed for the average RTP achieved. If it is too high or too low, game parameters are changed for a period to compensate for the low or high RTP. This process accordingly allows for the average RTP to be managed while a skill based game is in operation.

[0008] According to one aspect, the present invention provides a method of automatically managing RTP within a multiplayer electronic gambling game, the game including at least a component of skill and a random component, wherein players make wagers and play the game, the game having one or more game play parameters which can be adjusted, wherein the average RTP of the game over a plurality of players is calculated, and in response to the calculated average RTP, one or more of the game play parameters are automatically adjusted to increase or decrease the expected RTP, so as to approach a predetermined average RTP value.

[0009] According to another aspect, the present invention provides a multiplayer electronic gambling system, including a least one game having including at least a component of skill and a random component, wherein players make wagers and play the game, the game having one or more game play parameters which can be adjusted automatically by said system, wherein the system is adapted to calculate the average RTP of the game over a plurality of players, and in response to the calculated average RTP, said system automatically adjusts one or more of the game play parameters are adjusted to increase or decrease the expected RTP, so that the RTP approaches a predetermined value.

[00010] Implementations of the present invention allow for the RTP to be averaged over many players, and in response, the game parameters to be adjusted, so that a desired target RTP can be approached. This allows for more predictable financial outcomes for an operator of skill based games, particularly those with a large skill component.

[00011 ] It is emphasised that the present invention is not concerned with the specific details of games themselves, how they are played, the rules of the game or similar aspects. The present invention is concerned with the operation of the system from the perspective of the operator, and how the system can automatically vary parameters to produce a desired RTP outcome.

Brief Description of the Drawings

[00012] An illustrative embodiment of the present invention will now be described with reference to the accompanying figures, in which:

Figure 1 shows a graph of possible returns for a first player option according to a first implementation;

Figure 2 shows a graph of possible returns for a second player option according to a first implementation;

Figure 3 shows a notional selection screen according to a first implementation;

Figure 4 shows a selection of an option according to a first implementation;

Figure 5 shows a notional first screen according to a first implementation;

Figure 6 shows another screen according to a first implementation;

Figure 7 shows another screen according to a first implementation;

Figure 8 shows another screen according to a first implementation;

Figure 9 a notional selection screen according to a second implementation;

Figure 10 shows a notional further screen according to a second implementation;

Figure 1 1 shows a notional further screen according to a second implementation;

Figure 12 shows a notional further screen according to a second implementation;

Figure 13 shows a notional further screen according to a second implementation;

Figure 14 shows a notional prize awarding screen according to a second implementation;

Figure 15 shows a secondary game outcome screen according to a second implementation;

Figure 16 shows a first notional graph of levels reached and prizes won;

Figure 17 shows a second notional graph of levels reached and prizes won;

Figure 18 shows a paytable curve showing prize value relative to number of prizes;

Figure 19 is a graph of notional cumulative average RTP against games played;

Figure 20 is another graph of notional cumulative average RTP against games played;

Figure 21 is flow chart illustrating an implementation of a method for managing RTP. Detailed Description of the invention

[00013] While the present invention will be described with reference to specific implementations, these are intended to be illustrative of the inventive concept, and not limitative. For example, many different types of games could be provided, with smaller or greater components of skill and chance. The games may be played against the system, or may be in partly or wholly against other players. The details of the game play at each level are not important to the overall concept which the following description seeks to describe and illustrate.

[00014] The present invention refers to a prize being won by the player. The prizes may be monetary, being actual funds or credits; free spins or free games; virtual prizes, such as clothing, accessories, tools, weapons, different player icons, or other in-game features; status increases for the player, points or awards which contribute to status or virtual rewards, or other tangible or intangible benefits. They may be combinations of two or more types of prizes. It will be appreciated that while implementations which alter in-game parameters such as game play probabilities may not be acceptable for a gambling game where the object is to win cash or the equivalent, particularly in certain regulated jurisdictions, these may be implemented in similar games where the player does not win money but rather virtual rewards. For example, these could be options to buy extra features in the game for cash. This type of game is widely implemented as an app based game for tablet and smartphones.

[00015] The games themselves could be of any type, but specifically contemplated for the purposes of the examples below is a game called Moji Mania. In this game, the player takes control of a Moji riding 1 of 4 hoverboards, wherein different hoverboards represent easy, medium, hard and nightmare difficulty. Each difficulty level has different top prizes that can be further changed by changing the amount bet. The easy level has the best board, easiest progression to later levels, lower entry wager, and lower prizes. The nightmare level has worst board, harder progression to later levels, higher entry wager and larger potential prizes. The goal is to knock the other opposing Moji(s) off the platform and into the lava to advance to the next level. Every level adds harder opponents and even extra opponents, making it more difficult to complete. Every level has an associated prize, and once the player loses, they win the prize for the last level they have completed.

[00016] The present invention will be described primarily with respect to an online game, accessed either via a conventional web interface, or via an app on a tablet, smartphone or other suitable device. However, the invention could be implemented in a gaming machine, or in any other suitable way. It is not dependent upon any particular platform or operating system.

[00017] A particular implementation of the present invention relating to Moji Mania will be described briefly below. It will be understood that the particular gameplay details are not important, and many types, themes, etc. could be used, with similar or quite different games at each level. The general approach is that a player progresses through game levels, and the potential prize is related to how many levels are completed. This may be by accumulation, a level based prize, or via a secondary game.

[00018] Figure 3 illustrates a notional screen for a first implementation of the present invention. This screen has a number of possible game selections, A to D. A is easy; D is difficult. For a constant wager, or a single game, the player can select which option to pursue. For example, the table under option A indicates that completing the first level will earn 1 credit, and completing 4 levels will earn 15 credits. The potential winnings progress through option B, C and D. For level D, completing all 4 levels will win 1000 credits, but this is very difficult.

[00019] Figure 4 illustrates that the player has selected game C. At figure 5, the left box indicates the status, and on the right is the prize meter. For this illustrative game, the prizes are purely credits, which are the equivalent of cash in the appropriate currency. This is purely for simplicity of explanation, and it will be appreciated that additional prize components can be added as discussed above.

[00020] In figure 5, the game C is started, and the potential prize of 5 is highlighted. The player then plays the first level of the game. At figure 6, it is indicated that the player has won, and progresses to level 2, with the prospect of winning another 10 credits. At figure 7, the player has won level 2, and progresses to level 3.

[00021 ] At figure 8, the player has lost. They therefore win 5 (from level 1 ) plus 10 credits (from level 2), for a total of 15. According to this implementation, the credits accumulate from level to level, and the player is assured of a particular prize if they complete a level.

[00022] Figures 1 and 2 illustrate examples of returns, based on a 21 level game. Figure 1 illustrates the potential wins (vertical axis) for completing certain levels, shown on the horizontal axis, for the hardest option, game D. Figure 2 illustrates the potential wins for a player of the easiest game, game A. It can be seen that the curve is much steeper for game D - a player must complete more levels in order to have a prospect of a large return. For game A, although the potential win is much smaller, it is much easier to get to the lower levels.

[00023] A further implementation will now be described, with reference to figures 9 to 15. According to this implementation, at the end of play, i.e. when a player runs out of lives, a secondary game determines whether the prize is paid or not. Further, the initial buy in price varies with the expected prize returns.

[00024] Figure 8 shows a screen at the start of play. The player has the option to select form four options, A to D, with increasing value of prizes that can be won. However, the buy in price also increases, from 10 to 100 credits between games A and D, with B and C intermediate. This allows for a skilled player to decide to make a larger wager, and potentially win a much larger prize.

[00025] Figure 10 shows where a player has selected game C. The screen shows a status screen on the left (where in practice the game itself is shown), an indicator of the game level that the payer has reached, and a prize meter. At present, this is empty, as the player has just commenced playing game level 1 , as indicated by the bottom rectangle being highlighted.

[00026] Figure 1 1 indicates that the player has won. In accordance with a predetermined pay table, 100 credits is added to the prize meter. At figure 1 1 , the player commences to play level 2. A cross is through level 1 , indicating that it is complete, and level 2 is highlighted in the level indicator. The prize meter shows that 100 credits has been added.

[00027] Figure 12 indicates that the player has completed level 2. They have accordingly has a further 500 credits added to the prize meter. The player then commences level 3.

[00028] At figure 13, the screen indicates that the player has not completed level 3, and has lost. The level indicator shows levels 1 and 2 as competed, and level 3 highlighted as being played. The prize meter shows 600 credits.

[00029] Figure 14 illustrates the operation of a secondary game. The prize meter outcome is not automatically won: the secondary game determines whether the prize is won or not. In this implementation, the secondary game is a simple simulated reel game with four reels. These are spun, and to win, must indicate the word OPEN from left to right across the reels, but in any position on the reels. In this case, the reels (shown below the prize meter) indicate the word OPEN, and the player wins.

[00030] The chance of winning the secondary game forms part of the RTP, along with the difficulty of each level and the credits won by completing it. Thus, prizes can be relatively large if the secondary game is unlikely to be won. In one implementation, the chances of winning the secondary game generally increase, so that if all levels are completed, it is a certainty that all prizes are won.

[00031 ] It will be appreciated that the secondary game could be of any suitable type, employing any time of game. It is preferred that the game is a simple random game, and not skill based. For example, the type of secondary or bonus games conventionally used in slot games could be used, or a simple virtual card game.

[00032] Although in this implementation the whole prize was either awarded or not, the invention could be implemented so that partial prizes can be won, or that a percentage of the prize meter total is won.

[00033] The foregoing serves to explain the underlying game with which the present invention is concerned. It will be appreciated that over time, players will increase in skill, and their returns will improve, should the game parameters remain static. Implementations of the present invention provide a mechanism by which the game parameters can be automatically adjusted, so that the RTP over time remains within acceptable boundaries. This is achieved by periodically adjusting the game parameters, so that there are periods when the RTP may be higher or lower, but over time the desired RTP is approached. In order to conform with regulations in most jurisdictions, it is necessary that the parameters adjusted are only in relation to prizes, and the implementations below are in this context. However, it will be appreciated that in other jurisdictions, implementations are possible in which the underlying probabilities within the game are changed to manage the RTP, and the present invention encompasses such implementations.

[00034] The game, with many players, will operate for a predetermined period of time, or alternatively, a predetermined number of games. The RTP could be calculated after every game, but in practical terms for a large multiplayer game, this is more likely to be a longer period. The appropriate frequency is dependent upon the level of activity in a particular game, and the volatility of the outcomes in that game. In a preferred form, the period or number of games (or similar parameter) can be adjusted by the operator.

[00035] The software within the game server (or alternatively another device to which the data is communicated) takes a snapshot of the player wagers and returns over the period, and thereby can calculate an average RTP. Adjustment of the RTP can occur by changing either the prizes awarded, or the odds of winning a secondary game in which prizes are awarded.

[00036] Where multiple skill level options are provided, it is necessary to adjust the RTP across each level, both for reasons of fairness, and to ensure that the adjustments are correct for each difficulty level.

[00037] At the end of 5000 games, on a 20 level game, a plot of level reached and prizes won may look like figure 16. After another 5000 games, it may appear as in figure 17. It can be seen that many more players have progressed to higher levels, and hence large winnings per player, in figure 17 relative to figure 16. These graphs reflect very different RTP profiles, and demonstrate the importance of providing a mechanism to compensate dynamically for changing skill levels, in order to maintain a desired RTP level.

[00038] One approach to this is to adjust the prize table. At the end of each successful stage, a RNG (random number generator) is run on the Prize table, which has weighted odds for each possible prize. Each prize has a certain probability of being selected by the value generated by the RNG. The selected Prize is then transferred to the "Credit Meter", which accumulates the prizes from each stage that is completed by the player. Once the player has finished playing, typically by using up all their lives, the secondary game determines whether the prize in the prize meter is won (or which part of it, depending upon the implementation). Accordingly, when the prize table odds are adjusted, the expectation value of the prizes for each player of a given skill level is adjusted up or down, without interfering with the game play as such, or with the secondary game operation.

[00039] Where the prize per level is fixed, the adjusted values after the RTP analysis are applied to each level.

[00040] These prizes when plotted on a graph are expressed as:

Y = A^x + Bx, where A and B are arbitrary numbers.

[00041 ] "A" and "B" are modified after a predetermined number of games have been played, in order to adjust the prize curve, and hence average RTP, for subsequent games. Figure 18 illustrates a paytable curve for A of 1 .70 and B of 1 .20.

[00042] Figure 19 illustrates a notional graph of RTP, against games played. It can be seen that after 5000 games, the RTP is 235%. This is obviously not a desirable level long term for the operator, as the payouts are exceeding the wagers placed.

[00043] The software then will do an analysis, in order to adjust the RTP so that it tends towards 90%. It will be appreciated that the 5000 games have been played, so that only future parameters can be changed. Accordingly, it may be that in some implementations the intention may be to make the RTP somewhat lower, say 80%, for a period of time to compensate for the higher payout in a previous period, and vice versa when RTP is too low.

[00044] In this implementation, the Microsoft® Excel® goal seek function will be used. This allows an automated calculation of the parameters A and B required to achieve the desired RTP outcome, as the general formula is known as outlines above.

Formula

y = 1 .7^X + 1 .2x

YIELDS 235%

GOAL SEEK = 90%

A = 1 .4

New Formula for next 5000 games,

y = 1 .4X + 1 .2x

[00045] The next 5000 games are then run using values of A =1 .4 and B =1 .2 in the paytable formula. After the next 5000 games, it is possible that the RTP is now running perfectly at 90%. More likely, it will be greater or lesser than that the desired value, and further adjustments to A and B will be required.

[00046] For example, assume that the next 5000 game period yielded an RTP of for the next session of 140% instead of 90%. This is illustrated in figure 20. This implies that a more skilled group of players played the game since it is greater than the 90% target. A new "A" would then be calculated and the game operated for the next period with a target of 90%.

[00047] It would be expected that the player skill profile would eventually plateau, or that at least the rate of improvement would reduce. Eventually the RTP should move towards the target of

90%.

[00048] It will be appreciated that this specific curve is appropriate for this example, and an appropriate paytable curve would need to be selected which is suitable or the game in question.

[00049] The period of time, or number of games, selected is a matter for the operator. More frequent assessment ad sampling may reduce the volatility of changes, however, this may be misleading especially early in the introduction of a game, where it may be expected that skill levels will improve relatively quickly and so it may take some time for an accurate picture of the RTP trend to appear. On the other hand, it may be desirable to allow the RTP to be over target for an initial period, to encourage uptake of the game.

[00050] The frequency of the calculation of RTP can be varied by the operator, based in part upon the activity levels in the game. Instead of fixed time intervals, or fixed numbers of game cycles, the calculation could be triggered by other events, for example specific game play events (e.g. reaching highest level a certain number of times), a certain player winning more than a predetermined sum, or more frequent calculation if the RTP is further away from the target value.

[00051 ] In a preferred implementation, the RTP is further fine tuned over additional sample periods. For example, an assessment could be done after 10 sessions (e.g. 5000 games per session) in order to fine tune the large disparity of player skill. We will call this a check point, that is, 50,000 games.

[00052] An Average A and B value would be calculated as well as a resulting average RTP. So, at checkpoint 1 after 50,000 games, A=1 .5, B=1 .2, and RTP=120%.

[00053] Using the Microsoft® Excel® goal seek function, new values of A and B can be determined in order to yield 90% RTP based on the level of skill across the full set of 50,000 Games. Additional checkpoints could be established, for example:

[00054] Sessions = 5000 Games

[00055] Checkpoints = 10 x Sessions = 10 x 5,000 = 50,000 Games.

[00056] Checkpoint 1 B = 10 x Checkpoint 1 A = 10 x 50,000 = 500,000 Games.

[00057] Checkpoint 1 C = 10 x Checkpoint 1 B = 10 x 500,000 = 5,000,000 Games.

[00058] As more checkpoints are collected and assessed, adjustment of the A and B parameters will tend more and more to the desired level of 90% RTP.

[00059] An alternative calculation approach more directly assesses the difficulty of the game, and in particular the probability of the cohort of players reaching a given level. This may initially be based on a test sample of play, to provide starting data for the system. The test data is then used to create a prize table, which is dynamically adjusted after each session (as discussed above) so as to approach the target RTP.

[00060] The following formula may be used

Prize of Level X = Bet Amount/p(reaching Level X) x "SKILL COEFFICIENT (Z)"

[00061 ] For example, for Level 5, Bet Amount = $1 , p(reaching Level 5) = 20.38% (based on collected data), and Z = 0.0526315788. On this basis, the prize is $0.26

[00062] Z is a scaling constant which ensures that the RTP is not too large, which we will refer to as the skill coefficient.

[00063] The skill coefficient is calculated using the "Goal Seek" Function in MS Excel, as discussed above, to return an RTP that cause the average RTP over the session to tend towards the target value for RTP, based on the previous sample of player results. In this implementation, at the end of each session of checkpoint, RTP is updated.

[00064] So effectively will always be adjusted at each RTP checkpoint. The Skill Coefficient can be updated after every game or in batches of games. If updated after every game then the RTP will fluctuate less (than when updated every x amount of batch games) since adjustments to Z are done immediately.

[00065] A different approach to adjusting the RTP is to change the odds of winning the prize accumulated in the prize meter. As discussed above, in some implementations, at the end of play the player plays a secondary game in order to determine what prize, if any, has actually been won.

[00066] This provides a very simply implemented way of adjusting RTP, without interfering with the game play experience or the prizes at specific levels. Of course, this can be used in conjunction with the approach noted above to provide further levels of fine tuning. This may be particularly applicable where player skill has increased and the method described above is not able to provide the desired level of control. Combining the methods will tend to narrow the fluctuations in the RTP levels.

[00067] In the implementation discussed, with a 20 level game, the probability of winning the amount in the prize meter is generally fixed and is that same at all levels, except for the winner of the last level, who will win the prize in the meter.

[00068] If, however, the RTP was consistently returning an average RTP of 1 10%, the probability within the secondary game of winning the prize meter amount could be reduced.

[00069] The table below illustrates a change in the probability of a win of the amount in the prize meter, p(win), for various rounds.

RTP = 1 10% RTP=90%

[00070] The new P(WIN) amount should reduce the RTP towards 90%. If player skill drops then the rate at which it moves towards 90% would also slow. In this case a new P(WIN) amount and or "Prize Table" (value of A and / or B) would be recalculated and new values redeployed into the game.

[00071 ] It will be appreciated that these are examples of alterations to the game parameters which will correct the RTP towards a desired value. It is contemplated that other changes could also be instituted to the game to achieve this end, and these only provide specific examples applicable to the examples discussed. For example, the present invention is not limited in scope to level based games, and can be applied to simpler, single outcome type games.

[00072] The concept of managing RTP across a suite of players on a single skill based game could, of course, be applied to each skill level separately, where this was a selectable feature at the start of a game, or otherwise determined. Thus, the RTP for a group of players who opted for a more difficult version with a potential for higher reward could be managed separately from the RTP for the beginner level version.

[00073] Figure 21 is a flowchart illustrating the overall process as described above. At step 10, initial values for the probability of players reaching certain levels are determined, preferably using data from actual trial play, for example beta release data.

[00074] At step 1 1 , the process described in more detail above is used, with the goal seek function (or any suitable alternative calculation or modelling method) to obtain values for the various prize buckets, and from those at step 12 to calculate the prize values for each round or level. In the game example used, these are the prizes for each level, and for each difficulty level. [00075] At step 13, minimum and maximum prize values for the hardest or last level are set. These are parameters that the automated adjustment process cannot move beyond.

[00076] At step 14, after a certain number of games, in this case 10,000 (but in other implementations this could be smaller or larger) the overall average RTP to date is calculated. This is then used to calculate the target for the next set of games, for example 10,000, in order that the overall average RTP including the completed session and the next session will meet the target RTP value.

[00077] The RTP value for the next session is then processed at step 15, repeating the process above, the determine the new bucket values and then prize values for each level, and for each difficulty level. Step 16 indicates that this process is repeated to adjust the average RTP, with an expectation that after a sufficiently large number of games the average RTP will become relatively stable.

[00078] The concept of RTP management can also be applied across a whole set of games, whether related or not, to manage the games towards a desired goal RTP for the whole set or system of games.

[00079] Individual games will have their own RTP, which can be calculated at the end of sessions and checkpoints as discussed above. However, it is also important that the overall RTP of the system of games is within a desired range.

[00080] In the example below, there are 6 games A to F. The global RTP of the system = 82.23%.

Game Plays Total Coin In Total: Can Out RTP

A 50000 50000 39000 78,00%

B 2500 2500 2200 88.00%

C 65000 85000 54600 84,00%

D 42000 42000 36120 86.00%

E 5000 5000 4500 90.00%

F 22000 22000 16940 77.00%

186500 188500 153360 82.2»

[00081 ] In order to increase this Global RTP to 90%, then extra credits need to be rewarded to players outside of the scope of the normal game. A simple calculation can determine the amount of credits needed to be rewarded. This may be paid to all currently logged in players, or to all who were logged in within a certain time period.

Game Plays Tola! Coin In Totai Coin Out RTP

50000 50000 38000 78.00%

B 2500 2500 2200 m %

C 65000 65000 54600 84.00%

0 42000 42000 36120 86.00%

E 5000 5000 4500 90.00%

F 22000 22000 16940 77.00%

186500 186500 JL ? ~€ϊΟ 82.23%

167850 90.00%

Rewa ds M ti

[00082] In this example it can be seen that $14.490 needs to be paid out to players. The Rewards are funded by a Rewards Pool that sits adjacent to the entire game. [00083] This rewards pool preferable has an initial start up value, to begin paying the rewards to eligible players. This could be funded on an ongoing basis by a small percentage increment of all bets made, so that the fund is self sustaining.

[00084] To be self sustainable, the rate at which the fund increments needs to be greater than the rate at which rewards are disbursed. The rate of rewards is determined by the system RTP over the period for which it is calculated.

[00085] In one specific example, for every 10 minutes of being logged in to the system, on whatever game they have selected, the player receives a reward amount of credit. There is a maximum of 100 minutes to collect these credits/rewards. Therefore, players can receive a maximum of 10 x reward credits at one 100 minute logged in session.

[00086] The system will can instantly award the $14,490 in Remo Coins across all logged in players. The Global RTP will then be 90% within a few minutes of logged in players pressing collect to receive their share of the Bonus.

[00087] There are a several ways the loss in RTP can be adjusted via the reward credits, below is one example:

[00088] If the system RTP is less than 90%, then award the missing credit to all currently logged in players in one hit.

[00089] If the system RTP is less than 90%, then "Drip feed" the Award the missing $ to all players who clocks over 100 minutes worth of Remo in the next 24 hours.

[00090] If GLOBAL RTP > 90%, then award the minimum amount of $ as RTP is > 90%.

[00091 ] It will be appreciated that variations and additions within the general scope from the implementations described are contemplated and expected. The invention may be applied both to gambling games, and to non-gambling games conducted on a similar basis. It may be applied to a wide variety of game types and formats, and the specific examples provide in this regard should only be regarded as illustrative.

Claims

1 . A method of automatically managing RTP within a multiplayer electronic gambling game, the game including at least a component of skill and a random component, wherein players make wagers and play the game, the game having one or more game play parameters which can be adjusted, wherein the average RTP of the game over a plurality of players is calculated, and in response to the calculated average RTP, one or more of the game play parameters are automatically adjusted to increase or decrease the expected RTP, so as to approach a predetermined RTP value.

2. A method according to claim 1 , wherein the average RTP is calculated over a predetermined period or number of games, and the calculation is repeated after predetermined periods or numbers of games.

3. A method according to claim 1 or claim 2, wherein the game has a plurality of difficulty levels selectable by a player, and the average RTP is calculated and game play parameters adjusted for each difficulty level separately.

4. A method according to any one of the preceding claims, wherein the game play parameters which are adjustable are selected from one or more of adjusting the prize values, adjusting the probability of winning s secondary game, and adjusting parameters within the game playing operation of the game itself.

5. A method according to claim 1 , wherein the RTP is managed across a plurality of different games.

6. A method according to claim 5, wherein a portion of each wager is placed into a pool, so as to provide for periodical extra payments to players in order to maintain a desired global RTP across the plurality of games.

7. A multiplayer electronic gambling system, including a least one game having including at least a component of skill and a random component, wherein players make wagers and play the game, the game having one or more game play parameters which can be adjusted automatically by said system, wherein the system is adapted to calculate the average RTP of the game over a plurality of players, and in response to the calculated average RTP, said system automatically adjusts one or more of the game play parameters are adjusted to increase or decrease the expected RTP, so that the RTP approaches a predetermined value.

8. A system according to claim 7, wherein the average RTP is calculated over a predetermined period, and the calculation is repeated after predetermined periods.

9. A system according to claim 7 or claim 8, wherein the game has a plurality of difficulty levels selectable by a player, and the average RTP is calculated and game play parameters adjusted for each difficulty level separately.

10. A system according to any one of claims 7 to 10, wherein the game play parameters which are adjustable are selected from one or more of adjusting the prize values, adjusting the probability of winning s secondary game, and adjusting parameters within the game playing operation of the game itself.

1 1 . A system according to claim 1 , wherein a plurality of games are provided by the system, and the overall RTP is managed to approach an overall target across the plurality of different games.

12. A system according to claim 1 1 , wherein a portion of each wager is placed into a pool, so as to provide for periodical extra payments to players in order to maintain a desired global RTP across the plurality of games.