We have a foreign exchange student from Korea staying with us. The best part of that is the intended exchange of cultures. For example, to kill time on a recent plane trip, the student taught us a common finger game children play in Korea.

The rules are very easy:

1. Both players start by holding up one finger on each hand.2. On each turn a player must do one of the following: a. Touch one of their hands to an opponent's hand, adding the finger count on their hand to the touched hand. The player keeps the same number of fingers, but the opponent must add the player's finger count in addition to the fingers already on that hand. b. Clap their hands together to "transfer" one or more fingers from one hand to the other. You cannot transfer all the fingers off of a hand.3. A hand with five or more fingers is eliminated, which is shown by making a fist. An opponent can not add fingers to an eliminated hand and an it cannot be used in touches, but players may transfer fingers to it, "reviving" it. The first player with two eliminated hands loses the game.

Of course, as a programmer, I immediately tried to solve this game. I suck the fun right out of everything, but at least it gave us another quiz topic.

This week's Ruby Quiz is to programmatically solve Magic Fingers. Is it a win for the first or second player with perfect play, or can you always force a draw with repeating counts? Have your program print some output that would convince anyone beyond the shadow of a doubt what the game's outcome will be.

Quiz Summary

Eric I. said it best when he said the real trick of this quiz is figuring out a way to convince someone of the outcome beyond the shadow of a doubt. Eric's own code convinced me, after we clarified my mistakes in the rules.

Eric's code outputs a table of your moves compared with the opponent's moves. At each step, it tells you the move to make based on the following priorities:

1. It suggests a forced win if it can find one2. It aims for draw if there is no forced win3. As a last resort, it will stall a loss as long as possible to increase the chances of your opponent making an error

The first one is really the point of interest for this quiz. There's just not that many different hand positions in this game and a sufficiently deep search can find the wins. Here's the chart Eric's code shows for the game:

Columns and rows are labeled in normalized hand positions, meaning that a left hand of one finger and a right hand of two fingers is the same as a left of two with a right of one.

You find the row for your hands and cross reference it with the column of the opponent's hands. The cell where the two meet lists your best move, be it a touch or a clap. Don't worry too much about the format of those moves, but know this: a plus indicates that you have a forced win and a minus indicates that you face a forced loss.

Using that knowledge you can look up the starting position at row 11, column 11. You will find a minus there telling you that your best move still leads to a forced loss. That's correct. The second player can always win a game of Magic Fingers.

Now let's examine how the code reaches this conclusion. First, let's look at the class used to represent the current game state:

Most of this class is very straightforward. A GameState is created by providing the current values of the two hands. You can then query the resulting object for a win, loss, or yet unknown score(), whether or not it is game_over?(), or a String representation of the hands. The class also defines eql?() and hash() in terms of the hand counts so these objects can be used as keys in a Hash.

The only semi-involved method is do_turn(), which takes a Proc that will perform a move and uses that to create the resulting GameState object. You will see how this method is used when we get a little farther.

The main work here is in the two almost identical methods. They work by filling an Array with Proc objects that generate touch and clap moves when passed a pair of hands. These Procs return the new hands and descriptions of the move that are used in the chart we saw earlier. They also include a good deal of error handling to prevent illegal moves, as you can see. Finally the Moves constant is populated with the results of a call to each.

This next method is the work horse of this solution. This is a recursive depth first search of the available moves. It limits the recursion, to keep things like draws from creating infinite loops, and memoizes GameState objects to keep from redoing work. Let's take it in slices:

Right off the bat, we see the code that controls when recursion stops. As soon as the recursion limit is reached or a game is over, the code tosses a final score back up the stack.

When that's not the case, the method moves into search mode. The first step is to check for a memoized answer that would short circuit the need to search at all. When we don't have that for the current position though, it's time to recurse:

# try each of the possible moves on this state and generate an# array of the results of those choices move_choices = Moves.map do |move|begin# determine the new state if the chosen move is applied new_state, description1, description2 = *state.do_turn(move)

# recursively determine the score for this move (i.e., this# state); negate the score returned since it's in terms of# opponent (i.e., a win for them is a loss for us) score = -pick_move(new_state, levels - 1)[0]

# increment score (by shifting away from zero) in order to be# able to treat is as a count of the number of moves to a win# or a loss score += score / score.abs unless score.zero?

Here we see the Array of Proc move generators and the do_turn() method of GameState come together. Each Proc is passed in one-at-a-time to generate the resulting GameState. Remember that those Procs toss Exceptions whenever an illegal move is found and this code uses a rescue clause to skip over such moves. The new state is then recursed into by pick_move() to fetch a resulting score. That score will be from the opponent's point of view, so it has to be negated to count for our point of view.

unless winning_choices.empty?# if there's a winning option, choose the one that leads to a# with the least number of moves selected = winning_choices.firstelse# otherwise, choose a move that leads to a tie (preferable) or a# loss but in the greatest number of moves (to increase# opponent's opportunities to make a mistake) move_choices = move_choices.sort_by { |option| option[0] }if move_choices.last[0] == 0 selected = move_choices.lastelse selected = move_choices.firstendend

The first line is just a long-hand way to write move_choices.compact! and the second line filters the legal moves down to winning moves. If we have winning moves, the quickest kill is selected. Otherwise, the code checks draws and losses as I described earlier. At this point we finally know a best move and score. Those are memoized for future calls and passed back up the stack to the calling code.

The next step is to put this method to work by handing it all possible hand combinations:

This is just a brute force generation of positions, their scores, and the best moves to make in them. Everything shown in Eric's output is built here using the tools we have been examining.

Speaking of that chart, drawing that is our last bit of code:

ruby

# ...

# display instructions puts <<EOS INSTRUCTIONS

If it's your turn, select the row that describes your two hands. Then select the column that describes your opponent's two hands. The cell at the intersection will tell you how to move and what to expect.

A leading "+" indicates there is a guaranteed way to win. A leading"-" tells you that if the opponent plays perfectly, you will lose. If neither of those symbols is present, thenif you and your opponent play well, neither of you will ever win.

The rest of the cell tells you what type of move to make. A "T" represents a touching move, telling you which finger of yours first to user first, and which finger of the opponent to touch. A "C" represents a clapping move, and it tells you the finger counts shouldend up with after the clap.