p2-rps

EECS 183 Project 2: Rock-Paper-Scissors

Due Friday, February 26th at 8:00 p.m. (accepted until 11:59:59 p.m.)

Wellness Day is Wednesday, Feb. 24 - we encourage you to use it! The 5% deadline has been moved to Thursday, Feb. 25th.

Overview

In this project, you will be implementing 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.

This project is significantly more difficult than Project 1 and you can expect it to take 2 to 3 times longer to complete.

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

rps

Objectives

By completing this project, you will learn to:

You will apply the following skills you learned in lecture:

Getting Started

Starter Files

You can download the starter files using this link.

The IDE setup tutorials for Visual Studio and XCode include a video about how to set up a project using the starter files. You can access the tutorals here:

Make sure there are 3 files in your project: rps.cpp, test.cpp, and start.cpp.

Submission and Grading

Submit your code to the autograder here. You receive 4 submits each day and your best overall submission counts as your score. You can find where the files you need to submit are on your computer using these steps from Project 1. You will submit two files, which must be called rps.cpp and test.cpp.

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

Here is a grade breakdown:

The deadline is Friday, February 26 at 11:59PM Eastern. To encourage you to take advantage of the Wellness Day on Wednesday, February 24, the 5% bonus deadline will NOT be on Wednesday, Feb. 24 but instead will be on Thursday, Feb 25. If your last submission is on Thursday, February 25 by 11:59PM, you will receive a 5% bonus. There is no 2.5% bonus day for this project. If your last submission is on Wednesday, February 24 by 11:59PM, you will receive a 5% bonus. If your last submission is on Thursday, February 25 by 11:59PM, you will receive a 2.5% bonus.

You have 3 late days that you can use any time during the semester for projects. There are 3 late days total, not 3 per project. To use a late day, submit to the autograder after the deadline. It will prompt you about using one of your late day tokens. There are more details about late days in the syllabus.

Remember that we grade your BEST submission for style. If multiple submissions are tied in score, we take the last of those.

WARNING: Beware the autograder’s ability to detect cheating! See Collaboration Policy for further information.

Understanding the Distribution Code

Stubbing functions means adding the minimal necessary code to make a function compile. For example, some of the functions in rps.cpp have return types of bool. We have added return false in those functions so that they will compile even if you have not implemented all the functions yet. Be sure to remove our return statements when you write your own implementation of the function.

Testing Your Setup

Once you have created a project, you should be able to compile and run the distribution code. We have included a main() function in start.cpp which will allow you to run either your tests or the rps application.

  -------------------------------
  EECS 183 Project 2 Menu Options
  -------------------------------
  1) Execute testing functions in test.cpp
  2) Execute rps() function to play game
  Choice --> 1

  Executing your test cases
  Now testing function isMoveGood()
  'r': Expected: 1, Actual: 1
  'q': Expected: 0, Actual: 1
  ...
  

The second test case currently fails because the isMoveGood() function is not fully implemented yet.

How to get help

Most students in EECS 183 need help from staff and faculty multiple times each project. We’re here for you! Many more people need help with Project 2 than with Project 1.

If your question is about the specification or about something about the project in general, Piazza is the fastest place to get help.

Office Hours: All office hours and instructions for signing up/attending can be found under the Office Hours tab on the course website.

Group office hours: Group Office Hours are a great way to clear up commonly confused topics for projects. See this Piazza post for full details.

Individual office hours: You can get 1-1 help over a video call by signing up for office hours at eecsoh.org. You can find instructions here.

Collaboration Policy and the 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.

We want students to learn from and with each other, and we encourage you to collaborate. We also want to encourage you to reach out and get help when you need it.

You are encouraged to:

To clarify the last item, you are permitted to look at another student’s code to help them understand what is going on with their code. You are not allowed to tell them what to write for their code, and you are not allowed to copy their work to use in your own solution. If you are at all unsure whether your collaboration is allowed, please contact the course staff via the admin form before you do anything. We will help you determine if what you’re thinking of doing is in the spirit of collaboration for EECS 183.

The following are considered Honor Code violations:

The full collaboration policy can be found in the syllabus.

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. Discussing the project with other students will NOT be an issue. Sharing code between students, even if it’s just one function, 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.

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 students involved in honor violations cannot withdraw from nor drop the course.

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 more of the three rounds than their opponent to win the game. The game will result in a tie if no player wins more rounds than the other player. For example: if Player 1 wins the first round while rounds 2 and 3 both result in a draw, Player 1 would win the game since they have won more rounds than Player 2.

IMPORTANT: 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. Use of a diffchecker can easily catch such errors.

Here is an example of what the execution of your final application will look like:


    ----------------------------------------
                   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!
    ----------------------------------------

Development Cycle with Functions

In Project 1, you had to divide the program into pieces so you could test each part individually. In Project 2 and later, the program is already divided into functions in the starter code which you can use as the parts to work on. You should write, test, and debug one function at a time. See Lecture 5 for a recap of how to implement the iterative development cycle for functions.

The functions in a program call each other, and it is easiest to start with the functions that do not call any other functions. For example, in this project, getMove() will call isMoveGood(), so it makes sense to complete isMoveGood() before getMove(). We will be able to test isMoveGood() before we write the code that actually uses it in our program.

The order you write the functions will be different than the order they will appear in rps.cpp. We provide a suggested order for writing your functions in the Suggested Timeline.

Solution Overview

NOTE: Even though we are going over what happens in rps() early in the specification, this does NOT mean you should begin your implementation with rps(). Actually, you should write rps() last, after you have implemented all of the other functions, since rps() will work by calling all of the other functions.

----------------------------------------
               EECS 183
          Rock-Paper-Scissors
----------------------------------------
----------------------------------------
               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.

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

printInitialHeader()

printMenu()

printErrorMessage()

printCloser()

getName()

getMenuChoice()

isMoveGood()

IMPORTANT: 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. Those are bad input and prohibited by the REQUIRES clause.

getMove()

There are two things that could happen depending on the character that the user inputs for their move:

David Cao, enter your move: p
David Cao, enter your move: a

ERROR: Illegal move given, using default

isRoundWinner()

announceRoundWinner()

doRound()

announceWinner()

doGame()

Putting it Together: Writing rps()

Function Table

The table below provides an outline of which other functions each function should call, if any. You should not be using other functions if not specified.

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()
rps() getName(), getMenuChoice(), doGame(), announceWinner()

Here is an example of how to read the table:

Suggested Timeline

Note: It’s common to not completely understand the project after reading through the spec. This is okay! You can start working on the project without fully understanding the spec. In fact, working on the project will likely help you better understand the spec.

As an approximate timeline, you will be on track if by:

Creating a Project

If you haven’t done so already, read the 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, test.cpp, and start.cpp.

Xcode

Visual Studio

IMPORTANT: Repeat the process to add test.cpp and start.cpp to your project.

NOTE: 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 and test.cpp.

Running the Program

Once you have created a project, you should be able to compile and run the distribution code. We have included a main() function in start.cpp which will allow you to select exectuing your test cases or executing the game Rock Paper Scissors. When executing your project, you should see the following message:

Testing Overview

Testing getName() and getMenuChoice()

Implementing Test Functions for Submission

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 this part of the project. The autograder will tell you the names of the bugs that you have exposed, from the following set:

Preparing your test.cpp for Submission

How to Submit

Where to Begin

Style Checklist

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

Sample Output

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

NOTE: The following sample runs do not include the menu selection detailed in Running the Program.

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!
    ----------------------------------------

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


    ----------------------------------------
                   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
    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 Functionality

OPTIONAL: For more practice and fun, check out the S’More for Project 2. With this optional challenge you can update your project to play rock, paper, scissors, lizard, spock.

Style

Your code must follow the EECS 183 style guide.

Style Rubric

Top Comment

Must have name, uniqname, program name, and project description at the top of the file.

If all or part of the top comment is missing, take 1 point off.

Readability violations

-1 for each of the following:

Indentations

Spacing

Bracing

Variables

Line limit

Statements

Comments

RMEs

Coding quality

-2 for each of the following:

Global variables

Magic numbers

Function misuse

bools