Project 2

Rock, Paper, Scissors

EECS 183. Winter 2019.
Table of Contents
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1  

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1  

Honor Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2  

Grading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 

Distribution Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3  

Problem Statement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3  

Solution Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3  

printInitialHeader(). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5  

printMenu(). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5  

printErrorMessage() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5  

printCloser() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5  

getName() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5  

getMenuChoice() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5  

isMoveGood() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6  

getMove() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6  

isRoundWinner() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7  

annouceRoundWinner() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7  

doRound() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7  

annouceWinner(). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7  

doGame() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7  

Function Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8  

Putting it Together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8  

Creating a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9  

Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
 

Testing Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12  

Testing getName() and getMenuChoice() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12  

Implementing Test Functions for Submission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13  

Bugs To Expose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15  

Preparing your test.cpp for Submission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15  

How to Submit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16  

Where to Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19  

Style Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19  

Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20  

S’more . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
 

Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26  

How to Submit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29  
due Friday, 8 February 2019 at 6:00 p.m. (accepted until 11:59:59 p.m.)

Overview
In this project, you will be implemeting a rock-paper-scissors game! Rock-paper-scissors is a hand
game played between two people, in which each player simultaneously forms one of three shapes
with an outstretched hand. These shapes are "rock" (a simple fist), "paper" (a flat hand), and
"scissors" (a fist with the index and middle fingers extended, forming a V).

A player who plays rock will beat another player who has chosen scissors, but will lose to one who
has played paper; a play of paper will lose to a play of scissors. If both players choose the same
shape, the game is tied.

See the image below for a visual representation of the rules of rock-paper-scissors:

(wikipedia)

Objectives
• To have fun.

• To start thinking more carefully.

• To understand the use of existing operators to perform interactive I/O using C++.

• To use constants and variables appropriately.

• To implement functions given prototypes and use them appropriately.

• To write logical expressions and selection statements in C++.

• To write your first loop in C++!

Beware the autograder’s ability to detect cheating, see Honor Code for further
 information.

1
Honor Code
All students in the class are presumed to be decent and honorable, and all students in the class are
bound by the College of Engineering Honor Code.

• You may not seek to gain an unfair advantage over your fellow students;

• You may not consult, look at, or possess the unpublished work of another without their
permission;

• You are not allowed to look at or in any way derive advantage from the existence of project
specifications or solutions either for the current semester or for past semesters; and

• You must appropriately acknowledge your use of another’s work.

Any violation of the honor policies appropriate to each piece of course work will be reported to the
Honor Council, and if guilt is established penalties may be imposed by the Honor Council and
Faculty Committee on Discipline. Such penalties can include, but are not limited to, letter grade
deductions or expulsion from the University.

Also note that on all cases forwarded to the Engineering Honor Council the LSA Dean of Academic
Affairs is also notified. Furthermore, the LSA rule is that students involved in honor violations
cannot withdraw from nor drop the course.

We run every submission against every other submission and determine similarities. All projects
that are “too similar” are forwarded to the Engineering Honor Council. This happened to numerous
students last semester. Also know that it takes months to get a resolution from the Honor Council.
Discussion of the project will NOT be an issue. Sharing code between students will likely cause the
cheating detector to identify both programs as “too similar”. We also search the web for solutions
that may be posted online and add these into the mix of those checked for similarities. Searching
the web, by the way, is something that we are very good at.

Also note that on all cases forwarded to the Engineering Honor Council the LSA Dean of Academic
Affairs is also notified. Furthermore, the LSA rule is students involved in honor violations cannot
withdraw from nor drop the course.

Grading
• This project must be completed individually, i.e., no partners.

• 60 points: correctness. Implement functions in rps.cpp to create a working rock-paper-scissors

game. To what extent does your code implement the features required by our specification? To
what extent is your code consistent with our specifications and free of bugs? To receive a 5%
bonus for this part, submit it no later than Wed 2/6. To receive a 2.5% bonus, submit no later
than Thurs 2/7.

• 10 points: testing. To what extent is your code tested? Implement the testing functions and
submit them via the test.cpp file. See the Testing section for more details.

