My group project helped me to understand that people needed to understand your project just by looking at it. The key to a successful product is the ability for your audience to understand it immediately. Take for example the water bottle, the structure of it instantly tells the audience it is meant to hold some sort of liquid. It’s sole opening at the top limits the imagination of the audience to what it can do. The group project was different because it was something in the future, but this time we were building something that could be used. For our research, we looked at how earthquakes worked. Earthquakes vary on a scale, which determines the damage an earthquake can inflict. Some buildings are more resistant to the damage from an earthquake so we built all these interactions into our product. Depending on how quickly the user shook our city, that would determine the rate at which the towers fell. The towers would also always fall in order because the towers at the end are just more resistant than the towers prior.
We knew our name had to be not only catchy but also understandable. Therefore, our title “Shake to Quake” were all keywords to signify what our project was. We also added the city layouts on top of the box and included instructions on the front of the box. We really tried our best to avoid a norman door situation. Our materials were pretty limited so the only differentiating part of our project was our sensor. At first, we were thinking of using a gravity sensor, which would detect the movement relative to the gravitational pull. Looking back, the code for the gravity sensor would have not only been harder, but the way it would detect the earthquake would be worse too. Gravity Sensors detect vertical movement better when in reality, an earthquake has horizontal movement. Thankfully, the back did not have gravity sensors, so we went with a much better choice: an accelerometer. We then used the data from the accelerometer and put that into a formula which then gave the vector as the output. The vector was then used as the threshold to determine whether a tower fell or not.
One of our biggest struggles was the 3D printing because when we tried to print out our city, the printer broke. Therefore, we only had time to use one city for the user testing day, but that did not really affect our feedback. We got tons of great feedback during the testing, most of which we acted upon. One of the IMA fellows gave us this great idea to have the lights on before the game started to signify electricity, and as the earthquake took place the lights would slowly turn off to signify the loss of power. This also aided in our second problem where we lacked a countdown for the game to start. Originally, the goal was to light up the 5 lights, but changing it to turning off the 5 lights made it clearer. We also added a quick fade to each light when the reset/start button was pressed to further emphasize the game restarting and ready for use again. All this feedback definitely helped us to successfully demo our project during class because now everyone knew they had to Shake to Quake!
Our idea was an Earthquake simulator, and I believe that we successfully created just that. Not only was our project meant to be a fun multiplayer game, but also to show a side of realism. Earthquakes are frequent and they do not need to be that powerful to cause major damage. Take for example our game, some people would shake quite slowly, but even that would be enough to topple the great towers in our city. Our goal was always a fun game, but spreading awareness was also a side thought. I believe that is just natural if you make a disaster simulator people will learn how it works and the damage it can cause. Our project was definitely interactive to because not only were you able to compete against someone else, but your actions determined the rate at which the towers fell. I believed it would have been cool if we added a timer to our project because then we could have seen all the varying times it took for different people to decimate the city. Having people lose and wanting to rematch was always a fun sight to see because it showed us that people were having fun. If we had more time, data screens would have definitely been added. We could have hooked up screens and displayed all sorts of data like how quickly you were able to shake the city, how fast your shaking would translate on the Richter scale, and also maybe some high scores to entice people to play again. We learned preparation is key because sometimes printers fail, and you need to find another way. I have definitely learned that saying all your ideas is important because I thought it was silly when my last idea was an Earthquake simulator. Looking at the finished product though, it is a really awesome idea and I am happy and proud of the work my group put into it.
