HUD Elements

Problem: Design started with a request that we keep the screen HUD as minimal as possible, while still making it very accessible to new players. As the game progressed different features were adding and removed based on needs for the game at the time. My job was the maintain the overall HUD architecture and to fit in new features to the existing HUD at the time.

Process: I started by having discussions with Design and reading all available documentation on what features Design anticipated implementing in the game. I did some market research to see what other F2P Royales were doing, then broke down the needs of those games, the elements they used and compared them to what we had planned for our game. Then I used UX/UI heretics and laws to determine what the best user experience was for accessible gameplay.

Where it started (June 2020)

Layouts and Features through the years (2020 - 2023)

Starting iteration

I started with a basic re-organization/mapping of features that were currently in the game, while additionally proposing a game timer to the top center of the screen. Outline for Wild Fury meter feature proposal states on the right side of screen. Right side notes also shows possible implementations for special bullets and belay rope distances.

At the beginning of my work, there were certain aspects of the game that Design did not want to change. One of these things was the Paperdoll Health meter. I brought up UX concerns that players had difficulties knowing how close to death they were and how the different areas related to their overall health. Additionally the green-red-black scale was difficult to read, especially for those that were color blind. But I was told that it was there so that Design could implement body part specific trauma (hurt left arm makes it harder to aim, a hurt foot would slow a player down), and so this was kept in the design for a long time.

Marks, Idols, Relics and a Directional Rune Compass

For the next iteration of the HUD, in the center bottom of the screen is the passive Mark one could receive, as well as the Active Idol power one could activate. A player could also equip up to four passive power Relics, so I consolidated all power modifiers to one location.

At this point we had a primitive map system which was a beam from the equipped compass. Design really wanted to make this game about exploration and was very resistant to providing a map for the first 2 years I suggested one. Instead, we attempted a number of other map-like methods to give players directions without an actual map. For this iteration, the location to where to beam was pointing is selected from the menu above the person information that is only up while the compass is up. These locations were either found or purchased by the team members during that game session. All other global locations (such as exits) were pre-marked on screen, which icon size showing proximity.

In this iteration the Compass also had equippable runes. When equipped, the coordinating runes would flash when something of that rune type was nearby. This was to help detect all types of things, including treasure, monsters, relics, and other players.

Showing Luck/Corruption and Beginning of Communication

In this next iteration, we removed the idea of a Passive Mark, but we gained the ideas of "Luck" and "Corruption", which your specific character instance would collect over their lifetime. Once your character reached a certain level of Luck, you could earn more lives for your character; enough Corruption would turn the island against you.

This was the first iteration of our Communication system. Design really wanted to have all communication on the D-pad - so this restricted what/how we displayed this information. Since communication was contextual/reticle-focus based, the options and center icon would change as players looked around the screen. You can see this in the video below as I target a Borilla.

Top-Down Reorganization

I next attempted a re-organizing the information from a top-down approach. This allowed me to see the general spacing of items and how much space they were taking up/overlapping. It also allows Design to see all major HUD Features and their subsequent requirements.

Updated Health bar

At this point of the design we were able to convince Design that the body-specific trauma wasn't working the way they had hoped. Players didn't like the penalties to the characters and it was decided to we needed something that felt better for our game. Design wanted to stay away from a traditional shooter health bar because they wanted players to think of this more of an adventure game, than a shooter game. I came up with the idea of using hearts, as other traditional adventuring games used this idea as a concept for their health meters. I also moved the teammate's information closer to the personal information to keep all status information together.

We also see a progression of the Communication System, which, when you passive locked on an item/person, you would get additional options of things you could do. Here in passive lock the player is able to both communicate with the person they've locked onto and learn more about their history with that person (Relationship Story panel on right).

First Compass experience attempt

We eventually decided that the Compass was too hard to navigate with as the information it gave was too obtuse. Players would run around a spot for minutes not knowing how close or far they were from an entrance because the compass gave them no information. Players found it hard to coordinate where to go/meet up as the compass didn't have a "north" it just had a beam that shot out. Players also had to make the choice of having a weapon out or using the compass, so they found it annoying to have to consistently pull out the compass in deep jungle where it was easy to get turned around.
The following is our first attempt at moving away from the hand-held compass. Here we put a compass at the top of the screen so that players can easily coordinate directions with one another. This also allowed us to put navigational objectives on the compass so people could start moving in the general direction before getting more specific information. The specific location shown on screen was selected via D-pad, as shown above the player equipment area. The number 3 indicates how many compass locations are available for selection.

Final iteration

In this final iteration of the HUD Design, the elements have settled into a final organization that we felt fit best for our game. We now have a mini-map that allows players to see local information top-down. Our equipment area has been updated to reflect our character needs: Special Ability, Access to Inventory, Quick Use Item, and Equipped Weapon. I show the use of our QUIP system to confirm an action in the game. I also consolidated all status effects to the same area. If we'd had more time the plan was to move Player Status effects onto the hearts and keep the Relic Status Effects as the only effects to show below the hearts.

Final Implementation

Character Select

Problem: During my time at Mutant Arm there have been various requirements around what information we need to provide about our Characters. At first we had characters that had perma-death, which meant we needed to track a lot more information about each character in our roster. With this perma-death included ideas like "Training" and "Retirement", "Luck" and "Corruption", as well as showing all the Relics/Idols that had been acquired on that character instance.

We eventually moved to a model with no perma-death, thus making the roster sheets much more about the specific character instead of a specific instance of the character. This allowed us to highlight what makes each character unique to push players towards different playing styles.

Process: I started with what was currently in the system for each of the Characters. I asked Design for all the current design ideas and features that made each character in the game. I determined the high-level commonalities between the character and created mockups that reflected this information. As character designs changed and elements were added/removed, I continued to update recruitment page to reflect the critical information when selecting a character to play.

Mockups from May 2019 to Feb 2023

Permadeath Characters

As characters got more involved and had specific requirements for "Retirement", the "Choose your Character" page got more involved. The following is the page where you select a new permadeath character to add to your roster. This was to give high-level/comparable information about each character so that players could make informed decisions.

Once a character has been recruited to the Roster, the players could come see all the miscellaneous information, including how many lives they had left, what marks/relics they had found. The current view is showing the pop-up state when a player selects the "Retirement Information" button.

Here is the next iteration of the initial "Play Game" screen, which allowed players to directly select from their Roster. Here you can see the elements that were added to the game such as Luck/Corruption, Marks/Boons, Rune Compass, Training upgrades, and Retirement information.

I felt like the above screen was overall noisy and there wasn't the ability to put any additional features that we needed on the Main Landing page of the game. I decided that a lot of the upgrade/progress information didn't need to be readily displayed and could be nested in a collapsed tab. This allowed the Main Landing page space to show objectives, build one's party, and also have a large beautiful back-scape image/animation that would only be blocked when players went into to learn more about their adventurer.

Switch over to non-permadeath characters

When we switched over to non-permadeath characters, we no longer had to worry about maintaining a Roster sheet and could focus on showing information about the general character. This following design was an iteration that I made in an attempt to streamline the experience getting into the game. This would allow players quick comparisons of the different characters while letting player them also quickly purchase items and equip Relics they had previously brought home as a way to optimize loadout selections. It was decided that this was too removed from the "Cantina" experience they wanted (see Cantina section below).

As Design wanted something that was more "part of the world", I then switch to the below implementation. The numbers under each character are the levels of Fame (individual XP ) they had each reached.

When players select the "Additional Information" button they would be navigated to the sub-pages below that would allow players to learn more about each character. Basic information was the information that was comparable across characters; Backstory was information about how this character did in previous game sessions; Infamy was the tracking of Fame and rewards won by rewards certain thresholds; Closet was the area where players could customize their characters.

Going off the designs from above I decided that the comparable information needed to be surfaced more readily, and so after final discussions on what elements were comparable between characters, I came up with the below design.

Final Implementation

Fly-through Cantina Design

Problem: Design requested to have an intermediate menu-type space once the game started. This space was to allow players to meet up, plan their adventure, and gear up before leaving for the island. Design requested that players be bound to

Process: Before making the menu fly-around, we needed to determine all the menu features that we would need in this space and create a non-fly around version. While Design had a number of planned features, I decided to focus on getting an MVP Cantina started with the elements that we already had within the game.

Initial Mockups from Research Gathering

For this MVP - Design, Engineering, and I sat down to talk about the features and functions that we could get into the Cantina. There were elements that Design felt users should have access to prior to Readying Up, and elements that they should have access to once they are in the full Cantina.

In this first stage they wanted players to be able to customize their character and team loadout as much as possible. This meant having access to the Relics and Idols that had already been collected on the island, the ability to change what character they were playing, and access to Friends List. Prior to this step players could choose to "match up", which would auto-select players to be on their team.

