Building the Codehs 4 7 11 Rock Paper Scissors Game
The CodeHS 4 7 11 Rock Paper Scissors lesson walks you through making a simple two-player or player-versus-computer game using conditional statements and the Math.random() function. It's one of those early programming exercises where you learn to chain if/else blocks together, but people tend to overcomplicate it because they haven't seen the expected structure yet. At its core, the activity asks you to generate a random number for the computer, accept input from the user, compare the two choices, and output who wins the round. The specific version in lesson 4-7-11 uses an online coding environment where the computer choice is represented as a number between 0 and 2. Zero is typically rock, one is paper, and two is scissors. You get started by calling Math.floor(Math.random() * 3) and storing that in a variable like computerChoice. Then you ask the user for their input. In CodeHS, that usually means using the prompt() function or the built-in input tools the platform provides.
Here's what the basic flow looks like in code: var computerChoice = Math.floor(Math.random() * 3);
var userChoice = prompt("Enter rock, paper, or scissors:"); The tricky part is the comparison logic. You can't just compare the strings directly because the computer picks a number. You have to translate the user's text into a comparable value, or translate both into a common format. I ran into an issue once where my if conditions were checking the raw string against a number, and the compiler kept saying the result was always false. I fixed it by converting the user's input to lowercase with .toLowerCase() before running any comparisons. That saved me a lot of debugging time.
The Conditional Logic Breakdown
After both choices are established, the if/else chain handles every matchup. A correct implementation covers every winning and losing combination explicitly. The computer wins if rock beats scissors, paper beats rock, and scissors beat paper. The reverse conditions apply for the user winning. Anything else is a tie. A common mistake beginners make is only checking one side of the relationship. They'll write an if block for when the user wins, then assume everything else is a loss. That misses the tie case entirely and produces incorrect results roughly a third of the time. Always include an else branch that handles the draw condition. Another thing to watch out for: string matching. If the user types "Rock" with a capital R, a direct string comparison will fail. The .toLowerCase() call is essential here. Without it, the program behaves inconsistently depending on how the user formats their input. I've seen students lose points on CodeHS for this exact reason even though their logic was sound otherwise.
Get the Full Details
The full comparison section ends up looking something like this: if (userChoice === computerChoice) {
console.log("It's a tie!");
} else if ((userChoice === "rock" && computerChoice === 2) ||
(userChoice === "paper" && computerChoice === 0) ||
(userChoice === "scissors" && computerChoice === 1)) {
console.log("You win!");
} else {
console.log("Computer wins!");
} That structure covers every valid outcome without unnecessary nesting. You could flip the logic around and check the computer's wins instead, but the result is the same and the code is just as readable either way.
Input Validation Considerations
The CodeHS version of this activity doesn't always require input validation, but in practice it's the first thing that breaks when someone types anything other than the three expected words. If the grader checks for edge cases, an invalid input might cause your program to crash or produce unexpected output. Wrapping your comparison logic in a simple check that verifies the user's entry before proceeding will prevent that. Something as basic as confirming the string is either "rock", "paper", or "scissors" after lowercasing is enough. If your version of the lesson requires a loop that keeps asking until valid input is received, the pattern is straightforward. Set up a while loop that continues while the input doesn't match one of the three valid strings. This adds a few lines but makes the program robust. CodeHS instructors sometimes deduct points for missing validation even when it's not explicitly listed in the instructions, so it's worth including.
Output Formatting
The final piece is displaying the results clearly. The activity expects you to show the computer's choice alongside the winner announcement. That means translating the computer's numeric choice back into a word before printing. A switch statement or a simple array lookup handles this cleanly. For example, you can create an array like ["rock", "paper", "scissors"] and index into it with the computer's number to get the display string. This translation step is easy to skip. Your program will still run correctly without it, but the output won't match what the grader is looking for. The lesson specifically asks for the computer's choice to be revealed, so make sure it appears in the console output. Overall this lesson is straightforward if you keep the logic linear and test each branch separately. Start by verifying the random number generation works, then test the tie condition, then add the win conditions one at a time. That approach catches errors faster than writing the whole thing and running it once at the end.
