Pico-Fight fighting game

Introduction
High Level Design
Program/Hardware Design
Results
Conclusion
Appendix
Pico-Fight (Fighting Game)
Digital Systems Design Using Microcontrollers (ECE 4760) Final Project
⬆ Click
the game area above to play a computer version of our project!
Note: both players need to be pressing the same non-menu key to start.
Welcome to Pico-Fight
Demonstration Video
Our final project for ECE 4760 is a strategic two-person combat game inspired by the open source fighting game
"Footsies", a simple game designed to test the players spacing, timing and combat skills.
Our build leverages the Raspberry Pi Pico microcontroller connected to a VGA screen for visual display, with
player input handled through keypads inputs. The game allows players to execute a variety of combat maneuvers,
including attacks, blocks, shields, jumps, and crouches. The combat takes place in the critical "no man's land"
between fighters, where positioning and tactical decisions determine victory or defeat. The Pico microcontroller
processes player inputs with minimal latency, ensuring a responsive and fair competitive experience. Whether
you're trading blows at mid-range or executing a perfect defensive maneuver, the system offers an engaging and
intuitive gaming experience that captures the strategic depth of spacing-based combat games.
Figure 1: Team pic - Edwin, Zoey and Albert (from left to right)
High-level Design
Rationale
Our goal for this project was to create a fun fighting game run off the Pico microcontroller. To do this
we drew inspiration from the open source fighting game "Footsies", a simple game designed to test the players
spacing, timing and combat skills.
Taking the core moves and sprites from the game, we built our own game with new mechanics, art and sound effects.
UI Structure
Below shows the various UI screens and the state machine controlling the transistion between the UI screens. When
the game boots up it will display a title screen. From here, the players can press any key to enter the menu
screen where the players
can customize their character models and clothing. From here, both players can press the same key to enter the
game. Within the game, the players
can choose to pause the game and return to the title. When a player wins, the game will display a win screen based
on which character won.
Title
Menu
Game
Win
Figure 2: UI state diagrams.
Left: higher level abstraction. Right: lower level implementation.
Game Structure
Due to the amount of possible interactions between the player, we implement another state machine to
handle the game logic. At a high level, each player is in one of three possible positions: idle, crouching or
jumping.
Each of these positions has a set of possible actions that can be performed and rules that dictate the
interactions between the players.
Figure 3: Game logic state machine
Idle
The idle state is the base state that each player starts in. In this state, the player can walk left or right and
has access to
a kick attack and a uppercut attack. In this state, the player can also block other standing attacks with shield.
Jump
The jump state puts the player in the air. While in the air, if the player lands on the opponent, they will
perform a 'drop attack'.
A player is also able to block another 'drop attack' by jumping at the same time.
Crouch
The crouch state causes the player to duck. In this state, the player can perform a crouch attack and block other
crouch attacks.
Shields / Hits
From each state, a player can be hit and will take damage. If a player is hit, no matter what state they are in
they will enter a 'hurt' state.
After the 'hurt' animation plays out, the player will return to the idle state. If a player takes damage, their
health
decreases depending on the attack. When a players health reaches 0, they lose the game.
An important mechanic in the game is the shield. Each player starts the game with 3 shields and can
use them to block different attacks. For the shield to be effective, the player must be performing the correct
action
before being hit (the blocks are shown above). If a player shields an attack, they will not take damage however
they will
lose a shield. If a player runs out of shields, they will take damage from any attack. To get shields back, the
player must
hit the opponent when the opponent shield. This adds a layer of strategy to the game as players must decide when
to shield and when to attack.
Figure 4: Health and Shield bar. Health on top, shield on bottom
The above figure displays the health and shield bar. The shield bar can be distinguished by the 3 sections,
each representing a shield.
Sprites and Art
The player sprites were drawn over the original footsies sprites using Procreate (iOS) and PixelStudio (Android).
The visual style is intentionally minimalist, limited to black and white. This allowed us to keep the same
outlines however different heads and clothing models from the Footsies game. To integrate these assets into our
game, we wrote a Python
script that converts each sprite into a two-dimensional C array.
For memory efficiency, our drawSprite function in C only takes the coordinates of either only black pixels or only
white pixels depending on which one is fewer, and renders those, effectively outlining the sprite without needing
to store full image data. Most of our animations consist of multiple frames – such as a five-frame attack sequence
(Figure 4.). For each frame, we store an array of pixels (Figure 5.), with each pixel representing a displacement
from the origin position of the player. This origin position is defined at the center of the player on the ground.
Offsets are scaled by 4 to make sprites look bigger on screen.
Figure 5: Sample attack animation sprite sheet - Left: Reference sprite sheet from footsies. Right:
Our sprite sheet
Figure 6: Equivalent C arrays for each sprite in the attack animation (figure 4)
In addition to the player sprite sheets, the game also includes a variety of art for the various display screens
and background parts. Each of these components was stored in similar C arrays and drawn modularly rather than
as a whole because many
either need to move (eg. background clouds) or need to be switched around (eg. character select screen).
Figure 7: Title screen sample head. Only the white part was recorded and rendered.
Figure 8: Figure 4. The fillings of background clouds.
Converted to black for mass png-to-array conversion, but drawn in white on pico.
Background Music
Behind the game, we have a looping background music track.
Concept: let 0=pause, 1=C, 2=D, 3=E, 4=F, 5=G, 6=A, 7=B, then the melody becomes
4760 447760 2 4760 447760 2
which represents ECE4760 group 2.
notes : F4, B4, A4, 0, F3, F4, B3, B4, A4, 0, D5, F5, B4, A4, 0, F5, F4, B4, B3, A3, 0, D4
duration (1 unit = 130ms): 2, 2, 2, 2, 1, 1, 1, 1, 1, 2, 1, 2, 2, 2, 2, 1, 1, 1, 1, 1, 2, 1
Background Music:
Your browser does not support the audio element.
Sound Effects
In addition to the background music, we also have a set of sound effects that play
when the player performs an action. These sounds include: whoosh sound when the player attacks,
thud sound when the player is hit, shield sound when the player blocks, announcer sound when the game starts.
Hit Sound:
Your browser does not support the audio
element.
Shield Sound:
Your browser does not support the audio
element.
Announcer "Fight":
Your browser does not support the audio element.
Whoosh Sound:
Your browser does not support the audio
element.
Program/Hardware Design
Figure 9: A photo of our hardware.
Figure 10: Circuit Diagram.
The input to the game utilizes 2 keypads. These matrix-like keypads work by setting the columns of the matrix high
one at a time. By then checking which GPIO receives an input we can determine which key is pressed at any time.

