Important
GitHub repository options
If you are completing this repository as part of your IT 140 assignment, do not use the GitHub options in the upper-right corner except as follows:
- 🟡 Watch — Not recommended: Notifications may confuse students and are not needed.
- 🔴 Fork — Do not use: It will break the code later in this README file.
- 🟢 Star — Recommended: Later code will bookmark this repository so it is easier to find later.
- 🔴 Use this template — Do not use: It will break the code later in this README file.
Faculty: Consider selecting Watch → Custom → Releases + Issues to receive major repository updates and follow reported problems.
- Course: IT 140 - Introduction to Scripting
- Sequence: Project One → Module Six Milestone → Project Two
- Program: Text-Based Adventure Game
- Repository model: One personal repository used across all three modules
Note
The IT 140 project SDLC is distributed across three modules. Do not create a new project repository for each activity.
Module 5: Analyze + Design → submit Project One
Module 6: Construct + Test a simplified prototype → submit the Milestone
Module 7: Construct + Test the final game → submit Project Two
| Module | Activity | SDLC work | Graded deliverables | What carries forward |
|---|---|---|---|---|
| 5 | Project One | Analyze + Design | design/game_storyboard.md, design/game_map.drawio, design/move.pseudo, design/get_item.pseudo |
Your approved game world and command designs |
| 6 | Module Six Milestone | Construct + Test a reduced movement prototype | prototype/move_between_rooms.py |
Movement/dictionary/loop experience and instructor feedback |
| 7 | Project Two | Construct + Test the complete game | src/text_based_game.py |
Final implementation based on your Module 5 design, informed by Module 6 practice |
The Module Six prototype is intentionally not the complete Project Two
program. It uses a small course-provided dragon-game dictionary and an exit
ending so you can practice one part of the final system in a smaller problem.
Before beginning each checkpoint, open that activity's current Guidelines and Rubric in D2L Brightspace.
Those pages are the official sources for requirements, grading criteria, and submission instructions. Repository documents reorganize those requirements into a development workflow; they do not replace the D2L instructions.
Use this source priority if instructions ever differ:
- Current activity Guidelines and Rubric in D2L Brightspace
- Instructions from your instructor
- Current repository README and phase README files
- Supplemental project Wiki pages
it140-projects/
├── analysis/ # Requirements reference across M5–M7
│ ├── README.md
│ └── text_based_game_srs.md
├── design/ # M5 Project One: graded design deliverables
│ ├── README.md
│ ├── game_storyboard.md # graded M5
│ ├── game_map.drawio # graded M5
│ ├── move.pseudo # graded M5
│ ├── get_item.pseudo # graded M5
│ └── text_based_game_sdd.md # course-provided reference
├── prototype/ # M6 Milestone: reduced construct/test cycle
│ ├── README.md
│ ├── move_between_rooms.py # graded M6
│ └── move_between_rooms_sdw.md
├── src/ # M7 Project Two: final construction
│ ├── README.md
│ ├── text_based_game.py # graded M7
│ └── text_based_game_sdw.md
├── tests/ # M6/M7 testing guidance and working notes
│ ├── README.md
│ └── game_test_plan.md
└── README.md
Course-provided flowchart images and repository-management files are supporting materials. They are not additional student submissions.
Required graded work:
Required graded work:
Optional working notes:
Required graded work:
Optional working notes:
Leave the READMEs, SRS, SDD, reference images, CI files, tests, and repository configuration unchanged unless current course instructions tell you otherwise.
Complete these steps only once, normally when beginning Project One.
If you already have an it140-projects repository in your GitHub account or an
it140-projects folder in ~/Repos, open that existing repository instead of
creating another one.
From the VS Code integrated terminal:
cd ~/Repos
gh auth setup-git
gh api --method PUT /user/starred/GC-STEM/it140-projects
gh repo create it140-projects --template GC-STEM/it140-projects --private --clone
cd it140-projects
git remote -vReview the final output and confirm that the repository belongs to your GitHub account.
Note
GitHub is used to develop and back up your work. Submission, grading, and instructor feedback remain in D2L Brightspace.
Project One covers the Analyze and Design portions of the project SDLC. You are designing the game, not building the complete Python program yet.
Open analysis/README.md.
Use the Project One Guidelines and Rubric, sample game resources, and the Text-Based Game SRS to identify:
- The game goal and losing condition
- The minimum room and item requirements
- The start-room and villain-room constraints
- What makes the map winnable
- The two command types: movement and getting an item
- The inputs, outputs, decisions, and repetition needed by those processes
Open design/README.md and complete all four graded design
files.
Project One is finished when your storyboard, map, movement pseudocode, and get-item pseudocode form one consistent design.
Keep these files after submitting them. They are not throwaway exercises. In Module Seven, they become the source for your final room/item dictionary and command logic. Review Project One instructor feedback before coding the final game.
From the repository root, you may save the Project One work with:
git status
git add design/game_storyboard.md design/game_map.drawio
git add design/move.pseudo design/get_item.pseudo
git commit -m "Complete Project One design"
git pushSubmit the four Project One files in D2L Brightspace according to the current Project One What to Submit instructions.
The milestone is a reduced Construct + Test iteration. It gives you practice translating movement design into Python before you build the complete game.
Do not create a second project repository. Open your existing
~/Repos/it140-projects folder.
Review:
- Your Project One
design/move.pseudo - Any Project One instructor feedback
- The Module Six Milestone Guidelines and Rubric
- The Milestone Simplified Text Game Flowchart and supporting resources in D2L
Open prototype/README.md and complete:
The milestone intentionally uses the course-provided three-room dragon-game dictionary. Do not replace it with your Project One world for this checkpoint.
The prototype includes movement, an exit command, a gameplay loop, decision
branching, and input validation. It intentionally leaves out items, inventory,
the villain, and final win/loss behavior.
Use the Module Six section of tests/README.md and, if
helpful, record results in tests/game_test_plan.md.
Save the milestone with:
git status
git add prototype/move_between_rooms.py
git add prototype/move_between_rooms_sdw.md tests/game_test_plan.md
git commit -m "Complete Module Six movement milestone"
git pushSubmit move_between_rooms.py in D2L Brightspace according to the current
milestone What to Submit instructions.
Keep the milestone file and instructor feedback. In Module Seven, you may reuse
or adapt useful movement, dictionary, branching, and loop ideas—but the final
game must switch back to your Project One game world and must end through
the required win/loss conditions rather than the milestone-only exit ending.
Project Two is the final Construct + Test iteration of the SDLC.
Open src/README.md. Review these inputs together:
- Current Project Two Guidelines and Rubric
- Project One storyboard
- Project One game map
- Project One movement pseudocode
- Project One get-item pseudocode
- Project One instructor feedback
- Module Six prototype and instructor feedback
- Project Two sample flowchart/output resources
Resolve design inconsistencies before creating the final room/item dictionary.
Complete:
The final source must use your Project One rooms, items, villain, and map. The milestone's three-room sample dictionary is not the final game data.
Use tests/README.md to test at least:
- Valid and invalid movement
- Valid and invalid item commands
- Inventory updates
- A complete winning path
- A complete losing path
- Readability and removal of unfinished starter placeholders
Use your map to plan deterministic playthroughs instead of relying on random exploration.
git status
git add src/text_based_game.py
git add src/text_based_game_sdw.md tests/game_test_plan.md
git commit -m "Complete Project Two text game"
git pushSubmit text_based_game.py in D2L Brightspace according to the current Project
Two What to Submit instructions.
Each push runs the Project Checks workflow. The checks understand the three-checkpoint sequence:
- Module 5: Project One design files must be completed.
- Module 6: Project One remains complete and the milestone prototype must be completed.
- Module 7: Project One and the milestone remain complete and the final Project Two source must be completed.
The active checkpoint is inferred from which later graded file has been changed. A red X while you are still working can simply mean a checkpoint is not yet complete.
The checks verify basic structure and completion state. They do not assign a grade, prove that your map is winnable, or prove that every path through your final game is correct. Manual requirement-based testing is still required.
To review a run:
- Open your personal
it140-projectsrepository on GitHub. - Select Actions.
- Open the most recent Project Checks run.
- Open Check projects repository for details.
You create the personal repository only once. When returning in a later module:
- Open VS Code.
- Select File > Open Folder.
- Open
~/Repos/it140-projects. - Run
git status. - Continue from the current module checkpoint.
If you move to another computer, clone your existing personal repository. Do not create a new repository from the course template just because the module changed.
Start with the IT 140 Projects Wiki for supplemental explanations.
Use repository Issues for a reproducible technical problem with repository files, starter content, or repository instructions.
Use repository Discussions for repository-related questions that may help other students.
Do not post completed graded solutions.
Contact your instructor through the course-approved D2L Brightspace channel for questions about requirements, submissions, grading, feedback, deadlines, accommodations, or your individual work.