Flappy Jacob Prototype

I'm jamming on a flappy bird type game with my son called Flappy Jacob. We've implemented a heart point system, powerups based on a random number generator, bosses that have set patterns and attacks, and a scoring system.


While you're jumping through the game, different power ups appear randomly:


Shield - player can bust through the level blocks and reflect or be immune to damage from bosses.


The player's movement and jumping has less gravity applied. Boss projectiles slow down in speed.


The player's movement and jumping has more gravity applied. Boss projectiles are reflected back to the boss.

The feather and weight offer a challenging experience the way they are designed. Sometimes a weight is extremely helpful when you need to drop fast to avoid knocking into the walls. The feather can be beneficial when you need to float or glide through the walls.

However, if you get one of these powerups at the wrong time, there is a chance you'll die. It does create some momentum in the game play but many times it equals death for the player.

The shield is designed help the player along no matter what the situation is, allowing the player to destory walls.

While these are some decent designs for the game's mechanics, these powerups still need work. Instead of these powerups appearing randomly based on set percentages, we could design the powerups to be collected and the player can use them when they want to. This design is different but allows the player to make a decision instead of accepting what happens randomly.

Using elements randomly can be good and can add more layers to your game play loop. But don't get carried away unless you're creating a game for a casino! If a random mechanic causes the player to die unexpectedly too often, you'll need to look into the design. Do you need to redesign the whole mechanic? Can you get by with adding another layer to the loop? Experiment with different designs and ideas. Be positive the design is in scope and can be executed.

You could introduce a "miracle" type situation - the player would just wiggle through enough space to pass through the walls. Magical moments can spread stories outside of the confines of your game world. Maybe that's not enough or can be exploited. Some designs may need to be more clear. The player should be able to beat the levels by learning from their mistakes. If random powerups cause random deaths and no amount of learning will help - a redesign should take place. In this case, allowing the player to choose which powerup to use at a given time can help solve this design issue.

Balancing Act

Developing a boss encounter is a lot of fun. Thinking up all the abilities the boss can perform and trying to balance them out. Picturing this design in your head seems perfect at first, right? What could go wrong? Many times when designers are coming up with a boss fight, our mind fills in the blanks. When we see the boss in action, that's when we see the flaws in the design. While the boss encounter looked great in our heads and on paper, some of the design wasn't thought out at all.

Case in point - the bird that heals. When designing this fight, we made the boss heal way too often. The only way to really kill the bird is to get a shield and reflect the bird's projectiles back. So in order for a player to kill this bird - get the random shield powerup (which has a low chance to show up), and have the shield on at the exact moment the bird boss decides the throw projectiles. As you can see in the video - this design creates a frustrating game play experience for the player.

How do we fix this? We want to let the player know the boss can heal. So maybe the first few times the bird takes damage, it will heal. Then when the bird is on its last life, it heals. At that point - the boss never heals again. Maybe the heal needs a cast timer and one of the powerups can interupt the heal. Those are two designs that are feasible and can be improved even further.

Giving the Player Leeway

Pixel perfect collision detection has its place but most of the time, it doesn't give the player freedom to mess up and make mistakes. Perfect collision doesn't allow the player to experiment with different moves. It all has to be the same jump, same move, and distance. With Flappy Jacob, if the player's hair touches the wall, does the player really need to die?

Giving the player more freedom doesn't mean that the game's difficultly will be reduced. There is plently of room for balance. In our example with Flappy Jacob, we simply reduce the player's hitbox and the game is instantly more forgiving but still stays within the confines of the original design. The player can still die if they're not playing attention, being reckless, or simply not taking their time.

Designs need time and iteration

A design that may play out in your mind perfectly may not work at all. There are so many things your subconscious fills in so when you get to see your design take life, it will likely never match the idea you had in your head. It's our job to spend time at the drawing board, think of many possibilities, uncover other possibilities players will inevitably find that you never thought would exist!