Concepts and Content

Students will:

• Apply core MATLAB programming concepts — loops, conditionals, arrays, and user I/O.
• Use randomization to model uncertainty and simulate decision-making under risk.
• Calculate and interpret expected value as a measure of fairness or optimal strategy.
• Connect computational modeling to real-world processes: probability, optimization, and decision analysis.

Higher-Order Thinking Skills

Students will:

• Design and evaluate algorithms for banker offers and game logic.
• Synthesize programming concepts into a cohesive, functioning simulation.
• Analyze outcomes to compare strategies, assess fairness, and interpret probabilistic behavior.
• Reflect critically on how code models human decision processes and uncertainty.

Other Skills Developed

Students also practice:

• Technical writing in a short reflection describing algorithm design and decision logic.
• Problem-solving and debugging to refine program structure and accuracy.
• Data visualization and creativity through optional features, such as tracking values or plotting outcomes.

This activity is designed for introductory programming or computational modeling courses in mathematics, engineering, computer science, or related STEM fields. It is appropriate for college-level students, typically at the freshman or sophomore level, but can also be used in upper-division courses as a creative reinforcement exercise.

The project works best as a lab-based or short programming project assigned after students have been introduced to basic MATLAB syntax and logic structures. It generally requires one to two class periods (2–3 hours), with additional time outside of class for testing, debugging, and writing the reflection.

No special equipment is needed beyond access to MATLAB or MATLAB Online. The activity can be completed on personal computers or in a computer lab setting, and it adapts easily for in-person, remote, or hybrid instruction.

Students should already be comfortable with:

• MATLAB variables, arrays, and simple functions
• Control structures (for, while, and if/else statements)
• User input/output commands (input, fprintf)
• Random number generation (rand, randi)

This activity is typically situated midway through a course once students have practiced foundational programming concepts and are ready to apply them in an integrated, real-world simulation. It provides an engaging context for students to model uncertainty, make algorithmic decisions, and practice reflective reasoning about probability and computation.

Because the theme is familiar and adaptable, instructors can easily modify the complexity by adjusting the number of cases, the banker's formula, or the level of required output and visualization, making the activity suitable for a range of course formats and student experience levels.

Game Requirements

1. Setup

