OOP and a Rock, Paper, Scissors Game


Rock, Paper, Scissors Game to learn OOP

I made an object oriented Rock, Paper, Scissors game to practice working with Design and TDD. If you’re not familiar with Rock, Paper, Scissors:

Anyway, it’s a great way to learn and practice developing an application. (So is anything where you develop an application, but who’s counting)

If you wanted to make a RPS application, you should go on ahead. I just had the application run in the terminal, and you can check it out here in my Github:


Here are some of my notes on OOP if you wanted more help. It’s inspired/copied from LaunchSchool’s OOP course.


Notes on OOP

  1. Write a textual description of the problem or exercise.
  2. Extract the major nouns and verbs from the description.
  3. Organize and associate the verbs with the nouns.
  4. The nouns are the classes and the verbs are the behaviors or methods.

Finding a Description

We don’t think about the flow at all. First write out a textual description of RPS


RPS is a two player game where each player chooses Rock, Paper, or Scissors.

- rock > scissors
- scissors > paper
- paper > rock

same move is a tie

Here is a potential extraction


Nouns: player, move, rules
Verbs: choose, compare

Organizing Nouns and verbs


Player
  - choose
Move
Rule

- compare

Making an engine


class RPSGame
  def initialize
  end

  def play
  end
end

focusing on the play method


def play
  display_welcome_message
  get_human_move
  get_computer_move
  display_winner
  display_goodbye_message
end

if the human and computer were players, they would have #choose

After implementing the App

I liked working on a OOP method of Rock Paper Scissors and I tried to organize my application like a Rails App. I also installed Rspec to handle testing to add the bonus features.

Bonus features

I’m making branches to be able to access the app as I change it in various states. See the log to show all branches

https://github.com/RoadBytes/RPS

Lizard, Spock

Separate Paper, Rock, Scissors classes


def compare(other_move)
  return 'tie' if other_move.class == self.class
  other_move.class.to_s == "Rock" ? "win" : "lose"
end

Separate Paper, Rock, Scissors classes

Pros

Cons

History of moves

As long as the user doesn’t quit, keep track of a history of moves by both the human and computer. What data structure will you reach for? Will you use a new class, or an existing class? What will the display output look like?

Adjust computer choice based on history

Come up with some rules based on the history of moves in order for the computer to make a future move. For example, if the human tends to win over 60% of his hands when the computer chooses “rock”, then decrease the likelihood of choosing “rock”. You’ll have to first come up with a rule (like the one in the previous sentence), then implement some analysis on history to see if the history matches that rule, then adjust the weight of each choice, and finally have the computer consider the weight of each choice when making the move. Right now, the computer has a 33% chance to make any of the 3 moves.

Rule

When ever the computer loses, it just adds the non losing moves into an array. This array will then have more of a likelihood of returning the non losing moves when .sample is run on it.