Team HackerGEEN 1400

Professor Siek

Final ReportProblem:

When given the design project, our professor had a clear problem that the entire class had to address in their project. This was creating a game that advocated health, or a game that a person could play that would allow them to be physically (and mentally) active, while doing something that they enjoyed. Based on one study, students who were active, healthier and lived a more physically fit lifestyle were overall more successful in school (Thai, Lowenstein, Ching, and Rejeski, 2009). Creating a game for these students that not only was fun, but also incorporated physical activity would help them in and outside of the classroom. Also, from a study done by Carmen Russoniello, it has been proven that playing certain video games can help relieve stress and depression (Russoniello, 2009). Given that relieving stress is in the top 25 perks of physical activity, a game that was also physically challenging would reduce the amount of stress of the player even more so (Kravitz, 2007). This made presenting a solution to this problem even more important, as a well-created game for health would help the player in many ways while they were still having a good time.

Addressing the Problem:For the design project, we were set on creating a game that had all aspects of health, including physical and mental, and that was entertaining yet not too complicated. Our team picked the idea of a game that was greatly related to dodge ball. In our game, the user had to touch a certain sensor pad (either one to the left and right or one to the front and back) to move a sprite on some sort of screen. This sprite avoided some sort of ball that moved around the screen, and the goal was to not allow the ball to touch the sprite (which resulted in ending the game). If the user could “survive” the bouncing ball for a certain amount of time, another ball would enter the playing field and the user would have to continue to dodge both balls. The game was over when the sprite made contact with a ball, and the amount of time that the user played without getting hit was their score. The sensor pads were plastic structures that the user stood on, and they covered all four of the sensors. All of the electronic components were stored underneath the structure, and the structure was connected to the screen, which displayed the sprite’s movements as well as the ball movements. The programming tool that we used to make our game of health was Scratch.

In this game, we addressed multiple elements of health, including an agility aspect, a coordination aspect, and psychological aspect. Agility is a key part of a person’s health, and was very important in our game as the more agile the user can be, the faster and longer he will be able to avoid the obstacles. Also, coordination was very essential for this game since if the wrong square sensor was pressed, there

1

was a good chance the game ended. Finally, there was the mental aspect of the game, which is very important for health, as a user with strong mental ability was able to plan where they moved the sprite, allowing them to last longer in the game.

Prior to our attempt to address the problem of a game for health, there had been many other games that had allowed users to be physically active while playing some sort of game. One great example is the Wii, which make the user move to play certain elements of the game. Another example is the Xbox Kinect, which like the Wii is played using bodily motions, ranging from very strenuous to not so strenuous. When we were creating our game, we most definitely kept these previously created games in mind. When we created our game, we were greatly influenced by a game called Dance Dance Revolution, which is played using a gamepad that the user stands on (very similar to our design). Using some of the ideas from Dance Dance Revolution, we were able to create a game that physically involved the player to a significant extent.

Progression:As soon as we were assigned the project, our team looked into getting all the

necessary materials that were needed. We new that we wanted to make some sort of rigid structure for the board, but were not quite sure whether this meant using wood, metal, or another material. We immediately decided that we had to split the work up into multiple parts; one involving the code aspect, one involving the mechanics aspect (the board), and the final involving the electronics aspect (sensors and Pico board). The processes for the three sections are described in detail below. After the game was fully functional, we performed the User Studies with nine different undergraduate students, which is also detailed later in the report.

Mechanics (Board):The board part of the project was probably the piece that took up the most of

our time, as it was over engineered to be able to withstand the Design Expo (which excitingly it did). We began the process of creating the board with our first prototype, which consisted of an outline of tape on the ground. This allowed us to identify the optimal dimensions of the board, as to increase maximum physical activity while still keeping the size within reason. This was paired with some sketches of the size of the sensor pads, whose size we wanted to be relatively large to increase the area that the player could hit to trigger the sensor.

2

