Program Development History

by David Vanderschel

I am going to relate the story of how this program came to be.

I think I first saw the "box with the lid off" way of presenting the 3D cube many years ago in Doug Hofstadter's old Metamagical Themas column for Scientific American. That presentation is most analogous to the way MC4D works; and I thought that, for making points about how MC4D works, it would be useful to have a 3D cube simulation that presented it in the analogous way. I was hoping I could find an implementation in this style. I was unsuccessful at first; but I inquired on the 4D_Cubing@YahooGroups.com list in March of 2005, and David Barr suggested his applet.

That was not quite what I was looking for. The most obvious difference is that there the 'top' of the 'box' is flipped upside down, which I think makes it less intuitive. More importantly, I wanted a true perspective rendering with the ability to adjust the 3D viewing distance.

But I had other ambitions as well. I wanted to implement shrinking of faces and stickers as MC4D does and make the face shrink and sticker shrink be continuously variable so that a person could get a better idea of what they do. (It turns out that this capability has now been introduced in the new Java version of MC4D that Melinda Green has created.) I also wanted to try making out-facing stickers semitransparent so that you could tell what is going on behind them even without sticker shrink. (This is implemented and turns out not to be very helpful, but I left the feature in because it produces some neat looking pictures.)

I was not a Java programmer (C yes), but I was emboldened by possessing David's code to try making little modifications. Relying on documentation from Sun's Java Web site, I started learning about Java. As I began understanding how the code worked, I eventually felt confident to strike out on my own. Initially my code included a credit for David Barr's code from which I was adapting it. However, as I became more and more ambitious with my changes, I eventually replaced everything Barr had written and completely rearranged the whole thing. When I believed that it was no longer possible to recognize any 'artifacts' of David's original implementation, I removed the acknowledgement in my code. But I am getting ahead of myself.

I was not interested in simulating cubes of any order but 3, so I simplified David's code considerably by removing the generality for higher order cubes. I could even hard code the permutation cycles.

Thanks to Sun's sample Swing code, I had face and sticker shrink working with the slider fairly early in the process. Promptly after that I discovered Configuration #3. I was excited about that, because it meant that the approach had some virtue as a new and effective way to present the cube. I.e., it was not just for illustrating concepts any more. However, for real puzzle solving, it is easier to get a feel for what is going on if the slice twisting is animated.

Since this was also my initial Java-learning programming experience, I probably got a little carried away with trying various interaction mechanisms available in the Java Class Libraries. (I found that the Java language itself was not difficult to get along with (though I suppose that my code still looks a lot more like C-style coding than it should). What is tedious is learning how to use the various Class Libraries. Fortunately I have some general background in graphics programming so I did not have too much trouble with drawing in Java.)

My first major digression from Barr's program was to add animation for the twists. When I had that working, the program had developed enough of a geometric sense that it no longer needed to use an extensive list of explicit permutation cycles as had been in David Barr's program. I was able to compute which sticker went where based on the geometry.

It occurred to me to add the feature to take over control of the animation with the mouse. Using that when twisting the whole cube, I saw that it was interesting to be able to look at the cube without requiring that the projection be axis-aligned. In fact, it was in the middle of one of these whole cube twist animations that I realized that something like Configuration #4 was possible; but, without a twist in progress, my program could still not present the cube from such a point of view. I found that I could adapt my twisting code to the purpose of showing the stable cube with arbitrary orientation, but I was actually reorienting the cube in the MCS, which made some other things awkward. My first version for the tumbling code already had the property that it did not introduce unintended rotations. It turned out that this property arose naturally as a result of adapting the twisting code because it only knew how to rotate about an axis which lay in the xy-plane.

I decided it would be better to leave the cube alone in the MCS and make tumbling it be a viewing transformation issue. This was a significant rewrite of the geometric stuff. I created little 3D and 2D vector calculus packages to help make the code more compact. (I know this is usually done with 4x4 matrix algebra, but I found the vector calculus approach to be remarkably flexible.)

When I found that I was losing track of how the MCS was being mapped to the display by the viewing transformation, I decided to add the MCS orientation tattle to the display. Then I wanted to see FCS version also. I suppose that the desire to keep track of how the MCS or FCS is mapped to the display may be based on a deeper understanding of what the program is doing and not necessarily of interest to the casual solver, but it is interesting to see how the tattles behave in any case.

I had all the 2D projection and interaction stuff working quite nicely before I got around to implementing a 1D projection. My first effort at that was very disappointing; and, quite frankly, I lost interest in fooling with the program for many months (from the end of June '05 until April). That was silly because what I already had was pretty good for yet another Rubik's Cube simulation program. However, I wanted to complete the analogy to MC4D by making the sort of display that carried no more information than a Flatlander could glean. The idea of doing the Rover arose during this 'dead' period.

In April, I started working on the program again and, after adding a few more general features, I finished the 1D projections.

As the program became more and more sophisticated, I realized that the ability to save and restore one's configuration data was highly desirable; so I made an application version. (Actually, there is really just one very big file which implements a class for the whole thing, and that class can be invoked by a small Applet or application 'wrapper'.) With Save and Restore in place, it became desirable to allow the user to specify different color schemes.


Last modified: Mon Jun 26 04:53:00 CDT 2006