Project 3 — The Coffee Shop Conversation

“My grace is sufficient for you, for my power is made perfect in weakness.” — 2 Corinthians 12:9

Chapter: 3 — Asking Questions: Conditionals Due: End of Week 3 Submit: A link to your code — an OnlineGDB project URL or a public GitHub repo URL — with coffee_shop.cpp as the main source file. See Appendix D for the full workflow. Allowed tools: Everything through Chapter 3 — types, arithmetic, cin/cout, if/else if/else, boolean operators, switch, nested conditionals. Not yet allowed: Loops, functions you define yourself, arrays. (You can compile with them if you want to be ambitious, but the rubric doesn’t require them.)

The Setup

You’re at a coffee shop. A friend you’ve known for years — someone you respect, someone who respects you — sets their cup down and asks you the question.

“If God is good, why is there so much suffering in the world?”

You can hear in their voice that this isn’t a debate move. Something happened. You don’t know what yet, but you can tell it’s real.

This is the conversation. Your program models it.

A direct word before you start: this project will not produce an ending where you “win” the debate or “convert” your friend. That’s not how real conversations about real suffering go, and a program that pretends they do is a worse witness than no program at all. The endings you’ll write are honest ones:

• The conversation goes deeper. You both leave thoughtful.
• You stumbled, but were honest about it.
• You said “I don’t know” and your friend respected it.
• You got defensive. The moment closed.
• The conversation was interrupted by something more pressing — and that was okay.

You are not building a debate flowchart. You are building a model of how this question is actually engaged in real rooms by real people who care about each other. Aim for that, and the conditionals will earn their keep.

Learning Targets

By completing this project, you will demonstrate that you can:

• Write a multi-step program with conditional logic that branches based on user input.
• Use if/else if/else to model multiple-choice decisions.
• Combine boolean expressions with && and ||.
• Track and use boolean flags to gate later branches on earlier choices.
• Use a switch statement appropriately.
• Design a program that reads naturally out loud, like a script.

Normal Tier

Goal: A short interactive scene with at least three decision points. Each decision branches the conversation. At least one branch ends in a thoughtful, honest outcome.

Required features

1. Opening scene. Print a short narrative setup (2–4 sentences) establishing the coffee shop, the friend, and the question. Use multi-line cout for narrative blocks.

2. At least three decision points. Each one:

   • Prints a 1–3 sentence “what does your friend say” or “what’s the situation” narration.
   • Presents 2–4 numbered options for what you say.
   • Reads the user’s choice (an int).
   • Uses if/else if/else (or switch) to print the consequence of that choice.

3. At least one ending must be “thoughtful, no winner.” Examples that qualify:

   • “You both sit with the question for a moment. Your friend nods, eventually, and the conversation moves on. You make plans to talk again next week.”
   • “You don’t have a clean answer. You say so. Your friend appreciates the honesty more than you expected.”
   • “You realize halfway through that your friend doesn’t want a debate — they want to be heard. You shift, and the conversation gets quieter and more honest.”

4. At least one ending must reflect a stumble. Honest stumbles include:

   • “You launched into a stock apologetic before your friend finished talking. They smile and let you finish, but the moment is gone.”
   • “You got defensive when your friend pushed back. Later you’ll wish you’d just listened.”

5. No “you converted your friend” endings. No “your friend was persuaded by your reasoning and confessed Christ.” That ending is theologically off and dramatically false. Don’t write it. The grader will mark you down if you do.

6. Compiles cleanly with -Wall -Wextra enabled in OnlineGDB compiler settings (or g++ -Wall -Wextra if you build locally). No warnings, no errors.

Example flow (you’re not required to match this exactly)

*** The Coffee Shop ***

Your friend sets down their cup and looks at you for a second. Then:
"If God is good, why is there so much suffering?"

You can:
  1. Ask what brought this up.
  2. Offer a quick answer.
  3. Sit with the question for a moment before responding.

Choice: 1

Your friend pauses. "My uncle just passed. It was bad."

You can:
  1. Express sympathy and let them keep going.
  2. Move into the theological question.

Choice: 1

[...continues until an ending]

--- Ending: You Both Went Deeper ---

You spent the next twenty minutes just listening. The question
about God came up again — but quieter, less debate-shaped.
You made plans to keep talking. The conversation isn't over.
That's okay.

Grading rubric — Normal (out of 100)

Medium Tier (+up to 25% extra credit)

Pick any one for partial credit, all three for full Medium.

M1. Nested conditionals

At least one of your decision points must use a nested if — a follow-up question that only makes sense given a prior answer. For example, if the user chose to ask what brought up the question, the follow-up branches based on the friend’s response. If the user chose to give a quick answer, the follow-up doesn’t.

Use nesting where it reflects the actual shape of the conversation. Don’t nest just to nest.

M2. Two boolean flags

Track at least two bool flags across the conversation. Examples:

• friend_shared_pain — true if the user asked, and the friend mentioned something specific.
• you_acknowledged_it — true if the user, after hearing it, expressed sympathy before moving on.

Later branches gate on combinations of these flags. For example, the “you both went deeper” ending might require both flags to be true. The “you launched into apologetics too fast” ending might require friend_shared_pain == true && you_acknowledged_it == false.

The flags should affect what endings the user can reach. The dialog should feel like decisions actually mattered.

M3. One switch statement

Use at least one switch to handle a decision point with 3+ options. The switch should feel natural — the right tool for that specific decision. Not every decision point should be switch-based; just one.

Hard Tier (+up to 25% additional extra credit)

The Hard tier asks for depth in the model of the conversation, not surface complexity in the code. A great Hard tier project is one where a sensitive reader looks at your endings and thinks: “Yeah. That’s a real outcome. I’ve seen that one.”