After this prototype had been tested and proven to work well, we created our second prototype, which consisted of the same size floor design as the tape, but sketched on a piece of cardboard, so we could move the prototype of the board. The sensor size that was determined optimal in the first prototype was used in the second prototype, and was directly sketched on the piece of cardboard.

After the second prototype was tested and proven efficient, we began looking for a piece of wood to create our third and final prototype with. We were fortunate enough to stumble upon a scrap piece of particleboard by a dumpster outside the ITLL that was in usable condition, so we jumped on the opportunity for free materials. We then set our second prototype on the piece of wood, and seeing that the piece was more than big enough, began marking it to cut. After being fully marked, with sketched squares for the sensors, we took the piece down to the machine shop to cut. Using a shop tools such as a jigsaw, chop saw, table saw, and pad sander (to smooth edges), we had our top board finished.

3

With a now completed top piece of our soon-to-be gamepad, we advanced to the next step, which was putting wood underneath the board to lift it slightly off the ground. This involved a trip to Home Depot, where we picked up multiple 2x4’s for this next step. Once we had obtained the wood and some screws to secure it to the freshly cut particleboard, we headed back to the machine shop to cut new pieces to fit under the board. We cut four pieces for the sides, and two to run underneath the center of the board to add stability. After much drilling and cutting, we had a structure that could be stood on, with little to no shifting.

Now that our board was stable, we worked on putting additional pieces of wood underneath the holes where the sensors would soon be, as to provide a surface that the player could step on that would feel sturdy enough for them to apply some force to it. This was done by cutting small pieces of plywood (approximately 9” by 4”) to be adhered to the bottom of the top board. After much debate of what to use to attach the pieces, a brad nail gun was found under the workbench, and after putting close to 70 nails in the various pieces of wood, the platforms that the sensor pads would soon rest on felt very sturdy.

4

The final step in constructing the board was adding the carpeting the front and sides of the gamepad (the sensors and other materials related to them will be covered in the Electronics section). Fortunately, we were once again able to obtain free material through T&G flooring and Amerifloor, who gave us not only free carpet but also rubber for our sensor surfaces (also discussed later). Once the carpet was obtained, we cut pieces that completely covered the sides and top of the gamepad, and simply used glue to stick the two together. Once completely carpeted, the gamepad looked significantly more pleasing, and was ready to be judged at the Expo.

Code:The coding part of our project was mainly done by Ahmed Al Kiyumi and Bibi

Esmael. They started working on it the first week after we were assigned to work on our final project. The first thing that was created was an initial prototype that allowed us to get a feel for how our game was really going to work when it was in its

5

final stage. Our first prototype of the code was simply a piece of paper, with a character and ball taped to ruler ends (to simulate the player and ball that would eventually be on the screen).

After this prototype was tested, we were able to construct a very simple version of our current game that was basically a player that was controlled using (the computer moving keys): up, down, left and right arrows. The idea behind our game is to avoid getting touched by a ball that was coded to move around the screen. We coded our game so that whenever the ball touches the edges, it would bounce back. We tested different speeds for the ball and the player and we made sure that the ball was slow enough so that the player would get a chance to move around and dodge the ball. This is how we coded our first script (Figure1).

(Figure 1)

6

As it is shown above, using the arrows; the players’ x direction changes by positive 10 which allows the player to move right, the players x direction changes by negative 10 which allows the player to move left, the players y direction changes by positive 10 which allows the player to move up and the players y direction changes by negative 10 which allows the player to move down.

At the beginning we coded our first ball to follow the player at a speed of 8. In addition, we made our ball bounce back once it hits the edges of the screen, and we also coded the ball so that whenever it hits the player it bounces back with an angle of 180 degrees just to avoid the ball passing through the player. The x and y coordinates of the ball were set to 0 which made the ball start from the center. This is shown in the scripts below (Figure 2).

(Figure2)

The figure below shows what our first draft game looked like.

(Figure 3)

After discussing with our group members and after having them try our draft game, we started making improvements such as adding 2 more balls resulting in having a total of 3 balls. We thought that the idea of using 3 balls would be a great

7

