(Alex Wong, Jiale Yang, Tao Qiu, Tianyu Luo)
Hey guys how's it going, David's bros here!
Note: You may need to change some settings on the physical monitor for the game to be in fullscreen
Project Mark:87.5%
Project Title: FloppyBox
Project Description: A game where the player attempts to maneuver a block through a series of obstacles by clicking on a key to adjust its height.
Video URL: https://youtu.be/ZfAoKyxEzmo
Code URL: https://github.com/RarePep8/CSCB58-Project
We are making a game similar to Flappy Bird, the mobile game. Players will control a square that will be moving towards countless vertical walls. Each wall will have an opening which allows the player to get through and touching the wall will lose the game. The player can only move up and down and it is constantly moving down if not being controlled.
What do you plan to have completed by the end of the first lab session?: We plan to finish getting the player to move as well as getting walls to generate and allowing them to move. If time allows, we will randomize the position of the wall opening by using an internal clock combined with user input
What do you plan to have completed by the end of the second lab session?: We plan on implementing interactions between the player and the walls like having the player die when it touches a wall. We also plan on getting a scoreboard feature for this.
What do you plan to have completed by the end of the third lab session?: We plan on fixing any glitches and bugs that might exist within the game. If we’re done that, we can create other features such as changing the horizontal speeds of the moving walls or letting the wall openings move up and down so the game gets harder.
What is your backup plan if things don’t work out as planned? If we can’t get the first stage done, we’ll switch to a Guitar Hero-like game where you press keys in tune to blocks falling down and hitting a horizontal line. We can leave out some extra features such as modifying speed or wall openings.
What hardware will you need beyond the DE2 board (be sure to e-mail Brian if it’s anything beyond the basics to make sure there’s enough to go around) A monitor like the one used in lab 6
How does this project relate to the material covered in CSCB58?: This game has objects that move around over set intervals. We will use counters and decoders to simulate movement by selecting certain pixels to turn on and off certain colours across the screen. Furthermore, a FSM will be implemented to help organize the different game states. We will also use ALU registers to select between addition and multiplication modules when calculating scores, and memory will be required to stored the scores. Ultimately, we will connect these modules using a controller to configure the state properly, which allows the game to be replayed indefinitely.
Why is this project interesting/cool (for CSCB58 students, and for non CSCB58 students?): It takes a game we are all familiar with and breaks it down into basic components that we can build from scratch. It is interesting for CSCB58 and non-CSCB58 students to see how simple bit operations involving two digits can be built and modified in such a way to create a complex entertaining game. It is interesting seeing how advanced games can be made through complex and vast arrangements of atoms.
Why did you personally choose this project?: This project is challenging and requires us to use all of our knowledge we’ve learned so far in this course. Not only that, it requires us to further research and try out many different things to accomplish this task. Also, our group members are all interested in games and this project will provide us an experience of building a game from scratch.
Brian Harrington’s starter code for CSCB58 labs
Week 1: We adjusted the verilog code for lab6(vga) in order to display pixels through a register which stores X and Y coordinate instead of manually loading it like in lab6 (vga lab). This means we also created a register that acts as an object representing the character that the player is controlling, inside the register we store the X and Y coordinate as well as the state of the character (Flying, or Falling), at this point we used up the remaining time to test if the monitor can actually display the pixel(character), our plan next week is to start implementing the Flying and Falling states of the character
Week 2: We implemented the flying and falling state of the character, but we can’t tell if it works properly since the drawing module has issues drawing with changing x and y values. We also created and tested the pipe register which holds the x and y value of a pipe, suprisingly the drawing module works properly for the pipes. We started adding the erase states for the drawing module to erase it’s current frame before drawing the next, but we ran into timing issues where the pipe moves asynchronous to the speed of frames being drawn. Our plan next week is to change the pipe to move only after the drawing modules finishes drawing each frame. We also hope to rework our character module.
Week 3: Due to the short amount of time remaining, we decided to simplify some features of the game. For example, the character flies at a constant speed when the player holds the button instead of flying with gravity when the player taps the button. We also scrapped the scoreboard feature since the main component of the game still needs work. During our time in the lab, we successfully debugged the problems with the painter module, which let us draw as if the character and the pipes are moving. We then added a collision detection module along with reset signals for the character and pipe registers. Overall, we made a lot of progress thanks to the extra lab time.
Week 4: During this week , we finished working on the score counter which increases by 1 every second that the player is still alive, and it resets when the player starts the game again. After the game was finished, we cleaned up the verilog files and deleted any unused modules.