• 10 points: style. To what extent is your code written well? To what extent is your code
readable? Consult EECS 183 Style Guide and check the Style Checklist at the end of this project’s
specification for some tips! Also, see the Style Rubric for guidance on how style grades are

2
 determined.

• Remember that we grade your LAST submission only.

Distribution Code
For this project, you’ll first download “distribution code” written by us, and add your own lines of
code to it. You can download it either from the Projects page of the course’s website or by clicking
here on project2.zip. After downloading and unzipping it, you’ll find these files:

rps.cpp
This is the basic starter code for Project 2. It #includes all necessary libraries for the project, and
provides declarations for functions you will implement. It also has utility functions at the bottom
of the file that you should not modify.

test.cpp
Testing functions for your rps.cpp implementation. Holds the declarations of required testing
functions. We have stubbed all required functions for you.

Stubbing functions means adding the minimal necessary code to make a function
 compile. Be sure to remove our stubs when you write your own implementation of
the functions.

Problem Statement
Your task for this project is to create a program for playing a game of rock-paper-scissors between
two players. The game will consist of exactly three rounds of rock-paper-scissors. A player will
need to win the majority (i.e., greatest number) of the three rounds to win the game. The game will
result in a tie if no player wins the majority (i.e., more than the other player) of the rounds.

So that we can automate the testing of your code, the output messages for the rock-
paper-scissors game must be exactly the same as presented in this specification
and the function RMEs. Making sure they are exact is critical to passing the
 autograder. Check the Sample Output below for the exact prompts. To avoid
spelling errors, simply copy/paste the appropriate prompt into your code. Note
that a spelling error will cause you to fail almost every test case from the
autograder.

Solution Overview
• Your program will provide a menu, implemented using a loop, to obtain user input and play
rock-paper-scissors games.

Even though we are going over what happens in main() early in the specification,
 this does NOT mean you should begin your implementation with main(). Actually,
you should write main() last.

3
 • To begin, your program will call printInitialHeader(), which will print this heading:

----------------------------------------
  EECS 183
  Rock-Paper-Scissors
----------------------------------------

• Next, your program will obtain the two player names, which will not change for the duration of
the program. First, Player 1 will be asked to input their name:

----------------------------------------
  EECS 183
  Rock-Paper-Scissors
----------------------------------------

Player 1, enter your name:

Once Player 1’s name is entered, the program will prompt Player 2 for their name:

----------------------------------------
  EECS 183
  Rock-Paper-Scissors
----------------------------------------

Player 1, enter your name: Rana Makki

Player 2, enter your name:

Note that "Rana Makki" in the sample output above is user-entered text, and therefore is not
included in the output prompt. Also note that player names can contain whitespace.

• Next, your program will call getMenuChoice(), which will not only print the menu (there is a
function that does this) but will be also be used to obtain user input for menu selection.

• The menu options are:

Menu Options
------------
1) Play rock, paper, scissors
2) Play rock, paper, scissors, lizard, spock
3) Quit

Choice -->

• Depending upon the value the user enters for "Choice", the program will either initiate a game
of rock-paper-scissors, initiate a game of rock-paper-scissors-lizard-spock, or quit.

• Your program shall continue to play games and prompt the user for another choice until a user

4
 input of 'Quit' (user choice 3) is entered.

• When the user input indicates that they’ve had enough and want out of EECS 183 Rock-Paper-
Scissors, your program will call printCloser(), which will print this heading:

----------------------------------------
  Thanks for playing
  Rock-Paper-Scissors!
----------------------------------------

and the program naturally finishes.

• There are many functions that assist in making all of this happen. Below is a brief overview of
the functions you will use in this project. For in-depth descriptions of the functions' behavior,
please read the RME’s within rps.cpp.

For the functions you will implement, write their definitions below main(), as
 indicated in rps.cpp.

printInitialHeader()

• This function has been implemented for you.

printMenu()

• This function has been implemented for you.

printErrorMessage()

• This function has been implemented for you.

printCloser()

• This function has been implemented for you.

getName()

• This function prompts a player for their name and handles the input accordingly.

• This function utilizes the following function(s):

◦ printErrorMessage()

getMenuChoice()

• This function will handle everything for printing the menu and handling input from the user.