H1. Six decisions, five distinct endings

Build a scene with at least 6 decision points and at least 5 distinct endings. The endings should differ meaningfully — not just “good ending” vs. “bad ending,” but distinct flavors of how a conversation can land:

• The conversation goes deeper, both quieter.
• You stumbled but were honest.
• You said “I don’t know” and your friend respected it.
• You both ended up more confused, but in a good way — the kind of confusion that signals real engagement.
• You got defensive. The moment closed.
• The conversation was interrupted (a phone call, a coworker walked in). Maybe okay, maybe regret.
• You quoted a verse that was what the moment called for. (This is allowed. It’s also rare.)
• You quoted a verse that wasn’t. (This is also allowed. And honest.)
• Your friend revealed they’d been thinking about Christianity for a while. The conversation became something neither of you expected, but not in a “and then they prayed the sinner’s prayer” way.

Endings must depend on combinations of choices, not on single decisions. At least two endings should require specific combinations of &&-joined conditions to reach.

H2. The “stats” check

Track an integer score across the conversation — call it friend_warmth or mutual_understanding or whatever fits. Each decision adjusts it (+1 for “you listened,” -1 for “you cut them off,” etc.). At the end, one of the ending checks is something like (friend_warmth >= 4). This gates a specific ending — perhaps “you make plans to keep talking” — that requires accumulated good moves across the whole conversation, not any single choice.

Use compound boolean expressions in the final dispatch — e.g., ((friend_warmth >= 4) && you_acknowledged_pain && !you_got_defensive).

H3. The flex move

Find one C++ feature we haven’t covered and use it deliberately. Strong candidates this week:

• getline(cin, response) to let the user type free-form responses at a key moment (then ignore the text, but acknowledge they typed).
• A const variable for an ending threshold so the magic number isn’t scattered.
• The boolalpha manipulator (carried from Chapter 2) used to print the flag state in a “debug mode” controlled by another flag.

Document in your README per the same rules as Project 1 H4.

Submission

Submit one URL via the course portal:

• OnlineGDB project link (recommended for Coding 1 and Coding 2). Create your project at onlinegdb.com, set compiler flags to -Wall -Wextra in the project settings, build your solution, and share the link. See Appendix D for the full workflow.
• GitHub repo link (optional). If you’ve set up local development on your own, push the source to a public repo and submit that URL. You’re responsible for making sure the code compiles when the grader checks it out.

What the linked project must contain

1. The main source file — coffee_shop.cpp — containing your full solution.
2. A reflection comment block at the very top of that file:

/*
 * Tier targeted:    Normal / Medium / Hard
 * Features done:    list each feature you completed
 * What I learned:   one short paragraph (no bullets)
 * What I'd change:  one sentence
 * AI usage:         where and how, if any. Be honest.
 */

3. The program left in a “demonstrable” state — when the grader presses Run, the features for your targeted tier should be exercised. Hard-code inputs at the top of main() (or pre-fill OnlineGDB’s Stdin panel) so the grader doesn’t have to guess what to type.

That’s it. No separate demo.txt. No screenshots. The instructor will open your link, read the comment block, run the program, and grade against the rubric.

Coach’s Note — Coding 1 and Coding 2 focus on writing code, not managing development environments. If something behaves oddly, you and the grader are looking at the exact same browser-hosted environment — there are no “works on my machine” defenses by design. Coding 3 will introduce a local toolchain properly.

Hints

• “My program always reaches the same ending.” Likely one of: (a) a missing else, so multiple branches fire; (b) an = where you meant ==; (c) braces missing so a body that shouldn’t always run does.
• “I don’t know how to track flags.” Declare them as bool at the top of main(), initialized to false. Inside a branch that should set them, write friend_shared_pain = true;. At the ending, read them as conditions.
• “My endings are stacking — I get two endings printed at once.” Use if/else if/else if/else so exactly one ending fires. Or wrap the ending dispatch in its own block and return 0; after one fires (an early exit).
• “I’m not sure how to write a ‘thoughtful, no winner’ ending.” Read it back to yourself out loud. Does it sound like a real human conversation that you would believe? If yes, ship it. If no, rewrite. The litmus test is believability, not cleverness.
• “How long should this take me?” Normal: 1–3 hours, mostly spent writing the dialog and endings, less on the code. Medium: 2–4 hours. Hard: 4–8 hours.

What Mastery Looks Like

A great Project 3 reads like a thoughtful person actually wrote it. The dialog is specific. The endings are believable. The user doesn’t feel railroaded into any one outcome — every choice they made affected where they ended up.

A great Project 3 takes the theological weight of the question seriously. It doesn’t trivialize suffering. It doesn’t treat the friend as a debate dummy. It doesn’t claim more for the apologetic toolkit than the apologetic toolkit can deliver.

A great Project 3 has clean code under the dialog. The if/else if cascades are well-ordered. The flags are named positively. The switch (if used) is break-disciplined. A reader could scan your .cpp file and follow the dialog flow without running it.

You’re not being graded on theology. You’re being graded on whether your conditionals do honest work in service of a hard conversation. Aim for that.

When You’re Done

1. Read your own coffee_shop.cpp aloud, all of it, including the dialog. Where does it sound fake? Fix those lines.
2. Run it three times, picking different paths each time. Hit at least three endings.
3. Update your README to reflect what you actually built and which endings you reached.
4. Submit.
5. Read Chapter 4. Repetition starts.

Coach’s Note — This is the project where the apologetics frame of the course either earns its keep or doesn’t. If you treat it as a serious exercise in modeling a hard conversation — not “what’s the smart answer?” but “what’s the honest answer for the person in front of me?” — you’ll learn something that doesn’t fit on a rubric. That’s the goal. The grade is downstream.

See you on Monday.