Rock Paper Scissors

 Zoom Name:
[The tutorial software in this segment was written new for this Fall term, so it may not work very well. If you did everything we said to do, and it doesn't behave like we said it should, it's my fault, not yours. Hit the Mentor button (or "Ask" for help in Zoom) and a Mentor will advance you manually. Oh, also some of the videos have not yet been recorded ("00 minutes") you will need to read the transcripts instead. I apologize for the inconvenience, it happens with new software, as you probably already noticed with your own code.]

Video Introduction (00 minutes) <<--- Watch this video first, then

English IDE <<--- Click this link and write your game design in the program panel.

When your game design runs, click the yellow Done button in the IDE to continue.
Then come back here and click this Next link to skip down to the next video.

If it's not a link yet, you might need to refresh your browser, or else click this button to call a mentor:

If you are like me and prefer to read at your own pace instead of whatever pace set in some video, You can read the transcript (and probably come out ahead of the non-readers).

Video Transcript: Rock Paper Scissors

Almost everybody knows how to play Rock Paper Scissors. If you never even saw it played, Google
How to play Rock Paper Scissors
RPS is a hand-motion game played between two people. Today you will write a computer program (in English) that plays one of those people (the other player is still a person). You should design your program as a description of what that one player does -- except the computer has no hands and watching the other person's hands is too hard at your present skill level, so we will use text input and output instead of hand motions.

So much for a general understanding. Without getting stuck on the details -- you understand the game, right? If you never played it, find somebody to play it with a few times. You need to be comfortable playing it yourself before you can tell the computer how to play it. (Your program in) the computer will call out the timing, and then the computer and person expose their plays for that round, then the computer will decide who won. When you play with your friend, you do that: you call the timing, then you both expose your hands, then you announce who won. Watch what you are doing, you will need to tell the computer to do that. Find somebody in the room to play RPS with you right now, so it's fresh in your mind.

This is important, you need to do this, so you will have all the steps clear in your mind. If you only imagine how it will go, you will miss some steps that you think are unimportant, but they really are. Watch what you actually do. Observation is important in science, it's important when you write novels or screenplays, it's important if you are an artist because you need to know what you are painting or sculpting actually looks like, it's even important when you interact with people as a politician or teacher or librarian. It's especially important when you are writing a computer program that models the real world, you need to look at what you are modelling.

Ready? Here's your title, what the computer program you are about to write is going to do:

"Play One Round of Rock Paper Scissors"
Go to our Integrated Development Environment and type your title, in quotes so the computer knows it's a subroutine name, into the program panel.
Button to open IDE
Then under it you will type in a name for each of three things your computer must do to play that round, one line for each, three lines under the title.

Remember the game you just played with your friend? What three things did you do? Focus on what you did, not what you were thinking or deciding. The computer doesn't think, it only does what you (the programmer) tell it to do. If you have more than three things in mind, you need bigger concepts, so that each of your ideas encompasses a whole third of the round (one round, we can add repeats later), what happened, what the two players did. But keep the names of each thing short, one to three words, maybe four or five, but mostly fewer words.

Type in those three short phrases in, one line each, then click the Run button. Don't worry if it's not perfect, writing an incomplete -- or even wrong -- program will help you to think about what it really should be, and thereby realize what needs to change.

If you are totally stuck, keep trying different things, or click Mentor button to get help. But you need to do this, it's an important part of programming. Do it now.

Here, I'll help you... try
Compare hands and score

When you Run that, the computer will help you realize that it's not the first step. What do you think we should do first? Write your own, then when it's OK, add a second line, and when they are both OK, add the third. One at a time, try it out each time. Don't feel bad if you have trouble with this, that's why you are a student, you need practice and (often) help. That's what we are here for.

Then when all three are OK, go back and click this Next link. If it's not a link, refresh the page in your browser. Or else go back to the IDE and make sure you have three OKs in your Design. Or call for a Mentor...

This video is for if you need extra help on the first three lines:

RPS Design Video (00 minutes) (transcript follows)

RPS Help w/3 Transcript

The Mentor tells me you are having some difficulty writing three lines to describe one play of Rock-Paper-Scissors. Do you understand how to play the game? Did you play with another person? If not, go back and watch the first Rock-Paper-Scissors video again. Or read the transcript. Or both. Do what it says: Play the game and watch what you are doing. If you can't play and watch at the same time, get another person, two people playing the game while you watch.

