I conceived of this project when I was playing with children’s puzzle pieces. I wondered: ‘These puzzles are clearly a system. They take on similar visual forms that are lucidly defined, yet contain distinct information. The shapes compliment each other, parts making a whole…’ Then I thought: “What if I put this in ‘draw( )’, what if the pieces put themselves back together?”. I suddenly felt pumped.
To my relief, when I shared this idea with the professor, she loved it and was more than supportive. We thoroughly discussed the fundamental rules on which this puzzle automaton system can operate.
Below is some of the whiteboard draftings the professor and I carried out. There are various possibilities for visual outlooks, as long as the two (or more) pieces compliment each others when they collide.
Angela suggested me using vertex( ) to create the shapes, as well as writing objects for each type of block. I adopted these two methodic advices throughout the rest of the projects, which proved to be very efficient. In a later conference, she also pointed out that randomness doesn’t necessarily need to be a major player in this specific system (unlike most other check-ins we did), which allowed me to focus on the ‘operational rules’ first.
I explored the idea of after each collision the pieces split into smaller pieces, like an explosion. Or an atomic bomb – there’s fission, then fusion then fission then.. a cyclical motion system. It turned out that the quick exponential increase of the number of blocks were too difficult to keep track of.
Later on I entertained the idea of letting the pieces take complicated paths before finding their way back to make seamless connections. The paths I coded out were mostly linear, and not reaching the level of complexity I envisioned. I worked on compound curve motions, where I tasted a little success. However, it took hundreds of lines of codes just to get the precision right for one single successful fusion. To make the visual effects interesting enough, I needed at least a few dozen such ‘fusions.
My biggest hurdle was how to give self-autonomy to the blocks. I thought hard on it but couldn’t figure out. (Ironically, at the time that I’m writing this sentence, I now know exactly how to accomplish that. It’s a disappointment, but also ‘an unfinished business’ I can work on in the future). It’s sad to say that after a period of frustrations, I switched to an alternative route. The positive part is, I ended up happy with the end result (my third try).
One day I was staring into some digital letters. A thought came into my mind: ” These letters are made of building blocks as well, just like the puzzle pieces. I immediately got down to work, dissecting the geometrical makeup of realistically-looking letters.
Above is some of the paper sketches I to manifest the animation in my mind down to concrete entity. It is an understatement to say that this process definitely refreshed my math skills haha.
I still kept the same fundamental concept of the previous experimental systems: ‘collision transferring information’. In this case, each time two separate blocks (or letters) bump into each others, they switch colors. (For instance, I and T bump into each other numerous times with different bouncing speed, the consistency is that each time they take on the other letter’s color). I was satisfied with my sketch achieving this particular visual effect -transferring color, which is (as the professor pointed out) arguably one of the signature rules of my system.
I feel that ‘Let It Fly’ is a suitable name not only because of the actual physical display of these exact letters, but also for the motions they take on. The spinning up and down, away and back – it’s as if they are boomerangs. From the very
One problem is that once again, I hardcoded the phenomenon by altering at the exact frameCount I desired. This is one of the rarer times over the semester where I am barely yielding control to the computer. I wanted to enforce rules onto my system. I wanted to make the canvas listen to me meticulously and carry out my demands. Towards the end, it almost became an obsession. One can argue that yielding little control to the computer can possibly make a system more system-like.
However, ‘dictatorship’ has a price. In this case, it was having to make most, if not all of the decisions for every single object on the screen. I had to spend a tremendous amount of time sketching on paper, performing mathematics to make the movements seamless. Upon reflection, I overdid it. Some of my peers pointed out that they would like to see more randomness, more unpredictability. I agree to a certain degree.
On the bright side, the blocks I created do have systematic relationships with each other. They ‘know’ exactly where they need to be at any given time in order to make the system work. I wish I was able to incorporate Wolfram’s automata idea into my system, at least partially.
Honestly, throughout the semester, numerous classmates’ works and in-class comments made me gain new insights on what a system means. For this particular conference project, Livia gave me inspirations during some of our conversations. She was making a game herself, and so shared my targeted theme of ‘playfulness’. It goes without saying that my professor was there every step of the way.
Pry aside the results, I’m happy to say that this conference project helped me gain a notable improvement on object-oriented thinking. I’m proud to say that the final sketch contains the most amount of classes I have ever had to construct. I wrote a separate class for each building block, along with some many other classes/ functions for the background noise and particles. And each class had up to 10 properties. I’m thankful because it was honestly an amazing opportunity to sharpen my programming skills.
None of my puzzle sketches worked out perfectly, even though I performed a good number of experiments to explore different directions and possibilities. Yet I’ve learnt to see this whole process as a piece of art. Quite like artist Bas Jan Ader‘s artistic process, which I very much respect – embracing failure. Additionally, I realize now that the ‘breaking down into smaller building blocks then putting them back together’ idea does not simply apply to physical blocks , it applies to the creative process as well.
