Rob Cook


Home | Donate

Rock, paper, scissors, code! - part two


2020-04-06

Reviewing our game

We have a complete game, which is an achievement to appreciate. However programmers are forever on the look out for ways to improve their work, so let's take a step back and cast a critical eye over our program.

Only once

The most obvious limitation of our game is that it only lets you play once. Sure we can run the program again, but it would be nice if we could keep playing. If we did this we might even be able to write a tougher computer opponent, one that remembers each game and makes a choice more likely to beat you, instead of picking numbers at random.

Let's keep a list of all the potential improvements we could make to our game. Programmers often refer to such a list as a backlog. It's common to have more in the backlog than you have time for! Part of being a progrmmer is accepting there is always more that could be done to improve things.


Backlog for Rock, Paper, Scissors

- Feature: Let the game be played more than
  once, until the player decides to stop.

Invalid input

When playing the game you may have noticed a bug. What happens if you entered a number other than 1, 2, or 3? The input() function just reads the keys entered on the keyboard. It does nothing to validate the input, to make sure it is one of the numbers our program recognises. In fact we could enter a letter, word, or a whole line of text instead of a number. This gives our program a real headache.

Task

Run your program and enter a letter instead of a number when prompted. See the error that Python reports at the bottom of the screen.

Good programs are written to cope with such invalid input. Instead of erroring they gently prompt the user again until a proper choice is made. Let's make our program one of the good ones.


Backlog for Rock, Paper, Scissors

- Feature: Let the game be played more than
  once, until the player decides to stop.

- Bug: Player can enter an invalid choice,
  causing an error. Make sure the game only
  plays when 1, 2, or 3 is chosen.

Improving the code

Finally you may have noticed a lot of the code in our program was to do with mapping between the numbers of the choice variables, and printing out the words rock, paper, and scissors. Here's all of the code we used for that.


# Show player choice.
if player_choice == 1:
    print("rock", end=" ")
elif player_choice == 2:
    print("paper", end=" ")
else:
    print("scissors", end=" ")
# Show computer choice.
if comp_choice == 1:
    print("vs rock")
elif comp_choice == 2:
    print("vs paper")
else:
    print("vs scissors")

That's nearly half of our program! If the Python library had a function called choice_to_word() that gave us the correct word for each number, we could simplify this code a great deal.


player_word = choice_to_word(player_choice)
comp_word = choice_to_word(comp_choice)
print(player_word, "vs", comp_word)

Python's library doesn't have such a function. However we can write one to do just that. Writing our own functions lets us use the same code in many places in a program without having to write it all again. The less code, the less chance of errors.


Backlog for Rock, Paper, Scissors

- Feature: Let the game be played more than
  once, until the player decides to stop.

- Bug: Player can enter an invalid choice,
  causing an error. Make sure the game only
  plays when 1, 2, or 3 is chosen.

- Feature: Write a function to map the numbers
  1, 2, and 3, to the words `rock`, `paper`,
  and `scissors`.

So that's our backlog. Of the three items it's fair to say the bug should be our first priority. Deciding which of the two features we do next is a bit harder. Playing the game many times is an improvement that players will notice. Whereas writing our own function doesn't change the game, but improves our code. Some programmers prioritise new features, others like to have cleaner code. Either choice is valid.

Personally I would add the function first, then tackle the feature to play the game many times.

end