idea as it would increase difficulty. We noticed that adding the balls made the users more into the game and weren’t easily bored and kept going on. The coding for the second and third ball is almost the same as the first ball but then we decided to add a change in direction of 90 degrees to make the balls collide instead of going through each other. We added a timer that starts counting time right after starting the game and stops when the player loses. This timer is also used for each ball, after the green flag is clicked the first ball would start moving after 1 second to give the user some time to move around, and the second ball would enter the stage after 15 seconds from the start of the game with a faster speed than the first ball and is coordinated to follow the player. Finally the third ball would enter after 25 seconds from the start of the game with an even faster speed than the second and first ball (this is shown below in figure 4). We thought we should be more creative about when the player loses, so we decided on having some sort of ‘game over’ appear. We started by adding a variable called gameover. This variable has been coded to broadcast “Game Over” when any of the balls touch the player, and that would make the whole game stop completely. The code then would show the time survived in seconds and the score (which is calculated by multiplying the time by 23) (Game Over code shown in figure 5).

From there we thought having a menu would be a good idea for the users to be able to start the game whenever they pleased to. In our menu, we made a start button, how to play button and a credits button. We changed our stage appearance and added another stage, one for the main menu and the other for the game mode. Each button is an individual sprite that is linked to either another sprite or a stage, so when the start button has been selected it would broadcast start game and open the second stage that we created for the user to play the game on. When the how to play button or credits button have been selected it would broadcast either the How to play sprite (which includes a brief explanation telling the user how to play the game) or it would broadcast the credits sprite (which is a list of the names of the team members). Below is a screen shot that shows how our main menu looks (Figure 6) and a screen shot of the coding used for the credits button (Figure 7). At first we coded each one of the keypad buttons so that they switch to a different costume when they are selected by the mouse pointer (We later on changed this and controlled it by using the left and right to move and the up arrow to select).

8

(Figure 4) (This is the coding for the second ball, which is very similar to the first and third ball, with variations in the x and y positions and the time when the ball

enters)

(Figure 5)

9

(Figure6)

(Figure 7)

We then thought it would be a good idea to change our avatar from a stick man to a ninja, and change the ball from a plant to red balls (shown in Figure 8).

(Figure 8)

10

After doing all the above we changed the control keys from if up, down, left or right arrows from being pressed to A, B, C or D sensors being connected (shown in figure 9). After that change the user was be able to control the game using the foot pads that have the sensor under them which are connected to the pico board. That is connected to the laptop that contains Scratch which includes all the coding explained above. Finally the game is all ready for the user to play.

(Figure 9)

Electronics:The third and final part of our game was the electronics aspect. Of the many

electronic parts of our project, none was more important than the PicoBoard. When we were planning our project, we were given many options as to what to use to interpret our code. Since we were already somewhat set on Scratch, and the PicoBoard is designed to integrate seamlessly with Scratch, we decided to go with the Pico as opposed to the Arduino. The Arduino had many more inputs, but since only four were needed for our game, and we didn’t want to have to deal with a program known as Arduino for Scratch, it did not make sense to use Arduino.

A PicoBoard is a product manufactured by Sparkfun, and is essentially a piece of hardware that allows for multiple inputs of many types. It has a slider bar that can be used to set certain levels of sensitivity, a button that can be used for instantaneous switching tasks, and multiple other useful things. The piece that we were concerned most with was the four inputs at the base of the board, which allow the user to attach a multitude of wires to different sources and receive inputs from those sources. Below is a picture of a PicoBoard, with a few labels noting the main inputs (note that the bottom ports are specified for resistors, which is exactly what we were hoping to use). Image curtsey of http://www.sciencebuddies.org/science-fair-projects/project_ideas/scratch-picoboard.shtml.

11

In our case, the sources were .5” pressure sensitive resistors (also processed by Sparkfun). When one of these sensors is connected to the PicoBoard, it acts somewhat as a button (see code section for more on how the sensor is integrated into the Scratch code). Since the sensor is triggered by pressure, whenever there is a strong enough pressure applied (in this case, strong enough is between 10 and 100 kg; if more than 100kg is applied, the sensor is fully open), there is a current that flows through the resistor. Since the users playing our game were almost always applying at least 10kg of force (after some fine-tuning of the sensor pads), the sensor almost always would generate a current.

