Author: Dominick Nardone

Group Members: Isaac Schlager, Eva Solo, Nate Hecimovich

Step 1:

Isaacs project is based on the fact the many people who actually go to see the painting Mona Lisa, ten to be very unimpressed with the painting itself. In order to combat that, he offers to create an interactive version of the painting that allows users to select and emotion for her to express, thus adjusting the appearance of the paper. Some of the suggestions we gave Isaac were to consider adding dials along with the buttons, to adjust the amount of that specific emotion, from kind of happy to ecstatic. He was struggling to find a more meaningful purpose for his assignment, as in how it could help people in the future. I offered that he could slightly adjust the project to help children explain how they feel to doctors, as opposed to the piece of paper with 10 smiley faces on it that range from emotions of 0-10 and could really use an update. We also suggested that he saves each Mona Lisa his users make in order to see all the choices they did. 

Nate’s project seemed really cool. Based on a Bandersnatch, he wanted to make a Game of Thrones-themed create-your-own adventure story that would follow Robb Stark. I really liked this idea (although we weren’t allowed to talk much about the content of the game because Isaac had just started watching GoT and we would ruin the beginning for him. I also warned him to be careful, because depending on how in depth he wants to go along the options, it would require a lot of time to design all of the pages. He said that he would make sure a lot of options would result in immediate death, thus reducing the number of scenes he would have to make. 

Eva’s project focused more on the User’s experience, and how they navigate through a series of visual sketches. She was worried about a couple of things: how to enclose the user to prevent distraction, and how to bring sound in to play. We recommended that she enclose the user entirely, and used Ikea mirrors in order to achieve absolute visual concentration. On the sound concept, I warned her that she has to be very wise about what music she decided to use, as music has a massive effect on emotions. I suggested that she might want to use something as simple as white-noise in order to achieve an emotionally void pretense for her users. 

Step 2:

The most successful part of my proposal was that they really liked that I was pushing for a gaming mechanism that was void of buttons. They agreed that games tend to focus very heavily on the use of buttons (especially a game like Smash Brothers, which Nate brought up). The least successful part of my proposal was how I was going to have enough time to create a game, as it seems like a lot of work. I agreed with them, that it was very heavy on processing and would take a significant amount of time to create the game. I originally wanted to do two games, but they told me I should probably focus only on one due to time restraints. This will make me continue to push towards a single game that can be operated by a user without the use of any buttons. I will also spend all of my time on one game, rather than making two games as originally proposed. Due to focusing on the one game, the asteriod/space themed game, I feel like I will be able to get really well acquainted with Processing and will learn a lot and be able to find a more creative side of myself. 

This week, I attended the Object-Oriented Programming workshop with Tristan in order to learn how to better use the Class function and ArrayList function for my final project. Throughout the workshop, we utilized a Person class function in order to generate three people, Bob, Jose, and Jane. My little edit was that I added a new class, one that the player could use to interact with the people that we created in the class, a Zombie class. 

see code: 

Then, I set it up so this zombie would move with the mouse and “eat” the people one by one, growing larger each time.

code: 

In the end, I created a fun, easy game, and got to learn a lot about how to operate object-oriented processing.

video: 

Conception and Design:

My concept for GamesForAll originated from the lack of adaptive controllers for young gamers that push away from the standard use of buttons to something more accessible. So right off the back, I told myself that “absolutely no buttons.” So I started off by using an Infrared Distance Sensor, which as you can guess, was extremely inconsistent and it was very hard to get an accurate reading to stabilize the spaceship. Then, Professor Rudi suggested I try out the Ultrasonic Distance Sensor. Due to the delay in the input and output mechanism of this sensor, I was able to prevent the sporadic jumps in values that the IR Sensor was prone to. Another options, although slightly more complicated, was to use two IR Sensors that would constantly check the difference in values between the two sensors (similar to the turnstiles that you tap your NYU ID to go through). Yet, I decided to stick to the Ultrasonic Distance Sensor due to time restrictions and the ability to work with a new sensor (I used an IR Sensor for my midterm project). In terms of the game development side, I really got to learn a lot about Processing and object-oriented Processing (Thank you again, Tristan, for the fantastic lesson). I was able to utilize Array functions to best optimize and modulate my game. Although for my meteorites, I simply used an ellipse function, for the spaceship, I used Gravitz (free design application), to create my own spaceship from scratch, which was loads of fun and something that I have never done before. 

Fabrications and Productions:

To begin, I focused very heavily on the Processing side of the project and perfecting my ability to use Array functions. The first thing I did was use PImage to import a starry background, to set the mode for my spaceship shooter game. Next, I created a new Tab to make a class for the meteors. Within this tab, I created the Meteor class and created a function generateMotors() in order to create the meteors at a specific speed.

I also had to make a class and array for the bullets that the spaceship would e shooting. It is not much different than the meteor class.

Once I had these two classes created, I created functions for all of the scenarios that would cause the meteors to be added, such as when the meteors reach the bottom of the screen or a bullet comes in contact with a meteor, they should be removed to prevent the program from overloading, and a new one should be added.

As well as a condition to activate the endgame screen:

I must thank Tristan once again for his assistance and his amazing class on project-oriented programming, as it was a crucial foundation for the development of this game, from the math for hitboxes to the bullet delays.

During the User Testing Session, I had a few problems with the Sonar Distance Sensor. The discovery was that it doesn’t work so well at reading the distance of a hand (probably because it isn’t a flat surface). As a result, (although it defeats the accessibility aspect of the project) I was forced to make a physical representation of the spaceship to act as a controller (although thankfully it was still button free).

This is a print out of the model I created in Gravitz and I think it really helped guide the player, as they understood that wherever the spaceship is in relation to the screen, the spaceship is at on the screen. Another suggestion I got was to add a scoring mechanism, which was easy to implement and added to the bullet/meteor removal code above.  I was also told that the meteors moved a little too quickly, so I dropped he Framerate from 60 to 30, which also aided in the game running a lot more smoothly. Also, people didn’t know how to control the ship. This resulted in me sketching up a design for the fabrication portion of the project, that I was sadly incapable of completing due to a lack of slots. 

Gravitz image: 

Video of the game working can be seen here. 

Conclusions:

The goal of my project was to make a game that didn’t involve the use of buttons in order to make the game more accessible to young, physically disabled children that may be too young for the complex adaptive controllers that are currently on the market. Although I originally wanted the user to feel like their hand (or appendage) was the spaceship through the use of the Sonar Distance Sensor, I was unable to accomplish this, and as a result, made a handle for the user to use to guide the Spaceship. I still feel like this handle does maintain the no button goal, but decreases the level of accessibility (possibly?). I believe that even with the handle, the interaction still has a meaningful impact on the user (development of visuomotor skills), and still connects the user to the game. Sadly, I was unable to have my game displayed at the IMA show due to a class conflict. It would have been fantastic to see how the guests interacted with my game and what their thoughts were. My biggest takeaways from this assignment is that accessibility is no easy feat, and there is no single-off solution. I think my project still brings to light the fact that there are little to no products out there for young physically disabled gamers. My project is no solution, but I think it raises the questions: What other methods are there for gaming controllers outside of buttons? How can we make gaming a more accessible activity, especially for younger children? 

Creating the EtchASketch was very easy, as I have a complete understanding of the process of this device from my childhood. I immediately whipped together two 10k potentiometers to act as the left and right dials. On the Arduino coding side, I just set it up to read the analog data from both dials. On the Processing coding side, I had it use this information to control the x and y location of a small ellipse that would act as the brush. 

For the music machine, I had Processing just record the vertical location of the mouse and send it to Arduino, which then translated that information into a tone.