• This function utilizes the following function(s):

◦ printMenu()
• Invalid input. You also cannot depend upon users to get the input within range. You also need to

5
 handle out of range input. If the user enters a menu option other than 1, 2, or 3 you need to

◦ print Invalid menu choice

◦ re-print the menu, and

◦ get another menu choice

• This needs to be repeated until a valid menu choice is entered.

isMoveGood()

• This function determines whether or not a player’s move is valid. A valid move consists of an 'r',
'p' or 's' character, corresponding to "rock", "paper", and "scissors", respectively. The uppercase
versions of these characters are also considered valid. Any other characters a user enters will be
considered invalid.

Note that for this project you can assume user input will always be of the data
type expected (which is char for moves). In other words, as the programmer, you
 only need to check that values entered are valid moves - you do not need to worry
about users entering integers, doubles, strings,bools or any combination of these.

• This function utilizes no other functions.

getMove()

• This function prompts a player to enter their move during a round, and handles the input
accordingly.

• This function utilizes the following function(s):

◦ printErrorMessage()
◦ isMoveGood()

There are two types of messages that could be printed depending on the characters that users input
for their moves:

• Valid move: The program will print which player won the round or whether the round was a
draw.

----------------------------------------
  EECS 183
  Rock-Paper-Scissors
----------------------------------------

Player 1, enter your name: Rana Makki

Player 2, enter your name: David Cao
Rana Makki, enter your move: r
David Cao, enter your move: p
David Cao wins the round!

• Invalid move: The program will print an error message as shown below and then continue the

6
 round using a "default" move for the user(s) that entered invalid input.

----------------------------------------
  EECS 183
  Rock-Paper-Scissors
----------------------------------------

Player 1, enter your name: Rana Makki

Player 2, enter your name: David Cao
Rana Makki, enter your move: r
David Cao, enter your move: a

ERROR: Illegal move given, using default

This round is a draw!

Note that in the above example, the round resulted in a tie because the default move value ('r') was
used for David Cao once he entered invalid input.

isRoundWinner()

• This function determines if the player made a winning move. Note: a move that results in a tie is
not a winning move.

• This function utilizes no other functions.

annouceRoundWinner()

• This function announces the name of the round winner. If there is no round winner, it outputs
that the round resulted in a draw.

• This function utilizes no other functions.

doRound()

• This function will simulate one round of the game.

• This function utilizes the following function(s):

◦ getMove()
◦ isRoundWinner()

annouceWinner()

• This function announces the name of the game winner. If there is no winner of the game, it
outputs that there was no winner.

• This function utilizes no other functions.

doGame()

• This is the function that plays three rounds of rock-paper-scissors, announces round winners,

7
 and keeps track of the number of rounds each player has won. A player receives a point if they
win a round. If the round is a draw, no player receives a point. The full game will always consist
of three rounds. This means that even if the same player wins the first two rounds, the
third round will always be played.

• Hint: Make use of the MAX_ROUNDS constant defined and initialized at the top of rps.cpp when
implementing this function.

• This function utilizes the following function(s):

◦ doRound()
◦ announceRoundWinner()
• For the base project, if the game_type provided to this function is 2 (indicating that the user
selected rock-paper-scissors-lizard-spock), the only thing this function needs to do is return an
empty string after printing the following message:

Under Construction

Only the S’more version needs to handle a game_type of 2 and implement rock-paper-scissors-
lizard-spock.

Function Table

• The table below provides an outline of which other functions each function should call, if any.

Function Other functions it should call

getName() printErrorMessage()
getMenuChoice() printMenu()
isMoveGood() Does not utilize any other functions
getMove() printErrorMessage(), isMoveGood()
isRoundWinner() Does not utilize any other functions
announceRoundWinner() Does not utilize any other functions
doRound() getMove(), isRoundWinner()
announceWinner() Does not utilize any other functions
doGame() doRound(), announceRoundWinner()

Here is an example of how to read the table:

• getName() should call printErrorMessage()

Putting it Together

• Once you have written and tested each of the above functions, it is time to combine everything
in main() and do further testing with your new debugging skills. Be sure that your program
behaves as illustrated in the Sample Output.

