Project Overview
I was hired by V2 Games as their first Lead UX Designer. My role was to build up their UX processes and pipeline. I also happened to be starting at the very moment they were ramping up production on a new Unity-based mobile game entitled “Beast Brawlers”, and that become my first project.
What is Beast Brawlers? It can be described as a a multiplayer arena game with RPG / fantasy elements. Players can mount mythical beasts and battle each other using powerups in a grand arena in quick, 3 minute rounds. In essence, V2 wanted to push the boundaries of conventional mobile gaming by appealing to the “mid-core” gamer, someone who wants the thrills of a multiplayer AAA game experience but on their mobile phone. Even though the multiplayer technology was still in its essence, V2 wanted it to showcase what modern phones could do.
My role was to work with the analytics and game design team in order to develop the menu systems, design the onboarding experience and test the player control scheme.
Here’s a video featuring some gameplay:
Challenges
- The connectivity of a real-time game with multiple players on mobile was a new mechanic with many complicated dependencies
- The company had never considered UX as a primary component of the game design process before and were unsure how to proceed
- Due to the accelerated schedule, not all aspects of the research phase were able to be explored
Understanding the Core Gameplay & Audience
When I joined, the game designers had already fleshed out the theme and the combat mechanics. Originally the game was called “Tank Wars” and had a spinning mechanic where players could rotate 360 degrees in order to fight each other. They could also inflict damage to those that stayed in their circular Area of Effect for too long!
My first task was to read up on the Game Designer Document, and determine what the central aspects were and the core game loop. It was decided that this would follow a freemium model – players could download the game for free, but if they wanted to upgrade their Mounts skins (customize their costumes) they would need to pay. The game model was based on “Clash Royale” as well as elements of DOTA, and similarly, we used a hard currency, soft currency system. Players would collect points and soft currency (gold) through the arena battles, and then use real money in order to acquire hard currency (gems).
Our audience was players who enjoyed both multiplayer games, as well as card collecting games, such as Hearthstone and Clash Royale. Therefore, I knew I’d have to take these influences into account because we needed to make sure the card collecting mechanic was well-integrated into the gameloops. As players would score points, these cards would help them determine which mounts they could upgrade and which were better against their competition.
As previously mentioned, my job was not only to define the menu systems, but the onboarding process, so we could introduce players to their collectable items, inventory and shop. Basically “show them around the place” and get them levelled up so they could familiarize themselves with the game loops.
Sketching it out
With a better understanding of how we wanted players to navigate around the app, I decided to sketch out some concepts.
Mapping out the Arena UI
I worked closely with the junior UX designer to determine the arrangement of elements that would best work for the arena UI. In addition to the joystick and attack button, these included:
- the leaderboard
- player energy bars
- the passive attack button
- shoutouts
- clock timer
To determine how the game designers would prioritize these elements, I set up a whiteboarding exercise called a Bull’s eye. Essentially I had them write these elements on stickie notes and paste them on a whiteboard. Then, we collectively repositioned them either closer to the centre or further away. Based on this final layout, I started sketching out wireframes based on the visual hierarchy. Once we had those roughed out, the game designers greyboxed their prototype and had them playtested externally.
One element that we deemed essential was the clock timer. It worked best in the top middle of screen. If we positioned it in the upper left or right, it blocked the view of potential adversaries and frustrated players. Generally, the other UI elements were placed in areas that were easy to view quickly and help players strategize their next move.
Lastly, since this game featured intensive burst of action, player’s creatures might die or “sleep” fairly frequently per round. Because of this, I designed the element of a popover screen that would appear, allowing the player to reselect an active Mount with full health and re-enter the gameplay. Players would need to be able to select an available Mount, read a helpful hint about them, and then activate them. To separate these interactions, I identified several elements: the unselected Mounts, selected Mounts, unavailable Mounts (with a cooldown effect applied), and then the Mount activation button. This button would then spawn whichever Mount was both selected and available.
INSIGHT
What they discovered is that players generally reported a smooth gameplay experience, but found themselves getting lost in the arena due to the large arena and weren’t engaging in battle as much as they could. Since the general gameplay experience can be characterized by short, high intensity bursts of mayhem, separated by longer periods of rest, it was important to make sure players could find each other and battle in order to collect a significant amount of points.
So I worked to include locator arrows, to help guide players to where the main action was taking place. When we retested the game, we found that players were much more engaged and could attack enemies offscreen, since they knew the direction they could charge in.
Fleshing out the menu system
Once we had a good definition for the arena UI, I sent our UI designer the UX mockups, and they began building those out in more detailed form.
My next task was to determine the best way to integrate the additional areas, and continue on the core game loop:
Players would engage in battle > they would receive “cards”, potions and gold > they would visit their library which kept their cards and powerups > they would upgrade their mounts and provide them with powerups, and then re-enter the arena.
For the menu design itself, I first designed some low fidelity user flows, to illustrate the actions a user might take. We examined similar games that PC based, such as Defense of the Ancients, as well as other multiplayer games such as Rovio’s Battle Bay. Eventually, after presenting several iterations, we settled on having our menus accessible on the left-hand side.
Designing the Onboarding Experience
Coming Soon!