Rock–Paper–Scissors (The Odin Project)

Practice: Scope & Conditionals in JS

A small browser game I built to practice JavaScript scope, conditionals, and DOM events/updates.

Overview

Click Rock / Paper / Scissors to play rounds against a computer opponent.

• Scores update in the UI after each round
• Focus of this repo: how functions see variables (scope), how if/else logic decides winners, and how event listeners trigger code

Why this project

I used this as a sandbox to understand:

• Function vs block scope – let/const inside if/switch/functions and their visibility
• Conditionals – strict comparison (===) and correct use of && / ||
• DOM updates – writing to elements with textContent after state changes
• Event listeners – addEventListener vs inline onclick, and the difference between passing a function reference vs calling it immediately

How to run

1. Clone the repo
2. Open index.html in a browser (no build step required)
3. Click Start Game, then choose Rock / Paper / Scissors

Files

rock-paper-scissors/
├── index.html    # Markup with buttons and output containers
├── style.css     # Basic styles
└── script.js     # Game logic (computer choice, round handling, UI updates)

How it works (quick tour)

Computer choice:
Math.random() → getRandomInt(3) → switch to "Rock" | "Paper" | "Scissors"

Game state:
playerWins, cpuWins, roundCounter stored in the gameLoop closure so roundLoop can read/update them.

Round logic:
In roundLoop(playerChoice):

• Compare playerChoice and cpuChoice with strict equality
• Use AND (&&) for "A beats B" checks
• Increment the right score, recompute currentScore, and update the DOM (textContent) after changes

Events:
Buttons use addEventListener("click", () => roundLoop("Rock")) (arrow wrapper defers the call until click).

Things I deliberately practiced

Scope

• Variables declared inside if/switch blocks with let/const don't leak out
• Returning from inside an if returns from the enclosing function, not just the block
• Event handlers run later, so you can't "return from gameLoop" once it's done; instead use shared flags (e.g., isOver) or remove listeners

Conditionals

• === over == to avoid coercion bugs
• Correct use of && vs || in win conditions
• Order of checks matters (early return ends the function)

Events & DOM

• addEventListener("click", handler) expects a function reference
• handler() calls immediately; () => handler() delays until the click
• DOM isn't reactive—reassign text after state changes

Known limitations (by design for learning)

• Game reset/disable after win is minimal
• No persistence or animations
• UI is intentionally simple

License

MIT (feel free to use/modify while learning)