Since we at first had no idea if these .5” resistors would work as we wanted them to, we only ordered one from Sparkfun, and then tested it with the PicoBoard. Seeing that the sensor worked seamlessly with the PicoBoard, and we needed exactly four inputs (which was exactly how many the board had), we decided to buy three more sensors. After ensuring that the new sensors also worked with the board, they were integrated directly into the gamepad. This was done by threading the sensor through a small hole on the plywood piece under the surface board (see mechanics for more on the various boards), and then simply taping them to the support beam piece of 2x4. The thin layer of tape holding down the sensor gave little interference to it, and was sturdy enough to keep the sensor in place.

12

After the sensors had become part of the board, we had to find the best way to channel the force of the players step onto the sensor. This process was very tedious, as we tried many options to get the sensors to be more responsive. The .5” sensors were very hard to trigger with just the rubber padding on top so we began to change its design. We started by putting a piece of rubber flooring (obtained from T&G Flooring) on top of the sensor to hopefully dial in the force applied. In addition there was another piece of rubber cut to the exact dimensions of the square holes in the top board. This gave the surface of the gamepad a great aesthetic feel, and made the sensing areas fit in very nicely with the carpeted area. This method worked somewhat, but the player still had to step on the very center of the square to get a reading from the sensor. We then came up with a different approach, which consisted of a piece of acrylic on top of that smaller rubber piece beneath the cover, still with the piece of rubber on top of the newly place acrylic. This had a clear improvement, as there was much less force needed to get the sensor to respond. Given that this worked significantly better then before (and with a little help from Mr. Jeff Pitts), we came up with our final design. This design involved a large piece of acrylic underneath the top rubber pad piece with a small rubber dot under the acrylic that sat right on top of the sensor. This added a funneling effect that allowed for the user to step virtually anywhere on the sensor pad and still register pressure on the sensor, which triggered the character in the game. Since the pads were extremely responsive, the game was much easier to play, and much more user friendly. Once we finalized this as our final design for the sensing pads, they were integrated into the board.

User Studies:When it came time to do the user studies, Team Hacker was very prepared.

We were one of the first teams to have our protocol ready, and confirmed it with Professor Siek very early as well. We decided to complete our studies in the room outside of our classroom, which was very easy to use with our game (the television that was in the room connected with our computer very well). Once the user studies commenced we found out a couple things very quickly. One of these things was that having the users play the computer version of the game was not very efficient, as it simply bored them. Our results from this part of the studies were somewhat useless,

13

as most of the people who tried the game on the computer simply breezed through the survey so they could play the actual game sooner.

The game pad, however, was a completely different story. All of the users played the game at least three times, with some of them playing as many as 12 or 13 times. They all seemed very satisfied with how the game worked, and how the character on the screen was directly correlated to the directional controls on the gamepad. Also, the users thought the simplicity of the game was actually a good thing; they didn’t want to have to think about what they were doing with their feet since they were focused on the screen, and this was very easy to do in our game. Additionally, 88% of the players said they would either probably or definitely play the game again on their own time, with only one of the nine users saying they might. Also, when asked how physically challenging the game was, the results were pretty evenly distributed, with 33% saying it was very hard, 22% for fairly hard, 33% feeling average, and the remaining 11% saying that it was only slightly challenging. We viewed this as a good thing, as we wanted our game to be not too challenging, but at the same time challenging enough to where the player would play it again. Below is the graphical data to support these results.

