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?