Because we needed many GPIO pins to write to the VGA screen and DAC we decided to let both keypads
share the same scan GPIO keys. That way we save on GPIO pins and a single scan
allows us to check both keypads.
For the audio, we utilize both channels of the DAC to
play sound effects and music. Initially, we struggled to play both sound effects and
music at the same time without significant noise. By utilizing stereo speakers, we can plug one DAC channel into
the right speaker and
one into the left. This minimizes the amount of interference between the sound effects and music and also allows
both
to play at the same time.
Player States and Frames
As with most fighting games, all of the timing is based on a frame timer system. Each frame corresponds to a step of
the game. Within one frame, we must parse inputs, check for all interaction between the players then update the VGA
screen. Utilizing frames also allows us to play the animations for the proper amount of time. For example the ‘hurt’
state in the figure below is a sequence of 4 sprites. When a player enters the ‘hurt’ state, we can simply draw one
sprite per frame to complete the animation.
Figure 11: Frames of hurt
Each player is represented by a struct consisting of many variables making up the player's current state. The
state of a player consists of information about the players game status (eg. health, shield, hitbox) as well as
what animation should be played on a given frame (eg. state, frame)
Figure 12: Player States.
The player state is updated every frame. Each frame, we check the inputs of both players and update the player
state accordingly. For example, if a player presses the left key,