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.
Powerups - 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.
- Feather : The player’s movement and jumping has less gravity applied. Boss projectiles slow down in speed.
- Weight : 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.
As game designers, we shouldn’t accept any mechanic into the game unless it’s been tested, iterated on, and tested again and again.
Using elements randomly has the possibility of being a good design and can be another way to add additional layers to your game play loop. On the negative end, if we have a random mechanic causes the player to die unexpectedly, too often, the design will need more iteration. 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.
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 complete the levels or areas by learning from their mistakes. If random powerups cause deaths - no amount of learning will help.
To solve these issues, let’s look at allowing the player to choose which powerup to use at a given time. We limit the amount of powerups that can be carried to three and allow to player to decide when to activate.
Developing a boss encounter is incredibly enjoyable. Creating all the abilities the boss can perform and attemping to balance. Picturing a design in your head seems perfect at first, right? What could go wrong? Many times when designers are coming up with a boss fight, their mind fills in the blanks. When we see the boss in action, that’s the flaws can be seen. While the boss encounter looked great in our minds and on paper, some of the gameplay wasn’t thought out at all.
For example: the bird boss that wildly kept healing over and over; when designing this fight, bird’s tuning with casting its healing spell happened too often. The only strategy that works is to get a shield powerup and reflect the bird’s projectiles back. As seen in the video, this gameplay creates a frustrating game play experience.
How do we fix this? Let the player know the boss can heal.
- The first few times the bird takes damage, it heals.
- Then when the bird is on its last life, it heals.
Once those conditions are met, the boss never heals again.
- The healing spell has a cast timer and additional of the powerups can be used to interupt.
Instead of waiting for a shield to arrive - this allows for all the powerups to contribute to the player with defeating this boss.
Giving the Player Leeway
Pixel perfect collision detection has its place. In this game, we’re not interested in that. Collision that is extrmely tight 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 need to die?
Giving the player additional 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, reducing the player’s hitbox felt instantly forgiving but still stays within the confines of the original design. The player can die if they’re not playing attention, being reckless, or not taking their time.
Gameplay 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 creation take flight, it will likely never match the idea you had originally.
It’s our job to spend time at the drawing board, think of many possibilities, play with different concepts of gameplay - uncover other possibilities players will inevitably find that you never thought would exist!