As a kid I  used to spend a lot of time in the car traveling from Minneapolis to the lakes country of Minnesota (near Detroit Lakes, if anyone cares).  Two 4-hours trips a weekend was pretty normal.  So what do you do with 6 kids crammed into a Suburban for 250 miles?  Whatever it takes to keep them quiet!


One of the first games I learned to pass the time was the Dots-And-Boxes game.  The premise is simple enough:


There is a grid of Dots in a rectangular array (such as the 6x6 grid in the image below).  There are N (usually 2) players.  Each player takes one turn.  A turn consists of drawing a single line between any two adjacent dots.  If that turn completes a box then that player receives a bonus turn (which must be immediately taken).  Players may not pass on a turn.  Two adjacent dots can only be connected once (can’t draw the same line twice).  When a box is made the player writes their initials in the box.  At the end of the game the player with the most completed boxes is the winner.  It is possible to tie. 


In the car if a tie occurred we played a "cycle-bikel slug bug".  This would be much harder to explain and involved a lot of punching.  Our parents encouraged us not to tie.


Below is an example of a game being played:




So the question is … is anyone interested in walking through some of the more interesting points in the development of this simple, but quite challenging, game?


The interesting aspects are:


1)      ink input (figure out what dots to connect, best guessing, eliminating bogus moves, etc)

2)      Simple AI players (The screen shot above is from a Computer Vs. Computer game) using “Solved Form, Random” players.  The solved form of the game states that if a player can make a box, they must.  The “Random” part means that if a box can’t be made then a random valid move is made.  Only this particular computer player is bound by this rule, if a human player were involved the Unsolved Form of the game is played (any valid move is allowed).


Games are not my thing.  I’m not a games programmer.  This was a learning exercise not an example of game programming.


If there is any interest I’ll write a few columns on how I went from knowing nothing about ink input to creating this game (which admittedly does not require a lot of knowledge about ink input but which covers some fundamentals).


Let me know.