Embedded Systems B.Tech/B.E Intermediate

Stickman Ninja game

[Fall 2023] Stickman Ninja is inspired by Akshati’s favorite childhood video game3 Foot Ninja. In our version of the game, we have two stickmen players dueling to the death. The players move by left and right buttons, and for an immersive sword fighting experience, the swords are controlled by IMU’s to detect movement. The Raspberry Pi Pico is used as the core processing unit to take in input and create the VGA display of the gameplay. Our group chose this project as a fun way to explore motion

  • Suitable forB.Tech/B.E Embedded Systems students
  • Build time4-6 weeks
  • LevelIntermediate
  • Available atAjvika Labs, Kakinada

About this project

Stickman Ninja
ECE4760 Final Project
Stickman Ninja
Akshati Vaishnav, Grace Lo, Daniela Tran
Stickman Ninja is inspired by Akshati’s favorite childhood video game
3 Foot Ninja
. In our version of the game, we have two stickmen players dueling to the death. The players move by left and right buttons, and for an immersive sword fighting experience, the swords are controlled by IMU’s to detect movement. The Raspberry Pi Pico is used as the core processing unit to take in input and create the VGA display of the gameplay. Our group chose this project as a fun way to explore motion detection games, since they are not readily available on PC’s. Furthermore, who doesn’t like dueling it out with a friend?
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.
More
Program Design
Understand how we navigated programming the game and how the code actually works.
More
Visual Design
Explore the visual design choices that were made for this game.
More
Results and Conclusions
Learn about what the final product looks like, the results of our design, and our experiences working on this project.
More
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
ECE 4760 Course Website
Datasheets
RP2040 Datasheet
MPU6050 Datasheet

Technologies used

RP2040Raspberry Pi PicoCSPIVGALEDBLERFIRPIDIMUMPU6050

Hardware components

  • RP2040
  • Raspberry Pi Pico
  • VGA display
  • IMU
  • MPU6050

Software & tools

  • C
  • Arduino IDE

Project demo video

What you get

  • Working project / hardware kit, tested before delivery
  • Complete source code with explanation
  • Project demo and guidance for your viva
  • Project report, PPT and IEEE paper support (on request)
Delivery & Payment
Delivery takes a minimum of two weeks from the date your inquiry is confirmed. Payment is in two parts: • 50% advance to start the project • Remaining 50% before delivery Note: • Documentation and PPT are not included by default • If you need documentation/PPT, it can be arranged for extra time and cost We'll confirm the exact timeline and cost with you after reviewing your requirements.