-
Notifications
You must be signed in to change notification settings - Fork 0
Home
A button-triggered Flappy bird game
By Mattias Stahre and Gustaf Halvardsson
Our objective was to create a game which responds to the players button-presses and moves our object, a taco, one step up for every press - while the taco moves quickly through the world of tubes that stretches from the top and bottom of the screen. The challenge for the player is therefore to dodge these tubes as well as not to hit the top or bottom. The main requirements of the game include: The object, taco, needs to be specifically drawn as a taco in the game, (as oppose to a simple square). The game must be able to respond quickly to button-presses, and with a smooth refresh rate to maintain playability - especially since the game is reflex-based. Must be able to provide a score for the player at the end of the game. Must contain a start screen and a countdown to prepare the player.
The objectives that we decided as optional from the start but were still fulfilled:
- Moving tubes in the x- and y-direction
- A high score list that is sorted based on the most points.
- A crash animation when you lose.
- A small fade-to-the-right animation for our start screen text.
- The ability to change the difficulty of the game, by switching to a moving-obstacle mode.
We developed our project on the ChipKIT Uno32, together with the Basic I/O shield. We used the button (BTN3) to play the main game which is displayed on the built-in display. Our player object, the taco, is constantly being pushed down (increased y-value on screen) for 40ms and you as a player need to counter this by pressing the button. We can refer this constant push as our gravity. If the button is pressed or held, the object moves twice the speed of gravity upwards (decreased y-value) meaning you need to balance the two to avoid hitting the top and bottom. If the object crosses our drawn out tubes (which moves rapidly from the right), it’s game over. If game over is triggered, we display your score, and put it up against the other previously stored scores, in a high-score list. We use the button BTN4 to start the game from the start screen. If you choose to flip switch 4 (leftmost switch), the tubes that were previously stationary are now moving in the y-direction as well (besides the normal movement in the x-direction). The tubes goes upwards off-screen and reappear below the screen - which is done in a repeated pattern. The same rule of avoiding them still applies.
Because we only use one button in the main game we did not need to test for different scenarios of button/switches combinations. We instead focused on scenarios within the game. These included what would happen if we crashed instantly, crashed at the top, bottom or with an object. The testing process was further strength3ened by the fact that a single game could be over quickly, allowing us to test it for many rounds with variations.
Besides these cases, our game excluded a lot of different scenarios because of the linear playstyle. Most of the testing was thus done with achieving different scores in different orders and that it was then correctly sorted and displayed on the high-score screen.
Most of the code was done together, with a shared coding screen meaning we were both actively writing code. The main exceptions were parts of MarkPixel, Tube-generation and some smaller functions (like crash animation and main-menu fade), where they were done individually but then thoroughly explained to the other afterwards.
Having done this mini project we learned many technical things but one of the most interesting insights has been how hard it is to plan for a technical project when you have limited knowledge beforehand. One of the first things we did after deciding what project to do was to try and estimate what needed to be done and how much time each component would need to be completed. We realised quickly that this approach would not work since we simply had too little knowledge about how to solve each problem as well as what those problems might be. Instead we did everything in small blocks of time where we looked at what needed to be done, how to do it, and who should do it without really knowing how much time it would take. Something to be learnt from this is that it’s very hard to estimate how long things take to build without previous experience.