# Can Keith Code: Lesson 2, Rock, paper, scissors and user feedback

## In which our intrepid reporter discovers why developer friends get moody whenever they solicit user feedback.

"Can Keith Code?" is a series exploring the journey of a former middle-school programmer-turned-journalist as he re-attempts to learn a programming language, alongside his three children (and, hopefully, beyond). The goal? By the end of the series, Keith will know at least two or three different languages: Scratch, Python and Javascript.

With the kids in bed after our first Scratch project, I decided it was time to see if I could program something without them asking me to pick a new image or change the number of times our mouse/monkey or donut would move.

My project: To figure out the logic of a simple game of Rock, Paper, Scissors and convert it into the Scratch language and interface. If I could figure out that part, I could then add fancier items like graphics and sounds, and (gasp!) even scoring.

The basic structure of my program was that I'd ask the player to choose their option -- either rock, scissors or paper and have them type it out -- Scratch has a neat command that handles this. The "answer" becomes the variable which can then be used to determine whether the player or computer wins the match. For the computer (or AI, if you want to get all fancy), I had it choose a random number between one and three. "One" would be Rock, "Two" would be Paper and "Three" would be Scissors.

With both variables selected, I then created a series of "If/Then" statements, determining whether the player won, the computer won, or if there was a tie. This is where it got a bit tricky, because I tried to convert the text answer of "Rock" to the numerical value of "1" by creating a bunch of new variables. Clearly, I was making things more complicated than they needed to be. I started to remember why I switched interests from computer programming to writing/journalism. After a few minutes of swearing ("Why won't this stupid program work?"), I realized I could just combine the statements into something like "If answer = rock and computer-choice=2 (Paper), then computer wins" (it looks more elegant within the Scratch interface). After figuring out each statement (three winning possibilities for the computer, three possibilities for the player and three possible ties), I had the basic structure of a game.

I added a background image (a brick wall implied that this was a street-corner game), and the player would be challenging one of the Scratch sprites, a nice little cartoon penguin. After each round, I added a "forever" loop, which means that you'd keep playing the game, and either winning, losing or tying, until you stopped.

Voila! A program. Now for "quality control" or game testing, which meant showing the program to my wife and kids.

Showing it to the kids was pretty easy -- they know how to play Rock, Paper, Scissors, so they kept playing until they won against the computer, or trying to find all of the different scenarios. This was made easier because I then had them record their voices into the game, with each child saying things like "I pick Paper!" or "Paper covers rock -- I win!" or "Rock breaks scissors -- you lose! Wah wah wahhhhhh". The addition of allowing them to record their own voices makes Scratch a winner, and really keeps the kids engaged.

When my wife played the game, however, the hardest part was convincing her that the computer wasn't cheating -- since the player picks first, she assumed that the AI would just "see" the choice and pick the appropriate response in order to win. I tried explaining that the AI was generating a random number, but it didn't help that in the first four or five games, she kept losing to the AI. Eventually she did win, although I now had my first set of "user notes" from a game tester.

In fact, getting feedback from both my wife and kids made me realize something about coding -- you're never quite done with a program, are you? Immediately after I "finished" the game, I started thinking of different things to do to try to improve it. For example, instead of typing in "Rock," "Paper" or "Scissors", I should program it so that the user clicks an image of their choice. I should add a scoring component so that instead of making the player stop the game when they get bored, you could play until someone wins 5 games (or 10, or make the user choose!). I should add some animation!

I now understand why some developer friends get moody whenever they solicit user feedback.

Other than the addition of the kids' voices to the winning/losing scenarios, I haven't changed much of the game. I will likely add the scoring component at some point, but that will take a back seat as we learn more Scratch commands and try to figure out some other possible games/scenarios to write.

Related:
Shop Tech Products at Amazon
``` ```