We've spent a lot of time learning the individual building blocks of Ruby—arrays, hashes, loops, and classes. Now, it's time to actually glue them together. When I first started building CLI tools, I fell into a trap that I see almost every student hit when they try to build their first "game."

Thinking you need an "if" statement for every question

The most common mistake I see here is writing code that looks like a long, exhausting list of instructions. A learner will write puts "Question 1...", then a gets.chomp, then an if statement to check the answer. Then they copy and paste that entire block for Question 2, then Question 3, and so on. It looks something like this:

# The "Hardcoded Nightmare" approach
puts "What is the capital of France?"
answer1 = gets.chomp
if answer1 == "Paris"
  puts "Correct!"
  score += 1
end

puts "What is 2 + 2?"
answer2 = gets.chomp
if answer2 == "4"
  puts "Correct!"
  score += 1
end
# ... Imagine doing this 20 more times ...

This is what we call "WET" code (Write Everything Twice). It's a maintenance disaster. If you decide you want to change "Correct!" to "You got it!", you have to find and replace that string in twenty different places. It's tedious, and honestly, it's not how professional software is built.

Decoupling your data from your game logic

The secret to building a scalable quiz game is to separate what the game is asking (the data) from how it asks it (the logic). In Ruby, the most elegant way to do this is by using an Array of Hashes. Each hash represents a single "question object" containing the prompt and the correct answer.

Once your data is stored in a collection, you only need one loop to handle every single question, regardless of whether you have five questions or five thousand.

# The Professional approach
quiz_data = [
  { question: "What is the capital of France?", answer: "Paris" },
  { question: "What is 2 + 2?", answer: "4" },
  { question: "Which language are we learning?", answer: "Ruby" }
]

score = 0

quiz_data.each do |item|
  puts item[:question]
  user_answer = gets.chomp
  
  if user_answer.downcase.strip == item[:answer].downcase.strip
    puts "Correct!"
    score += 1
  else
    puts "Wrong! The answer was #{item[:answer]}."
  end
end

puts "Final Score: #{score}/#{quiz_data.length}"

Notice two small but critical things I did there: .downcase and .strip. Users are messy. They might type "Paris " with a trailing space or "paris" in lowercase. If you do a strict string comparison, those users get marked wrong even though they knew the answer. I've spent far too many hours debugging "incorrect" answers in my own early projects only to realize the user just hit the spacebar by accident. Always sanitize your input.

By moving the questions into an array, the logic stays lean. If you want to add more questions, you just add more hashes to the quiz_data array. You don't touch the loop at all. That's the power of decoupling.

📋 Practical Task

The Ruby Trivia Engine: A Dynamic Question-and-Answer System

Your task is to build a fully functional Command-Line Quiz Game. Instead of hardcoding your questions into the logic, you must use a data structure to drive the game.

Requirements:

• The Data: Create an array of at least five hashes. Each hash should have a :question key and an :answer key.
• The Engine: Use a loop (like .each) to iterate through your questions and prompt the user for input.
• Input Handling: Use .downcase and .strip on both the user's input and the stored answer to ensure the game isn't unfairly strict about capitalization or accidental spaces.
• Score Tracking: Maintain a running total of correct answers and display the final score (e.g., "You got 4/5 correct!") at the very end.
• User Feedback: Provide immediate feedback after each question, telling the user if they were correct or providing the right answer if they were wrong.