Game for a Lost Treasure

Eric Heichelheim
In this lab I will walk through step by step how I will go about creating my final application project. First, I will open the Monty Hall problem for modification. Then I will make two frames before it: a welcome page with a play button, and a directions page with a continue-to-the-game button. I personally don’t feel the need to keep the amount of doors input because the game is quite the same with any number; all that changes is the amount of doors opened to reveal the bogus prize. So, I will take that out and delete the programming for it. Identifying one part of the programming that codes for a specific part is a challenge, but you might learn about the language and organization while doing it. Also in the programming, I will have to create commands for the buttons and stop commands so you can go advance to each frame at your convenience. Finally, I will change the art work so that it will have the theme of an ancient pyramid, with sarcophaguses instead of doors, mummies or zombies as the losing prizes and ancient treasure as the winning prize. Finally I will need to identify, finish and keep the coding for the simulation of many games.

Art:

I choose an adventurous ancient theme because it is original and creative; instead of doors, there are sarcophaguses, and one has ancient treasure, and the others have rotting mummies. This kind of art makes the game interesting, and draws the user in. By playing with the application, perhaps the user will be inclined to think about the mathematical probability behind the problem.
Math:

The mathematics behind the application lies in the probability within the brain-teasing problem. The Monty Hall problem is a misleading set-up that fools you into thinking the odds of winning are 1:1 when they are really 2:1, if you switch coffins. The set-up is if you try to win a prize behind one door by selecting it, and you are shown one of the two losing doors, then you have the choice of staying or switching. Applying probability visual aid to this problem we see three first branches: win, lose, and lose. If you choose one of the losses, and you stay, those are both losses. But if you were to switch, you’d win. If you choose win the first time, and stay, that’s a win. If you switch, you lose. So altogether that’s a 3-out-of-6 chance of winning, a 3-out-of-6 chance of losing. However, 2 of the 3 wins are indeed switching, therefore this tree diagram shows the greater chance lies in switching.
Programming:

The programming for this application consisted of a button code, starting the application, as well as the programming for next buttons, as we learned in "show me," and the button to start the actual game.

function gotoNextFrame(evt:MouseEvent):void {
if (currentLabel!="endFrame") {
txtLabel.text = (currentFrame + 1) + ": " + currentLabel;
gotoAndStop(currentFrame + 1);
}
}
btnStartGame.addEventListener(MouseEvent.CLICK, startClicked);

The most complicated part of the programming comes with the probability portion. Basically I used a series of coding around Math.random to spawn randomness when the program is deciphering which coffin is the winner. But this was already present.

correct=Math.floor(Math.random()*numDoors);
txtSwitchingProbability.text="P(winning by switching) = 0 (0 out of 0 trials)";
txtStayingProbability.text="P(winning while staying) = 0 (0 out of 0 trials)";