About the expectation value

[KFC]

Hi all,
I am creating a game for fun, which need some math skill to work out the chance of winning and the way to keep the banker never lose. The configuration of the game is like this: five boxes marked no.1, no.2, no.3, no.4 and no.5; there are many balls in different color in each box. For each game cost 1 token to play. Player drawing one ball from each box from no.1 to no.5. If player get 5 red balls, he/she will be given 1250 tokens as reward.

The chance to get 1 red ball from no.1 box is 10%
The chance to get 1 red ball from no.2 box is 80%
The chance to get 1 red ball from no.3 box is 50%
The chance to get 1 red ball from no.4 box is 30%
The chance to get 1 red ball from no.5 box is 20%

Based on my understanding from stat class, the expectation of winning this game is

$0.1*0.8*0.5*0.3*0.2*1250 \text{(tokens)} = 3 \text{tokens}$

This means on average players will win 3 tokens back. The banker add a new rule to the game that if player get 4 red balls from no.2, no.3, no.4 and no.5 box, he/she could draw one ball once from the no.1 box again (with the drawn ball put back to the box) by paying extra tokens. This sounds good chance for player since three is 10% of chance to win 1250 tokens in this case. However, in order not to lose, banker must increase the extra token for redraw. I am thinking how many tokens should be asked for. My first thought, since the expectation of winning 5 red balls in 3 (tokens), each redraw should cost 3 tokens to compensate that. I did the simulation, running the game for 10000000 times with proper drawing probability for red ball in each box. It turns out the expectation value is very close to 3 (without redraw); however, with redraw case, if I ask 3 tokens as extra cost, it gives expectation of 5.42 instead of 3. So asking 3 tokens for redraw is not correct to balance the lose. There must be something I don't understand correctly from my math. Any one could give me some hints on that. Thanks

 

[StoneTemplePython]

Have you tried drawing a tree / applying total expectation?

It seems to me that you charge 3 tokens for the based game, and overall it's a fair game. You want to layer an option in where the 'near miss' case occurs when ball 1 misses but everything else hits. Let's make sure that option is fairly priced too -- in the option scenario, you have a 10% chance of of winning 1250 tokens and otherwise nothing, hence expected value of the option is $125$. Charge for this. (Note I assume this is actually an option / incremental decision faced by the player given a sequence of events in game, like choosing whether to buy insurance in blackjack...)

The above are guidelines for so called 'fair' pricing. This does not mean that the banker will 'never lose' -- in particular there are a lot of subtleties involved for even money games, and even somewhat tilted games, as to whom -- banker or player-- will run out of money / be 'ruined' first.

 

[KFC]

Hi there,
Thanks for the reply. Your comment give me some hints on how to view the problem in different aspect. But I found that there is an issue in the number I gave since it will cause the expectation value (without redraw) to over 1, which means the player have advantage to win in long term while the banker will lose. Let me change the numbers a bit, let's assume all the chance to draw a red ball from the box unchanged but it only wins 400 tokens when 5 red balls obtained. In this sense, the expectation value (without redraw) is 0.96, so for long term, the player will lose about 4% of his total input. From your hint, I am trying to compute the new expectation of redraw, which give 400*0.1 = 40. Now if I use this in the simulation, the total expectation after playing the game 10 millions times is a bit higher than 0.96. So I think the "fair price" for draw may not be 40 since I want the bank edge stay in 96%, I would like to use 400*0.1/0.96 = 41.66666667 as the new redraw price. And from simulation, that gives me almost the same expectation (95%) with or without redrawing. The result looks good to me but I don't know if logic correct or not. If above computation is right, which concludes that the "fair price" should be computed as

fair price = (probability of obtaining red ball in redraw) x the pay for 5 red ball) / expectation value (without redraw)

Now if I change the rules, allows more wins by different obtaining 5 same color ball (green, blue, red ... etc.), each have different chance to draw and different pay, obviously, expectation value (without redraw) should take all cases with color ball into account, for example, on each box, probability to get red, blue green ball are

red: 10% 50% 30% 20% 10% pay: 180
blue: 20% 30% 40% 40% 50% pay: 120
green: 70% 10% 30% 40% 40% pay: 100

total expectation without redraw is 0.966

Now the same game rule, if player saw 4 blue one, fair price = 0.2* 120 / 0.966

But it seems not correct because 0.966 is overall expectation for all color balls but in above case, player already know the only possibility to win is for blue ball, so should I use the expectation value of blue ball (without redraw) 0.576 instead of 0.966?

 

[StoneTemplePython]

Hi there,
Thanks for the reply. Your comment give me some hints on how to view the problem in different aspect. But I found that there is an issue in the number I gave since it will cause the expectation value (without redraw) to over 1

I'm not sure what this means. I've confirmed that $0.1*0.8*0.5*0.3*0.2*1250 \text{(tokens)} = 3 \text{tokens}$

and I don't see an expectation in the neighborhood of 1 anywhere? I'd strongly suggest sticking with the model you original specified and flushing out the details in it -- for starters what exactly is this issue you're speaking of?

It seems premature to complicate the model at this point and add a bunch of different calculations and scenarios -- the main idea is to figure out what a fair game 'looks like'. Again, what is the issue with the simple game you outline in the original post? My view is you should be drawing a tree (or possibly a directed graph), recognize that you need to price each branch at fair value, and make sure you are doing this correctly. Once this is pinned down, it should be straightforward to add more features/ branches later on as you see fit.