What happened first? Both players pumped their fist up and down three times. Do you know why they do that? The idea is to get both players doing it at the same time, so when they expose their play, nobody has an unfair advantage by seeing the other player's play before playing their own. It's different with the computer, because it's just text, but we do it anyway because it feels more like RPS. Can you in just a few words on one line describe what is happening before the two players expose their plays? Did the computer tell you your first line is OK? If not, try to get that right and click Run again.

If you are just not getting it, not to worry, a Mentor can come help you think about it. Maybe you need to spell your words more carefully. Computers are pretty fussy about spelling. You can do this.

After your first line is OK, let's work on the second line. The first part of each round, both players pump their fists up and down together while the caller (that would be your program) or else both humans together call out "One... Two... Three" or maybe "Rock... Paper... Scissors" or something like that to get the timing together. When that is done both players show their play at the same time. Your program will do it slightly differently, but we'll put in the second line what the human players do. Can you write what they do in one line? Did the computer tell you your second line is OK? If not, try to get that right and click Run again.

After your first two lines are OK, let's work on the third line. After they counted the timing (the first line), after both players showed their play (the second line), is it over? Not really, everybody looks at the plays to decide who won that round. "Scissors cut Paper" (scissors wins over paper), "Paper covers Rock" (paper wins over rock), and "Rock breaks Scissors" (rock wins against scissors). Otherwise it's a tie. We might think of this step as scoring the round. Can you think of a simple one-line way to say that? Did the computer tell you your third line is OK? If not, try to get that right and click Run again.

Then click the yellow Done button and come back and refresh this tutorial page in the browser then click this Next link to get to the next video. But that won't happen until the computer likes your three lines. If it's too hard, ask for a Mentor. If it's not a link, refresh the page in your browser. Or call for a Mentor. You need to make this work or you will not be able to write your own program when you get there.

Starting to Code RPS

RPS Subroutines Video (00 minutes) <<--- Watch this video next, then

English IDE <<--- Go write more of your game program.

When the next part of your game design runs, click the yellow Done button in the IDE, then come back here and click this Next link to get to the next video.

If it's not a link yet, you might need to refresh your browser, or else click this button to call a mentor:

If you are like me you can read the transcript.

RPS Subroutines Transcript

After you have added your three-line description of what your program must do, make a subroutine for each of those three things. You may recall, we did that with PBJ, but you can go back and review it if you don't remember the process clearly. For now you can put a single Print line with the name of the subroutine, followed by the end-of-subroutine command "Done". For example, if one of your three lines was "Scoring" then you would have a subroutine that looks something like this:
  Print "in Scoring"
Do this for each of your three lines. That way, when you click Run, it will print out the three subroutine names (instead of the computer commentary) before it stops.

If the computer does not do the print line -- or even if it complains about not understanding your original three lines, it might be that you misspelled the name of that subroutine. I do that a lot, so I try to use copy/paste to make sure the name is spelled the same in both places.

When it does that correctly, you will have three subroutines to fill out. It doesn't really matter which one you do first, so let's do the easy one. Can you figure out how to do the timing part?

When two people play, the player who does the announcing chants out, about once per second, "One... Two... Three!" or maybe "Rock... Paper... Scissors!" depending on who tells you how to play. The purpose for this timing chant is so that both players can pump their fist up and down together, then at the end of the third word (whatever it is), both players open their hands at the same time. Of course nobody is waving their fist up and down, but you can have the computer do the chant anyway. You will need some way to wait 1 second between prints, which the English computer knows how to do:

  Wait 1 second
I think you know enough to finish this subroutine, then Run it and then click the yellow Done button.

Then come back and refresh this tutorial page then click this Next link to get to the next video. If you have problems, that's what we're here for!

Choosing Computer Play in RPS

RPS Computer Play Video (00 minutes) <<--- Watch this video next, then

English IDE <<--- Go write the part of your game program where the computer chooses its play.

When that part of your game code runs, click the yellow Done button in the IDE and come back here and click this Next link to get to the next video. At least that's the way it's supposed to work 

If it's not a link yet, you might need to refresh this tutorial page in your browser, or else click this button to call a mentor:

You can also read the transcript.

RPS Choose Computer Play Transcript

Exchanging plays, that is, each player throws out their hand in one of the three defined shapes at the same time so they both see the other play at the same time, is also faked up somewhat for the computer. Your program will input the human player's play, one word (rock or paper or scissors) or the first letter of that word (r/p/s), which you as programmer get to decide, and then it prints out the computer's play (likewise). You are on your honor not to have the computer cheat. Besides, if the computer cheats, nobody will want to play your game.

Input and printing you already know how to do, just declare the two play variables at the front of the program (before the first subroutine) so they can be seen everywhere they are needed, like this:

Variable HumanPlay
Variable ComputerPlay
or whatever you want to name them.

You can look on the internet for all kinds of ideas on how to win at RPS, but they are a hoax. Like the stock market, if a perfect strategy existed, then everybody would use it and then it wouldn't be perfect, would it? Human players often try to psych out their opponents, perhaps look for a "tell" like poker players do, but you don't have the skills to do the computer camera yet -- maybe next year: we had a high school group doing an autonomous car for a while, and they took camera input, but it was very hard. So for now we will just play randomly.

Most programming languages (including the English computer) know how to do random numbers, usually between zero and one (for very fine gradation), or else some number of contiguous integers starting at zero. They are not really random (usually a couple billion before it repeats) but the sequence is so long, that it's good enough. In the English computer you would say:

Random rn < 3
if you want variable rn to be one of three random numbers, 0 or 1 or 2 (always less than three). Then you can use three If commands to choose one of the three words (or letters) for the computer play. Can you do that? Then move your Print line to be after you have both plays, and change it to print out the two plays. Make sure it runs correctly before advancing to the next step. If you are totally stuck, click the Mentor button here to get help.

Finally, you can do the scoring subroutine. Do you think you can do that? Try it. If everything works correctly, click the yellow Done button and refresh this tutorial page then this Next link will advance you to Seaman. If you need some help with scoring, the link will take you there (or read on). If you are totally stuck on the computer play, or if the automatic advancement software fails, click the Mentor button here to get help.

RPS Scoring

If you cannot think of a simple way to compare the computer and human plays, Watch this video (or read the Transcript):

Comparing Rock Paper and Scissors (00 minutes) Transcript follows

English IDE <<--- Go write the next part of your game program...

When your game code correctly compares the human and computer plays, click the yellow Done button in the IDE then come back here and click this Next link for other ways to score the game, or else to advance to the next video.

If it's not a link yet, you might need to refresh this tutorial page in your browser, or else click this button to call a mentor:

You can also read the transcript.

Comparing Rock Paper and Scissors (Transcript)

You cannot just compare the words "rock" to (for example) "scissors" because the normal alphabetic sort has scissors greater than both paper and rock. It's a bit tedious, but you can try all nine possible combinations, one at a time, where score>0 is the computer won, <0 is the human won:
if myPlay = "rock" then if HumPlay = "rock" then let score = 0
if myPlay = "rock" then if HumPlay = "paper" then let score = -1
if myPlay = "rock" then if HumPlay = "scissors" then let score = 1
if myPlay = "paper" then if HumPlay = "rock" then let score = 1
or you could preset a default, and reduce it to the six comparisons that are not a tie:
let score = 0
if myPlay = "rock" then if HumPlay = "paper" then let score = 1
if myPlay = "rock" then if HumPlay = "scissors" then let score = -1
You cannot use "otherwise" here because the mixed true/false tests confuse the English computer (for example, if both the human and the computer chose rock, the first compare is true, so English assumes no otherwise applies).

Some programming languages let you combine the multiple conditions using "and" or "or" but the English computer does not understand those words.

When you are playing this game, you will quickly see what a drag it is to type in the whole eight letters of "scissors" (or even the four or five of "rock" or "paper"), and if you don't spell it exactly right, the compare will fail and you can't win. Usually games like this let the user type in just a single letter (the first letter in this case happens to be unique among the three). The English computer will even capitalize it for you, so that it doesn't matter whether the user has caps-lock set or not:

Input HumPlay,1
Of course you must change the generated myPlay to be "R", "P", or "S" to match.