• There are 15 briefcases (or another reasonable number — as long as it's greater than 10).
• Each case is randomly assigned a money value from a predefined list:

                                values = [0.01, 1, 5, 10, 25, 50, 75, 100, 200, 500, 750, ... , 1000, 5000, 10000, 25000];

• The user selects one case to "hold" at the start of the game.

2. Rounds

• In each round, the user opens a set number of unopened cases (e.g., 3 in Round 1, 2 in Round 2, then 1 per round afterward).
• After each round, the program calculates a banker's offer.
  • This could be the mean of remaining case values multiplied by a factor (e.g., 0.75).
• The program should then prompt the user to accept or reject the banker's offer.
  • Example prompt: Deal or No Deal?
  • If the player accepts, the game ends, and the deal value is reported.
  • If the player rejects, the game continues to the next round.

3. End of Game

• If the user rejects all offers and only two cases remain (their chosen one and one more), both are revealed.
• The program reports:
  • What the player won
  • What was in the other case

4. Optional Features (Extra Credit)

Enhance your program by adding one or more of the following:

• Track and display which case numbers are still in play
• Show values that have been eliminated
• Plot remaining values after each round (e.g., using bar or stem)
• Add simple graphics or text-based UI elements
• Customize the number of cases, case values, or round structure

What to Submit

1. deal_or_no_deal.m – Your main MATLAB script
2. deal_project_report.pdf – A short write-up that includes:
   • A brief description of your program design and banker strategy
   • One or two screenshots of your game running
   • Your reflection (see below)

Reflection Guidelines 

The reflection helps you connect your code to broader computational and mathematical ideas.
In a short essay (approximately one page), address the following prompts in your own words:

1. Algorithm Design:
   • Describe one key programming decision (e.g., how you randomized the cases or designed the banker's offer).
   • Why did you make this choice, and how does it affect the gameplay or the fairness of the simulation?
   • What debugging challenges did you encounter, and how did you solve them?
2. Probability and Decision-Making:
   • How does your program model uncertainty and randomness?
   • Does the banker's offer seem "fair"? How might you change the logic to make it more realistic?
   • If you ran the game multiple times, what trends did you notice in the outcomes?
3. Connections to STEM Concepts:
   • Deal or No Deal has been used to study real decision-making under risk (Post et al., 2008; de Roos & Sarafidis, 2010).
   • How does your simulation serve as a simple computational model for decisions involving probability, optimization, or risk?
   • What parallels can you see between this game and real-world problems in math, physics, engineering, or computer science?
4. Reflection and Improvement:
   • If you had more time, what would you add or change in your code?
   • How could you expand this simulation to include strategy testing or visualization of expected value over many trials?

KeyNoDeal -- educator-only file

Hide

• Introduce the Game Context:
  Some students may not be familiar with the game show Deal or No Deal. Begin by showing a short clip (1–2 minutes) or explaining the premise: players select a case, open others, and decide whether to accept a banker's offer. This helps students visualize the program flow and understand what their simulation should model.
• Start with Pseudocode or Flowcharts:
  Encourage students to outline the logic before coding. Having them write pseudocode or sketch a flowchart helps those with less programming experience break down the project into manageable steps (setup, rounds, offer calculation, user decision, end of game). Consider walking through a partial pseudocode example as a class.
• Scaffold the Coding Process:
  Students can begin by coding the randomization and setup first, then progressively add rounds, user input, and banker logic. Framing the activity as a series of milestones prevents students from feeling overwhelmed and provides natural checkpoints for feedback.
• Encourage Debugging Strategies:
  Remind students to use disp() or fprintf() statements to track variables and confirm that cases and values are behaving as expected. Debugging is an important part of computational problem-solving, and this activity provides good practice in testing and logical tracing.
• Support Different Experience Levels:
  For students new to programming, provide a template script with input/output prompts and case initialization pre-written. Advanced students can explore enhancements like adjusting the banker's offer dynamically, adding graphics, or tracking probabilities.
• Highlight Modeling and Analysis:
  After students complete their code, guide a short discussion:
  • How does the banker's formula affect fairness?
  • What happens when the randomness or multiplier changes?
  • How might this simulation relate to modeling risk or uncertainty in engineering or data science?
    This reflection reinforces higher-order thinking and connects the game to broader STEM contexts.
• Time Management:
  Instructors may allocate one lab period (75–90 minutes) for the initial build and debugging, with another class or homework session devoted to testing and reflection writing.
• Common Student Challenges:
  • Forgetting to remove opened cases from the remaining list.
  • Misplacing parentheses in the mean or randomization calculation.
  • Getting stuck in an infinite loop if user inputs are not validated.
    Sharing these in advance or discussing common debugging tips can reduce frustration.
• Encouraging Reflection:
  After completing the project, have students share or compare strategies in small groups before writing their individual reflection. Peer discussion often deepens understanding of algorithmic design and probability reasoning.

Deal or No Deal MATLAB Project Rubric

Total: /100 points

• Post, Thierry; van den Assem, Martijn J.; Baltussen, Guido; Thaler, Richard H. (2008). Deal or No Deal? Decision Making under Risk in a Large-Payoff Game Show. American Economic Review 98(1): 38–71. DOI: 10.1257/aer.98.1.38. American Economic Association+2ResearchGate+2
• Korsós, László; Polson, Nicholas G. (2011). Analyzing Risky Choices: Q-Learning for Deal-No Deal. arXiv preprint arXiv:1110.0883.
• "Deal or No Deal." (2024). Wikipedia. Retrieved 10/28/2025, from https://en.wikipedia.org/wiki/Deal_or_No_Deal