Project 8 — MIDTERM: Mission Trip Simulator

“Iron sharpens iron, and one man sharpens another.” — Proverbs 27:17

Chapter: 8 — Midterm Review When: In class, 75 minutes — one full class session (your instructor may use 60–90) Submit: A link to your code — an OnlineGDB project URL or a public GitHub repo URL — with mission_trip.cpp as the main source file. See Appendix D for the full workflow.

Allowed during the exam:

• The textbook itself (printed or non-interactive PDF).
• Your own past project files, if you brought them in a printout or on a USB drive.
• The compiler and a basic editor.

NOT allowed:

• Internet.
• AI assistants of any kind.
• Anyone else’s code.
• Communication with another person during the exam window.

The Setup

It’s the last week of a one-week mission trip. You have a small team — a leader, a medic, a builder, a teacher, and an encourager. Each person has finite energy. They wake up, do devotions, work, eat, debrief, sleep. They need to make it through the week.

This is the kind of system you’ve already practiced in lots of small shapes: an array of structs (Players, Citizens, Manuscripts, Evidence), updated phase by phase, with summary statistics at the end. You’re not doing anything new on this midterm. You’re combining seven chapters of skills in one program.

The thematic frame (mission trip) doesn’t change the technical content. If the word “mission trip” doesn’t speak to you, mentally substitute “service week,” “summer camp,” “church camp staff week,” whatever fits. The code is the same. The data is the same.

What You’re Building (Normal Tier)

A complete program that:

1. Defines a TeamMember struct with these fields (at least):

   • string name
   • string role (one of: "leader", "medic", "builder", "teacher", "encourager")
   • int energy (starts at 100, can go up or down)

2. Initializes an array of exactly 5 team members at the top of main(). Use real-sounding names. The roles should cover all five listed above (one of each).

3. Runs a fixed 4-phase day in this order. The exact energy deltas depend on each member’s role:

   • Devotion (morning) — every member’s energy goes up by 5.
   • Work — energy goes down by work_cost(role) (see below). Different roles cost different amounts.
   • Meal — every member’s energy goes up by 10.
   • Rest (evening) — every member’s energy goes up by 8.

4. Implements int work_cost(const string& role) that returns the per-role work cost:

   • "leader" → 10 (coordinates rather than carrying)
   • "medic" → 12
   • "builder" → 18 (heavy physical work)
   • "teacher" → 10
   • "encourager" → 8
   • anything else → 15 The work phase function calls work_cost once per member and subtracts the returned int from that member’s energy. This is the chapter-3 conditional / chapter-5 return-value test, by design.

   Use if/else if/else for the role check — switch only works on integral types in C++, not strings.

5. Prints a per-member energy report at the end of the day, with each member’s name, role, and final energy. The report also prints the most-energetic and least-energetic member at end of day (use int find_highest_index(const TeamMember[], int) and int find_lowest_index(...) — chapter-6 find-pattern functions returning indices).

6. Uses functions — at minimum, one function per phase: void devotion(TeamMember team[], int count), void work(...), void meal(...), void rest(...). Plus a void print_report(const TeamMember team[], int count) that internally calls find_highest_index and find_lowest_index.

7. Compiles cleanly with -Wall -Wextra enabled. No warnings.

8. print_report is called once at end of day. (Optional: also call it between phases for debugging; the rubric only requires the end-of-day call.)

Example output (rough — your exact format can vary)

=== Mission Trip Day Simulator ===

Starting energies:
  Maya (leader):       100
  Marcus (medic):      100
  Lin (builder):       100
  Jonah (teacher):     100
  Sade (encourager):   100

[Phase: devotion]
[Phase: work]
[Phase: meal]
[Phase: rest]

End-of-day report:
  Maya (leader):       113
  Marcus (medic):      111
  Lin (builder):       105
  Jonah (teacher):     113
  Sade (encourager):   115

  Most energetic: Sade (encourager, 115)
  Least energetic: Lin (builder, 105)

Normal-tier rubric (out of 100)

Medium Tier (+up to 25% extra credit)

M1. Exhausted check

After every phase, check whether any member’s energy fell below 10. If so, mark them as “skipped next phase.” Track skipped phases in a new int field on TeamMember: int phases_skipped = 0;. A skipped member’s energy is unchanged during the phase they skipped. They re-enter at the phase after.

After the day, the report should also print “phases skipped: N” per member.

M2. Two-day simulation

Run the whole 4-phase day twice, with a “good night’s sleep” reset between days that returns every member’s energy closer to their starting value (e.g., regenerate by 20 toward 100). Report end-of-week stats — accumulated energy delta per member.

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

H1. Variable-length week

Ask the user for the number of days to simulate. Run the 4-phase day that many times. Track aggregate week stats per member: total phases skipped, lowest energy reached, average end-of-day energy.

H2. Random events

Each day, before the phases start, roll a “day type”:

• 60% of days: normal.
• 25% of days: “team breakthrough day” — everyone gains +10 energy.
• 15% of days: “hard conversation day” — everyone loses 12 energy.

Use rand() from <cstdlib>. Don’t worry about seeding it perfectly — srand(42) at the top of main is fine, and makes your demo reproducible.

Print the day type at the start of each day.

H3. Weekly summary report

After the variable-length week, print a comprehensive summary:

• Most-rested team member (highest accumulated energy across all phases).
• Most-overworked team member (lowest minimum energy reached during the week).
• Recommendation: a one-line text suggestion based on the data (“Lin needs a rest day,” “Marcus is steady; rotate someone else to medical work,” etc.).

Use functions cleanly. Don’t pack all this into main.

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 — mission_trip.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 (Read These Before the Exam, Not During)

• “I don’t know what shape to put my code in.” Use the menu-loop / phase-loop pattern from Chapters 5–7. Functions per phase, called in order from a run_day() function or directly from main.
• “My functions don’t change the team.” Pass-by-reference. The signature void work(TeamMember team[], int count) works because arrays effectively pass by reference. The individual team[i] modifications stick.
• “I’m running out of time.” Submit what you have. A working Normal that doesn’t attempt Medium beats a half-finished Hard. The rubric rewards completion of lower tiers over partial completion of higher ones.
• “I’m panicking.” Read the prompt out loud once. Then write the struct. Then write main with hardcoded data. Then write one phase function. Then call it. Then add the next phase. The first compiled output is the hardest. After that you’re just adding features.

Coach’s Note on Exam Day

The students who pass this exam have done two things: (1) the reps before the exam, and (2) one full timed practice run.

If you haven’t done a timed practice run, do Drill 5 in the exercises right now, even if you’re reading this two hours before the exam. The discipline of writing the same shape of program under a clock changes how your fingers move in the actual exam.

In the exam room: start with the struct definition. Get it on the page. Then main. Then one function. Compile early, compile often. The compiler is on your side. Use it as a tight feedback loop.

The midterm is a project. Treat it like one.

See you on the other side. Chapter 9 begins the second half of the course.

A theological footnote (confessional Lutheran framing). This midterm is not a verdict about who you are. In confessional Lutheran terms, our standing before God is established by Christ — not by what we can do under the lights. What the midterm measures is the stewardship of the time and attention you’ve given to the craft so far: how well your training has taken root, where the gaps are, and what to keep practicing. Submit honest work. Receive an honest grade. Both are stewardship.