• Now that you have a new project created and rps.cpp in front of you, it’s time to begin! Recall

8
 that the execution of a program begins in the main() function, so you will be writing lines of
code there — but not before you have thought about the problem.

• You can find some starter pseudocode for implementing the rock-paper-scissors game below to
help get you started:

// Print the header

// Get player 1 name
// Get player 2 name
// Repeat the following until the user quits the program:
// Print the menu and get the menu choice, continuing to prompt until the user
// chooses a valid menu choice
// Play the game and announce the winner, or quit the program (according to
user's menu choice)
// Print the closing message

• In programming, when you start by outlining the problem at hand, add in one small piece at a
time, and test as you go, implementing a solution is much more manageable.

Creating a Project
If you haven’t done so already, read Getting Started with Xcode guide or Getting Started with Visual
Studio guide, depending on the operating system you’re using. They will walk you through creating
a new project and basic editing.

Once you create a project, you’ll need to import rps.cpp.

Xcode
• There are a couple of ways to import a file in Xcode. The easiest way, perhaps, is to drag and
drop that file next to main.cpp in the Navigator area on the left side of the Xcode window.

9
 Check the checkbox next to Destination: Copy items if needed, make sure that the checkbox
next to Add to targets is checked and click Finish.

• Alternatively, you can choose File > Add Files to… in the menu bar, navigate to your file,
select it and click Add (or press Option-Command-A). Make sure that the checkbox next to
Add to targets is checked when you are adding .cpp files.

• Now there is a problem: there are two main() functions in your project: one in main.cpp that
was automatically inserted by Xcode when you created a new project and another one
written by the staff in rps.cpp that you’ve just imported. Recall that a C++ program must have
one and only one main() function, so your code will not compile. But not to worry! Just delete
main.cpp by right-clicking (or Control-clicking) on main.cpp in the Navigator area on the left
side of the Xcode window and choose Delete.

Visual Studio
• To add a new file to your Visual Studio project, right-click on Source Files in the Solution
Explorer and choose Add > Existing Item… (or press Shift-Alt-A).

10
 Navigate to rps.cpp, select it and click Add.

• You should now see the contents of rps.cpp in the Code pane (editing area).

Be sure to add your name, your uniqname and a small description of the program
 to the header comments at the top of rps.cpp.

Testing
• As part of this project, you will also submit a test suite for testing some of the functions you
implement in rps.cpp. It is important to note that you will only be testing your program for
invalid input rather than bad input. For the purposes of this document, “bad input” will refer
to input whose type (char, int, double, etc.) is different than what is expected by your program.
So if your program is expecting that the user will input an integer — you are guaranteed to
always receive input of type int and will not receive something like char, which would be
considered bad input. On the other hand, you will be testing for “invalid input,” which has the
correct type but is considered invalid given the program specification. The RMEs will be clear
about what is considered to be invalid input for a specific function.

• One question you might have is: how do I know that I have enough tests? In practice, the
answer to this question is almost always “not enough.” However, for this project, you can take
advantage of test.cpp and the autograder. You will write your test functions in test.cpp and
submit it to the autograder. (See How to Submit section.) The autograder will run your test suite
against buggy programs in order to see if your tests can expose enough bugs. The nature of the
bugs will be hidden from you so you will have to think about how invalid input may affect your
program and cause it to produce incorrect behavior given specifications.

Remember, you only have to think about exposing bugs related to invalid
 input and not bad input.

11
Testing Overview
• It is considered good practice to write the test suite BEFORE you implement a function. The idea
is to know if you are correct or not without using a submit to the autograder. This is also a very
good way to cut coding time by a significant amount.

The basic idea of testing is you start small and build. Start with the obvious
 inputs needed then expand to the boundary conditions, and then expand
further into the what else category.

• Remember, a computer does not interpret. If you misspell a word, you will fail all autograder
test cases. If you omit punctuation, you will fail all autograder test cases. We strongly suggest
you test your code. Use diff tools to compare the Sample Output against the output generated
by your code using the same input. Some easy-to-use diff websites that we recommend are:

◦ diffchecker.com

◦ quickdiff.com

◦ diffnow.com

