Progress

Given a list of possible usable sensors, each of us came up with several ideas for games. These included a pasta cooking, music interpretation, knock-knock, multi-sensor, heartbeat racer, and asteroid dodging. We settled on pasta cooking, knock-knock, multi-sensor, and a hybrid heartbeat racer-dinosaur game. 

Pasta cooking: In a kitchen and given a pot of water over the stove and some pasta. Most of it is guided and the stages go on for you once completed. 

Knock-knock: Simulate multiple knock-knock jokes through the knock (piezoelectric) sensor. 

Multi-sensor: Given a list of commands, complete each within a certain time frame. The more that are completed, the longer the given commands will be until you eventually can't complete them in time.

Heartbeat racer-dinosaur hybrid: Similar to the classic google dinosaur game, but speed is dependent on heart beat, and jump is controlled by the knock sensor.

Each of us was tasked with a game. Henry with a Pasta cooking game, Demann with a Knock-knock game, and Luke with a Dinosaur heartbeat racer.

If time permitted, we would collectively work on the Multi-sensor game.

Henry: Fire and water, heartbeat

These were very fun to work with! Wiring and Arduino code were mostly straightforward. Testing was incredibly unique, I can't count the amount of times I filled up my water bottle or lit a flame. This mostly consisted of reading analog values, so what I did with these values was the real key...

Demann: Piezoelectric

My piezoelectric sensor was incredibly simple to use! It required very little wiring to my Arduino board. Its testing was straightforward as well. It required its threshold reading to be lower than normal so Arduino could get great readings. Its values were read through analog so making sure I had the current pins for both my LED and sensor was important and intuitive. 

Luke: Gesture, light

Gesture: I accidentally soldered the pin headers in the wrong direction into the gesture module, so the sensor was pointing downwards. After fixing this, my first issue arose when registering my gestures. After a bit, I was able to consistently register left, right, up, down, and wave. I could not get clockwise and counter-clockwise so I scrapped those two. 

Light: This was really straightforward. I used example code found on the Arduino website along with wiring also found online. 

Pasta Cooking Game: 

In the pasta cooking game, you are tasked with boiling pasta from the box. The game uses water, fire, and gesture sensors. First, you must dip the sensor in water and fill up the pot for boiling. This mechanic involves a fully functional in-game sink and faucet, connected to the sensor. Next, you need to set the stove burner aflame to boil. It is as if the gas isn't working properly and you need to give it a spark! Once the pot boils, the pasta can go in. This uses the gesture sensor to put the pasta above the water, and then in. After a while, perhaps after enjoying some other games, the pasta is fully cooked!

The wiring was very simple, just a lot of analog reading! Since the water sensor could sometimes be unpredicted, it was important to find a threshold that meant dipping in more made things go faster, dipping in less meant slower, and neither was ever too fast or too slow. For both fire and water, the main labor was mapping these sensor values accurately to implementation needs. I am thankful for the map() function in processing. The gesture was mostly all good, just a bit finicky and sometimes didn't work.

Knock-knock Game: 

In this knock-knock joke game, a user "knocks" on the sensor to tell a knock-knock joke. The purpose of this game is very intuitive. Its wiring was simple. I found all the information I needed on Arduino's website. 

At first, my Arduino would read a tap from the sensor and display the entire joke on its own which obviously wasn't my intention for this game. So I had to figure out a way to display each line one at a time without adding a delay or speeding through an entire joke. The serialEvent() function was a lifesaver. With this function, I could finally read each received "knock" from my sensor and increment the current line of my joke array! Though the sensor was still a little buggy, it was able to get the job done.

Bunny Game: 

I found that making a dinosaur sprite would be too difficult, so I changed the sprite to a bunny. I had trouble in bunching cacti together to increase the difficulty of the game. In addition, I had difficulty calculating hitboxes to determine when the bunny had come into contact with a cactus particularly if there were multiple cacti. I tried to organize everything as much as possible to keep up with the clutter. This game was fairly straightforward, but took a while to completely implement especially considering I began with essentially no experience in Processing.

Multi-Sensor Game: 

This game was significantly more difficult to implement than I originally thought it would be. My vision for the game changed considerably while working on it as well. My original idea which is explained in Stage 1, felt too bland, so to spice things up I took inspiration from a classic typing game I'd played as a kid. You had to type the words pasted on asteroids falling from above before they hit the ground. Using this, I decided upon the following idea: A randomized list of commands would fall from above. If you fulfilled all the commands, the chain of commands would disappear. If it hits the bottom of the display, you lose. You had to fulfill the commands from left to right. If you failed to fulfill one, it would blink red and the chain of commands would speed up. If you succeed in fulfilling it, the command turns green and stays green. My biggest issues arose in having specific parts of a chain of commands colored and the rest black. Unfortunately, we were never able to fully incorporate this game into the final arcade as we came across too many issues.

This was the biggest obstacle for us to face, and we knew it. It was one thing to make programs on our own, but having them work simultaneously took a lot of work! 

On top of that, everything needed to wire together correctly. Most of the issues during this step were about incorrect wiring, or one PIN having a minor issue. It was a lot having to rewire 4 sensors, a joystick, and a button every time we needed to work.  We got a lot of tips online about serial communication, like using the bufferUntil() function so the serial didn't overload with data. 

In addition, we had to come up with a repeatable system for sending multiple sensor values. Thus, we implemented a sendValues(int[] values) command which loops through the values array and serial printed each, with commas between. These values were then split in processing into an array, and read. Of course, this took many iterations to figure out, and there were a couple of major obstacles along the way. (See final report).