Final Project: Submarine Explorer — Jake Scavone (Rudi)

                This documentation will illustrate my thought process throughout the development of my Interaction Lab final project. Before I begin, I believe it’s important to first explain my original idea and why I ultimately discarded it, considering it was the basis of my project proposal essay (which seems to be a component of our final project grade).

                For our Interaction Lab final project, our project was required to utilize both the Arduino hardware and Processing software. This opened a lot of ideas that I wanted to explore. Since some focus was on the significance and importance of our project, I first explored concepts that would be environmentally proactive. I thought about how I’m always finding myself recycling a bunch of empty bottles at the end of each week. Even though I’m recycling them, I still think it’s a waste when they could be reused. In addition, a lot of these bottles weren’t originally water, some were sodas and other types of beverages. I thought it would be cool if there was a way to refill them with whatever type of beverage you want. This led to my idea of creating a model machine that you could insert empty plastic bottles into. Then, it would move the bottle into a visible compartment, and an interface via processing would prompt you to select a drink. After choosing what you want, the machine would then mock the process of filling up your bottle with a liquid. Since the availability of fluid compatible parts is rather limited and the combination of liquids, cardboard, my laptop, and Arduino hardware would probably not end well, it was clear that it would be best to not have it dispense anything that was actually wet. Instead, this process could be represented by filling the bottle with colored little plastic balls or paper scraps that would have to be released from a compartment hidden above with a servo motor or something. While there are machines where empty bottles are recycled in exchange for money, my project would instead refill the bottle to your preference. This idea would hopefully cause people to be more conservative about their plastic bottle waste, which according to studies is a massively high number.

                After proposing this concept with my professor, he explained that this idea alone wouldn’t be a very strong example of interaction, and because of this I would need to add certain elements to make it more interactive. He also pointed out many significant flaws that I would encounter. I started to think that I should pursue a different idea. For one, I realized that this choice of a project isn’t really something I feel I would excel at and be passionate about. I also didn’t like the fact that I would most likely have to fill the bottles with some sort of material as opposed to a liquid. In addition, the actual fabrication of the model machine would most likely be challenging, and I expected there would be unpredicted obstacles and flaws that I would have to overcome during the process. Because of these reasons, the final product would only be a model, and not completely achieve its purpose. Furthermore, I wasn’t certain that I would be able to fully accomplish the design that I had in mind. As a result of my uncertainty, I decided to completely scrap the idea and pursue a project that I believed would open doors for much more creativity and flexibility, all while remaining something I’m passionate about and interested in: video games.

                A major theme of the Interaction Lab course involves exploring the concept of interaction. Similar to our midterm, our final project needs to involve interaction. More specifically, our final project prompt states that “any interactive project is going to involve listening, thinking and communicating.” Not only are video games naturally a form of interaction, but they can also be made to entirely meet these requirements.  In making a game for my final project, the direction of communication between the two programs would be Arduino to Processing. This was because Arduino hardware would only be used as the controller for the game, and these inputs would control the functions within the Processing interface. In the time we had during recitation to achieve tasks utilizing both Arduino hardware and Processing software, I noticed certain parts I had trouble understanding. Most of these difficulties were related to Arduino. I found it very challenging to establish efficient communication between the two programs when there were multiple inputs from Arduino hardware to account for. As a result, I decided that my game should require as little inputs as possible. Using minimal controls brought consequences though, one being how most of the user’s focus would then be on the display. This emphasized the importance of creating a game that was visually sophisticated, consistent, and most of all, entertaining. Another consequence of using minimal controls ties back to the assignment itself. Our project must include a relatively unique way of interaction, meaning my plan for a very simple controller would need to be improved somehow.

                While the topic of video games was on my mind, I noticed my friend using a slide potentiometer that he planned to implement into his final project. I found the movement of it to be very smooth and accurate, making it a preferable candidate for the controller for my game.

               I realized that it similarly resembled a throttle control found in many modern-day vehicles, and my mind started to explore possible themes for my game that would be relevant. Not long after, I checked out a slide potentiometer from the IMA equipment room. When playing around with it, I found the use of a slide potentiometer as a throttle to feel very arcade-like, which was also the style for what I wanted my game to be (an arcade game). Nonetheless, there were many more things I needed to figure out before I began developing.

                Before planning out what game I would create, I realized it was important to first understand the possibilities and limitations within the Processing software. I began to research the games that other people created in Processing. I started with browsing through many of the 2D games uploaded by the community on Open Processing’s website. Since I was trying to figure out what elements were possible to include in my game, I was specifically looking for the most developed and complicated games. In my search, I analyzed and played around with a wide variety of both unimpressive and noteworthy games. One of these was a game titled “Timberman” by Santiago Fiorino, which provides a strong example of how this research helped. While I found the game to be poorly made and very undeveloped, it utilized different animations for the character. In return, I learned that this element is possible to include, and my game could utilize different character animations as well.

                It’s important to note that at this point during my research, the theme I had in mind for my game steered in the direction of something similar to the well-known mobile game called “Flappy Bird”.

               While this game is notorious for being super simplistic, there are elements that make the game entertaining and challenging that I wanted to include in my own game. For example, the notion of dodging obstacles by controlling the y-axis of a character is perfectly suitable for the sliding potentiometer I hoped to use. Also, this challenge of dodging obstacles can be very entertaining, especially if there is enough variety in their occurrence and a progression of difficulty. Anyways, back to researching…

                After testing and viewing the source code for the many games that I found online, it was obvious that I needed to massively develop my understanding and ability to code in the Processing software. By typing something along the lines of “how to make a game in processing” into google, I discovered two websites that would prove to be massively helpful resources. The first one was a post titled “Let’s make a Mario game” which provided an in-depth tutorial on how to make a simple Mario-styled game in Processing. Unfortunately, the game was made using Java Script in Processing.js, making the code explained somewhat useless since I would be coding in a different language. Regardless, this tutorial provided an excellent reference for figuring out the elements I want to include in my game beforehand. For example, the beginning of this tutorial discussed the type of background for the game. Since the author was creating a Mario-styled game, he noted how the background should move according to the movement of the player. It made me think that if I do decide to create a Flappy Bird style game, I would want to use a background consisting of different layers that are on a loop to create an illusion of distance and movement.

               The second website this search brought was an article titled “Ultimate Guide to the Processing Language Part II: Building a Simple Game” by Oguz Gelal. This tutorial massively contributed to the production of my game and can be credited for many of the elements I was able to include. After all, the game that is developed throughout the tutorial is literally called “Flappy Pong”- which was basically a different take on the game Flappy Bird. After skimming through this post, my plan to create a Flappy Bird styled game was only encouraged and eventually became definite. There are only a few tutorials online for developing video games in Processing, and this one is perfectly suitable for what I planned on making.