For this project, we will not check differences in whitespace; "hello " and "hello"
 are considered to be equivalent. This will not be the case in future projects.

Testing getName() and getMenuChoice()

• To test getName() and getMenuChoice(), you do NOT need any of the other functions
implemented. You should test these functions thoroughly now, so if something goes wrong with
your code in the future you will know it is NOT these functions. This method of testing will save
you mega-time.

• To test getName() and getMenuChoice(), you need to check them against good input and invalid
input. Therefore, to test these functions, call them within main() and make sure you get the
output and action you expect.

12
 void test_getName();
void test_getMenuChoice();

int main() {
  test_getName();
  test_getMenuChoice();
}

void test_getName() {
  cout << "testing good input" << endl;
  cout << getName(1) << endl; // input "Rana"
  cout << getName(2) << endl; // input "David"
  cout << "testing invalid input" << endl;
  cout << getName(1) << endl; // input invalid values
  ...
}

void test_getMenuChoice() {
  cout << "testing good input" << endl;
  cout << getMenuChoice() << endl; // input 1
  cout << getMenuChoice() << endl; // input 2
  cout << getMenuChoice() << endl; // input 3
  cout << "testing invalid input" << endl;
  cout << getMenuChoice() << endl; // input invalid values
  ...
}

• For "good input" in getName(), you want to check valid player names. For "good input" in
getMenuChoice(), you should try the valid menu choices 1, 2, and 3. Run your code. Make
absolutely sure that the functions output the values you expect for the different inputs you
provide.

• Now that we have laid out the testing approach for getName() and getMenuChoice(), take the
concepts and apply them to the other functions. You can do this. Just follow the same line of
thinking.

Implementing Test Functions for Submission

• The file test.cpp includes function stubs for test_isMoveGood() and test_isRoundWinner(). Your
task is to implement these functions, which should call isMoveGood() and isRoundWinner(),
respectively, to test their behavior.

• The test functions you write should reveal incorrect implementations of isMoveGood() and
isRoundWinner(). Your job is to create a thorough test suite, calling the RPS functions with a
variety of valid and invalid inputs (not bad inputs, as noted above).

• Keep in mind that you should only test values that adhere to the Requires clauses of functions.
For example, when testing isRoundWinner():

13
 bool isRoundWinner(char move, char opponent_move) "Requires" that "both move
 and opponent_move are valid moves".

What this means is you can — and should — test:

// because 'r' and 's' are valid moves

cout << isRoundWinner('r', 's') << endl;

However, a move like 'x' is invalid. Therefore, even though it is “legal” within C++ to write

// invalid test case

cout << isRoundWinner('r', 'x') << endl;

It violates the Requires clause and the programmer should not do this. It is the responsibility of
the coder to not violate the Requires clauses of the functions they call.

• Note that the functions stubbed in test.cpp are the only test functions you will be submitting
to the autograder.

• However, you should still write tests for getName(), getMenuChoice(), and the functions involved
in game play to ensure that your individual functions behave as expected before writing the
main() function for your program. You can call these test functions in main() and remove them
before submission. Do not include these functions when you submit to the autograder.

• When you submit test.cpp, we will compile and run it with our correct implementation of
rps.cpp and with our buggy implementation of rps.cpp, so as to generate two different outputs.
We’ll then compare two outputs. If there is any difference, you’ve successfully exposed a bug!
The autograder does not go into the details of what the difference is, it only sees if there exists a
difference.

• Remember that some functions don’t print anything on their own; we have to print their return
value, as with the function isMoveGood():

14
 cout << isMoveGood('r') << endl;
cout << isMoveGood('q') << endl;

(Keep in mind that bool values are printed as 0 or 1.)

• After you submit your test suite, you might see output that looks like this:

That means that your test suite exposed 1 out of 8 bugs in the staff’s “buggy” implementations
of rps.cpp and your score for the test suite is 1.5 out of 10 points.

Bugs To Expose

There are a total of 8 unique bugs to find in our implementations. Your tests do not need to expose
all of the bugs to receive full points for the lab. The autograder will tell you the names of the bugs
that you have exposed, from the following set:

• CHECK_ISMOVEGOOD_1

• CHECK_ISMOVEGOOD_2

