203 One Die Game

Description

Hej Rubyists,

This week’s quiz was submitted by Siep Korteling through the suggestions page.

Imagine a two player game with the following rules:

Let’s say it’s your turn. The current total is 24 and the die is facing 3. You can win by turning the die to face 6, totaling 30. Your opponent cannot play 1 because it’s at the bottom of the die, so he is forced to overshoot the goal of 31.

Build a program which plays this game against a human opponent and blunders occasionally (to keep it fun).

P.S. I did not invent this game; I’m pretty sure I found this game in a chapter about nim-like games in one of Martin Gardner’s books.

Have Fun!

Summary

Luke Cowell and Chris Cacciatore both submitted solutions for this week’s quiz. There was some ambiguity in the way the quiz was posted, so the implementations were slightly different from one another. Luke had a running total for each player and Chris had a single total. Despite that difference, both solutions tackled the problem similarly and are both interesting.

The Dice classes in both solutions have methods for rolling a random side and validating moves by keeping track of opposites. Chris keeps an array of explicitly defined opposites: @opposites = [[1,6],[2,5],[3,4]]. Luke’s method for determining available moves makes use of the fact that opposites are defined by the faces adding up to seven:

def available_nums
 (1..@total_sides).reject {|n| (@top + n == (@total_sides + 1) || n == @top)}
end

Each of these implementations has a different strength when it comes to future changes: Chris’s is easier to rearrange the configuration of the dice and Luke’s is easier to expand to dice with a different number of faces. One caveat for dice of more faces is that additional adjacency information would need to be added (for example a dodecahedron or icosahedron would have different adjacencies).

Both solutions require the definition of only one method to create a new player or different AI. For Luke’s code the only method that needs to be implemented is next_move. Let’s take a look at the Human and Computer Player implementations:

class Human < Player
  def next_move(dice, opponents = nil)
    done = false
    while(done == false)
      choice = gets.to_i
      if(dice.valid?(choice) == true)
        done = true
      else
        print "!!!you can't choose #{choice}!!!"
      end
      puts
    end

    choice
  end
end

For the human player it gets the choice from the prompt, prompting again if the player selects an invalid choice.

class Computer < Player
  def next_move(dice, opponents = nil)
    if(@score == 30)
      return 1
    elsif((@score % 6) == 0) && dice.available_nums.include?(6)
      return 6
    else
      return dice.available_nums[rand(4)]
    end
  end
end

The computer player tries to set up a path for a win. If the score is a multiple of 6 and the computer is able to choose 6 on the die, then it will choose 6 each time until the score reaches 30, and then will choose 1 on the next turn to secure victory. If it can’t then it makes a random choice. It would be fairly easy to implement different computer AI by providing different ways to compute the next move.

Chris uses a similar technique for choosing the next move from the computer player. It checks for a winning move and takes it if available, otherwise it makes a random move.

def choose_move(score)
  sleep(1)
  if score < 25
    while !@die.legal_move?( (r = rand(6)+1) )
    end
    return r
  else
    #simple win
    return 31-score if @die.legal_move?(31-score)
    return rand(6)+1
  end
end

The play consists of players alternating moves. Both programs check for the validity of the move outside of the player’s implementation, so you are unable to cheat by having your player return a roll of (31 - current_value).

An interesting element of Luke’s program is that he allows you to set up a game between two human players or two computer players rather than just between a human and a computer.

Though the specific game mechanics were slightly different in each program, they both provided interesting solutions to the problem.

Thank you Luke and Chris for your submissions to this week’s quiz!

Friday, May 01, 2009