My project will be to create something like the ‘Wah Wah Glove’ in the brainstorming post.
My project will incorporate several sensors to try and determine the orientation of the glove and whether the hand is open or closed.
It will then use that input to generate a sound.
I have also programmed it so that it will play sound effects when the button is pressed.
For pictures see: http://www.joshuarosenstock.com/teaching/IMGD3x00_B12/2012/12/05/final-project-concept-2/
Our idea has evolved from where we initially started, but our final project is now complete! As you can see from our previous blog posts, we’ve been working on the hardware and software, and with some final additions and polish our Safe Cracker game is complete!
Our final hardware consists of the Arduino uno board, a tilt sensor and a buzzer mounted inside the plastic case, and three buttons, a red LED, and a green LED mounted on the outside. Our homemade “safe cracking” controller hooks into a computer to play the game.
On the software side, we are using Processing to control the mechanics of the game, including the input from our hardware, and the visuals of the game that appear on-screen. We are using Pure Data to control the sounds of the game, based on the hardware input and on information passed from Processing to Pure Data. Finally, for software, there is the Arduino firmware itself that interfaces with the hardware we’ve assembled.
We really wanted to add sound to our project as another dimension of interactivity, another sense to add to the mix. Now that it has been implemented, we definitely think that it improves the game and makes it more fun to play! When the game starts, the initial background music is the smooth jazz of the “Pink Panther” which is reminiscent of mystery and spy movies, which goes well with our “safe cracking” game. However, as the timer counts down for how much time the player has left to crack the safe, the music fades from the “Pink Panther” to a more tense and fast-paced soundtrack to reflect that there isn’t much time left! Having these background sounds adds to the overall game experience. Additionally, we have a few triggered sounds over the course of the gameplay. When the player presses one of the physical hardware buttons, not only does the image change on-screen to reflect which button has been pressed, but a button “click” sound now plays as well. Also, when a player successfully completes a level, a sound effect plays to indicate that they’ve completed the puzzle correctly. Last but not least, applause plays when the player has completed the final puzzle, indicating that they have won the game!
As another part of the polish, we switched out the placeholder art for art that we have made. The screen shows a safe, with “safe cracking” equipment and the paper “cheat sheet” that directs the player on how to solve the puzzle and crack the safe. The hand icon moves depending on which button the player has pressed, as well as the wrench moving if the player tilts the controller one way or the other. The black buttons also light up red if the player does something incorrectly, and there is now an official win screen as well to go along with the applause sound effect.
The video below shows the final implementation of the Safe Cracking game that we’ve created, with the multi-sensory experience, hardware controller, and a pretty good demonstration of playing the game!
To see more of our process, see some of our previous blog posts:
http://www.joshuarosenstock.com/teaching/IMGD3x00_B12/2012/12/02/final-project-concepts-ideas/
The monster is fully made. I do not yet limit the amount of total limbs you can choose so you can add up to 5 more of each part onto the base monster. This is a picture of him with all parts filled in:
I do not have any game components in but the art aspects are basically done. I think I will add background music and maybe sound effects though. I may add a few other things if there is time but for now I will likely move to the game components. My script is below feel free to add parts to the monster. Tap 1 through 6 to add parts. 1 = arms 2=legs 3 = tails 4 = heads 5 = eyes 6 = wings. The keys used will change when the makey makey is added in. Also I thought it looked cool to alternate coloring for the legs and wings. I tried this effect in a few other places and it looked too busy. I like how it came out with the coloring differences just on those two.
On a random note my program is exactly 777 lines long at this point. Just thought that was funny.
After the code was mostly complete, and the images were filled with temporary place holder art, it was finally time to get the hardware into a permanent state. I found that the box that the Arduino and components came in had a very sturdy base and could be adapted to sufficiently hold the hardware. In order to mount all of the buttons, the tilt sensor, the buzzer and the LED’s, a few hours of ingenuity and effort were required. To mount the button, I borrowed a perforated board from my roommate, and stuck the push buttons onto the board. Using a dremmel, I cut out three square holes on the top of the box and hot glued the perfboard to the underside of the box lid. For the LED’s that indicate whether an action is correct or incorrect, I made 2 small dremmel holes so that the leads of the LED’s went inside of the box and the LED heads stuck on top of the lid. A large hole was then cut out of the side of the box in order to allow the USB cable to connect into the Arduino. Finally, I used the breadboard’s built in adhesive to stick it permanently to the bottom of the box while carefully rewiring and positioning the Arduino inside of the box to limit movement. A picture of the final hardware design can be found below.
After all of the electronics and hardware were essentially complete, it was finally time to start on the logic of the safe cracking through C code in processing. In general, the simulation plays as follows: Players are in a warehouse and arrive at a safe they need to crack. Luckily for them, they brought specific step by step directions to follow on a scrap piece of paper. The player must execute each move correctly in a row in order to move onto the next part of the safe. In the three given “levels” of cracking the safe, the players will interface with various buttons, all while rotating their device to the correct orientation. If a player gets a sequence wrong, they will lose all progress on that level and must restart form the beginning. The main problem with failure on the levels is that there is a global timer that ticks down quite quickly. Since you are robbing the facility at night, it is important that you make your escape before daylight. If the player cannot traverse the directions on all three levels within the time limit, they will be “caught” and have to start the game all over again. The code to implement all of this functionality was actually complicated and verbose. I ended up having to store all of the correct moves within special arrays, track the users current moves in lists, all well polling the hardware to see its’ current pin orientation. Complications arose when users rotated the device; the tilt sensor would receive many values very quickly, which would confuse the game logic into thinking that a player acted incorrectly when in reality they performed the correct maneuvers. Many added delays, timers and Boolean variables had to be implemented so that the hardware worked as smoothly as the software. Below is a placeholder screenshot of in-game footage that describes the above.
Once my sketch was compiled, and I could get the blinking built in LED on my Arduino board to interface with my processing sketch, it was then time to build actual circuits. The kit I received came with multiple sensors, most notably, a tilt sensor, 5 push buttons and a piezo buzzer. In order to hook up all of the circuits, I found all of the schematics online, which thankfully came with somewhat documented Arduino tutorials to show how to connect each of the devices. The first step I learned how to accomplish was to set up power for the entire board. I ran a red wire form the 5v power supply on the Arduino board to my breadboard, and followed that up with connecting another red wire from GND on the Arduino to GND on the breadboard. Once that was setup, it was finally time to hook up the first push button. Following given tutorials on the Arduino website, I found an example sketch in the processing library that checks the input of all the pins on the Arduino and was able to register a button press on the Arduino from processing! Once the first button was created, the next two followed suit and finally I had all three buttons on my breadboard fully implemented. The next two components, the tilt sensor, and the buzzer were relatively the same circuit setup. The only difference between the implementing the buttons and the tilt sensor/buzzer is simply the code needed to activate and deactivate the triggers. The tilt sensor works by moving a ball inside of a black box, where once the ball makes a connection with the side of the box, it completes the circuit making the pin go high. For the buzzer to be active for a set period off time, the implementing code must have a manual digital write to the accompanying pin to cut the connection and stop the buzzer. A completed circuit with all of the sensors and buttons added can be seen below!
Last Friday, I had received all of the Arduino components in the mail, that is both the Arduino Uno board and the given components had finally shipped after a few weeks in transit. After opening the package, I found the first step to start the new project would defiantly require assembly. I found out rather quickly that I had no explicit knowledge in creating circuits, so in order to hook up many of the buttons and sensors that came with the kit, it was necessary for me to start some technical research. Below is a general idea of what parts came with the Arduino kit:
After some more technical research I came to the conclusion that in order to control my Arduino board from processing, it was necessary to download a specific library and install it into the correct folder. I then found out that the actual Arduino IDE which is used to interface with the Arduino board alone has an example sketch that can be used right out of the box to serially connect with other devices so that no code has to be running on the Arduino side while the processing sketch is being executed. After setting up the correct libraries, I attempted to compile the given code but was faced with some errors. The first error I received was the fact that serial connections could not be made in the 64 bit version of processing. After some simple google searching, I found the easiest solution was to merely download the 32 version of processing. After completion of the above steps, I tried to compile the processing code, however I was met with another error that prevented me from interfacing with my Arduino board. The error was very obscure and after some more extended google searching, I found a bizarre hotfix on github that seemed to fix the bug. Finally, after completing all the installation steps, the sketch finally compiled and I could use a simple script in processing to blink the built in LED on pin 13.
I finished actually making one of the enimies in processing. I took a screenshot of it in a sample color scheme. I will post screen shots of each of the enemy types to this page as I finish them. When all 4 are done I will post the script so you can see all color variations.
Speed-demon: 
Warrior: 
Defender: 
Wizard: 
Here is the current script, press space bar to cycle through enemies!
I’ve been told I’ll need to make my creatures more artistic. This may be tricky but I’m going to try. I don’t know how good this will look in final implementation but here are some designs I came up with.
These are the enemy shapes based on their high level stat. The fill and stroke will still be based on secondary stats:
This is the monster if all parts were added. Note that the monster before anything is added will have a body, 1 head, 1 arm, 2 legs (legs just get longer), 1 tail, 1 eye, and 1 wing (note this will be the right wing at the top, so there will be a long line sticking out of the monsters head at the beginning. I know it’s silly but it was the best way to make things fit for all combinations. The monster as a whole is silly so it’s not too out of place):
I had the enemies randomly being created using the simple shapes. ALl of their stats are determined but not directly shown to the player. I have them printing to the console though and they seem to be generating correctly. The fill, stroke, and naming will not change so I might as well post this to give an idea. Press space to generate a new enemy:
I went ahead and actually created the layout that will be displayed. I made some slight changes from my paper version. The dice roll display has been moved to the right portion of the area next to the stat section. It will always display the last roll you made and will say “please roll” when it is time for you to roll. This currently doesn’t do anything but I wanted to share my progress and show the current design. Unlike the paper one this allows you to see my color scheme. I thought the different shades of brown and tan would be representative of roleplay and adventure possibly because it makes me think of old maps and scrolls. I could be wrong but that was the color scheme I found fitting. I also colored the stat labels with the respective colors I’m using to represent them. If the monster has that stat than that will be the same color used to represent their primary stat. That could also be useful in helping the player remember the color correspondence when looking at the enemy. All of the numbers currently displayed are variables and could easily be changed to whatever is needed. On an unrelated note, I now have my makey makey!
Here is the layout made in processing: