. . . e-mail sent to my editor on February 23, 2004:
Hi Carol,
Well, I finished working on the new type of puzzle that has been mulling around in my head for the past eight months or so. There's quite a back story to this one, so bear with me.
When I was thinking about redesigning my web site [2001], I knew that I couldn't just list out all of the puzzle categories in one big lump anymore, there were simply too many (and the list keeps growing!). I needed some meta-categories, so I came up with a four category structure ranging from pure mazes on one end to pure puzzles on the other. But I realized that this was a very solver-centric way of looking at things (which is partially because I was taking a problem-solving, cognitive science approach). That may be the way to go for the web site, but there could be a different way to classify things from my puzzle-construction perspective.
After a great deal of reflection, I noticed that there are essentially two ways that I create puzzles. The first way is to build a solution path and build dead ends around it. The other is to build multiple paths and then pick one to be the solution path. Neither way is easier/harder then the other just based on that description. For example, building the knight jumping puzzles by making a solution path and keeping track of the dead ends usually isn't too tough, but doing the same thing with the double jumping puzzles is very complicated. I tend to build mazes by drawing out a whole bunch of paths and picking one, which is relatively easy to do, while the jumping wall puzzles requires mapping out all of the possibilities of the wall and the jumps and how those interact with each other, which can be a lengthy process. It comes down to how the physical space of the puzzle maps to the problem space of the puzzle, but that's a whole other story.
I've been coming up with a few puzzle ideas in the last couple of years that are of the "build several paths and pick one to be the solution" type. This moves the bulk of the work up front - creating the various paths. Picking one tends to be pretty easy once the paths have been fleshed out. For mazes, drawing out the paths is time consuming but, once they're there, they're there. For a puzzle like the If/Then City Blocks, the physical space of the puzzle masks the true nature of all the possible paths that are contained in the physical space. That means that I have to go through and systematically search the space to find all the paths, chart them out, and then double check everything to make sure I didn't skip anything (which usually happens). That can be very time consuming and, quite frankly, boring.
Last summer [2003] it dawned on me that this would be a perfect task for a computer. It would be a little tough to get the computer to "understand" the space of the puzzle in which it was "moving around", but once the space was described to the computer, it could search the space and find all of the paths with far greater accuracy and speed then I ever could.
It took a while to determine all of the parameters of a problem that the computer would need to know, especially since I wanted to be able to use this program on a wide variety of puzzles, not just one type. I looked around on the internet to see what others had done, and found some interesting stuff, but nothing that I could use. One person has written several programs that generate puzzles for him by creating several puzzles (according to certain rules), judging the puzzles (according to other rules) and picking the "best" ones, making variations of those, picking the best of that crop, etc.... After going through, say, a hundred iterations, the computer spits out some puzzles, and then the guy checks those out. Talk about sucking all of the fun out of puzzle creation!
I went to work building the actual application over Christmas break. I had to enlist the help of my friend Louis in the math department (who just happens to have a lot of programming experience), who corrected some of my variable passes and calls. The program finally compiled and executed successfully a week ago. For the record, I used the developer tools that come with Mac OS X (called Xcode) and wrote the program in C++, and I'm pretty sure it's the first time I've used my programming skills to do something other than homework.
The new type of puzzle I used the program to create are called "bathroom tile" puzzles, as you are installing hexagonal tiles than need to be laid out in a certain order. I knew that, as the number of tiles increased, so would the number of possible layouts. In fact, the third puzzle in the group I've created thus far has 54 possible paths (which totally floored me when I put the information into the program and it gave me back 54 solutions quicker then I could snap my fingers), and that was achieved with only a dozen hexagons.
The moral of the story is that my puzzlemaking has grown so much that I no longer can use 100% off-the-shelf tools to do it. Creating custom tools using a computer isn't all that tough, which is good because this has prompted me to think more about how the computer could help me (while not taking away all the fun).
While I'm excited to keep using my new program, I need to get back to work on my dissertation before I can dabble away in making more puzzles. Have a great weekend!
- Tim
Last updated: September 1, 2004
Copyright © 2000-2004 All Rights Reserved