In this recitation, we learned how to send information from Arduino to processing and vice versa. The time slot was divided into two sections: one to create an “Etch a Sketch” machine using potentiometers to control the direction of a line on processing, and the other to create a musical instrument using the buzzer and variables from processing to change the pitch.
Exercise 1: The Arduino code was very simple to set up, but the processing code took some time. I started by drawing ellipses in the draw loop, but they would not create a continuous line because they could not keep up with the frame rate. After making a line, the transition was much smoother. Besides that, the processing code required a lot of library information I am not familiar with to work properly, which can be very confusing. Below is the final product along with a schematic of the Arduino circuit:
Exercise 2: For this portion, I decided to use the “mouseX” position on processing to alter the pitch of the buzzer. Originally, the buzzer did not have much of a range because it was only registering the width of the canvas for the x values, which did not extend to the limits of the buzzer’s range. Using the map function, I was able to use the entire range of the buzzer with my limited canvas space. I ran out of time, but I would have liked to draw a line when my mouse was pressed, which would not have been very difficult since we have already done that in a class exercise. Again, below are the video and schematic of Exercise 2:
(NOTE: I used the same breadboard for this as the last exercise, so the circuit looks much more complicated than the schematic because the two potentiometers from Exercise 1 are still attached, but they serve no purpose in Exercise 2).
Prior to the group projects, I viewed “interaction as “a process by which two actors can make decisions based upon what the other is doing or has done. Whether the actors are human, animal, or automated, as long as they are capable of acting, processing, and reacting, interaction is possible” (Murdoch, Group Project post). Although close to what I envision now, this definition lacks one crucial aspect. It measures interaction as Boolean: either interaction exists, or it does not. There is no scale of less interactive to more interactive. Low interaction may be something like the light in the refrigerator (although perhaps this counts more as a reaction than an interaction). In comparison, Wii tennis seems grossly more interactive than a refrigerator light, but the definition I provided does not account for that.
Researched Projects
For my first researched project, I selected one called “Points of Interest.” This project was put on display at the International Contemporary Art Fair for Independent Artists in January of 2019, and although it appears interactive, it does not very well fit my idea of interaction. This project invites viewers or other artists to take a small sticky note, write their favorite hotspot or location to visit, pin it to a map, and write the exact address on it. This allows people to come and see what other people have done and view a plethora of interesting location with readily available addresses. To me, it is interactive insofar as it invites people to physically do something and engage with the project. However, the project is not responding to any of the actions the viewer takes, nor is it outputting any information. One possible area of interaction is if the project invited multiple people to pin their hotspots at once and then converse with one another about said locations, but that would consist of interaction between people and not between the project and viewer/actor. Therefore, while I find this project genuinely interesting, it is not something I consider within my parameters of “interaction,”
The second project I found is titled “Chatty Coasters”. Chatty Coasters is a project that I find to align well with my definition of interaction because, when compared to the previous example, it clearly demonstrates the different levels of possible interaction. These coasters have been programmed to detect long lapses of silence in a conversation and ask interesting, sometimes provocative questions to stimulate the conversation. One may argue, again, that the interaction is occurring on the side of the people having the conversation, but once analyzed more closely this is not the only interaction occurring. The coaster inputs sound values, and as long as they remain high, does not activate. This means it actively either responds to silence or to the noise level by talking or staying quiet. I can become more interactive by hearing silence, or less interactive if the conversation continues on its way.
New Definition of Interaction:
Although Chatty Coasters is very interactive, it still does not achieve what I consider optimal interaction. Here I will draw from Horkbaek’s research on interaction. I agree that interaction must consist of a continuous transfer of information between two agents that may change according to sent and received information, but Hornbaek mentions something I find very interesting. Agents that communicate are especially interactive when they can not only exchange information but also adapt to the received information to better achieve a desired goal (4). Therefore, here is my new definition of interaction:
“A process in which two agents, whether they be human or other, send and receive information from one another. What each agent sends must be influenced by what it receives from the other agent. The level of interaction can be low or high based on the variation of sent and received information, as well as to what degree the information changes the other agent’s response.”
Works Cited
Hornbæk, Kasper. “What Is Interaction?” University of Copenhagen, 2017.
Madeeha, Jasper, Cecile, Adam and Sangeetha. “Chatty Coasters.” Arduino Project Hub, Feb 2015.
In this recitation, we explored further the capabilities of processing. In previous classes, we had made simple shapes and learned to randomize colors, or make them move around the screen either by using the mouse or by preprogramming the shapes to do so. Instead of animating Recitation 6’s project, I chose to do something new.
The idea was to make a circle follow the mouse and change to a random color when it hits the edge of the screen (only for the x). Although very much useless, it seemed challenging and plausible. Below are the video and code:
This was my first experience using boolean, which we had studied but never actually used. Leon helped me fix an issue where only the right side of the screen would prompt a the color change.
Homework Part:
I found this not to be exceedingly difficult until the last (optional) step of confounding the circle to the screen. I managed to do it when the circle was not expanding and contracting, but not during. The video and code are below:
Using colorMode(HSB); to change the color of the circle was interesting. On the first attempt, the circle contracted and then expanded infinitely, until I remembered I needed to specify an outer boundary as well. This also helped me differentiate between the “if” and “for” functions, which I was rather confused about.
Albers, Joseph. “b and p.” 1937, Guggenheim Museum, New York.
I chose this image because it consists of shapes we learned to make in class. It seemed like a relatively simple design, but unique enough to provide a challenge. I attempted to directly emulate the image’s shapes rather than taking the liberty of creativity because I wanted to see how close I could get with my processing skills.
The first step was to create the background color and the smaller blue square. After that, things got more complicated. I first tried to make the “b” and “p” using four smaller rectangles, but the brown stroke would cut through the letters. I opted rather to write in the coordinates of each shapes’ vertices.
My version
For the brown centers, the lack of strokes allowed me to use simple rectangles. As for the color, I was uncertain of how to create the grainy texture the original painting has, so I stuck with the regular fill and matched it as close as possible.
However, there is one glaring difference between the two. The tan shape within the blue rectangle is not a rectangle; in fact, it appears to be two or three different rectangles that are slightly offset. Processing proved to be a very useful tool to realize this design. I’m sure there are many more uses that I am unaware of, but to the extent of my knowledge, I was able to fairly accurately replicate b and p. The code I used is below:
If we trace our final product, “Laser Arcade,” back to the planning period, it may be surprising that it did not even exist. Immediately after the Group Project, Daniel and I began brainstorming ideas for our Midterm Project. Daniel, who has much more experience in computer programming than me, had an idea to create a sort of virtual interface that users could play a simple game on using a remote (kind of like the Wii). However, we agreed that I would be fairly useless in such a task, so we scrapped that idea. It was only after the recitation with the drawing arms and servos that we finally knew what we wanted to do.
I researched some arcade games before finally (and strangely) arriving at the alien game Gru and the girls play in Despicable Me.
(Use the guns to shoot the spaceship).
From there, we transitioned from working together to playing against another player. Although the original idea was good and the level of interaction would be similar, the competitive nature proved much more exciting. I have been to many arcades in the US and have seen many similar games. However, most of the games register “hits” and “misses” with programmed coordinates rather than sensors. Since we had the sensors available, we decided to do that instead (also, the coordinate system would have burdened Daniel because I have no experience in that area). This project is intended for any two players looking for competitive fun. The laser pointer allows the player to easily identify where he/she is aiming and adjust accordingly, making it easier to control than other “shooters.”
Concept and Design:
Originally, we expected to have a list of rules for players to read prior to playing. However, we later reasoned that an arcade game should be clear and intuitive, and we shifted our design accordingly. We decided to limit ourselves to “Player 1” and “Player 2” signs to give the players a starting point. We included knobs for players to intuitively grasp and test, as well as including a winning sound and winning/losing animation for each player.
Knob.
Audio Cue:
Winning/Losing Animation:
As far as materials, we decided to simply save time and use the same green drawing equipment as in the recitation. In addition, we decided to use the ambient light sensor from our Arduino kits. We tested other sensors, but most of them were either too large or not sensitive enough (meaning the room light would almost max out the threshold). Our use of servos was inspired by the same recitation, and we saw no reason to replace them. The cardboard seen in the above footage was simply for the prototype; the final product was 3D printed, as I will show in the next section.
Fabrication and Production:
The first step in our project was writing the code. Although I did not contribute much to this aspect, I did what I could. Daniel explained to me what he did and why; although I cannot replicate it, I understand its function.
The next part was building the first testable prototype. This step took a lot more time than we anticipated due to unforeseen difficulties. For example, one of our servos unexpectedly stopped working (after we glued it together, of course). In addition, we had to 3D print a few small gadgets to facilitate the process:
Sketches for a tool to keep the arms of the drawer together (we ended up just using screws).Daniel and me designing something to hold the target-moving servo in place on the drawing arm, as well as a device to hold the laser button down.A design to attach the laser pointer to the arms.Our design for the base of the project (to hold the servos and backboard).
The cardboard set up we developed was only changed after the User Testing Session (mostly due to time management). This session also illuminated previously unknown problems with our design. Most commonly, players did not seem to understand the objective of the game. They understood they could control their lasers, but not where to aim. In response, we added a target around the light sensor.
Before the target.With the target.
Next, we realized players were not turning the controls as we intended: they were using them as two joysticks instead (this caused one potentiometer to break, further complicating the project.
To fix this issue, we took Marcela’s suggestion and 3D printed controls that looked like car radios, which everyone should know to rotate (as seen in the video above). The last thing we had to do was take apart the entire project and recreate it on the printed base. With precise measurements, Daniel and I completed this surprising quickly, and here are the results:
Aerial view of the structure.Side view of the structure.Final Presentation.
Conclusions:
The goal of our project was to create a two player game that requires each player to hit a target with a laser while simultaneously avoiding the other player’s laser. According to our definition of interaction, this project is highly interactive. The arms move in response to a player’s inputs, and according to their position, the player then readjusts accordingly. Furthermore, there is player-to-player interaction. The players are each responding to the actions of the other and making decisions based on the movements of the other player. However, one of the instructors pointed out (I don’t recall who), the game could be altered to a cooperative game rather than a competitive one. Again, we considered this but ultimately chose not to go down that path simply out of preference. Both concepts are equally interactive, but the competitive one was easier to imagine and build.
After the User Testing Session, we unfortunately did not have much time for further testing. The presentation went well, and the few who tested it understood the objectives and mechanics of the game. If we could do the project again, perhaps we would opt for the cooperative game. We would definitely be certain to test all our servos before gluing them to anything. We would also be more creative with the base. We wanted to include art/stickers typically seen on arcade machines but simply did not have the time to add them. From our accomplishments, I gained the knowledge that I can do much, much more than I originally thought I could do. Never did I think I would be able to 3D print such complicated gadgets or understand a more than a basic code. This opened a gratifying door for brainstorming final project ideas. The process of creating this has set a new standard for me, as far as future projects.
Lastly, our project shows that arcade games can be some of the most interactive forms of entertainment available. Laser Arcade brings forth aspects of interaction that are slowly fading away. Because our virtual world is rapidly expanding, many young people use the internet to connect with one another. Besides sports (which are physically taxing or require specialization, and therefore not for everyone), real-world competitive activities are almost exclusively virtual. In other words, our project revives competitive interaction for anyone willing to use it.
