Game Concept
Buzzy Bee was developed after I did some research into bees, including their behaviours, predators, prey, life cycle, and role in the environment. After doing this, I distilled the information into some ideas, and came up with an endless runner based on the role that bees play in the pollination process. The reason I selected an endless runner was because one of the primary goals of this project was to create a mobile game, both for my own benefit and for the benefit of the friends that inspired me to create the game, and an endless runner is a good fit for mobile devices, with games like Flappy Bird being a massive hit on mobile devices.
Control Scheme
One of the first things I worked on was designing how the player would control the bee. I came up with two solutions; the player could control the bee either by tapping the screen to do a small jump upwards, or they could hold their finger on the screen to make the bee go upwards. I quickly prototyped these two control schemes, and deployed it for people to test. For the tap controls, the main feedback I got was that the jump didn't feel adequate enough, players feeling that it should be a bit stronger. A similar response was given to the hold controls, in that it felt slow to respond to the player's touch. The fix to the tap controls was just a simple adjustment of values, and for the hold controls I decided to also increase the rate at which the player rose to make it feel more responsive to the player.
This gave me another issue to face, which would I use? As both control schemes were equally liked amongst testers, I decided to leave that choice in the hands of the players. I chose this because I wanted to allow players to select which control scheme was most comfortable for them, and to enable those who had trouble either holding or tapping to still be able to enjoy the game. I designed an option for the player that determined the control scheme they would use. But without a lot of context, the option looked confusing, so I also designed a screen they could access in order to show them how each control scheme worked.
The option as it was implemented ingame, with tap currently selected
The instructional screen that shows the player how each control scheme works
Pollen
The initial design of pollen included a flower that players would be able to touch in order to get a boost of some kind. The player would touch the flower, do a small animation where they rub the flower, with pollen effects coming off the flower as they do so, before they jumped off the flower and continued forwards. To incentivise this, a bonus would be given to the player in the form of a speed boost, protection from a hit, bonus points, or a score multiplier depending on the colour of the flower.
One of the initial flower concepts
Diagram showing how the bee would interact with flowers
The issue with the flower is that it stopped the stage as the player completed their small animation. This just felt out of place, awkward, and disrupted the flow of the game. I didn’t want to abandon the pollen idea, as the concept of the game was based around the important role that bees play in the pollination process.
This is where the next iteration of pollen was made, where it was designed to be a collectible the player could aim to get for points. Pollen was placed in the gap of an obstacle and was also placed near enemies. This implementation had issues, as the points were tied to collecting the pollen, as opposed to clearing obstacles, and the pollen that was placed near enemies sometimes felt impossible to collect, which was not the intention of the design.
The next iteration of the design removed points coming from pollen, and applied them to clearing obstacles. But I still wanted to find a purpose for pollen. I wanted to incentivise the player to take risks, but I didn’t want to make the pollen also feel like it was impossible to collect or vital to increasing the score. I created a score multiplier, that would be increased each time the player collected pollen. This multiplier would have a maximum, and wouldn’t be reset when a player missed pollen, but instead reset after a short time. The pollen was also tied directly to obstacles, spawning only in the gaps in obstacles and not near enemies. Pollen also had a variable height, so that it could spawn close to an obstacle, creating a greater risk for the player.
The score multiplier shown at the bottom of the screen
This implementation incentivised risk from the players, without the pollen feeling like it was vital to the player increasing their score. To make the pollen more enticing for the player, I created a particle effect for the pollen, and even included an explosion of pollen when the player collected it. The visual effect, collection effect, and multiplier gave the player plenty of incentive and good feedback for collecting pollen, as well as incentivising risk from the player and keeping true to the core idea for the game.
Enemies
The enemies in Buzzy Bee were created to be dynamic obstacles, and I looked at the predators of bees that I found in my research, namely spiders and wasps. Spiders were designed to follow the players vertical position on the screen, shown visually by them climbing up and down their webs. Wasps would fly directly across the screen at a random height. Players responded to spiders in the manner I had intended, as they felt they were being chased by them and would have to work to get away from them.
Sketches of wasp and spider designs
However, the initial design of wasps felt rather boring, as they came across as just another obstacle but a lot smaller and players felt like they weren’t much of a threat. I wanted to make them feel a bit more threatening and dynamic rather than just static objects coming across the screen. So the next iteration made them move up and down in a sine wave as they moved across the screen, and this achieved the goal of making a dynamic obstacle, as the player would have to be more wary of how the wasp was moving in order to avoid it.
Difficulty
Throughout testing, I had been given feedback from players that felt the game was in a good place, and at the same time other players felt the game was slightly too fast and intense. As I was making the game with my target audience being those that don't regularly play games as much as myself, I designed options that the players could use to alter the difficulty of the game. The intent of the options was to make sure that everyone who plays the game can enjoy it, without feeling the need to play it on the most difficult settings. These settings that I chose to implement were the speed the player moved at, the scroll speed of the screen, the distance between the obstacles, and whether or not enemies were enabled.
Player speed and scroll speed were selected due to some testers expressing that they felt the bee rose and fell too quickly and the screen moved too fast. Obstacle distance was intended to allow the player extra space to play between the obstacles if they desired. Enemies are a more dynamic obstacle, and allowing players to turn them off let those players who were overwhelmed by enemies still enjoy the game. These options were intended to allow players of different skill levels to play the game at a difficulty of their own choosing, and players responded well to the implementation of these options.
The options that the player may choose between
Some testers gave feedback on specific aspects of the game, some wishing that obstacles were further apart or that the screen moved by too fast or slow. From this feedback, I wanted to include as many options for the players to tweak in order to make the game as enjoyable as possible for themselves, as opposed to making just a set easy, medium, and hard difficulty setting.