Results and Conclusions


Results

Overall, our game runs very smoothly. We tried to optimize our code to ensure that there would not be too much flickering that would affect our project. Unfortunately there is only a lot of flickering when the users are spamming the left and right buttons too much and the characters are on top of each other. Other than that, the game hardly ever flickers and the animation of the characters is very smooth. For the main menus and ending screens we have a timer and a button that determines when the next screen or game state will occur. With each frame a part of the screen is erased whenever the player moves but things that stay stationary like the ground for our game is almost never erased. There was no significant delay to the user pressing buttons or moving their sword with the output on the screen.

The accuracy of our game is very variable depending on the user. Since the characters on the screen move according to the IMU data, this means that even if the user’s movements might have signified a block or a stab, the character on the screen might not change states unless they properly angle their IMU remote. This means that sometimes the movements of the player might not smoothly show up on the screen because the IMU data does not match with the conditions needed to block or stab.

We enforced safety in our design by properly soldering everything together on protoboards. This was done to ensure that rough play would not disconnect the wires of the remote which could affect the gameplay significantly. We also split the buttons used to control the player and the remotes so that the user would have ample space to play. We also used very long wires to connect the wires and the microcontroller board. We attached all the non movable parts of our hardware like the microcontroller board and the button boards onto a foam slab to ensure that even with rough play the interface would still be very stable.

The interface of our game made our project very usable and intuitive for others. In addition to a normal title screen introducing the game to new players, we also have an instructions screen that teaches the users how to play our game. Our hardware interface is also very intuitive since there is a clear delineation between the buttons the players are supposed to press and the moveable remote that acts as the sword for the player. Our game is very user friendly in that it allows for two players to duel against each other and their movements would be replicated on the screen. However the game requires that the user angle their remote at very specific ranges of angles, which could make the controls of the character a little finicky since sometimes whenever a user would stab, sometimes the characters would not stab because the IMU values are not within their specific ranges. We think we could have picked bigger buttons for users to play with since the buttons were a bit small that it would be difficult to spam these buttons. Additionally our game is very aerobic in that it requires the user to exert a lot of physical effort to move the remotes. This means this game is not for the faint of heart and requires our players to be physically able. Thus users playing this game might experience fatigue otherwise. However we feel that this physical activity of the game is what makes our game very fun to play.


Conclusion

In conclusion our game design turned out like we envisioned and was very fun to play. The stick figures that we designed turned out well animated. Originally we had planned to have the stick figures have jumping functionality and have various background noises and sound effects following a character action. We had also first planned this to be a one player game where the user would play against an AI however we felt that a two player game would be more fun and easier to implement. However we decided to add more interesting game functionality rather than spending time on music to make the game more fun to play.

If we had more time, we would have definitely added some background music and sound effects to our game. We also might have added jumping functionality like we mentioned earlier as well as made the game more like 3 foot ninja. Some more improvements we might have made was to add more locations that the characters could interact with to make gameplay more interesting. We also might have added different weapons the characters could choose to allow the user to customize their character.

While our initial game design was based off of 3 foot ninja, we ultimately customized and created our own version of the game. For example in the original game, the player maneuvers their character around using keyboard presses, however in our game, we decided to have a remote where the user could physically move their sword to simulate a stabbing motion. We also drew and designed our own stick figure characters rather than taking them off the web. We did not use any outside code or designs, nor did we reverse engineer any designs. We also did not have to sign any nondisclosures. Additionally since this is a game, we do not think there are any patent opportunities for our project.