High-level Design

Rationale

Our project is motivated by our group’s interest in motion detection. We wanted to develop an interactive game in which the user will have an immersive experience. Since computer games are limited by keyboard and mouse inputs, we felt that adding motion detection to a nostalgic childhood video game would be the perfect extension. So, we settled on a sword fighting game inspired by 3 Foot Ninja, in which the sword is operated via motion detection. For this reason, our project draws inspiration from calculating IMU angles in Lab 3: PID control of a 1D helicopter.

Logical Structure

The logical structure behind our project is that we have two IMU sensors that each represent a sword for a player that provides us the position and speed of the player's movements. This data is used to determine what type of movement the player is making from either resting, blocking, or stabbing. The game has different states as well from the start screen, instruction screen, to gameplay, and finally win screen and restart. To move the player across the screens there is a left and right button for each player to maneuver their characters. The players essentially fight each other until a player’s health’s bar reaches zero.

Hardware/Software Tradeoffs

The hardware tradeoffs that we decided on were between trying to put all the user interface buttons on a single board with the microcontroller or separating them for ease of use when playing. Ultimately we decided to have more breadboards for the different aspects of our game as it would make playing much more intuitive to the user. We also decided to solder all our parts to ensure that our game was robust and sturdy enough with continued playing. For the software tradeoffs we had decided between animating on both cores or a single core. Since our calculations did not require much of the CPU we decided to just animate on a single core for ease of logic.

Relevant Work

Since our project is a fully self-constructed game, there are no patents, copyrights, or trademarks to worry about.

Instructions

Movement Buttons

Every player has two buttons to control the leg movement of their character. The left button moves the character to the left, and the right button moves the character to the right.

IMU

Every player has an IMU/breadboard unit to control the movement of the player's sword. A vertical IMU indicates the block position, while a constantly "stabbing" horizontal IMU indicates the stab position.

Gameplay Button

The game has one gameplay button, which is used to control gameplay. It allows the players to continue from the Intro screen to the Instructions screen to the game screen, and also restart player the game.

Display

The animations for our game happen on the VGA display. These animations constantly change based on each player's inputs from the buttons and the IMU.

Dive into Details!

Hardware Design

Learn about our thought process behind the hardware and how the hardware is set up.

Program Design

Understand how we navigated programming the game and how the code actually works.

Visual Design

Explore the visual design choices that were made for this game.

Results and Conclusions

Learn about what the final product looks like, the results of our design, and our experiences working on this project.

Appendices

Appendix A: Permissions

The group approves this report for inclusion on the course website. The group approves the video for inclusion on the course youtube channel.

Appendix B: Code

Our code is available on Github!

Appendix C: Schematics

Refer to the Hardware Design section for schematics.

Appendix D: Work Distribution

All of us were involved in creating this project. We worked together in assembling the hardware and creating the software. In terms of work we did separately, Dan worked on soldering the components onto solder boards, Grace was responsible for determining locations for players on the VGA, and Akshati worked on the hardware schematic and determining the collision logic. Other than that, all parts of the project were done together by all team members.

Appendix E: References

Course Resources

Datasheets