CSC 1001 — Lab 10: Build Your Own Text-Based Game

Work mode: Individual (you may ideate with classmates, but your requirements, pseudocode, and code should be your own)

Time expectation: This is the first lab this semester that you are not expected to finish during the scheduled lab time. Use the rest of lab to get as far as you can (through pseudocode, at minimum), and plan to finish the rest on your own before the due date.

Intro

You're going to design and build a simple text-based game that runs in the terminal. This lab pulls together everything we've built up all semester: variables, conditionals, loops, and functions. There is no single "correct" game — you're going to invent your own.

You are expected to use an AI agent as part of this process, but the idea for the game and the bulk of the code should be yours. Think of the AI as a coding partner you are directing, not a vending machine you're pulling a finished project out of. You should be able to explain every part of your code and why it's there.

Submit: your Lab 10 Worksheet (Steps 1–4 and 6) and lab10_game.py or Lab10.ipynb (Step 5).

Step 1: Ideate

Before you touch any code — or any AI tool — you need a concrete idea.

1. Brainstorm 10 different text-based game ideas. These can be silly, serious, weird, whatever. A few categories to jog your thinking:
   • A choose-your-own-adventure story (explore a haunted house, escape a dungeon, survive a road trip)
   • A guessing game (guess the number, guess the word, guess the secret rule)
   • A quiz or trivia game
   • A simple simulation (a lemonade stand, a pet you take care of, a garden you grow)
   • A dialogue-based mini mystery ("who stole the cookies")
2. Write down all 10 ideas — one sentence each is fine.
3. Circle your top 2–3 favorites.
4. Pick one to build. Talk it over with a classmate if it helps you decide — a second opinion is useful here, and this is the one part of the lab where collaborating on the idea itself is encouraged.

Record on your worksheet: your list of 10 ideas, with your final choice clearly marked and one sentence on why you picked it.

Step 2: Requirements

Turn your idea into a non-technical description of what the game needs to do — like a client describing what they want, before any code exists.

Answer these questions in a few sentences each:

• What does the player see when the game starts?
• What choices or inputs can the player make, and when?
• What determines whether the player "wins," "loses," or the game just ends?
• What information does the game need to keep track of while it runs? (Think: what would need to be a variable?)
• Are there any rules that repeat, or that require checking a condition? (Think: what would need to be a loop, and what would need to be a conditional?)

Record on your worksheet: your written requirements description — no code, no pseudocode yet, just plain language.

Step 3: Subtasks

Break your game into smaller pieces. This is where you start thinking like a programmer: what are the individual jobs your program needs to do, and how could each one become its own function?

For example, a guessing game might break down into:

• Get a random number
• Ask the player for a guess
• Check if the guess is correct, too high, or too low
• Keep track of how many guesses the player has used
• Decide when the game ends

Record on your worksheet: your list of subtasks, with a note next to each one indicating whether you think it will be a variable, a conditional, a loop, a function, or some combination.

Step 4: Pseudocode

Now write pseudocode for your game. This should be detailed enough that someone else could read it and understand exactly how your program will behave, without needing to know Python syntax.

Your pseudocode should clearly show:

• Where variables are created and updated
• Where conditionals make decisions
• Where loops repeat actions
• Where functions are called and what they return

Record on your worksheet: pseudocode covering your full game, organized by the subtasks from Step 3.

Step 5: Code (with AI)

Now it's time to implement. Work with an AI agent to turn your pseudocode into working Python code — but you are the one directing the process.

Guidelines for this step:

• Give the AI your pseudocode and requirements, not just a one-line prompt like "write me a text game."
• Build and test one function at a time. Don't ask the AI to generate the whole program in one shot.
• If the AI generates something you don't understand, stop and ask it to explain — or ask your instructor. You should never turn in code you can't explain line by line.
• If the AI's implementation drifts from your pseudocode or requirements, that's a signal to redirect it, not to just accept whatever it gives you.
• Test as you go. Run your program often, not just once at the very end.
• Remember to have your types listed explicitly, even if AI doesn't do it for you!

Submit: a working Python program implementing your game, saved as lab10_game.py or in Lab10.ipynb.

Step 6: Communicate — Playtest

Find a classmate (or another willing victim) and have them play your game — not read your code, actually play it.

While they play, watch and take notes:

• Where did they get confused?
• Did they do anything you didn't expect?
• Did the game ever crash, freeze, or behave strangely?
• What did they say they liked or didn't like about the gameplay?

Afterward, ask them directly:

• What was confusing?
• What would make the game more fun or clearer?

Record on your worksheet: a short written summary (4–6 sentences) of your playtester's feedback and at least one thing you would change (or did change) as a result.

Reflection

Answer the reflection questions on the worksheet.

Submission Checklist

Submit the following:

• Lab 10 Worksheet: Steps 1–4 (ideas, requirements, subtasks, pseudocode), Step 6 (playtest summary), and Reflection
• lab10_game.py or Lab10.ipynb: your working game (Step 5)

A Note on AI Use

Using AI well here means using it the way you'll use it on the job: to speed up implementation of ideas you already understand, not to skip the thinking. If you can't explain why a line of code is in your program, that's a sign to slow down before you submit — not something to hide. We'll be checking that your requirements, subtasks, and pseudocode came before your code, not after.