Part 3: Developing SeePilgrims
The decision to undertake an installation for the Pilgrims festival was a big one for me, in that the result was always going to be visible to others. Up to this point all my work was done purely for the act of learning, and possibly to submit to a narrow audience for online course submissions in Coursera.
There was also an element of physicality and scale – making something that had to work in a large space, projected big and working robustly for adults and children.
This was double-edged – it gave me excitement , motivation, intent, but it also gave me pressure to deliver, even if I should lose interest, or if I should think that maybe I had learned all I was going to. Both of these negatives were soon dismissed. I was hooked on getting it good, getting it finished, and the learning was less half technical and half about the challenges of getting something finished; out of the lab; Shipped!
I only have a few hours a week I can give to study and development without stealing time from work, family and domestics, and I found myself more disciplined than I had been for previous study or code projects. It was hard to plan as there were so many unknowns, but at least I knew there were dates where I had to complete R&D and get stuff converted to robust working code, and by when I needed to have the whole physical setup completed.
So what did I learn? This was a chance to go back to classic Processing, based on Java. My most recent studies had me looking at a lot of JS and I was looking into P5JS, the JS port of Processing. But for this, and to use the library, I had to use the Java. Although I was rusty, it was the first language I gained any traction with in my UoD studies, and it was like an old friend. I had to really use hard what I knew and learn a lot more. I used objects, inheritance, and polymorphism in a way I had never used them before.
I found the processing limitations of what I could do with a 1/30 second frame and what compromises I needed to make. I learned to be very thrifty with my use of loops, especially where thousands of objects had to be refreshed each frame.
I hit the boundaries of my very informal coding style. As my code grew, while it was kind of modular, the interfaces were leeky. I could see why a more structure approach would eliminate the pain of trying find bugs across the whole code base. With time constraints and a slightly cowboy flair, I took shortcuts to get stuff working, even kind of knowing I was making future pain for myself. For me this is still early days, and you kind of how to learn how something breaks to hammer home why you need to take the harder road. Lessons were learned.
I loved getting a chance to break out and use some of the tricks and techniques I had learned from Daniel Shiffman’s excellent Nature of Code book. Most of all, I enjoyed the chance make big visual stuff happen out of my own code, for my own fun and that of others. It feels great to have committed to a public launch of an idea, and to have achieved it. Like any other project, it got tight and sweaty right at the end. But it worked.
Now back to the lab for the next block of study and creation.
No comments yet.