• CHECK_ANNOUNCEROUNDWINNER_1

• CHECK_ANNOUNCEROUNDWINNER_2

• CHECK_ANNOUNCEWINNER_1

• CHECK_ANNOUNCEWINNER_2

• CHECK_ISROUNDWINNER_1

• CHECK_ISROUNDWINNER_2

Preparing your test.cpp for Submission

• Once you have written all your tests and have successfully executed them from main(), copy all
test-related code into your test.cpp file. This will include:

◦ The function bodies of both of the test functions (test_isMoveGood() and

15
 test_isRoundWinner()).

◦ The code you wrote in main() to call the test functions.

• Now submit your test.cpp to the autograder (How to Submit) to see how many bugs your tests
exposed. Once you have successfully submitted your tests, you can remove the testing code
from your main() in rps.cpp and write the main function for your program.

To see a detailed example of how to make your test.cpp see the guide here:
 https://eecs183.org/projects/2/testing/

How to Submit
• Write your program using Visual Studio or Xcode as described in lecture and discussion section.
Your program must be written and documented to comply with the Style Guidelines provided
for EECS 183.

• You must submit both rps.cpp and test.cpp for grading.

If you’re using Xcode and don’t know where exactly rps.cpp is located on your computer,
right-click (or click while holding down the Command key) on the file in the Navigator area
on the left side of the Xcode window and choose Show in Finder.

16
If you’re using Visual Studio and would like to know where rps.cpp is on your computer,
right-click on rps.cpp in the tab above the Code pane and choose Open Containing Folder.

17
 • When ready to submit to the Autograder:

◦ To submit rps.cpp, https://autograder.io/web/project/294

◦ To submit test.cpp, visit https://autograder.io/web/project/295

▪ You can also find the link to submit on the Course Schedule, and choose Submit or
Submit (test) where Project 2 is listed.

• On the new page, click Choose file and navigate to your file. The file you submit to the
autograder MUST be called: rps.cpp or test.cpp.

• If confident that you’ve selected the correct file, click Submit to submit your code to the
Autograder.

• For each part of the Project (rps.cpp and test.cpp),…

◦ You have 2 submissions with feedback per day.

◦ You also have one additional “wildcard” submission with feedback.

• We provide some information regarding the tests that you do not pass. However, it is our intent
that you learn to develop code independently. It’s important to have tests to tell you whether or
not your code works, but real life does not have an autograder. Providing complete feedback
from our own tests will hurt your ability to learn to test.

• You have an infinite number of submits per day, but only the first two submits per day return
autograder feedback and a score. Any additional submits are "blind submits," which do not

18
 return autograder feedback — not even a score. Be very cautious with these or you may be
surprised by your grade.

• Remember: your last submit is the one we grade, even if an earlier submit would have a higher
score. We do not accept submissions via email.

• You will soon develop a “love/hate” relationship with the autograder. You will “love” that you
can check your code to see your score. You will “love” that it gives you feedback. You will “hate”
that it tells you that you are not totally correct on the first submit.

For this project, we will not check differences in whitespace; "hello " and "hello"
 are considered to be equivalent. This will not be the case in future projects.

Where to Begin
• The best approach is always to start small and build your solution up one piece at a time. Never
try and do the entire thing at once.

• First, start with writing out some logic on a piece of paper. What needs to happen first?

• Implement one function at a time, thinking about what this function needs as input, what it
should return, and how it should be used.

• We suggest starting with pseudocode, remember Lecture 01. Pseudocode is a way to explain
what needs to happen in English before having to figure out how to do it in code. It is a way to
lay out what is needed logically without the overhead of C++ code.

• Only after writing out the pseudocode of what is described above is it time to then translate it to
C++. This will save you hours when you start coding, trust us!

Style Checklist
To maximize your style points, be sure to follow this non-exhaustive checklist:

☐ Review EECS 183 Style Guide. Pay particular attention to Comments, Whitespace and
Indentation and Variables and Constants.

☐ Be sure you’ve included your name, your uniqname and a small description of the program in
the header comments.

☐ Be sure to use descriptive variable names. The more descriptive the variable names, the less
you need to comment.

