top of page

Battle Birds- Hybrid Humans

Giving power to the user through
quick customization menus.

My Role

  • User Experience Design & Prototyping

  • Game Design

  • Rewards & Progression Design 

  • Economy & Monetization system & Balance

Results

  • Increased RV count

  • Increased utilization of monetization system

  • Consensual monetization design

  • Increased functionality and customization of class system

Credit: 

All 2D front-end assets were created by Wellington Fattori: https://www.behance.net/wfattori

Prototype

The prototype was used by our development team to understand the flow of all the screens of the game, as well as fine tune the positioning and layout of the UI elements. 

MAIN MENU.png

main menu

Overview

Battle Birds is a mobile multiplayer mid-core free to play racing game. You race as various birds with magical abilities, competing for the "spark", the finish line. Choose from a selection of unique classes that have unique abilities and upgrade your stats to giving you the edge in races. There's a campaign mode with a narrative story and boss fights that will keep you glued to the screen. 

Users & Audience

Our target audience for the game was for users between 5-16 years of age. Through game conventions such as "Middle East Games Con", our target group was confirmed to be the highest count of users that played Battle Birds.

Scope & Constraints

  • 3 months pre-production: this included the competitive analysis of other similar games, team collective designing sprint, writing the game design document, decision of art style, overview of possible monetization systems, and UX prototyping. 

  • 9 months production: this included the hands on development such as illustrating, modelling, animating, programming, quality assurance, and user experience adjustments.

Ticket Menu.png

Loadout: tickets

BIRD – 5.png

Loadout: birds

Spell Book – 2.png

Loadout: spells

Problem Statement

Users were not utilizing the "loadout" feature of the game which allowed users to​​

  • Equip a ticket to race with: Tickets are betting challenges to be completed within the next race to earn more rewards. If the challenge of the ticket is not completed, it is lost. E.g. Junior Prize ticket as above, circled in yellow on the image in the left is the Junior Prize ticket. "Loadout: tickets"

  • Choose a different bird: There are 3 different classes of bird, each with their own unique abilities. E.g. Ostro class as above, circled in yellow on the image in the middle is the Ostro class. "Loadout: birds" 

  • Choose a different spell: Spells can be used in a race to directly affect other racers. E.g. Blue shell spell as above, circled in yellow on the image on the right, is the Blue shell spell. "Loadout: spells"

We noticed users were not customizing their loadout unless we reminded them that it existed, which was an important feature of the game as it gave users a unique way to play the game as was also one of the pillars of monetization in the game.

Another problem was that if users remembered to change their loadout, they would have to go through too many screens to change their ticket, bird, and spell before a race. The bulk number of screens were due to the loadout feature allowing the user to:

  • Buy upgrades

  • Equip items

  • Read information on items

Storyboard.jpeg

storyboard

What did I do? and Why did I do it?

What? Mini-Loadout flow on tapping "Race".

We incorporated a mini-loadout loop whenever the user played a race as as "pre-race" screen. This insured that the user would always be informed about their current loadout and is free to customize it as they deem appropriate. This served a similar purpose to a checkout reminder flow in retail websites where during a checkout page, you are reminded of the overall order, as well as your previously used method of payment for checkout using the application/website. We implemented a similar approach to our pre-race flow. A screen to screen flow of the "mini-loadout" can be seen below.

MAIN MENU.png
3_stage_loagout_TICKET_–_12.png
3_stage_loagout_BIRD_–_7.png
3_stage_loagout_BIRD_–_43.png
3_stage_loagout_BIRD_–_44.png

First, the user will have to choose between the 4 different ticket types, after which, their previously selected bird and spell will be shown to them with them option to tap on "GO" to proceed to race. If the user wanted to change their bird or spell. they can do so by tapping the "ready" button circled above.

Why? Giving "power" to the user.

Previously, the user had to go to a separate menu selection within the main menu called "Loadout" to select their loadout in a more "manual" manner. The user had to go to 3 different screens, the "spells", "ticket", and "birds" screens. This didn't give the user a sense of direction in terms of loadout customization. Thus, enforcing the loadout feature within the core gameplay loop reminded the user of the feature and thus enhancing their gameplay experience. A screen to screen flow of the "full loadout" can be seen below.

Ticket Menu.png
MAIN MENU.png
Loadout Menu.png
BIRD – 5.png
Spell Book – 2.png

The ticket selection appearing first was made mandatory as it is the only part of the mini-loadout sequence that the user can spend in-game currency as well as watch a reward video advertisement. Also, if the user purchased a ticket, the user can opt for a specific bird/spell that would help them complete the challenge of the ticket, and thus earn more rewards.

What was the result?

The results, unsurprisingly were that users cared more about their loadout and no longer entered races saying "Oh! I forgot to change my bird!" or "I could've earned more this race if I had purchased a ticket!". This "pre-race" mini-loadout addition to the core gameplay served great purposes:

  • Reminded the users of the loadout customization, a core feature of the game

  • Acted as a safety net incase users forgot to change their loadout from the loadout menu

  • Increased use of the monetization system since the users is always prompted to purchase a ticket before racing.

PURCHASE CONFIRMATION POP UP.png

purchase confirmation pop-up

What did I learn?

During development, features of  your application/game may seem very obvious to developers to use in terms of flow and usability. This blind-siding effect is quite dangerous and thus, it is extremely important to bring a fresh pair of eyes to the development team. Games con, although, not the best environment to test a game, served as a great platform to observe users. Through observation, we understood that the users weren't using a key feature of our game which we worked so hard to implement. Sometimes games need to protect users from hurting themselves. The mini-loadout is not an "easy" mode for users, but simply acts as a reminder to supplement the core gameplay and expose features of Battle Birds that we deemed to be a pillar of monetization and customization.

Using the checkout reminder of retail websites as a reference for the flow helped us put together a usable, quick, and effective method to expose a key feature of Battle Birds. 

bottom of page