The Mega-Dots puzzle automation started with hacking my CNC machine’s programming infrastructure, then developing custom tools to convert it to a connect-the-dots style game.
In the previous post about the general initiation of the puzzle, I went over the broad strokes of my plan to make a viable commercial product. This is the second in a long string of posts pertaining to the details of how this puzzle came into fruition.
As I mentioned before, a lot of the code was already basically done. I used the base code and custom XML format that I used to feed the “Monster” CNC application. The plug-ins in MEL and C#.net work from any image pixel color retrieval. I did modify the variables a little on the MEL polyline exporters a little, just so that I could reasonably accommodate for the size of the text tag that would eventually appear next to the dot. (Remember, unlike the CNC machine, where the distance between dots is irrelevant unless it is bigger than the dimensions of the tray, I’m now concerned with the smallest distance between dots. I want to eliminate as much tag overlap as possible.)
Where the new code begins is the process of taking the contents of the XML in the form of float XYZ values, and inserting them into a 2D sheet. This is not a difficult exercise in theory. I elected to use CATIA to do this, just because I can’t stand Rhino, and Maya’s printing is atrocious. Also, I have a LOT of experience doing large scale automated tagging in CATIA; it was a natural transition.
Screencapture of the XYZ points in 3D space, with various tags attached.
The process is pretty straightforward:
- Read the XYZ’s
- Place points in 3D space
- Drop a tag on each point in order
- Make a Drafting Sheet
Well, where the difficulty lies is when I tried to implement non-Arabic numerals. Also, I wanted to have one sheet for each number type. There would be one Mega-Dots puzzle for each number type:
- Babylonian numbers
- Mayan numbers
- Inuit (Kaktovik Inupiaq) numbers
- Roman numerals
- Chinese Rod numbers
The mathematician in me loved the prospect of numbering things in archaic or distant number systems, but then the engineer in me tried to figure out the most efficient number base. That lead me to the production of these number puzzle sheets too:
- Binary (2)
- Decimal
- Hexidecimal (16)
- Alphanumeric (36)
In theory, the Alphanumeric puzzle should be the most efficient use of characters. (Later, I would determine out that I found the Inuit Kaktovik Inupiaq numbers tended to be the clearest and most efficient, probably due to its base 20 and easy to sequence characters, beating the higher base Alphanumeric puzzle due to the oddness of the Arabic+English Alphabet sequence.)
As I was programming these number systems into my code (this topic will be addressed in a future blog post on this site), the psychopath in me wanted to push this puzzle even further. Since I was programming all of these different numeral systems, why not randomize the numerals but keep the sequence. So the first dot might be in decimal, but the second might be in Babylonian, the third might be in Mayan, and so on. It was just a matter of coding the randomization of the number conversions, so it was not much trouble. At first, I assumed this would be an impossible puzzle to complete without a computer, but after playing around with a test prototype, I found it to be kind of challenging, fun, but ultimately completely possible. This was the genesis of the “Mark Twain Random Numeral Puzzle.”
If that wasn’t masochistic enough, I then decided to push the concept of a connect-the-dots even further, by making another sheet that contains the dots in order, but the numbers have their bases randomized. The first dot could be in a base 14, the second dot could be in a base of 5, the third dots could be in a base of 33, and so on. The maximal base was 36, since I did not want to extrapolate the English alphabet. Also, I discontinued any R&D on bases less than five, since the binary puzzle would have tags that easily extended over four inches long even in the size 3 font.
Mega-Dots Importer and Name Tagger
I constructed a simple interface to assist in the debugging of this now overly-convoluted connect-the-dots game, so that I could run sections of the code on just certain types of numbers. Also, with some simple CATDrawing title block customization, I already had a page size option too. But the nice thing about this design was, I could essentially run all versions of the game in one giant run of the code. Barring any obvious reasons why a certain puzzle should not be processed, maybe for cultural reasons, it would automate nearly everything. In theory.
Close-up of the dot tags with various number types overlapping.
The code worked well at distributing points and tags. In some scalability tests, like in the image to the right, I was able to process thousands of dots, with over a dozen tags on each.
So now that simple list of five tasks had been expanded to include all sorts of font R&D, drafting workbench R&D, tag and leader experimentation and optimization, and so on. The next posts will go over some of these topics.
Recent Comments