When you have this much working, you can stop here, click the yellow Done button and refresh this tutorial page so this Next link will advance you to Seaman, or if you are adventurous, you can try the mathematical scoring method...


If you like math, there's a really elegant approach you might be interested in. If math is not your thing, just stop here, and you have a working program (skip to exit). Otherwise...

If you convert the two plays into numbers (basically reverse the calculation you did for deciding the computer play) and multiply either of them (not both) times a larger number (three or ten) then adding them together gives you one of nine unique numbers, which you can test with a single conditional (so otherwise works) and your code is a little simpler, but not so easy to understand:

let h = 0
if HumPlay = "P" then let h = 1
if HumPlay = "S" then let h = 2
let score = h*10+rn  {rn is still 0/1/2 from the random calc}
if score=01 then let score = -1 {h=rock, r=paper, comp wins}
if score=10 then let score = 1 {r=rock, h=paper, hum wins}
if score=12 then let score = -1 {h=paper, r=scis, comp wins}
otherwise let score = 0  {00 or 11 or 22 = tie}
A more mathematical approach would be where you convert the plays into the ternary number system (base 3, assuming they taught you that in school), then the difference would be the desired score. If you do not understand strange number systems like ternary, then you might have trouble understanding this, but you could Google "ternary number" for a better understanding. Where other number systems are generally all positive, base-3 is often represented as zero and plus or minus 1. Here is the subtraction table (read the human play along the top, minus the computer play down the left, and the score is the table value:
H-C -1=R 0=P 1=S
-1=R -1 
0=P -1 
1=S -1 
For example, if the human plays rock (1st column) and the computer plays rock also (1st row), then the difference is zero, a tie. If the computer plays paper (zero, second row), that beats the computer's rock (-1: the human lost). If the computer plays scissors (bottom row) to the human rock, rock breaks scissors (+1, the human won). And so on.

So your code might look something like this:

let score = 0
if HumPlay = "R" then let score = -1
if HumPlay = "Z" then let score = 1
if myPlay = "R" then let score = score+1
if myPlay = "S" then let score = score-1
if score>1 then let score = -1
if score<-1 then let score = 1
The first three lines convert the human play to ternary. The next two combine turning the computer play into ternary and subtracting it from the human play. The difference (in ternary, but not decimal) will be +1 if the human won, and -1 if the computer won, which is exactly what we want to know.

You already have numbers for the computer play (from Random), you can subtract one from that value to convert it into signed ternary, and then those two "myPlay" conditionals turn into a simple subtract:

let score = score-(rn-1)
You can also combine those last two lines into one. If you subtract -1 from +1, the result (in decimal) is +2, which is out of range, it needs to be wrapped around to -1; that's the first of the two lines. The other way around it goes negative to -2 and must wrap around to +1 in the other line. In both cases the intermediate result is (plus or minus) two, which squared is +4. The wrap-around wants to be the negative of whatever you had, but one instead of two, like this:
if score*score=4 then let score = -score/2
This is a little shorter than the six compare lines, but carries oh so much more bragging rights (assuming you understand how it works). If you get lost in the math, stick with the six compare lines above: it's much more important that you understand what your program does (and therefore it works and you can explain it) than that it looks elegant but fails in ways you do not understand and Bad Things Happen. Programmers do not go to jail* for writing bad code today, but in your lifetime that will start to happen. Don't be one of them: it might be too late after you find out.

If you have trouble, ask another student, or click the Mentor button here to have one of us look at your program and suggest a way forward.

Click this link to advance to Seaman

* Jail: Most of the people designing autonomous cars truly believe that cars can be smarter than the people who designed them. If they convince enough legislatures and governors to agree, there will be a million autonomous cars and trucks out there on the streets in your lifetime. Even if the cars really are smarter than people (and the physics says otherwise), accidents will happen, stupid people will get in the way of the cars, and at first they will blame the owner. Then a celebrity will lose her child and hire a high-priced law firm, and they will go after the manufacturers, who will offer up the programmers as scape-goats. That will be the end of autonomous vehicles on city streets for a couple centuries, but the floodgates will already be open. Once they get a few programmers in jail, all those fine-print "Licenses" you must agree to when you start up a new program will go in the trash and programmers everywhere will be required to defend their code or go to jail. You need to be ready for it, because this will happen in your lifetime.

[2022 October 24]