*We are actually a team of 6, but please treat us as a team of 4 as we would like to be considered for prizes. We will decide how to split up any prizes, if we do win anything. Thank you! The other's are Natasha Wall and Amelia King.
Originally our team consisted of 5 members, with no clear hack idea or direction. Our biggest dilemma was that the team was split between a hardware and a software hack. Through the power of slack, we gained another member, one with much more hardware experience. Together we scoured through the Arduino kit, and found an MPU-6050 and a pulse monitor. We thought, why don't we try and make a game, but aim it around the player's physical state, such as their heart rate? Heart rate is a great indicator of feelings and behaviour, and will spike at things such as frustration. Video games are known as a source of frustration, so why not use this frustration to fuel the game's difficulty, and give the player initiative to stay calm, and not let the game get the better of them. Instead relax, and take, "a walk in the woods". Inspired by Trent's beautiful scenery and dedication to keeping it green, we decided to have our game team reflect the calming environment this school provides.
The game has 2 main parts; the initiation, or mapping, and the game-play phase. In the initiation phase, the data from the gyroscope is combined with the data from the pulse monitor. The gyroscope data is collected with a MPU-6050 sensor around the MPU's x-axis. This data is recorded as negative or positive angles, in degrees. In order to connect the tilt angle to the change in height of the character, angle ranges are made to correspond with certain integers, ranging from -8 to +8 (e.g. angles 10 to 20 degrees correspond to integer 1). These integers then correspond to a pixel change in the height of the character within the game. In the mapping stage the pulse rate data is multiplied by the gyroscope data (a value between -8 and +8), which gives a height coordinate. This coordinate represents the height of the "obstacle" at that point in the terrain. For "A Walk in the Woods", we chose the ECHacks' tree logo as the obstacle, and the top of the screen as the bounds of the game (e.g. touch the top of the screen or a tree with the character and you loose). In game play, the gyroscope data from the MPU-6050 represents the up and down movement of the character, while the player's pulse rate (heart rate) represents the speed of the character. Like most obstacle games, the objective is to avoid the terrain obstacles for as long as possible.
Challenges were faced with extracting usable data from the MPU-6050 and formatting it in order to be usable further along in the project. Originally, we wanted to change the height of the character by moving the MPU up and down along the z-axis. This proved very difficult as associating accelerations to possible position changes was very difficult, and the data was largely affected by things such as gravity. It made it very hard to see relevant changes and to correspond them to integers in order to represent a change in height (in pixels) of the character.
Plotting the data in order to create the tree terrain for the game proved very difficult. The data was difficult to translate into coordinates that could be used to modify the tree photo heights. At some point, we had 3 group members attempting to work through the code in order to find any issues. Lastly, the hardest component was plotting the game-play data dynamically, so that the position of the character could be seen continuously changing as the gyroscope was moved. Dynamically updating forms in Visual Studio was our first issue, as our first approach did not dynamically "plot" the character, but rather only plotted the final position. After changing our approach we were able to read the game-play data more efficiently, and were able to continuously plot the data so that the character's motion could be tracked.
We are very proud of ourselves, as a majority of our team are first time hackers. Our largest accomplishment is properly defining the scope of the project, as it allowed us to properly divide and conquer the work. We were all able to work on an area that we enjoyed, and it allowed us to solve our original hardware vs software dilemma, as the project incorporated both. Our largest Arduino accomplishment is realizing that we could use the pitch change as a way to control our character's height, while our biggest Visual Studio accomplishment is using polling to get data from the sensor to the form (display).
All of us were able to learn something, whether that be new skills or improving old ones. Our members were able to improve their Arduino, Visual Studio, C#, and app development skills. Some members worked on programs that they had never used before (like Visual Studio) and had a chance to learn skills that are very applicable in the real world.
We believe that the idea of incorporating this hardware setup with other games is very feasible. This set up allows players to really understand how they are connected to the game, and the effects they have. Future games can be educational (for children and students) or just for entertainment.