Welcome to the blog of This blog will include posts on the use of technology in the classroom, teaching in general and tutorials on how to make the most of

Programming Flappy Bird in Scratch - A Guide

Blog post banner

This week I've been working on resources for for the programming aspect of the new computing curriculum. It's been great fun and has really taken me back to my degree in computing. I've found it especially interesting to see that many of the terms and concepts I will be teaching my class in September are the same terms and concepts I was being taught at university. As part of my work this week, I couldn't resist building a version of Flappy Bird in the excellent Scratch software that many schools up and down the country will be using. The game is fully commented, so I hope may be a useful resources for guiding students.

Play the game here.

Take a look inside the game here.

I'll use this blog post to share how I approached this challenge and the order in which I did things.

Why Flappy Bird?

Well it's actually a very simple game with some relatively simple programming concepts. In particular, it is made up of:

  • 3 sprites: a bird (in my game a butterfly), a floor and a pillar
  • a physics engine
  • some basic collision detection
  • a simple scoring system

With this in mind, I set to work.

Stage 1 - Create / Import the Sprites

As has already been said, the game needed 3 sprites; a controllable butterfly, a floor and a pillar. What purpose did each sprite serve and what programming did they each need?

  • the butterfly was to be controlled by the player using the up arrow on the keyboard
  • the pillar was to move across the screen, acting as barrier to avoid
  • the floor was needed to detect if the butterfly touched the floor, ending the game

I also decided to add a simple background image to improve the look of the game, although this could have easily been added at the end. When drawing the sprites for the pillar and the floor I decided to use simple colours as I knew I would be using Scratch's 'if touching colour' block to sense for any collisions. This works far better with solid colours rather than gradients. I have no doubt the appearance of my floor and pillar can be improved, but it's an important programming concept to understand that this should be added later and is a separate skill to that of programming.

Stage 2 - Programming the movement of the butterfly

This was actually the hardest part of the whole game and the part that needed me to turn to the excellent Scratch Forums. It was easy to make the butterfly move up and then down again every time the up key was pressed, but it didn't feel right as it was lacking any form of gravity coding. Normally I would suggest this is a 'bells and whistles' bit of programming, but it's actually a crucial part of the Flappy Bird game, so I decided it was important to get it right early on. The concept is fairly simple:

  1. If the up arrow is pressed, set vertical speed to 7 (see below); this is the fastest the butterfly will ever go in an upwards direction
  2. All the rest of the time, the vertical speed is being multipled by 0.9. This serves to reduce the value, slowing its upward speed down
  3. When the vertical speed is less than 3, gravity takes over which is why it is reduced by 1 every time. Negative values mean it is now heading towards earth; the smaller the value, the faster down it falls

Once I had this programming setup, it was time for testing. It all worked well, but I needed to tweak the initial vertical speed before settling on 7. Why not get your students to see what happens with larger or smaller values and then explain why.

Stage 3 - Programming the movement of the pillars
The pilars have a single job to do; to move from right to left scross the screen, with their gap at a random height each time. Programming this was easy and was broken up into two main programming blocks:

  1. Commands to move the pole from right to left, after first picking a random vertical height (this affects where the gap is)
  2. Commands to reset the pole once it gors off the left of the screen

I made use of internal messages this time as it allowed me to reuse my code for more than one instance. Again, the reuse of code is an important programming concept.

Stage 4 - Collision detection
It was back to the butterfly now to program the collision detection, which was actually the simplest part of the whole game. Scratch has a range of 'Sensing' options under the sensing menu and the 'touching colour' option was perfect for my needs. Since I had chosen a different colour for my floor, I used a simple OR block to detect for touching the two different colours. Initially, for testing, I programmed the game to stop if a collision was detected, but I soon changed this to instead send a message to end the game (see Stage 6 below).

Stage 5 - Scoring system
The scoring system, despite being simple for the player, was actually a little tricky to program. This however didn't become clear until I started debugging. The concept was simple enough; if the pole was further left than the butterfly, then the butterfly must have gone through the gap, so a point should be awarded. Programming this was pretty simple, but during debugging I ran into two main problems:

  1. The score increased constantly all the time the pillar was to the left of the butterfly. Therefore the score would increase very quickly until the pillar position was reset to the right of the screen.
  2. The butterfly could crash into the right hand side of the pillar and a point would still be earnt. It turned out that a point was given whenever the butterfly was past the centre of the pillar.

Fixing both these took some time and the aproach was as follows:

  1. I needed a variable to store whether a particular pillar had already been used to generate a point. I choce to call this 'barInMotion', but in hindsight this was not the best name. The purpose was simple; a point would only be awarded if barInMotion=1. If this was the case, the variable was immediately set to equal 0 so no further points could be awarded. The variable was reset to equal 1 when the pillar was repositioned on the right of the screen.
  2. I compensated for the x position of the pillar to make up for the fact it was wider than the butterfly

Stage 6 - Game Over

As mentioned in stage 4 above, during the initial stages of programming I chose to stop the game in the event of a collision being detected. This wasn't great for the player though as it provided no feedback on their total score. To improve this, I chose to use another 'message' block that would handle the end of a game. This had two main functions:

  1. Make the butterfly fly towards the floor, as if dead
  2. Feedback to the user that the game was over and what their top score was.

Stage 7 - Bells and Whistles
At this stage, the game was running really well, but it still didn't quite feel as natural as the real thing, however natural that can feel. I pinpointed this to the movement of the butterfly. The gravity was working well, but the butterfly was always pointing horizontally, rather than up or down depending upon where it was heading. Fixing this certainly came under the 'Bells and Whistles' heading. To fix it, I knew I could use the vertical speed variable which was being used to tell the butterfly whether to fly up or down. By using this value I was able to calculate the angle of rotation of the butterfly so it matched the speed.

So, having built a version of Flappy Bird from the ground up was it really as simple as I initially thought? Well yes and know. To get the basics of the game it was incredibly simple and well within the reach of a year 6 class in my opinion. It was the added extras such as the gravity engine and the rotation angle that made it a little tricky, but certainly within reach of a KS3 programming class.

Get Remixing
The code for this game is fully commented. Please use it is lessons and get your students remixing it. I have no doubt there are improvements that could be added, such as:

  • high scores
  • the ability to select a level of difficulty
  • different levels (could the gaps in the pillars get smaller?)
  • a game that gets harder as scores increase

If you or your students have remixed the game, please post a link below.


This post has no comments. Be the first to comment by using the form below!

Add Comment

Your email address will never be published or used for spam. Required fields are marked (*)

Comment *
Get in touch