☐ Be sure to use consistent variable naming style. Use either camelCase or snake_case, but do not
alternate between them. Do not change the case of the variable and function names provided.

☐ Be sure that your code is well-commented. It might at first seem that the algorithm is straight-
forward and self-explanatory, but would you remember all the details a month from now? Pro
Tip: It’s much easier for the staff to help you with your code if you have comments!

☐ Remember to avoid magic numbers.

☐ Don’t use global variables. However, global constants are OK and should be used.

☐ Remember that all lines must be 80 characters or less.

19
☐ Check out Project 2 Style Rubric to avoid any deductions.

Sample Output
Here are a few examples of the way your program output should look, wherein underlined text
represents some user’s input.

20
Sample Run 1

----------------------------------------
  EECS 183
  Rock-Paper-Scissors
----------------------------------------

Player 1, enter your name: Rana Makki

Player 2, enter your name: David Cao

Menu Options
------------
1) Play rock, paper, scissors
2) Play rock, paper, scissors, lizard, spock
3) Quit

Choice --> 1

Rana Makki, enter your move: r

David Cao, enter your move: p
David Cao wins the round!

Rana Makki, enter your move: r

David Cao, enter your move: r
This round is a draw!

Rana Makki, enter your move: p

David Cao, enter your move: s
David Cao wins the round!

Congratulations David Cao!

You won EECS 183 Rock-Paper-Scissors!

Menu Options
------------
1) Play rock, paper, scissors
2) Play rock, paper, scissors, lizard, spock
3) Quit

Choice --> 3

----------------------------------------
  Thanks for playing
  Rock-Paper-Scissors!
----------------------------------------

21
Sample Run 2

----------------------------------------
  EECS 183
  Rock-Paper-Scissors
----------------------------------------

Player 1, enter your name: Rana Makki

Player 2, enter your name: David Cao

Menu Options
------------
1) Play rock, paper, scissors
2) Play rock, paper, scissors, lizard, spock
3) Quit

Choice --> 4

Invalid menu choice

Menu Options
------------
1) Play rock, paper, scissors
2) Play rock, paper, scissors, lizard, spock
3) Quit

Choice --> 2

Under Construction
No winner!

Menu Options
------------
1) Play rock, paper, scissors
2) Play rock, paper, scissors, lizard, spock
3) Quit

Choice --> 3

----------------------------------------
  Thanks for playing
  Rock-Paper-Scissors!
----------------------------------------

Sample Run 3

22
----------------------------------------
  EECS 183
  Rock-Paper-Scissors
----------------------------------------

Player 1, enter your name:

ERROR: Illegal name given, using default

Player 2, enter your name:

ERROR: Illegal name given, using default

Menu Options
------------
1) Play rock, paper, scissors
2) Play rock, paper, scissors, lizard, spock
3) Quit

Choice --> 1

Rocky, enter your move: R

Creed, enter your move: p
Creed wins the round!

Rocky, enter your move: s

Creed, enter your move: S
This round is a draw!

Rocky, enter your move: S

Creed, enter your move: P
Rocky wins the round!

No winner!

Menu Options
------------
1) Play rock, paper, scissors
2) Play rock, paper, scissors, lizard, spock
3) Quit

Choice --> 1

Rocky, enter your move: S

Creed, enter your move: p
Rocky wins the round!

Rocky, enter your move: r

Creed, enter your move: A
ERROR: Illegal move given, using default

23
 This round is a draw!

Rocky, enter your move: S

Creed, enter your move: P
Rocky wins the round!

Congratulations Rocky!
You won EECS 183 Rock-Paper-Scissors!

Menu Options
------------
1) Play rock, paper, scissors
2) Play rock, paper, scissors, lizard, spock
3) Quit

Choice --> 3

----------------------------------------
  Thanks for playing
  Rock-Paper-Scissors!
----------------------------------------

S’more
• Want more? Try implementing S’more! Allow the user to play a game of rock-paper-scissors-
lizard-spock. The game is played in the same fashion as traditional rock-paper-scissors but
introduces two new move options. See the image below for a visual representation of the rules
of rock-paper-scissors-lizard-spock.

24
(instructables)