Once ready, players and their teams would select "Ready Up" to enter the full Cantina. Once in the full Cantina, they would additionally have access to the Outfitter (equipment store), Brews (session bonuses), and be able to see a countdown for how much time is left in the Cantina.

Additional features that were determined to not be MVP was the ability to friend Solo players, see the Island Map, and see people on the other teams. Below are additional mockups for the pieces that were approved for MVP.

Cantina Implemented

As we were creating the Cantina in 2D we had a number of design changes. One change was that Idols no longer selectable, and we got rid of the Relic Storage area (they just remained in the backpack). With these changes, we adapted our Cantina design to reflect the new MVP needs and desires.

As part of this - I implement all Blueprint Widget pages and sub-widgets for the Cantina space in Unreal. I created the front end UI, connected as much Blueprint to the UI as I could, and then worked with Engineering for final hooks to the system.

"Final" 3D Fly Around Menu

Once we had all the menu features working in the 2D non-fly around space we were ready to move onto the fly around area. We contracted another company to create a 3D space that matched our 2D background. Once I had that 3D space as it's own level, I was able to use Blueprint Widgets to create the 3D fly-around space you see below.

Unfortunately, we ran out of time getting this space hooked into our game logic, which is why none of the widgets show any data within them. Layoffs happened before we made it to that milestone.

Ammo Box Count

Problem: When an Ammo Box is used, the ammo fills up to the full reserve of the weapons on the character. When first proposed, each player had two gun with separate reserves. If an ammo box was used before the reserve ammo was empty, players would lose possible ammo from the box. Design wanted to make sure that the game was about care use of resources, and did not want ammo boxes adding to overall reserve of bullets. Therefore, players would need to wait until both weapon reserves were empty enough to receive the full amount of bullets from a box.

Process: We'd had this problem of not knowing how many bullets you'd get from an Ammo Box from the very beginning, so we wanted to make sure players were aware of this information prior to using the Ammo Box.

Pop-Up Information

At first we decided the easiest thing to do would be to have a dedicated area on the HUD that would display the information about the items that were equipped from the backpack. At this time in the game, we felt like there were a number of items that were not immediately understandable when equipped, so we provided a short description in the space to the left of the inventory.

When the Ammo Box is equipped, it showed the number of bullets that you would receive per gun. Since each gun would receive different amounts of ammo based on how much reserve was left, I decided the best way to highlight this was to show a ratio of "how many you'll get"/"how many you could get".

Active Slot Information

Eventually we got to the point in our inventory design where we had an Active Equipment Slot on the HUD that we could "ready" items to. With this dedicated "Active Slot" area on screen, I felt this we could improve the experience of the Ammo Box by using the space above the Active Slot to display information about the item in that slot. Here are some of my initial mockups:

When I presented this design I showed that:

there was already room dedicated above the Active Slot because of the special on the Ability Slot
this design had enough space to show not one, but two types of ammo

this is a previous a requirement for character weapons

this could be expanded to other items (such as the health kit) to show players additional information
also proposed showing a stack on the 2nd example (with the circled 2)

this is not functionality we currently had in the UI

During the meeting we talked about how only one character weapon would need bullets, so we didn't need to worry about representing two values. We talked about using progress bars instead of numbers:

But in the end it was decided that the specific information was more helpful in the end, and so we went with my proposed design. Additional things we were able to do with this design was to color the count Red when players would get 0 bullets (wasting a kit) to draw attention to that fact, and colored the count Green when the player would get the max amount of ammo from the box.

Society Pages

Problem: In the last few months of my job, Design created documentation around the idea of Secret Societies. These Societies existed outside the game to give players additional objectives to do on the island.

Process: From the design documentations I was able to come up with initial high-level mockups of what the space may look like. The ask was for 4 elements to be shown: The Individual Society pages, a seasonal Challenges page, an Adventures page, and a Contracts page. I realized that the Contracts fit better within the Cantina space, while the other 3 areas were spaces that should be looked at and examined outside of the timed Cantina space.

I created the following mockups to show the Design intent, and once discussed and approved, I implemented the front-end in Unreal.

Settings Page

Mostly in this example I wanted to show off my Blueprint skills. I label all my elements, I've been using Overlays and Vertical/Horizontal boxes to keep all elements aligned correctly, and I've been using Widget Switchers to keep tabbed states working easily.

Update Suggestions

The following are suggestions I documented to capturing elements of the game that could use improved user experience. I provide my solution, my reasoning, and those that I feel will need to be involved if we decide to make this change.