Rock Paper Scissors Analyzer (Certification Project)

[beaucarnes]

Create project from the Python machine learning certification.

[x-dune]

I tried this project on and off for about two weeks, and I was finally able to beat all four bots. At the end of the day, I really liked the concept of this project 😄.

Maybe, I am quite daft, but this project was really challenging for me. Perhaps I don't have the prior knowledge required.

I felt the instructions were too vague and open ended, and I ended up doing deep dives on a few solutions that didn't generate good results. The hint was very helpful, but I think a few more pointers could help guide campers towards the solution.

Abbey was a lot harder to beat than the other 3 bots, I was only able to beat Abbey by checking the RPS_game.py. I basically implemented the same strategy as Abbey. Which to my understanding; is a Markov Chain. I used that to predict Abbey's prediction of my move and countered it. I couldn't think of a better approach 🤷‍♂ .

[beaucarnes]

@adamdune Thanks for your input. You said you thought the instructions were too vague. Do you have any specific suggestions on how to make the instructions more clear?

[x-dune]

@beaucarnes I suppose it's not really vague as much as it's very open-ended. However, I assume the nature of this project in particular is meant to be open-ended to encourage the camper to think for themselves. Which is perfectly fine.

But, I felt like there isn't many options to beat Abbey aside from implementing a Markov Chain.

Of course, I definitely could be wrong here. If there are many possible methods to beat Abbey that the campers can stumble upon in their research, then that suits the project's open-ended nature.

On the other hand, if the options to beat Abbey is too limited, then I'd consider reworking Abbey's difficulty or point to some helpful resources to guide the campers.

[borntofrappe]

I haven't completed the project yet, as I'm trying out different approaches, but I've already a few suggestions for the README file.

Typos

• when introducing the program the word usually is misspelled to usualy

A program that picks at random will usualy win 50% of the time.

• describing the RPS file, the word argument is misspelled agument

create a function called player that takes an agument which is a string containing the last move of the opponent

• describing the first argument, the word receive is misspelled recieve

A player function will recieve an empty string as an argument

• describing the play function, the snippet provided as example passes a verbose argument misspelling the word to vebose

play(player, quincy, 1000, vebose=True)

Wording

I've a couple of suggestions for the content of the README as well. Personally, I've found the paragraphs introducing the player and play function to be quite confusing. The position of the hint is also a tad misleading. Let me elaborate.

player()

In the file RPS.py, create a function called player that takes an argument which is a string containing the last move of the opponent ("R", "P", or "S").

The function is already present in RPS.py, so the challenge is to actually complete the body of the function. Most importantly, the function takes two arguments.

To this end, I'd suggest modifying the text with something similar to:

In the file RPS.py you are provided with a function called player. This function takes two arguments:

• a string describing the last move of the opponent ("R", "P", or "S")

• a list detailing the history of the opponent's moves

play()

My issue is actually with the Development section as a whole. I would suggest to:

1. move the text wrapped in parenthesis either at the top or the bottom of the section. This can also provide more weight on the warning.

Do not modify RPS_game.py.

1. rephrase the paragraph describing the play function to stress its testing purposes and lay out its arguments more clearly. Something along the lines of:

To test your code, the play function takes four arguments:

• two players to play against each other a game with the play function (the players are actually functions)

• the number of games to play in the match

• an optional argument to see a log of each game. Set it to True to see these messages.

Hint

Since the hint is connected more to the assignment than the development section, I'd suggest moving the italicized text under the Assignment heading. This should also create a more clear separation between the two sections (I 've found this separation to be much clearer in the scientific computing projects).

Let me know if that helps, or if you need more information 👍

[beaucarnes]

@borntofrappe Thanks for your input. I incorporated most of it. I added a new section in the README to explain why the example player function had two arguments. It only is ever called with one argument. I'd love your input on if the new explanation makes since. Here is the paragraph I added about the player function arguments.

The file RPS.py shows an example function that you will need to update. The example function is defined with two arguments (player(prev_play, opponent_history = [])). The function is never called with a second argument so that one is completely optional. The reason why the example function contains a second argument (opponent_history = []) is because that is the only way to save state between consecutive calls of the player function. You only need the opponent_history argument if you want to keep track of the opponent_history.

[borntofrappe]

I think I understand the point regarding player(): opponent_history is not passed in the function, but it is updated by the function to keep track of the moves. The explanation seems a tad excessive, especially considering that the previous paragraphs already describe the player() function.

I'd suggest something along the lines of:

In RPS.py the function is defined with two arguments (player(prev_play, opponent_history = [])), but the second argument is completely optional. opponent_history = [] is specified to save state between consecutive calls of the player function, and is needed only if you want to keep track of the opponent history.

---

I know it's a small change, but I'd also remove the word should when describing the argument of the function.

- The function should take an argument that is a string describing the last move of the opponent
+ The function takes an argument that is a string describing the last move of the opponent

Unlike the value that is returned by the function, the argument is given by the assignment and is not changed by the camper/developer.

---

Let me know if that helps 👍

[scissorsneedfoodtoo]

@borntofrappe, thanks for your patience and your thorough review of this project. I agree that we should remove the word "should" from that sentence.

I went in and updated the README. Now the full sentence reads:

The function takes an argument that is a string describing the last move of the opponent ("R", "P", or "S").