You must first complete the Regular version of the project and submit it to the
 Autograder.

• In implementing the S’more, you do not need to add any new functions to rps.cpp. However,
you will need to edit the existing functions in the file to handle both types of game play. A
correct implementation of the S’more allows the user to play either rock-paper-scissors or rock-
paper-scissors-lizard-spock.

• Note that for rock-paper-scissors-lizard-spock, a valid move consists of an 'r', 'p', 's', 'l', or 'k'
character, corresponding to "rock", "paper", "scissors", "lizard", and "spock", respectively. The
uppercase versions of these characters are also considered valid. Any other characters a user
enters will be considered invalid.

• To implement a working version of rock-paper-scissors-lizard-spock, consider editing the

following functions:

◦ isMoveGood()
◦ getMove()
◦ isRoundWinner()
◦ doRound()
◦ doGame()
◦ announceWinner()

Hint: It may be useful to add the game_type variable as a parameter to some of the functions listed
above.

25
Sample Output
Here are a few examples of the way your program output should look, wherein underlined text
represents some user’s input.

S’more Sample Run 1

----------------------------------------
  EECS 183
  Rock-Paper-Scissors
----------------------------------------

Player 1, enter your name: Rana Makki

Player 2, enter your name: David Cao

Menu Options
------------
1) Play rock, paper, scissors
2) Play rock, paper, scissors, lizard, spock
3) Quit

Choice --> 2

Rana Makki, enter your move: k

David Cao, enter your move: l
David Cao wins the round!

Rana Makki, enter your move: s

David Cao, enter your move: p
Rana Makki wins the round!

Rana Makki, enter your move: k

David Cao, enter your move: r
Rana Makki wins the round!

Congratulations Rana Makki!

You won EECS 183 Rock-Paper-Scissors-Lizard-Spock!

Menu Options
------------
1) Play rock, paper, scissors
2) Play rock, paper, scissors, lizard, spock
3) Quit

Choice --> 1

Rana Makki, enter your move: k

ERROR: Illegal move given, using default

26
David Cao, enter your move: p
David Cao wins the round!

Rana Makki, enter your move: l

ERROR: Illegal move given, using default

David Cao, enter your move: s

Rana Makki wins the round!

Rana Makki, enter your move: p

David Cao, enter your move: s
David Cao wins the round!

Congratulations David Cao!

You won EECS 183 Rock-Paper-Scissors!

Menu Options
------------
1) Play rock, paper, scissors
2) Play rock, paper, scissors, lizard, spock
3) Quit

Choice --> 3

----------------------------------------
  Thanks for playing
  Rock-Paper-Scissors!
----------------------------------------

27
S’more Sample Run 2

----------------------------------------
  EECS 183
  Rock-Paper-Scissors
----------------------------------------

Player 1, enter your name: Rana Makki

Player 2, enter your name: David Cao

Menu Options
------------
1) Play rock, paper, scissors
2) Play rock, paper, scissors, lizard, spock
3) Quit

Choice --> 2

Rana Makki, enter your move: o

ERROR: Illegal move given, using default

David Cao, enter your move: K

David Cao wins the round!

Rana Makki, enter your move: s

David Cao, enter your move: L
Rana Makki wins the round!

Rana Makki, enter your move: p

David Cao, enter your move: P
This round is a draw!

No winner!

Menu Options
------------
1) Play rock, paper, scissors
2) Play rock, paper, scissors, lizard, spock
3) Quit

Choice --> 3

----------------------------------------
  Thanks for playing
  Rock-Paper-Scissors!
----------------------------------------

28
How to Submit
• When ready to submit the implementation of S’more to the Autograder

◦ To submit rps.cpp, https://autograder.io/web/project/296

• On the new page, click Choose file and navigate to your file. The file you submit to the
autograder MUST be called rps.cpp.

• If confident that you’ve selected the correct file, click Submit to submit your code to the
Autograder.

• Make sure to first submit the Regular version for project. S’mores are for additional practice
and not for the points. However, we do take correct S’mores into consideration when we
determine final grades.

Don’t forget to submit your regular version of the project, even if you submit a
 S’more version. Your project grade comes from your submission the regular
version.

29