Oguz Gelal’s Flappy Pong game

                    After reading through the tutorial, I carefully analyzed the finalized Flappy Pong game. I thought it would be important to figure out what elements my current game concept shared with it. After figuring these similarities out, I would then be able to take out the corresponding sections of code from the tutorial. As a result, I could have the core elements for my game already established, allowing me to prioritize other elements I wanted to include and return to altering the copied code later- especially once I figured out the theme for my game.  

                 First, Flappy Pong utilized different game screens: an initial screen, the game screen, and a game over screen. The initial screen would serve as the introduction, displaying the title and other relevant information. After clicking to continue, the initial screen would shift to the game screen, where the game is played. When the user loses, the game screen shifts to the game over screen, where the score is shown as well as the option to retry. Since my game would be an arcade game, these different screens were perfect to include. The code made in the tutorial for this structure provided me with an organized and efficient way to implement the contents for each screen throughout the development process.

                Another element I wanted to reference this tutorial for was the randomly generated walls that would serve as the obstacles. The code made by the author included interchangeable variables for the attributes of the walls, making it easy to alter according to my desires. The code also included a method for determining collisions between the “ball” and the walls. This would be very useful since my game would involve consequences when the user failed to avoid the obstacles as well. Though ultimately needed to be edited anyways, the code for recognizing when something collides with the walls was extremely intricate and by including it early on, I saved a lot of time and confusion.

                After the different game screens and randomly generated walls were in place, it was time to start creating the character. I hooked up the slide potentiometer to an Arduino circuit and established the communication to Processing. Since Processing would be able to read the values given by the potentiometer, I could have the movement of the character controlled by it. Since I didn’t know what my character was going to be yet, I used an ellipse in its place. The ellipse was fixed to a certain value on the x-axis, while its location on the y-axis was determined by the slide potentiometer.

                At this point, it became obvious that I needed to figure out what type of theme my game should have in order to make more progress. Lacking creativity in this department, I decided to browse EnvatoMarket and view the game sprites that could be used as my main character. This proved to be a great idea, as I was immediately overwhelmed by the number of options related to what I was searching for. After considering a variety of spaceships, planes, rockets and everything related, I decided to use a submarine as the main avatar. I chose this for a few reasons. First, the complicated generated walls that my game contained had to match with the theme. If I decided to go with the submarine, then the walls could be changed to rocks throughout a cave. Second, I had a lot of ideas for cosmetics that would work well if I was to go with an underwater-styled theme. Finally, I really enjoyed the animations that were included for the submarine. There were different images for levels of damage on the vessel, which I wanted to use for when the user collides with one of the obstacles. Once I made my decision, I purchased the rights to download and use this content, as well as a portfolio of similar-styled background layers from the same creator.  





              With the structure, core elements, controller input, and theme of the game established, I could finally start developing and altering further aspects of my game. Since this documentation is already ridiculously long, I’m going to skip most of the things I added during this period. I would like to include a few things which were very challenging and did not go the way I expected to though.

               A significant problem I encountered was related to the use of gifs in Processing. Since I had such cool little animations from purchasing the submarine game graphics, I really wanted to include them in some way. Using these animations was not as simple as it seemed, and after extensive research on forums and references, I realized that Processing no longer supports the use of .gif files. Furthermore, the downloadable library that solved this problem was no longer available, neither in the software itself or anywhere I came across online. I ultimately tried to overcome this problem by separating the images within the gif files and having them animate directly within Processing. I achieved this by having the images shift between one another based off intervals of milliseconds that passed. While the result was working, it had two major consequences. The first one I realized was that using this method caused the game to have lag, but I was able to slightly reduce this by increasing the intervals between shifts in the images. The second problem was much more severe- this method of animating the submarine massively complicated my desire to include the different levels of damage on the vessel. Since this is something that I thought was more important to include, I decided to exclude the animations with hopes to get back to it in the future.


             Another major setback I encountered was during the later-stages of my game development. The code I used from the tutorial that generated the walls had them appear as black rectangles with rounded edges. When I chose to use an underwater-styled theme for my game, I intended to replace these rectangles with rocks, which would also be totally different shapes than rectangles. This problem I encountered was massively due to over estimating my ability to understand and alter the code for these walls when I would need to. Since I was finally at the point where it was appropriate to make this adjustment, I confidently scrolled down to the copied code from the tutorial. After hours of re-reading this section in the tutorial, countless forum posts, references on Processing’s website, and YouTube videos, I still couldn’t understand what was going on within the code. During this period, I made many attempts at making the changes I intended, but each one failed. Ultimately, I realized that changing the code from making randomly generated walls to randomly generated rocks was not possible with my current understanding of the language as well as the time restraints to complete this project. Regardless, my game massively depended on this element and it was too late to turn back. Since my previous intentions weren’t realistic, I decided my best option was to change the texture of the walls themselves. Even though they would still appear as out-of-place rectangles, I thought at least they could have the appearance of rocks. I somehow still had confidence in my ability to do this, since I thought it would be as simple as using the texture function on the already made walls. I was once again totally wrong, and I spent more hours trying to determine the vertex points of randomly generated moving rectangles. Eventually, I decided to just change the code from spawning randomly sized rectangles to randomly sized images of a cartoon-styled rock that I found would most closely fit into the theme.

            Although it worked, I wasn’t pleased with the result as it looked anything but natural within the game. Regardless, I was running out of time to complete my project, and I would have to leave this element how it was as there were countless more things I needed to accomplish.

                A few days later and after much trial and tribulation, I finally had a complete version of my game that resembled what I originally had in mind. I chose to name the game “Submarine Explorer” as a placeholder for when I thought of a more creative name. It was now time to focus on the controller for my game, which at this point was just a slide potentiometer. I was still determined to utilize only this single piece, as I had confidence in my ability to transform this minimal input into a unique, entertaining, and relative method of interacting with the game. I was also still fixed on the idea of using the slide potentiometer to mimic a throttle control for changing the depth of the submarine, so it was important to clearly convey this to the user. Because I intended for my project to resemble an arcade-styled game, I began to draw concepts that used a board-like interface that contained both the controls for the game, as well as the information on how to play.

                I really liked how this looked and thought that as long as I did a good job with the actual designs on it, the controller should have no problem achieving my intentions stated before. I found a strong and in-tact piece of cardboard to use as the base. I then carefully made cuts to make ideal dimensions for the board, as well as a space that perfectly would fit the slide potentiometer. Since the overlay that contained all the text and illustrations needed to be sophisticated, I couldn’t just draw directly onto the cardboard. It was clear to me that this overlay would be best if made with the use of software and then printed out and glued to the cardboard. However, the cardboard was already cut, which meant that the overlay I would print out had to perfectly align with it. I downloaded Adobe Illustrator since the professor suggested that it would be easiest to achieve this in. I carefully copied the dimensions of the cardboard and then created the size of the canvas in Illustrator accordingly.

               After printing the colored overlay out and gluing it to the cardboard, I was very happy with the result. I placed the sliding potentiometer into the designated space and secured it with a piece of tape on the back. In order to fully accomplish my design, I needed to attach some sort of piece to the slide potentiometer that resembled a handle. Luckily, I found the perfect piece while scavenging through the storage room. After using hot glue to secure it to the potentiometer, my controller was complete.