During the user studies, we also asked the participants whether or not they would consider buying the game if, for example, it were to be offered as some sort of game that could be played in a similar manner to Dance Dance Revolution. To this the majority of the users responded with maybe, with %56 saying that they would consider paying money, while 33% said that they would definitely pay for it, and 11% saying that they would not. Again, our team thought this was great, as having more than half the users saying they would even consider buying our game was very reassuring. Finally, we asked the users how many times overall they played the game, which again provided some surprising results. Like stated before, all of the users played the game at least three times, with 67% playing 3-5 times, 11% playing 6-9 times, and 22% playing ten or more times. This was the most encouraging thing for us, as it showed us that the users were actually enjoying themselves, as they continually went back to the menu to try it just one more time. The next page has the graphs that support this data.

14

During the user studies, we did receive some quality feedback that we later integrated into our designs. Many of the users said that the sensors were not quite sensitive enough, which we fixed a few days before the Expo (see above in Electronics). Also, there was a slight rock to the board, which was easily fixed by placing a rubber piece under each corner to level out the gamepad.

Recommendations:After we gave our demo for class, we received constructive feedback and recommendations from various different people such as fellow colleagues and instructors. Some of them are listed below:

Increase the sensitivity of sensors of the gamepad. Improve the accessibility of playing the game especially for non-gamers. Adjust and tweak the game to gain a more balanced gameplay. Improve the stability of the gamepad to prevent it from slipping.

We prioritized the recommendations based on the feedback of which are mentioned frequently (by class demo and user studies), our instructors and what we thought must be done first to get our project to function at the optimal level. The rest are secondary and thought to be minor improvements that can be added if we had enough time to do so. In the end, we improved the responsiveness and the sensitivity of sensors by having many different iterations of the flooring between the sensor and the player’s feet, by knowing the trick was to funnel the pressure to the sensor, we added acrylic under the rubber flooring. We tweaked our game by finding the right values of each ball’s speed and the time of when of each ball appears as well as changed the avatar from a stickman figure to a ninja. This was based off of our user studies as well, as the users said the stickman was relatively bland and unexciting, and they were somewhat unsure when the ball had touched the player. Also, we added to the balls a sense of physics, so that if one of the balls came into contact with another, it would reverse its direction. To improve the accessibility of the game, a head start of one second was added for the player to move before the ball moves. This helped new players get a grasp of how the game

15

was played, in addition to a ‘how to play’ section which was added to the menu with highlighted texts to indicate what section of the menu the player is selecting. Stability of the gamepad was improved by adding rubber under the corners of the gamepad to increase the friction between the floor and the gamepad; also, the gamepad was reinforced with wood underneath to flatten out the board when standing on the gamepad.

Future Implications:If we had a chance to improve our project, we would most likely start with

rounding the container edges. This will not only make the game safer for the player, but also more aesthetically pleasing. Another thing that we would keep in mind is to use a different, more specific glue for our carpet; the glue that we used for our project was wood glue, which did not keep the carpet attached to the board like we would have liked it to.

In addition, we could add some interesting features to our game mode to make the game more challenging and entertaining. For instance, we would change our game from a one-player version to a multiplayer version. During the Expo, we had multiple people approach us saying that the game was great, but would be even better if more people could play it at once. To do this, we would most likely have multiple boards, and they could control a variety of things. One option would be to have one game pad control the character on the screen, while the other game pad controlled the ball. Another option could involve a simple competition, where both the characters were on the same screen, and the one to survive the longest would be the winner. Adding this second controller would, however, make the coding part of the game much more complicated, and we would most likely have to use an Arduino board in addition to the Scratch components.

16

Works Cited

Kravitz, Len. "The 25 Most Significant Health Benefits of Physical Activity & Exercise." Www.ideafit.com. IDEA Health & Fitness Inc, Oct. 2007. Web. 02 May 2013.

My Thai, Ann, David Lowenstein, Dixie Ching, and David Rejeski. "Game Changer: Investing in Digital Play to Advance Children's Learning and Health (Executive Summary)." Health Games Research. N.p., n.d. Web. 26 Feb. 2013.

Russoniello, Carmen V. "The Effectiveness of Casual Video Games In Improving Mood and Decreasing Stress." Journal of the CyberTherapy and Rehabilitation 2.1 (2009): 53-57. Web. 27 Feb. 2013.

17