p2-rps

EECS 183 Project 2: Rock-Paper-Scissors — Student Quickstart

Full specification (all details + sample runs): Full Spec

This page is a shorter, student-first version of the full spec. It keeps every requirement, but organizes them for faster onboarding.

Note: you will need to use the details in the full specification to complete the project.

0) Logistics (Dates, Grading, Submissions)

Due date: Friday, October 2, 2026 at 8:00 p.m. (accepted until 11:59:59 p.m.)

Autograder: Direct autograder link

Early bonus (autograder score):

• Last submission on Wednesday, September 30: +5%
• Last submission on Thursday, October 1: +2.5%

Grading:

• 10 points testing (test.cpp)
• 60 points correctness
• 10 points style (only rps.cpp is graded for style)

Submissions:

• 4 submissions per day with feedback
• 1 extra wildcard submission (once during the project period)
• Best submission counts for style
• If multiple submissions tie in score, the last of those is used for style

This project must be completed individually — no partners.

Difficulty warning: this project is significantly more difficult than Project 1. Expect it to take 2 to 3 times longer to complete.

1) Big Picture (What You’re Building)

You will implement a menu-driven rock-paper-scissors game for two players:

• A menu loop that plays games until the user quits
• A game of exactly three rounds — the player who wins more rounds wins the game
• Input validation for names, menu choices, and moves
• A test suite in test.cpp

2) Files You’re Given

Download the starter files using this link.

Stubbing means the functions contain minimal code (like return false;) so the project compiles before you implement them. Remove our stub return statements when you write your own implementation.

Important constant in rps.cpp:

• MAX_ROUNDS = 3 (rounds per game — use it in doGame())

Add your name, uniqname, and a small description to the header comments at the top of rps.cpp and test.cpp.

3) Read the RME Comments Like Contracts

Every function declaration in rps.cpp has an RME comment:

• Requires: preconditions the caller must satisfy.
• Modifies: what the function is allowed to change.
• Effects: what the function returns or does.

If your tests or code violate a Requires clause, the autograder will penalize you. Treat RMEs like a contract between the caller and callee.

Key simplification for this project: user input will always be of the expected data type (e.g., char for moves). You only validate invalid input (wrong value), never bad input (wrong type) — bad input is prohibited by the Requires clauses.

4) Collaboration (No Partners)

This is an individual project. Partners are not allowed.

Allowed collaboration:

• Help understanding course concepts
• Discuss the spec and design ideas
• Help debug or interpret compiler errors
• Reuse the test cases you created with your group in lab

Not allowed:

• Copying or deriving code from others
• Sharing your code in any form (public or private)
• Collaborating so solutions are identifiably similar
• Receiving help that tells you what to write
• Sharing test cases submitted for grading

If unsure, ask course staff first. Full policy: Collaboration Policy

5) Suggested Implementation Order

Write, test, and debug one function at a time. Start with functions that call no other functions; write rps() last:

1. isMoveGood(), isRoundWinner(), announceRoundWinner(), announceWinner()
2. getMove()
3. getName(), getMenuChoice()
4. doRound()
5. doGame()
6. rps()

(printInitialHeader(), printMenu(), printErrorMessage(), and printCloser() are already implemented for you.)

6) Test Suite Basics

You will implement the stubbed test functions in test.cpp, called from startTests(). Write tests before you implement each function.

Full details: Testing

Testing notes:

• Do not call functions with inputs that violate their Requires clauses (e.g., never pass 'x' to isRoundWinner()).
• The autograder runs your test.cpp against both correct and buggy staff implementations of rps.cpp and compares output.
• If the outputs differ, you exposed a bug. You do not need to find all bugs to get full testing points.
• Something must be printed for a test to expose a bug — print return values of non-void functions.
• Only the test functions stubbed in test.cpp are submitted. Tests for getName(), getMenuChoice(), and gameplay functions are still worth writing locally — just remove them before submitting.

Bug IDs the autograder may report (8 total):

• CHECK_ISMOVEGOOD_1
• CHECK_ISMOVEGOOD_2
• CHECK_ANNOUNCEROUNDWINNER_1
• CHECK_ANNOUNCEROUNDWINNER_2
• CHECK_ANNOUNCEWINNER_1
• CHECK_ANNOUNCEWINNER_2
• CHECK_ISROUNDWINNER_1
• CHECK_ISROUNDWINNER_2

7) Game Rules (Short Version)

Full details: Problem Statement

8) Exact Output Rules (Very Important)

Output messages must match the spec exactly — a single spelling or whitespace error can fail almost every autograder test case. Copy/paste prompts from the spec and use a diff checker.

Sample runs: Sample Output

Key messages:

Player 1, enter your name:
Player 2, enter your name:
Choice -->
[name], enter your move:
[name] wins the round!
This round is a draw!
Congratulations [name]!
You won EECS 183 Rock-Paper-Scissors!
No winner!
Invalid menu choice
ERROR: Illegal name given, using default
ERROR: Illegal move given, using default
Under Construction

Newline rules:

• getMenuChoice(): print an extra newline right after every call to cin.
• getMove(): print an extra newline before the function returns.
• Invalid menu choice: print Invalid menu choice, re-print the menu, and get another choice — repeat until valid.

9) Function Dependency Map (Who Calls What)

Full details: Function Table

You should not use other functions if not specified. getMenuChoice() gets a single menu choice — it should not play the game.

10) Style and Autograder Reminders

Full details: Style Checklist and Style Rubric

Style essentials:

• No global variables (global constants are OK and encouraged)
• No magic numbers (use MAX_ROUNDS, not 3)
• Descriptive, consistently-named variables (camelCase or snake_case, not both)
• Braces on all conditionals, loops, and functions; consistent brace style
• 80 characters per line max
• Comment before the line, not at the end of it
• Keep RMEs above function declarations (including any helper functions you add)
• Return true/false from bool functions, not 1/0
• Define your function implementations below rps(), as indicated in rps.cpp

Autograder reminders:

• Submit exactly two files: rps.cpp and test.cpp
• Whitespace differences can fail tests
• You get 4 submissions per day + 1 wildcard submission; extra submits are blind
• Best submission counts for style
• If multiple submissions tie in score, the last of those is used for style

11) Recommended Timeline (Fall 2026)

12) Fast Start Checklist

• Download and unzip starter files
• Create a project; import rps.cpp, test.cpp, and start.cpp (delete Xcode’s auto-generated main.cpp)
• Compile and run the distribution code to verify your setup
• Add your name/uniqname to the header comments
• Implement and test one function at a time, in the order above
• Write rps() last
• Diff your output against the Sample Output
• Submit early and often

13) How to Get Help

Most students need help from staff multiple times each project — more people need help with Project 2 than Project 1. We’re here for you!

• Spec questions: Piazza is fastest
• 1-1 help: Office Hours
• Code not working? Check the troubleshooting checklist

14) Optional Challenge

• S’More (optional): Project 2 S’More — add rock, paper, scissors, lizard, spock