Group Project 1: Terminal Applications

'F' → Fullscreen

Choose Your Route

You have five working programs behind you — Number Guessing, Rock Paper Scissors, Heads or Tails, the Dungeon Crawler, and a quiz built on parallel lists. Most teams should build on those rather than starting over. Three build sessions is not long, and a program that already runs is a real head start.

Route 1: Build On What You Already Made

Two ways to do this, and you can mix them.

Grow one program. Take something you built and make it genuinely bigger. The Dungeon Crawler is the obvious candidate — more rooms, an inventory that holds several items, enemies with health, a map you can look at. It started as nested conditionals; there is a lot of room above that.

Combine several into one. Put your games behind a single menu — an arcade, a casino, a game night. The player picks what to play, plays it, and comes back to the menu.

If you combine, give it a wallet. One variable holding the player's money, that every game pays into and takes from. That single shared value is what makes your project one program instead of four programs sitting in a folder, and it is the difference a grader will notice first. Track the player's history in a list while you are at it — what they played, what they won.

Route 2: Start Something New

Fair game, and some teams should. You get no head start, so be honest about the three build sessions before you commit.

A terminal game. Any terminal-friendly game: turn-based, puzzle, choose-your-own-adventure, or something entirely your own. It needs a clear win/lose condition, real player choices that matter, and enough state tracking (score, health, inventory, branching paths — your call) that playing it twice doesn't feel identical.

A utility application. A program that solves a real, specific task for a real kind of user. It needs to do more than one simple calculation — think a menu system with a few related features, and data that builds up over the course of a run.

A good idea starts specific, not a topic. "A sports app" isn't a project — "a program that tracks a team's win/loss record across a season and calculates their winning percentage" is. Pick one real thing to track, calculate, or organize.

Some starting points (you don't have to use these):

• A school-subject helper (grade calculator, flashcard quiz app)
• A specific sports stat tracker (season win/loss record, points-per-game average)
• A budget or allowance tracker
• A workout or habit log

Both routes are graded against the same four criteria. Route 1 is not the easy option and Route 2 is not the ambitious one — a lazily grown Dungeon Crawler and a half-finished original idea score about the same, which is to say badly.

What "Success Criteria" Means

A success criterion is a specific, checkable thing your finished program must do. Not a feeling ("it should be fun" or "it should work well") — something you could point at when the project's done and say yes or no.

Not checkable: "The game should be fun and challenging."

Checkable: "The player can lose all their lives and see a Game Over message with their final score."

Write 4–6 of these for your project before you start building. They're what Criterion D evaluates you against at the end.

Meeting the Complexity Bar

Your finished program needs to genuinely combine what this unit taught — not just show off one skill in isolation. At minimum:

• Conditionals (if/elif/else), including nested ones if your concept calls for it
• At least one loop, chosen for the right reason — while for something that repeats until a condition changes, for for counting or traversing a list
• Real list usage — traversal, the accumulator pattern, membership checking, or parallel lists. One hardcoded list that never gets processed doesn't count.

If you took Route 1, some of that is already true on day one. So there is a second bar that applies to you:

Name what your program can do that it could not do before. Your success criteria should describe new capability — a wallet that carries between games, an inventory that holds more than one item, a history the player can look back at, a difficulty setting that actually changes play.

The trap to avoid: renaming variables, changing the printed text, and swapping the theme. That is not growth, and it is obvious from the outside. The question is never how different it looks — it is what it can now do.

One Honest Warning About Size

You do not know how to write functions yet — that is Activity 2.5, next quarter. Until then, everything lives in one file, driven by one menu loop and a chain of elif branches.

That is completely fine for three or four games. It gets genuinely unpleasant at six, when you are scrolling for two minutes to find the branch you meant to edit. Plan for three or four, done well. If your program starts feeling impossible to navigate, that is not you being bad at this — it is the exact problem functions were invented to solve, and you will meet them soon enough.

The MYP Criteria, In This Project

• A — Inquiring and Analysing: your idea, who it's for, 1–2 similar games/apps you looked at, and your success criteria. On Route 1 this includes saying which of your programs you started from and why that one.
• B — Developing Ideas: a feature plan (what/why/how for each feature — not strict pseudocode) and a menu flowchart.
• C — Creating the Solution: the actual working program, meeting the complexity bar above. On Route 1, what gets judged is what you added — so hand in your starting code too.
• D — Evaluating: a test plan, feedback from someone outside your group who tried it, and an individual reflection from each student.

Full grading detail is in the rubric your instructor provides, along with a student checklist you should keep with you the whole project.

Task Journal

Every work session (or every couple of days if you work outside class), log a short entry: what you worked on, who did what, any blockers, and what's next. Your instructor will give you a template. Fill it in as you go — a journal reconstructed from memory the night before it's due doesn't show your real process, and it'll be obvious.

Timeline

Roughly 2–2.5 weeks, depending on how much time is left in the quarter. A rough shape to aim for:

• Early: pick your track and idea, research, write success criteria, plan your features and flowchart
• Middle: build — this is where most of your time goes
• End: test against your success criteria, get outside feedback, write your individual reflections

What You'll Turn In

• Your problem statement, similar-products notes, and success criteria
• Your feature plan and menu flowchart
• Your finished, working program
• On Route 1: the program you started from, unchanged, so the difference is visible
• Your test plan and outside playtester feedback
• Your task journal
• An individual reflection from each group member

Meet with your group, pick a route, and start with your problem statement.