The TV Game show “Deal or No Deal”, is played with up to 26 boxes, each containing randomly assigned sums of money. You claim one box at the start of the game, without its contents being revealed. You then choose other boxes, one at a time, that are immediately opened and removed from play. Throughout the game, you are offered an amount of money or prizes to quit, being asked the question, “Deal or no deal?” If you reject every deal and eliminate all the other boxes, you keep the money that was in the original box. Thus, you “win” depending on whether the you should have taken one of the deals or should have held onto the original box until the very end.
When I build a new game, such as a casino or TV game show game, I search for a similar game online; that way I can play the game and really understand how it works. With Deal or No Deal, I found several websites that offered a free version of this game, and I modeled my audio version after that website.
The first step in a game laying out the screens. Since there are 25 boxes, I knew I would need a list of 25 items where you select a box: the first box would be entitled “Box 1”, the second “Box 2” and so on. Even though the Blindfold Games are audio games, there is still a screen component that is spoken to you as you play.
Next, the game needs to know what phase of the game is being played. There are five phases in this Deal or No Deal. Phase 1: claiming the initial box. Phase 2: rejecting a number of boxes. Phase 3: being asked the question “deal or no deal”. Phase 4: answering that question. Phase 5: revealing what was in the final box. The game starts with phase 1, moves through multiple occurences of phases 2, 3 and 4, and finishes with phase 5.
I assign gestures to each of the major actions of the game. Swiping up and down lets you navigate the list of boxes, and you select a box by double tapping. When you are asked “deal or no deal”, you swipe left to reject or right to accept the deal.
Implementing the rules of the game in each phase is fairly straightforward. For example, the programming code would have rules such as “If I am in phase 1 and you double tap on a box, consider that box to be your original box” and “If I am in phase 2 and you double tap on a box, reject that box.”.
That’s usually enough to get version 1.0 of the product ready to be tested. I write up an initial user guide, identify things in the game still unfinished, and then send it out to 50 testers for their feedback.
Once I resolve all the problems found by the testers, and implement all of their recommendations, I add sounds and music. In Blindfold Deal or Not, that means including crowd sounds when you find out if your choices were lucky or not. I’ll usually include about 5 variants of each type of sound, so the game does not get predictable. For example, if you missed out on a large prize, you’ll hear the audience sympathize with you. As the box is opened to reveal its contents, you hear the sound of a box being ripped apart.
One of the challenges in Blindfold Deal or Not was computing how much the banker would pay you to give up your box. I tried to determine the banker’s algorithm by playing the online version of the game, but ended up researching the problem on Wikipedia.
Here’s what I found:
There are several theories concerning the algorithm that the banker uses to determine the appropriate bank offer. Naturally, this is a secret held by the various TV Game Show publishers around the world, however a number of people have approximated the algorithm with various levels of accuracy.
Statistical studies of the US version of the show were undertaken by Daniel Shifflet in 2011, and showed a linear regression of bank offers against expected value. He found that the bank would offer a percentage of the expected value of the remaining cases, and this percentage increased linearly from approximately 37% of expected value at the first offer to approximately 84% of expected value at the seventh offer.
You can download Blindfold Deal or Not here: