4.7.11 rock paper scissors is a useful programming exercise because the game is familiar but the implementation still demands careful decisions. You must represent two choices, compare them consistently and decide what happens when the user enters something unexpected. A working program is more than a collection of conditions that happens to produce one correct result.
The public CodeHS AP Computer Science A Mocha outline lists “Rock, Paper, Scissors!” as exercise 4.7.11, following a get-winner exercise. This guide focuses on Java reasoning, not a verified answer key. Read your assigned prompt for exact method signatures, output wording and stopping rules. Sources were checked on 20 October 2026; illustrations are AI-generated learning concepts.
4.7.11 Rock Paper Scissors: write the rules first
There are three choices for each player, giving nine possible pairs. Equal choices produce a tie. Rock defeats scissors, scissors defeats paper and paper defeats rock. Before writing a conditional, put those outcomes into a table. This gives you a small, complete test plan rather than a vague impression that the game works.
| User choice | Computer: rock | Computer: paper | Computer: scissors |
|---|---|---|---|
| rock | Tie | Computer wins | User wins |
| paper | User wins | Tie | Computer wins |
| scissors | Computer wins | User wins | Tie |
Read the table by row and column. In the paper row and scissors column, the computer wins. Reverse the choices and the user wins. That simple reversal check catches a surprisingly easy mistake: writing the right relationship but awarding the result to the wrong player.
Separate deciding the winner from running a round
Think of the winner calculation as a small function with two inputs and one output. It should not need to ask for keyboard input or generate a random choice. Given the same two valid moves, it should always return the same result. That makes it easy to test before the rest of the game exists.
The surrounding round handles interaction: obtain the user’s choice, decide whether play should stop, validate the input, choose a computer move and display the result. Keeping these responsibilities separate makes debugging more precise. A wrong comparison is different from a prompt that never reads a new line.
An original decision outline
The following is pseudocode, not Java to paste into an editor. It assumes both arguments have already been validated as rock, paper or scissors. Translate it into the structure your course supplies, preserving any required method name and return type.
IF user choice equals computer choice:
result is tie
ELSE IF user has rock AND computer has scissors:
result is user wins
ELSE IF user has paper AND computer has rock:
result is user wins
ELSE IF user has scissors AND computer has paper:
result is user wins
ELSE:
result is computer winsThe final branch is justified only because invalid choices were removed earlier. Without that assumption, a misspelling could incorrectly become a computer victory. Write assumptions beside helper methods while learning; they explain why a short implementation is complete rather than merely convenient.
Compare Java strings by their contents
Oracle’s String API documentation describes equals for content comparison and isEmpty for a zero-length string. Use content comparison for moves rather than treating == as a general text-equality test. An empty string and a null reference are also different things.
For example, "rock".equals(user) asks whether the input contains that exact text. Case and spaces matter unless you deliberately normalise them. Decide whether your assignment accepts only the displayed lowercase words or permits variations, then follow that requirement consistently rather than changing behaviour halfway through debugging.
Our guide to values and data types provides related background: representations that look similar are not always interchangeable. In this game, the distinction between text, a Boolean comparison and the result message is worth keeping explicit.
Give each computer move one place in the mapping
If you use standard Java, Oracle’s Random documentation specifies that nextInt(bound) includes zero but excludes the bound. With a bound of three, the possible integers are zero, one and two. A course-provided random helper may use a different interface, so read its own documentation instead of assuming identical endpoints.
Write the mapping down before connecting it to the game: zero becomes rock, one becomes paper, two becomes scissors. Each possible integer should produce exactly one valid move. Do not leave an unused number that results in empty text, and do not accidentally assign two numbers to one move while omitting another.
During testing, temporarily choose the computer move directly. Randomness makes repeated tests less predictable, which is unhelpful when you are trying to reproduce one faulty outcome. Once all nine comparisons are correct, restore the random selection and check that its outputs remain within the intended choices.
Handle stopping and invalid input deliberately
If your assigned version says that pressing Enter ends the game, check the empty input before attempting a round. Do not print a computer choice or winner after the user has already requested an exit. If the prompt specifies a different stopping rule, use that rule instead.
For invalid nonempty input, decide where the program returns to the prompt. The important point is that the input must change before the same validation is attempted again. A loop that continually examines the same rejected value cannot make progress, no matter how accurate its error message is.
Keep the termination check distinct from validation. An empty line can be an intentional instruction to stop; an unrecognised word can be a request to try again. Treating both as a loss confuses interaction with the game’s actual rules.
Test 4.7.11 Rock Paper Scissors systematically
Run the nine table cases as controlled tests and record expected and actual outcomes. Then check the interaction separately: one valid round, several rounds, an invalid word and the required exit input. If normalisation is allowed, add examples with capital letters and surrounding spaces.
The same small-step approach appears in our Leash graphics debugging guide. Although that exercise uses a different language environment, the transferable habit is to isolate a responsibility before combining it with others.
Frequently asked questions
Is this an official 4.7.11 answer?
No. It is an original learning guide supported by public course and language documentation. Your teacher’s assigned requirements remain authoritative.
Why does a misspelled move produce a winner?
Your final outcome branch may be receiving invalid input. Validate the move before calling the winner calculation.
Why do random tests miss a bug?
A random run may not exercise every pair. Use the nine-case table with controlled inputs before relying on ordinary gameplay.
Make every branch earn its place
The lesson in 4.7.11 rock paper scissors is not memorising nine answers. It is learning to define valid inputs, organise exhaustive decisions and test them independently. When you can explain why the last branch is correct, you understand the program rather than just its output.
