Ninja-Cowboy-Bear is a fun variation of rock/paper/scissors. There is an entire website dedicated to this game:
(Sidenote: I was also introduced to the bear-fish-mosquito variation this summer if you want to tie in ecosystems!)
I emailed the folks running the NCB website asking for permission to reuse their graphics, and Hilary Leung graciously approved this request.
This is an open-ended challenge with lots of room for variation. Attached is what my students came up with, including the graphics from the NCB folks you can reuse. For your class: you'll want to delete the index.html file (and the kung fu sound) and rewrite it from scratch.
Here is a rough outline of how this lesson played out:
1. Introduce ninja-cowboy-bear as an icebreaker. Students stand up, pair off, and play a few rounds. On the dry-erase board write a 3x3 table showing which player wins for each combination.
2. Ask students to return to their seats. Explain that now you are going to program this game. The first step has nothing to do with programming: first they have imagine what the game should look like. This is the design. Sketch on the dry-erase board how game play works. Ask, "What should the user first see when they sit down to play this game? Then what should happen?"
3. Begin implementing this design one piece at a time. Using one computer connected to a projector: let students take turns programming. When you spot syntax errors: challenge the class to identify where they are. (Explain that there will be several, and that this is normal.)
We ended up using two divs: "intro" and "battle". We had a design decision (and a vote) about whether you should just click the image or whether we wanted a button. (When they voted to include the button: I jumped in and wrote a simple HTML table for them to help format the button placement--since that's outside the scope of our class.)
4. Every 10-15 minutes (after wrapping up an object or function): save and open the webpage in a browser. Test what you have so far. Does it perform as expected? If not: why not? If so: what do you want to add next?
When students get to the point where they're copying and pasting code: intervene and create an abstract function.
5. Introduce the Math.random() method for the computer's choice. Students had a surprisingly hard time using this method to help the computer make a choice. This required a mini-lesson on the board using a number line and fractions. (You could also ask: "What will happen if the fractions are different? .5/.25/.25? .8/.1/.1?)
6. Once you have the computer's choice: refer back to the 3x3 table to help double-check whether you're calculating the winning/losing/tying condition correctly.
Once we had our basic game up and running, we looked for ways to improve it.
7. We went to freesound.org to look for sounds, and found a kung-fu-yell sound that we play whenever you win. (This doesn't make sense if you win as the cowboy or bear, but that was their choice). We happened to choose a sound that doesn't require attribution, but you take this opportunity to teach them about attribution and how to legally reuse media. If you might do this: be sure to create an account in advance. (You must have a registered account to download sounds.)
We didn't get around to this, but if we had extra time I was going to introduce this challenge:
Try asking them to make a version that cheats. But not all the time -- that would be too obvious. Ask how frequently it should cheat before it would be obvious: 60% of the time? 75%? They could introduce a hidden button or easter egg to give the user an unfair advantage (so the computer only wins 30% or 40% of the time).