This week we did the sound and video unit and learned about how capturing video and making pictures and tracking faces–all of which would have been helpful a few weeks ago, when I wrote my PhotoCube sketch. I thought this week would be a good time to build on that project to make something better. I simplified it but also added several elements. Also it turns out WEBGL doesn’t play nicely with 2D so I just scrapped the idea of a spinning cube for now.
Every time I open this project I can’t help but work on the next component, but for the purposes of this week’s assignment, a preliminary version is here.
The Intercept recently published a series of articles based on leaked documents obtained detailing U.S. government [attempted] assassinations of targets in Afghanistan, Yemen, and Somalia. Already intrigued by what information might be publicly available related to this covert war, one of the ICM homework links, one of Jer Thorp’s blog posts, Art and the API included information on a project which collected information on U.S. Drone strikes:
“Josh Begley, a data artist living in New York, has recently created an API which allows access to information on every US drone strike, using data from The Bureau for Investigative Journalism. Updated as new strikes are reported and confirmed, The API allows others access to verified and aggregated data on drone activity.”
I ended up using data from Dronestream to create a website where you could click on a country to chronologically look through information on drone strike deaths in that country. Continue reading Drone Strike Deaths
This week we learned about p5.dom and how to create things beyond the canvas. I tried creating a sketch where you could take a photo of yourself and then see it on the side of a rotating cube, but this proved very challenging. I modified this idea a bit, and hope people will be amused by the unexpected result! See the final product here.
The first challenge was to figuring out how to make a photo booth-like experience. All the reference seemed to have to do with taking and using video, not preserving a single static image from that video. It was even hard to find examples of something similar using p5 online. But, Alex Wiles did make this emoji cam, and so I looked through the code for clues. This sketch saved the canvas and automatically downloads this, which isn’t what I wanted, but it definitely helped.
I drew inspiration from these flash animated poems and my friend’s twitter poetry to create a page where you can cycle through three animated poems. These don’t quite work right yet for a number of reasons.
The code is basically three constructor functions with a button, and using the mousePressed function to switch between calls to a write method within each function. Each poem moves around the screen in a different pattern.
Issues:
For this week’s assignment, we were taking old code and cleaning it up with functions and/or javascript objects, as appropriate. I found I was still using a lot of redundant code when creating and animating the falling ellipses, “food,” and solicited Lauren’s help to learn how to use for loops and arrays for this kind of repetitive task.
There was functionality I knew I wanted to add to my initial project: I wanted a restart button and I wanted the food to avoid the player, so that it was clear the cards were stacked and you would inevitably lose. From last week, I knew how to create a button, so I added this to the You Lose screen. Animating the food away from the player was a bit more challenging. I thought just moving food away in a particular direction would be boring, so I tried adding some randomness to the avoidance. For some reason, the ellipses moving back and forth sometimes looked like they were on top of the player, which was not my intended effect.
This week we learned about for loops and using mouse clicks to create buttons. I worked on a project with Annie Goodfriend (her blog is here) to incorporate these two elements. The cool thing about for loops is they allow you to create an iterative design. Buttons and sliders (we didn’t incorporate a slider) allow users to interact with the elements on the screen in a clear, defined way.
Annie and I met to see what inspired us and what kinds of algorithmic designs we thought were cool. In going through examples we realized I had played with some semi-transparent ellipses that bled into each other by animating them across the screen, creating the illusion of a changing gradient. I had programmed just one, so we used our new knowledge to create multiple down the screen.
We wanted every other stream to move in opposite directions so we created two loops.
The rules for this assignment were just to have one element controlled by the mouse, one element that changes over time, independently of the mouse, and one element that is different every time you run the sketch. I was excited to work with arcs after learning how they worked in the last class, and played with transparent arcs, and stacking them, imagining a kind of spinning ever-changing spiral. After Dr. Mitu Khandaker-Kokoris, game developer and NYU Games professor, came to speak to our Applications class, I wondered if I already had the skills enough to make a game. That, along with the creation of this Pacman-like arc-element I created when playing around became the inspiration for a game.
I thought it would be funny to create a game that you could not win and would make the player perpetually more frustrated. (Is it a game if you can’t win? This is a question for another time.) I also wasn’t confident in my ability to execute something complicated, with clicking (how do you click and have that result in an action?) and other rules to make it a functional game that you actually could win. So, my element that would be controlled by the mouse would be the player, my element that would change over time would be the falling “food” (I also added a score), and my element that would change each time would be the background color of the game.
I hope my neighbor is not offended by my final portrait.
I started my sketch with rect() for the shirt/body and ellipse() for the head. I’ve never really played with visual software besides Microsoft Paint, and I spent probably too long using a color picker to get a combination of background and clothing that I found to be not terrible. All the shapes, stroke(), and fill() map pretty directly to the shapes, line and bucket functions in Paint, which is fun and illuminating. Because I failed to take a photo of my neighboring classmate, clothing choices should not be considered a reflection of my neighbor’s taste.
As I added new shapes to create a larger form and add details to the face, I began using /* */ comments to label different things, like hair, eyes, shoulders, etc. This was helpful when I went back to eliminate redundant uses of noStroke() (see redundancy highlighted line below!) or different colors while also making sure all the shapes overlapped properly–for example, making sure the code for the lower arms came after the code for the shirt, so that the arms were visible over the shirt area.
