Zombie Bird Tutorial (Flappy Bird Clone/Remake)
Day 1 - Flappy Bird - An In-depth Analysis
To clone a game properly, we must understand its behavior perfectly. In this section, we are going to study various gameplay elements of Flappy Bird so that we can emulate the game more accurately.
I am going to try to determine how each gameplay element was implemented. Of course, this is just an approximation -- I may be completely wrong, but it should be close enough for us to mirror the game. If any drastic changes need to be made, I will let you know in a future section.
I am going to try to determine how each gameplay element was implemented. Of course, this is just an approximation -- I may be completely wrong, but it should be close enough for us to mirror the game. If any drastic changes need to be made, I will let you know in a future section.
It's All About the Gameplay
If we want our game to feel like Flappy Bird, we need to focus on the gameplay. The two essential elements that our game will need to get right are the Bird and the Pipes. Specifically, our bird has to move like Flappy Bird, and our pipes must generate and move exactly as do their Green counterparts.
The Bird
A quick tracing of the bird revealed its dimensions to be 17 pixels (width) x 12 pixels (height). It makes use of just seven colors. The bird takes up 1/8 of the game width, which seems to be 135 or 136 pixels at quick estimation. The bird is scaled accordingly to fit the device width. The bird also comes in three different color schemes, alternating randomly.
Bird Physics
It's difficult to experiment with physics in this game without dying, but from my attempts, I have discovered the following:
1. The bird accelerates due to gravity; i.e. vertical velocity is always increasing downwards.
2. But there's a cap. You can't go faster than this velocity cap.
3. No matter the current velocity, the bird will gain the same amount of height when the screen is tapped.
4. The rotation of the bird is correlated to its vertical velocity. Animation (flapping) only occurs when moving upwards.
Our primary focus will be to get these things implemented as closely as possible, as the feel of the gameplay depends primarily on the physics.
Collision Detection
When should the bird die? I have no idea how it was implemented in the actual game. From what I can see, however, pixel-perfect collision seems to be the way to go. We are going to create a hit box for our bird, which will be used to check for collisions with the pipes.
We don't want a small hit box, as that would make the game too easy. We don't want to make a large hit box, because people will get angry if they die without hitting anything.
It's difficult to experiment with physics in this game without dying, but from my attempts, I have discovered the following:
1. The bird accelerates due to gravity; i.e. vertical velocity is always increasing downwards.
2. But there's a cap. You can't go faster than this velocity cap.
3. No matter the current velocity, the bird will gain the same amount of height when the screen is tapped.
4. The rotation of the bird is correlated to its vertical velocity. Animation (flapping) only occurs when moving upwards.
Our primary focus will be to get these things implemented as closely as possible, as the feel of the gameplay depends primarily on the physics.
Collision Detection
When should the bird die? I have no idea how it was implemented in the actual game. From what I can see, however, pixel-perfect collision seems to be the way to go. We are going to create a hit box for our bird, which will be used to check for collisions with the pipes.
We don't want a small hit box, as that would make the game too easy. We don't want to make a large hit box, because people will get angry if they die without hitting anything.
The way I'm going to implement this is to create a single hitbox using a Rectangle object.
The Pipes
The Pipes may be the most difficult part of the game to get perfectly right, but it is essential that we do so.
A large part of the appeal of this game is its difficulty. If the difficulty somehow changes, by our miscalculating the speed or generating the pipes inconsistently, the game will not feel right. It won't have that frustration-reward-addiction system.
You never see more than 6 pipes at once, so we will create 6 pipes. The pipes seem to come at the same time interval every time, so the distance between each set of pipes will be constant. As soon as one set of pipes becomes invisible (moves beyond the left edge of the screen), we will redetermine the height (more on that below) and move the set to appropriate location beyond the right edge of the screen.
The height of the opening varies, but the size of the opening does not. The easiest way to implement this would be to simply move the column vertically to a random Y position when we reset its X position (within parameters). When we implement the pipes, I will examine the pattern in more detail to determine whether they truly follow a random pattern and how much they are able to shift up and down.
Animations
This is an extremely simple game. I have blacked out the static elements in this game -- the background and the sand. These will never change.
The bird stays fixed horizontally, at approximately 1/3 of the screen width.
The grass(?) and the pipes are the only elements that need to scroll horizontally, and they do so at the same speed. The grass will be extremely easy to implement, so we will not discuss that here.
The Pipes may be the most difficult part of the game to get perfectly right, but it is essential that we do so.
A large part of the appeal of this game is its difficulty. If the difficulty somehow changes, by our miscalculating the speed or generating the pipes inconsistently, the game will not feel right. It won't have that frustration-reward-addiction system.
You never see more than 6 pipes at once, so we will create 6 pipes. The pipes seem to come at the same time interval every time, so the distance between each set of pipes will be constant. As soon as one set of pipes becomes invisible (moves beyond the left edge of the screen), we will redetermine the height (more on that below) and move the set to appropriate location beyond the right edge of the screen.
The height of the opening varies, but the size of the opening does not. The easiest way to implement this would be to simply move the column vertically to a random Y position when we reset its X position (within parameters). When we implement the pipes, I will examine the pattern in more detail to determine whether they truly follow a random pattern and how much they are able to shift up and down.
Animations
This is an extremely simple game. I have blacked out the static elements in this game -- the background and the sand. These will never change.
The bird stays fixed horizontally, at approximately 1/3 of the screen width.
The grass(?) and the pipes are the only elements that need to scroll horizontally, and they do so at the same speed. The grass will be extremely easy to implement, so we will not discuss that here.
Handling Different Screen Sizes
On my device, the bird seems to be centered vertically (see red line in image to the left). Looking at this, I predicted that the game stretches equally at the top and bottom, so that the size (or ratio) of the essential gameplay area remains the same. No device confers an advantage, as you can never see a beyond a fixed width. Instead, the two reddish regions at the top and the bottom of the screen seems to stretch if you have a taller device, rather than show you a smaller width.
To confirm this, I had a look at the game's 3.5 inch iPhone version, which I believe the game was originally built for, and the essential gameplay area has a similar size to the non-shaded region on the image to the left.
So, we are going to stick with the following assumptions when building the game, to maintain a level of consistency:
- We will use the 3.6 inch Retina iPhone (640x960) as our baseline.
- We assume that all the essential gameplay happens in the rectangle of that ratio.
- Bird Width is 17 pixels (scaled accordingly).
- Game width is ~135 pixels, scaled accordingly (by factor of 4.75x on iPhone)
- Game height will vary with the device, but the essential height (where all the gameplay actually happens) will be (960/640) * 135 = 203 pixels.
To confirm this, I had a look at the game's 3.5 inch iPhone version, which I believe the game was originally built for, and the essential gameplay area has a similar size to the non-shaded region on the image to the left.
So, we are going to stick with the following assumptions when building the game, to maintain a level of consistency:
- We will use the 3.6 inch Retina iPhone (640x960) as our baseline.
- We assume that all the essential gameplay happens in the rectangle of that ratio.
- Bird Width is 17 pixels (scaled accordingly).
- Game width is ~135 pixels, scaled accordingly (by factor of 4.75x on iPhone)
- Game height will vary with the device, but the essential height (where all the gameplay actually happens) will be (960/640) * 135 = 203 pixels.
Enough With the Theory
Let's build our game. Join me in Day 2.