After completion, I realized that I forgot to change the name of the game to something more creative. Also, this photo was taken after our final was presented, and the “handle” I attached fell off when transporting the board


 Below is a demonstration of playing the finalized game with the control board being used.






  int sensor1 = A0;
   int a = 0;
void setup() {
void loop() {
  a = analogRead(sensor1);
  Serial.println(); // add linefeed after sending the last sensor value
  // too fast communication might cause some latency in Processing
  // this delay resolves the issue.


//*******Submarine Explorer********//
// Final Project
// Jake Scavone
// **Credit to original author of "Flappy Pong" processing game for providing tutorial how to make many of the elements included

// Arduino Communication - Import Processing Values
import processing.serial.*;
String myString = null;
Serial myPort;
int NUM_OF_VALUES = 1;  
int[] sensorValues;      /** this array stores values from Arduino **/

// Sound Files
import processing.sound.*;
SoundFile gameplay;
SoundFile crashing;

// Sprites - Change Image depending on health
int gameScreen = 0;
PImage photo;
//PImage[] ship = new PImage[2];
PImage photo2;
//PImage[] ship = new PImage[2];
PImage photo3;
//PImage[] ship = new PImage[2];
PImage explosion;
PImage heart;

// Scoring
int score = 0;
int maxHealth = 100;
float health = 100;
float healthDecrease = 1;
int healthBarWidth = 60;

// collision settings
float ballX, ballY;
float ballSize = 50;
color ballColor = color(0);

// Background Bubbles
Drop[] drops = new Drop[20];
PImage bubble;

//Background Image
PImage ocean;
int x=0;

//Rock Image
PImage rock;

// Wall Settings
int wallSpeed = 10;
int wallInterval = 1700;
float lastAddTime = 0;
int minGapHeight = 100;
int maxGapHeight = 300;
int wallWidth = 200;
color wallColors = color(94, 102, 96);
ArrayList<int[]> walls = new ArrayList<int[]>();

/********* SETUP BLOCK *********/

void setup() {
  size(1500, 1000);
  gameplay = new SoundFile(this, "gameplay.mp3");
  crashing = new SoundFile(this, "crash.mp3");;
  ocean = loadImage("ocean.png");
  ocean.resize(1200, 1000);
  photo = loadImage("ship.png");
  photo2 = loadImage("ship2.png");
  photo3 = loadImage("ship3.png");
  heart = loadImage("heart.png");
  //  ship[0] = loadImage("ship1.png");
  //  ship[1] = loadImage("ship2.png");
  rock = loadImage("rock.jpg");
//  explosion = loadImage("explosion.gif");
  bubble = loadImage("bubble.png");
  for (int i = 0; i < drops.length; i++) {
    drops[i] = new Drop();

/********* DRAW BLOCK *********/

void draw() {  // Display the contents of the current screen
  if (gameScreen == 0) { 
  } else if (gameScreen == 1) { 
  } else if (gameScreen == 2) { 

/********* SCREEN CONTENTS *********/

void initScreen() { // Starting Screen
  background(158, 205, 216);

// Bubbles
  for (int i = 0; i < drops.length; i++) {
// Start Screen Text Contents:
  fill(52, 73, 94);
  text("Submarine Explorer", width/2, height/2);
  text("An Interactive Game by Jake Scavone", width/2, height/2+50);
  text("Press any Key to Start!", width/2, height-30);

void gameScreen() { // Level of the Game
  tint(255, 255); // Tint the bubbles by opacity
  background(236, 240, 241);
  image(ocean, x, 0);
  // Loop ocean background
  image(ocean, x+ocean.width, 0);
  if (x<-ocean.width) 
    for (int i = 0; i < drops.length; i++) {
  tint(255, 255); // Tint back to Normal Opacity (So it doesn't affect the environment)
  // Collision and Sprite animation images
    if (health > 80) {
      image(photo, 120, sensorValues[0] - 60);
      photo.resize(130, 100);
    } else if (health > 30) {
      image(photo2, 120, sensorValues[0] - 60);
    } else {
      image(photo3, 120, sensorValues[0] - 60);
  photo.resize(130, 100);
  // image(photo, 120, sensorValues[0] - 60);

// Place Classes

void gameOverScreen() { // Game Over Screen
  background(158, 205, 216);
// Bubbles
  for (int i = 0; i < drops.length; i++) {
  // Text on Screen
  fill(236, 240, 241);
  text("Your Score:", width/2, height/2 - 120);
  text(score, width/2, height/2);

// Custom Ending Messages
  if (score < 5) {
    text("That's a pretty low score, you should probably practice...", width/2, height/2 + 50);
  } else if (score < 15) {
    text("Not bad! Try again...", width/2, height/2 + 50);
  } else if (score < 25) {
    text("Wow! You're a pro!", width/2, height/2 + 50);
  } else if (score < 100) {
    text("You hold the record!", width/2, height/2 + 50);      // Add more in the future
  text("Press any Key to Restart!", width/2, height-30);

/********* INPUTS *********/

public void keyPressed() {
  // if we are on the initial screen when clicked, start the game 
  if (gameScreen==0) { 
  // if we are on the end screen when clicked, restart the game
  if (gameScreen==2) {

/********* OTHER FUNCTIONS *********/

// This method sets the necessery variables to start the game  
void startGame() {
void gameOver() {

void restart() {
  score = 0;
  health = maxHealth;
  //  ballX=width/4;
  //  ballY=height/5;
  lastAddTime = 0;
  gameScreen = 1;

// Collision Object
void drawBall() {
  ellipse(ballX, sensorValues[0], ballSize, ballSize);

void wallAdder() {
  if (millis()-lastAddTime > wallInterval) {
    int randHeight = round(random(minGapHeight, maxGapHeight));
    int randY = round(random(0, height-randHeight));
    // {gapWallX, gapWallY, gapWallWidth, gapWallHeight, scored}
    int[] randWall = {width, randY, wallWidth, randHeight, 0}; 
    lastAddTime = millis();
void wallHandler() {
  for (int i = 0; i < walls.size(); i++) {
void wallDrawer(int index) {
  int[] wall = walls.get(index);
  // get gap wall settings 
  int gapWallX = wall[0];
  int gapWallY = wall[1];
  int gapWallWidth = wall[2];
  int gapWallHeight = wall[3];
  // draw actual walls

  //  rectMode(CORNER);
  //  noStroke();
  //  stroke(130, 130, 130);
  //  strokeWeight(5);
  //  strokeCap(ROUND);

  //  texture(rock);
    rect(gapWallX-10, 0, gapWallWidth+20, gapWallY, 0, 0, 15, 15);
    rect(gapWallX-10, gapWallY+gapWallHeight, gapWallWidth+20, height-(gapWallY+gapWallHeight), 15, 15, 0, 0);
    image(rock, gapWallX, 0, gapWallWidth, gapWallY);
    image(rock, gapWallX, gapWallY+gapWallHeight, gapWallWidth, height-(gapWallY+gapWallHeight));

void wallMover(int index) {
  int[] wall = walls.get(index);
  wall[0] -= wallSpeed;

void wallRemover(int index) {
  int[] wall = walls.get(index);
  if (wall[0]+wall[2] <= 0) {

// Detecting if Ball collides with walls
void watchWallCollision(int index) {
  int[] wall = walls.get(index);
  // get gap wall settings 
  int gapWallX = wall[0];
  int gapWallY = wall[1];
  int gapWallWidth = wall[2];
  int gapWallHeight = wall[3];
  int wallScored = wall[4];
  int wallTopX = gapWallX;
  int wallTopY = 0;
  int wallTopWidth = gapWallWidth;
  int wallTopHeight = gapWallY;
  int wallBottomX = gapWallX;
  int wallBottomY = gapWallY+gapWallHeight;
  int wallBottomWidth = gapWallWidth;
  int wallBottomHeight = height-(gapWallY+gapWallHeight);

  if (
    (ballX+(ballSize/2)>wallTopX) &&
    (ballX-(ballSize/2)<wallTopX+wallTopWidth) &&
    (sensorValues[0]+(ballSize/2)>wallTopY) &&
    ) {
  if (
    (ballX+(ballSize/2)>wallBottomX) &&
    (ballX-(ballSize/2)<wallBottomX+wallBottomWidth) &&
    (sensorValues[0]+(ballSize/2)>wallBottomY) &&
    ) {
// Adding a point to score when pass wall
  if (ballX > gapWallX+(gapWallWidth/2) && wallScored==0) {

void drawHealthBar() {
  fill(189, 195, 199);
  rect(ballX-(healthBarWidth/2) - 20, sensorValues[0] - 70, healthBarWidth, 5);
  if (health > 60) {
    fill(46, 204, 113);
  } else if (health > 30) {
    fill(230, 126, 34);
  } else {
    fill(231, 76, 60);
  rect(ballX-(healthBarWidth/2) - 20, sensorValues[0] - 70, healthBarWidth*(health/maxHealth), 5);

void decreaseHealth() {
  health -= healthDecrease;
  if (health <= 0) {

void score() {

void printScore() {
  fill(89, 188, 255);
  stroke(27, 129, 198);
  rect(40, 30, 130, 50, 7);
  text(score, 150, 67);
  text("Score:", 90, 67);

// Reading Inputs from Arduino
void setupSerial() {
  myPort = new Serial(this, Serial.list()[ 0 ], 9600);
  // You will definitely get an error here.
  // Change the PORT_INDEX to 0 and try running it again.
  // And then, check the list of the ports,
  // find the port "/dev/cu.usbmodem----" or "/dev/tty.usbmodem----" 
  // and replace PORT_INDEX above with the index number of the port.

  // Throw out the first reading,
  // in case we started reading in the middle of a string from the sender.
  myString = myPort.readStringUntil( 10 );  // 10 = 'n'  Linefeed in ASCII
  myString = null;

  sensorValues = new int[NUM_OF_VALUES];

void updateSerial() {
  while (myPort.available() > 0) {
    myString = myPort.readStringUntil( 10 ); // 10 = 'n'  Linefeed in ASCII
    if (myString != null) {
      String[] serialInArray = split(trim(myString), ",");
      if (serialInArray.length == NUM_OF_VALUES) {
        for (int i=0; i<serialInArray.length; i++) {
          sensorValues[i] = int(serialInArray[i]);

Recitation 10: Making a Media Controller- Jake Scavone (Rudy)

Recitation Exercise

To begin this project, I first wired a controller that I would use to control the functions in processing. I noticed a lot of people using potentiometers, but I decided to use two buttons instead. The wiring was relatively basic and I was able to complete it without any difficulties.

Using two buttons as inputs left me with a difficult challenge that I did not know how to go about. Instead of sending a single byte of information, the two buttons would need to send multiple bytes. Since I really had no idea what I was doing, I reached out for help with this process and had an extremely helpful lesson from one of the IMA professors. I sat down with him for about an hour and in our discussion, he not only walked me through the process on how to achieve what I’m trying to accomplish but also made sure that I understood every step of the way.

After testing my understanding of the process, the Arduino controller I made could communicate with processing.


I decided to use two images and assign them to a single button. Using if, then, else statements to alternate between the two photos depending on whether the button is pressed or not. The other button would use the same statements but instead would apply a filter to the images if pressed. The result was a relatively basic yet sufficient example of a project that used physical inputs on an Arduino controller that controlled an interface in the Processing software.


import processing.serial.*;

String myString = null;
Serial arduino;

int NUM_OF_VALUES = 2;   
int[] sensorValues;      
PImage happy;
PImage mad;

void setup() {
  size(600, 600);
  happy = loadImage("happy.PNG");
  mad = loadImage("mad.PNG");

void draw() {

  if (sensorValues[0]==0) {
    image(happy, 0, 0);
  } else {
image(mad, 0, 0);
  if (sensorValues[1]==0) {
  } else{


void setupSerial() {
  arduino = new Serial(this, Serial.list()[ 0 ], 9600);


  myString = arduino.readStringUntil( 10 );  // 10 = 'n'  Linefeed in ASCII
  myString = null;

  sensorValues = new int[NUM_OF_VALUES];

void updateSerial() {
  while (arduino.available() > 0) {
    myString = arduino.readStringUntil( 10 ); // 10 = 'n'  Linefeed in ASCII
    if (myString != null) {
      String[] serialInArray = split(trim(myString), ",");
      if (serialInArray.length == NUM_OF_VALUES) {
        for (int i=0; i<serialInArray.length; i++) {
          sensorValues[i] = int(serialInArray[i]);

Final Project Proposal Essay: Jake Scavone (Rudy)


I constantly find myself with countless empty plastic bottles that end up on my desk or at the bottom of my bookbag by the end of the week. While I could fill them up at a water fountain and reuse them again, many, if not most of the bottles, weren’t originally water. While I usually just recycle them and go buy more, I still feel like it’s a waste of a reusable bottle. Vending machines are proven to be very successful, practical, and easy to use for all consumers. Back home, whenever I go to a wholesale store such as Costco or Walmart, I notice there’s a machine out front where people insert empty cans and bottles to be recycled, and the machine rewards the contributor with a couple cents for each one. I also notice conventional vending machines, where money is inserted and then the chosen beverage is dispensed at the bottom. What if there was a combination of the two, where you could insert an empty bottle that would otherwise be thrown away or recycled, and the machine refills it with a variety of beverages that you could choose from? For my final project, I would like to design, code and prototype this machine while using both Arduino hardware and an interface coded in Processing.

As for how the machine would work, it would actually be quite simple. I could use a cardboard box as the structure for everything and I would want it to be about two and a half feet tall and two feet wide, while the depth could be only a couple inches. At the top would be a section cut open where you would insert an empty bottle. Then, using gravity and some strategically placed angled pieces, the bottle would fall and orient itself upright and in a clear compartment near the bottom-left side of the box. I could place my laptop in front of the machine and use processing to create a user interface that instructs users on the steps to take, similar to as if it was a digital display on a conventional vending machine. For example, the screen would first say something like, “Take off the cap and insert the bottle above.” Once a bottle is passed through the top, a type of sensor in Arduino would indicate the event happening. The interface would then change to a selection of beverages, each one being a button with some texts and designs on it indicating what it is. Once a button is pressed by the user, the interface would display “Your drink is being poured, please wait a moment.” During this, you could look to the compartment and see your bottle being refilled with whatever you chose. In theory, if you select Sprite then a system would fill it with Sprite. Since the availability of fluid compatible parts is rather limited and the combination of liquids, cardboard, my laptop, and Arduino hardware would probably not end well, it would be probably best to not actually have it dispense anything that is wet. Instead, this process can be represented by filling the bottle with colored little plastic balls or paper scraps that would have to be released from a compartment hidden above with a servo motor or something.

Over the next few weeks, I will follow a rather lenient but structured order of steps for the development process. I will first like to make the user interface in processing and establish a proper order of events for the user’s interaction. After this would be a good time to connect the necessary components into Arduino. I predict that I would probably use a servo motor, infrared distance sensor, a buzzer, and possibly a few other parts. Since the servo motor and distance sensor are going to be separated from the breadboard, I expect that I will need to solder extensions to account for the distance. After the hardware is connected, I can establish the communication between the Processing software and Arduino. Finally, I can create the physical structure of the device by using a material like cardboard or foam boards. Then, I would have to fix the Arduino hardware into the correct locations.

Over 20 billion plastic bottles are thrown away every year. That’s over 60 million a day, and these numbers will only increase as the human population continues to grow. This garbage will either end up in landfills or even worse, the ocean. In order to cut back on this massive carbon footprint we are leaving for future generations, methods of recycling plastic bottles are very much encouraged. Still, only 10 percent of plastic bottles are actually recycled according to Forbes.

The Re-Vend machine would encourage people to reuse bottles instead of discarding them. As a result, the effort could hopefully reduce this large amount of waste that is polluting our planet.

Recitation 8: Final Project Process- Jake Scavone (Rudy)

Preparatory Research And Analysis


The work in the IMA course has certainly involved aspects that I previously claimed when defining “interaction.” I discussed that ‘interaction is the occurrence of an input of some sort, followed by an output, in this case usually over some sort of technological medium.’ This occurrence of an input and output can be witnessed throughout many of the tasks that we’re assigned in class. A strong example of this is the program Processing that my classmates and I have been exploring recently. The program interprets the lines of code that we input, currently referring to shapes, colors, movements, and functions alike. Once processed, the program illustrates the output.


After completing the midterm assignment, my definition of interaction remains the same and applies for the most part. While this is true, I had the pleasure of testing and observing my classmates’ projects, and each one was different from the next in some unique way. This opportunity allowed me to broaden my understanding regarding how many ways interaction between a user and device can be interpreted as. I specifically remember a project that I played around with during the user testing session. I don’t recall the students’ name, but he created an impressive box-shaped game that had rows of led light strips on the top that were adjacent to one another, looking like a grid. He programmed his project to utilize sensors that detect when the box is tilted in a direction and quantifies the values. With this in place, he programmed the LED’s on the strips to form paths resembling a maze. The maze would alternate each round, and a single LED light would be colored white resembling your position, and a blue LED was placed at the end. By tilting the box, you maneuver the white starting LED to reach the end. While I imagine creating this was no easy task, the prototype amazed me, and the core foundations were flawless. I later explored another project whose purpose was to maintain and care for a plant. Though the project was not finished, the students planned to have moisture detectors and servo motors controlling a cup that would pour water onto the plant when needed. After witnessing both projects, I couldn’t help but think about how each one is a great example of interaction, yet they were both so different from one another. This significantly contributed to the evolution of my definition of interaction, as I realized there’s a countless number of ways an input and output can be pronounced.


I often look out for any new or unusual methods of interaction that I may come across. Just recently, I had the opportunity to travel to Tokyo, Japan. During my trip, I visited an apparently popular place called Sushi Ginza. My experience in this place was unlike any other restaurant in my life. The reason for this is because it used a conveyor-belt styled delivery system. While this is quite common in Japan, this was my first time eating at a place with such a system. Sushi Ginza was unique in relation to conventional styles of conveyor-belt sushi. Three levels of tracks wrap around the restaurant, each seat facing some portion of it. Then, between you and these tracks, was a built-in touch-screen device. On this device you would browse through a selection of foods and select whatever you want. In less than a minute, your order is delivered right in front of you. The screen instructs you to take your food, and then press the “return” button right after.

My brief and unprofessional video above demonstrates the delivery process and the image below that provides a glimpse of the touch-screen displays as well as the number of empty plates in front of me. I could go on forever on how much more efficient and enjoyable of an experience this was, but that’s for a different time. This method of interaction that Sushi Ginza implemented into their restaurant strongly contributes to my previous definition. While replacing the waitress and server, this system requires an input, and shortly after, there is an output. In this scenario, the input is the touch of a button on a digital menu and the output is a fresh piece of sushi.

On the other side of the world, Boston Dynamics is an exclusive company based out of Massachusetts in the United States.  For the past decade, Boston Dynamics builds “advanced robots with remarkable behavior: mobility, agility, dexterity and speed.” I’ve been following any information regarding this company since I first discovered it three years ago. I find their accomplishments fascinating and the progress they have made in the robotics sector is truly unbelievable. The products that Boston Dynamics have been exploring challenge my definition of interaction. This is because of the role that specific robots are being made to take. “Atlas” is the name of one a specific robot they have developed, and its method of interaction is too sophisticated to be understood as an input/output. While we can reduce this technological complexity down to an array of sensors and code to fit this understanding, I believe that would be rather illogical as well as disrespectful in a way (to both the robot and the development team). The intended purpose of the robot and current reality is that it’s made to interact completely with the environment around it. The artificial intelligence packed into Atlas is advanced enough that it can outperform human tasks and even handle any interferences. For example, the video below shows Atlas handling a variety of challenges.

Video Link

To explain what I’m trying to argue, we can reference the clip where Atlas opens the door. Instead of being programmed to open that specific door, Atlas can open any door. The movements made by Atlas to open the door are not pre-determined, and in fact is a result of the information gathered and computed by hundreds of LiDAR and Stereo Vision sensors. The ability to understand and process the environment allows Atlas to approach a variety of challenges without being instructed exactly how to do so.


Tilting a box around to complete a maze, ordering sushi off an iPad, and sitting back while a robot does your job for you are all strong examples of interaction. The medium which interaction is apparent varies between such technologies making it impossible to define while still being applicable to the next. Nonetheless, throughout this vast ocean of devices, there is a shared similarity that can certainly be defined. Interaction, in respect to my personal and observed experience, can be interpreted as any technology that influences or is influenced by the environment around it. These environmental influences can come in the form of data, movement, or the touch of a button.


Midterm Project- Jake Scavone (Rudy)




The main purpose of our project was to create a simplistic game that involved a competitive style competition between two users. Our goal was to have the project replicate an arcade styled game, that could be played and understood in a quick and efficient manner. As many people have been introduced to arcade style games at some point in their lives, it’s clear to notice that many of the games follow a specific formula that keeps users interested and entertained. Two of the main components of said formula are both a challenge and a reward. To cater to this successful strategy, we designed BackFire to be a game that would require the players to compete against each other and be challenged and rewarded at a relatively fast pace. To beat your opponent, you need to have a quicker reaction time. Our game tests the players’ ability to react to a signal in a very fast way, and the more you fall behind the harder of a chance you have to come back and win.

Literature and Art, Perspectives and Contexts:

There’re many different methods for creating a challenge in a game and we explored a variety of examples, including mimicking used in the game Simon Says, and forms of strategy like in the game Battleship. We ultimately chose the challenge of reacting fast(er) not only because it didn’t present many challenges, but because it’s a valuable characteristic in every-day life. To verify the importance of one’s reaction time, we referenced an article on the website CogniFit titled Reaction Time, Cognitive Ability-Neuropsychology”. The author explains reaction time to be “the amount of time that takes place between when we perceive something to when we respond to it. It is the ability to detect, process, and respond to a stimulus.”  The article also discusses the different ways reaction time is important and affects our daily life, and even claims it can be trained and improved. When my partner and I were brainstorming how our game would be played, we wanted to know if testing user’s reaction time would be a significant challenge to base it off, and this article confirmed the importance of this skill. Our game BackFire tests your reaction time in a competitive manner and playing the game can ultimately enhance your ability to respond to a stimulus.

Throughout the process of creating our game, I had two main concerns. First, if the task and objective would be easily understood by the user. Second, how we would design the physical appearance of the game to be structured, uniform, and not flimsy in any way. I had these concerns because I believe these two ideas are up there with the most important elements relating to game design. I wanted to convey my thoughts to my partner to make sure we were on the same page. To assist my effort in doing this, I used an article by Chris Cosentino titled Simplicity in Game Design”. The author explains how the importance of having “tight controls and a clear objective” contributes to the ability for anyone to pick up a game and start playing it, which is something we wanted our game to involve.

My second concern relating to the physical structure of our project came from viewing our classmates’ creations. I saw multiple projects that I thought were amazing, as well as a variety of creative ways to interact with technology. Despite this, I was always disappointed when the project was made of something like three pieces of cardboard connected by a bunch of wires and tape, requiring two people just to carry it somewhere without falling apart. I would imagine how “it could be so much better if it just, well, looked better!” This made me realize the importance of having a structured physical design of our game. Because we kept this in mind, the final product of BackFire has no wires hanging out of it, no pieces that would fall out if flipped over, and is all packed into a strong casing. Although, the consequence of having all the wiring and hardware packed inside made it very difficult to make changes and secure connections.

Researching fundamental ideas about the concepts we wanted to include in our game validated our questions on what was most significant while exploring other projects gave us an understanding on how we wanted to structure the physical appearance and steer away from certain design flaws.



Our project, BackFire, is a two-player game where both players compete against one another. The game tests your reaction times against each other, and the quicker you are, the quicker you’ll win.

The left side of this photo can represent where player one is, and player two on the other side. To start, both players sit across from one another and places a finger on the button respective of their side. When ready, both players need to hold their button down at the same time for three seconds. After this is done, all the lights on the board flash a couple times indicating the game is about to begin. Then, complete silence… Both players readily stare at the LED on the top, waiting for it to flash. Once this random increment of time is over, the LED at the top flashes, and the player who presses the button first wins the round. If player one was had the quickest reaction time and pressed the button first, the green lights on his side flash, then the indicator piece pointing out from the top controlled by a servo motor will move an increment in the opposite direction, pointing at player two. Then, after a random number of seconds, the light will flash again. If player one pressed the button first for the second time in a row, the indicator piece will move in another increment in player two’s direction. Although, if player two won that round the piece would have gone back to the starting position. Then, after another random number of seconds, the light will flash again. If player one was the first to hit the button quickest for the third time in a row, the indicator will move to the last interval, concluding player-one to be the winner. The lights on player one’s side will flash a bunch of times indicating who won.


My partner and I believe that the significance of our game lies upon the fast-paced competitive aspect. These two elements are what makes a game intriguing, challenging, and entertaining. We hoped to grasp these elements and replicate them by the end of our project, and we believe our game BackFire is a strong representation. The core elements that BackFire is built upon can appeal to audiences from all demographics, and there is no specific audience we wanted to target most.                             

Design & Production:

My partner and I decided to make a game for our project for the main reason that games are often a strong way of representing interaction. We also believed that making a game would allow us to utilize our creativity and ability to alter ideas/concepts. We decided that we wanted our creation to include a strong competitive aspect and involve no more than two players at a time. After this was established, we spent a considerable amount of time brainstorming different games, as well as creating many sketches modeling how it would work. A strong contender was the idea presented in the sketch below:

The thought process behind this concept was that each player would have two buttons and be challenged to use them in a (undecided) way to influence a motor in order to raise an object to the top. The winner would be declared by whoever reached the top first, and the objects would be connected to a string that acts as a pulley system, with the motors being hidden inside the base platform. We ended up moving away from this concept because we wanted to avoid using strings since that proposes the possibility of them getting tangled or not performing how we want them to.

After exploring many more concepts, we ultimately decided on the following model:

Both my partner and I understood that if we found a suitable object to use as the base/container, we would only have to alter the board on top. We also wanted to avoid using cardboard, as we agreed that it usually doesn’t end up looking too clean or sophisticated. We scavenged through the materials closet on the 8th floor and found a plastic box that would work perfectly. We traced the outline of the base onto a piece of foam board. After that was done, we placed each piece of hardware on top of it and played around with different layouts to see what we thought would work best. Once that was established, we used a pen to mark the areas for where we would need to cut to insert each component, such as the LED lights, buttons and servo motor. We used the box cutters in the class and discovered that making clean cuts took a lot of patience and precision. We then signed out a drill from the equipment room and alternated between a few sizes to make the proper hole dimensions we would need in order to fit the buttons and LED’s.

Creating the circuit and code for the game came as a huge challenge, and we found ourselves looking up almost every statement that we didn’t understand how to use properly online. At many times we had to ask other students for help with troubleshooting the issues with wiring we came across. While very time constraining at the moment, this process of using outside sources to help us solve issues ended up being a significant learning experience and massively increased my ability to understand the wiring of circuits as well as the code used in Arduino. Something I didn’t have much experience with prior but was required to do was soldering wires. For the wires for the buttons to reach our breadboard, we needed to solder extensions onto them. This was a cool experience though and I enjoyed learning the process behind a technique I see myself using in the future.

We got very unlucky when it came to our presentation. Since we were behind on schedule, we only finished the model the night before. When we took it out to present the next day, we found out that the battery died. We quickly signed out a new battery, only to discover that one was dead as well. We later confirmed it wasn’t a hardware issue because it worked when we hooked up an adapter and provided power from an outlet instead. We didn’t lose hope because we remembered we still had a video demonstration of the game working included in the slides for our presentation. When we went to go play the video, it said that it needed authorization from our Google account to play, which we didn’t even think about since we had no issues viewing it from our own computer, and the presentation was being viewed from the professors account. The inability to have our project functioning made it almost impossible for our audience to understand how the game worked. Rudy seemed very disappointed.


At the end of this process, I believe that our game achieved the goals we had. When working, BackFire is a simple, fast-paced competitive two-player game that my partner and I had a fun time testing. Although the end result appeared to be a failure to my professor and classmates, I know that our errors could’ve been solved by managing our time better to allow for more testing prior to presenting. If we had more time, me and my partner both would have liked to add more of a design and theme to the game, as well as a speaker to add more elements such as buzzing a certain melody when there was a winner, or when the game is starting.

In retrospect, I realize that this midterm wasn’t about coming up with the most unique and fancy project. More importantly, this was a way to challenge our abilities to turn an idea into a product and tackle the countless obstacles that are presented by the process that follows. Collaborating with your partner and agreeing on the same goals, organizing the order for what steps you need to take, prototyping different concepts, using the resources available to fabricate a physical product, and even utilizing the constructive criticism presented by classmates during user testing is not an easy task. I can confidently say that this project was a powerful learning experience, and I took valuable lessons away from the process. I realized that I’m good with organizing what step needs to be done first in order to move onto the next one, but I need to improve on my time management skills for certain parts of the process. For example, I found myself still thinking about other concepts to pursue while we were already halfway finished. I shouldn’t have spent so much of my thought process on redesigning the entire project and instead just stuck with what we decided in the first place. One thing I hope to accomplish in the future is to choose an idea that would require the use of different fabrication processes, such as 3D Printing, laser cutting, or the CNC Machine. I would like to have the opportunity to experiment with those machines and learn more about them.  Regardless, the freedom we were given to create an interactive project we could think of gave me the opportunity to really test my ability to follow the creative process and stay organized. I had the pleasure of working with different tools and materials offered by the course and discovered ways that I could improve my ability to be more productive and effective for the next project.


Recitation 4 Documentation – Jake Scavone

Drawing Machines


  • 1 * 42STH33-0404AC stepper motor
  • 1 * SN754410NE ic chip
  • 1 * power jack
  • 1 * 12 VDC power supply
  • 1 * Arduino kit and its contents

Step 1: Build the circuit


Unfortunately, I forgot to bring my Arduino kit to class. As a result, I was required to check out the equipment I needed for the project. All the wires they had available were red so please excuse the mess.

Wiring wasn’t too difficult. It would have been easier to wire if I could color code, for example, red wires for 5V Power and black for any wire that’s grounded. Overall the circuitry wasn’t far different from what we’ve done prior, and comparing the result to the diagram in order to check everything was very helpful.

Step 2: Control rotation with a potentiometer

After I connected the potentiometer correctly according to the diagram, I loaded up the code required in the Arduino software. After uploading the code to the board, nothing worked. I had to troubleshoot and see if there was something wrong within my wiring. Although it was quite difficult to find when all the wires are red, I ultimately discovered that my problem was a simple wiring error. Once I fixed said problem, I was faced with another challenge. I uploaded the code again and started the program. The potentiometer started rotating, but after about five seconds everything stopped working. The Arduino board lost power and refused to turn back on.

Step 3: Build a Drawing Machine!

The two problems I faced with the Arduino left me with no time as well as no working motor to assemble the drawing machine. My partner, Stanley Virgint, was ultimately able to get his working, but we were unable to find an available student who didn’t already have a partner and were up to the same step.

Question 1:

What kind of machines would you be interested in building? Add a reflection about the use of actuators, the digital manipulation of art, and the creative process to your blog post.

Although more fantasy, this topic is soon becoming a reality. Exoskeletons have fascinated me since I saw the movie Iron Man released in 2008.  I would love to build some sort of exoskeleton on a smaller scale, perhaps just for an arm or something. Theoretically, I would use multiple actuators and motors, all connected to a variety of sensors within a brace-like structure that would go over someone’s arm. When the sensors detect that your arm is moving in a certain way, it would use the motors to assist the user. Exoskeletons are currently being tested for soldiers carrying heavy equipment over long distances. The goal is to take all of the weight and strain off of the user.

Question 2:

Choose an art installation mentioned in the reading ART + Science NOW, Stephen Wilson (Kinetics chapter). Post your thoughts about it and make a comparison with the work you did during this recitation. How do you think that the artist selected those specific actuators for his project?

An art installation mentioned in ART + Science NOW that caught my attention was Andy Gracie’s “quasi-symbiotic environment” maintained by a robot. On the topic of replacing jobs with more efficient and precise robots, this installment closely relates to where I think the future of agriculture is headed. In this environment, the “robot cares for plants by moving back and forth to control nutrients and other conditions.” This is similar to what we did during the last week’s recitation. The relationship that I see most is how small inputs produce bigger outputs. This is seen by how we made small rotations with a key on our potentiometers to instruct the arm to draw accordingly. Andy Gracie’s installation also requires little inputs but ultimately fulfills an entire task on its own.

Week 4 Research Project: Jake Scavone (Leon)

To define interaction in my own way, I reflect upon the daily communications I have with different technologies. From pressing a button in an elevator to speaking to Siri through my phone, interaction can be witnessed through many different mediums. Interaction is the occurrence of an input of some sort, followed by an output, in this case usually over some sort of technological interface. Two examples of interaction that I would like to reflect on is the ALEXA Smart Mirror made by Grensom on YouTube and the Breakfast Machine by Simone Giertz, also on YouTube.

A channel named Grensom on YouTube posted an 8-minute video about his most recent project. This impressive project is what he calls the ALEXA Smart Mirror, and the author even includes a tutorial on how to build it yourself. Personally, I liked everything about the final product. The ALEXA Smart Mirror is efficient, clean, and so useful that it comes off as an absolute necessity for an average person’s daily life. Also, this interactive device also has lots of feedback consisting of many people in the comments on the video interested in purchasing one, so it’s clear that this device is appealing and has a market.

Video Link


On the contrary, I disliked a product made by Simone Giertz called the Breakfast Machine. Although the creation of this device is obviously not to be taken seriously, it provides a good example of certain interactive devices that are the opposite of the direction we should be taking technology. While such technologies are supposed to improve our daily lives, making tasks more time-efficient and friendly, the Breakfast Machine does the opposite.

Video Link

When given the task to prototype an interactive technology that would be used 100 years in the future, I couldn’t help myself from thinking about drones. The use of drones in our daily lives is inevitable and is undeniably going to cut out countless conventional standards for performing certain tasks. My group decided to come up with a design for a food delivery drone and create a basic prototype that we could present to the class.

The delivery drone is a very realistic product that would make massive improvements to the current delivery system of food. In theory, food vendors would own one or many of these drones. After receiving an order, the food is prepared and then placed in the compartment under the drone. This compartment would then be locked, and the delivery address would be inputted into the screen interface by the vendor. The drone would then send off and arrive at the destination within minutes of ordering. When the drone arrives at the consumer’s address, the person who ordered it would then have to scan the QR code on the drone to verify the correct purchaser. After, the compartment would be unlocked, and the food could be taken out. The drone would then fly back to the vendor and remain ready for another delivery.

The Delivery Drone would open an entirely new market for vendors. First, it would cut down delivery time dramatically. It would also reduce the need for delivery cars, which is an ecologically friendly alternative as well as reduce traffic in highly populated areas. An extremely big upside to our product is the increased market base. If you open any food delivery app on your phone, you’ll notice that you only have the option to order from places that fall into a certain distance radius. With the delivery drone, this radius would increase massively, allowing for food vendors in obsolete locations to provide for a much larger market.

When I view interactive technologies such as the ALEXA Smart Mirror and the Breakfast Machine, I can’t help but think about the practicality and realism associated with these products. The Smart Mirror is a beautiful device that clearly has a market and practical use, while the Breakfast Machine is rather pointless. The Delivery Drone would be an extremely useful technology that would provide many more possibilities for tens of thousands of food vendors across the world.

Recitation 3 – Jake Scavone

LED lights by an Infrared Distance Sensor

My partner and I created a device that utilizes an infrared distance sensor to control a series of three LED lights. Certain LED’s are assigned different value categories from an infrared distance sensor. There are three LED’s: green, yellow, and red. Depending on how close an object is to the distance sensor (in this case, a hand), different lights will be activated. If the object is far away, the green LED will toggle on. As the distance decreases, the yellow LED turns on, then the red one.

Electrical Diagram

Electrical Circuit



Question 1:

What did you intend to assemble in the recitation exercise? If your sensor/actuator combination were to be used for pragmatic purposes, who would use it, why would they use it, and how could it be used?

My partner and I wanted to create a circuit that would provide an example of how certain distance sensors could work. This type of system is widely implemented in technologies that already exist. A good example of this is the parking sensors on modern vehicles. As you get closer to a obstacle, such as a curb or wall, the display on your car warns you similar to how our circuit does.

Question 2:

Can you identify your circuit with any device you interact with in your daily life? How might your circuit be used to have a meaningful interaction?

A device that I interact with in my daily life that uses a distance sensor is my iPhone. If you are on a phone call, the screen will automatically turn off every time you put the phone to your ear. This is because of the infrared sensor on the top of the device, and it turns the screen off so that when your phone touches your face it doesn’t press any buttons unintentionally.

Question 3:

How is code similar to following a recipe or tutorial?

When following a recipe, the goal is to follow every single thing correctly and replicate the final product. This is very similar to coding because if you follow a specific guide, you’ll end up with the same results as long as you did everything correctly.

Question 4:

In Language of New Media, Manovich describes the influence of computers on new media. In what ways do you believe the computer influences our human behaviors?

The computer has a profound influence on human behaviors, as it serves as such a powerful tool, capable of altering human behavior in a means to accomplish tasks more efficiently.


Recitation 2: Arduino Basics – Jake Scavone

Recitation 2: Arduino Basics

Jake Scavone and Stanley Virgint


1 * Arduino Kit and its contents

Recitation Exercise:

Circuit 1: Fade

The “Fade” circuit utilized a minimal amount of materials, making it the simplest circuit to create. All that was needed was an LED and one 220 ohm resistor. As seen in the video, the program instructed the LED to fade brightness continuously.

Circuit 2: toneMelody

Constructing the “Tone Melody” circuit was similar to the  “Fade” circuit, as a minimal amount of materials were needed. The whole circuit consisted of one buzzer. Once the program was uploaded to the Arduino, the buzzer played a short 4-second melody, as seen in the video below.

Circuit 3: Speed Game

The “Speed Game” circuit was definitely the most difficult circuit to construct. It required a variety of materials, which included 2 LEDs, 2 buttons, 4 resistors, and a buzzer. Our first attempt at creating the circuit was unsuccessful, as the LEDs were not receiving power. However, after analyzing the circuit, I was able to pinpoint a wire connection issue and resolved this problem. Once completed, my partner and I were able to play a 10-second game, competing to see who could press the button the most times. As shown in the video below, the LED light would turn on to indicate the winner of the game.


Question 1:

Reflect on different interactions with technologies that you have observed in your daily life. Pick a few of these and write down your own definition of interaction based on your observations.

In my daily life, I interact with a vast amount of technologies. These include, but are not limited to, Amazon Alexa, the elevator, and the key card-activated entrances.

For Amazon Alexa, the device is activated and controlled by the user’s voice. This method of interaction between consumers and technology is relatively modern and can be found on many different devices. An example of the interaction between Alexa and myself is when I ask it to set an alarm. I simply say “Alexa, set an alarm for 9:45 tomorrow morning” and it does that.

The elevator is another method of interaction. Universally simplistic, you just push the corresponding button to your floor number and it will bring you there. The elevator is also packed with sensors and such that make sure the ride is safe. For example, a sensitive pressure sensor makes sure that when the doors close, if there is something obstructing its path, it will stop and return to being open immediately.

Every day walking into the academic building at NYU Shanghai, students and faculty alike are required to put their key card close enough to the gate sensors in order for them to allow entrance. This method of interaction allows for a secure and efficient way of entering buildings.

If I was to define interaction in my own words based on my personal experience, it would best be described as the collaboration and interface between a consumer and a technological product. Another interesting thing to note is how the interaction between the consumer and technology seems to get more efficient and productive as time goes on.


Question 2:

During the assembly of the circuits, we used many electronic components as inputs and outputs. Which of these components do you recognize in the circuit?

One of the components that I was familiar with was the Arduino UNO microcontroller. Throughout my computer science and engineering courses in high school, we would often use microcontrollers to make our projects.

Question 3:

If you have 100000 LEDs of any brightness and color at your disposal, what would you make and where would you put it?

If I had 100000 LEDs at my disposal, I think a fun project to make would be a giant clock that would be able to shift from digital to analog at the user’s choice. It could also have some cool features, for example, every time it becomes a new hour it all shifts into a giant colorful projection of that hour.