Kenneth Chen
Digital Media PhD Student
Kenneth is a doctoral student in the Digital Media PhD program. In his series “Kenneth on Games” he writes about his passion for games and game design.
Mobile apps always need to worry about UI, but in a game like Fire Emblem Heroes, the UI also needs to synergize with the game design. This can create constraints on both sides, but it can also result in intuitive solutions. Although UI design is a completely different field from game design, the affordances from each can support the other.
Comparing Units and Team Compositions
In FEH, the player has a team with four slots, and they have many heroes who could fill those slots. Heroes have different attributes: some wield swords, lances, axes, others use magic or bows. They can be mounted on horseback or equipped with cumbersome armor. Some of them have high resistance, or high defense, or high attack damage.
The game design naturally encourages diverse team compositions rather than using multiple similar units. A player may have many units who wield swords, but they would not want to use a team with four swordsmen. For each team, the player must decide which swordsman they want to put on that team, if they want a swordsman at all. Therefore, the player will spend a lot of time comparing two similar units to determine which of them fits the task better. Perhaps this team needs a tanky swordsman, or this team needs a fast and powerful swordsman.
In UI terms, the user story is “I want to view the stats of one unit. Then, I want to view the stats of another unit. Once I have mulled over this information, I want to decide which one of the two units will be on this team.”
A character view appears in every menu where characters could be needed, including team composition. When you tap on a unit, their information appears at the top of the screen, and if you are in the team menu, they are immediately added to the team if there is space remaining. However, this contradicts the player goal of only having one unit of a single type. If the player taps one swordsman to view their stats, that unit will be added to the team. Then, if the player taps another swordsman to view their stats, that unit will also be added. Now the player has both swordsmen, when they only wanted one and just needed to decide which of the two.
Of course, the player can just take units out of the team by pressing an undo button, but since this is UI design, there should be as few clicks/taps as possible. But there also isn’t enough space to display two units side by side so that a player can compare their stats. If the player performs a long tap-and-hold on a unit, it brings up a detailed page which covers the whole screen, which is nice for flavor but doesn’t help fulfill the user story.
FEH’s solution exists between the actions of “tap to add to party” and “hold to view detailed page”. If you tap on a character and then slide your finger off that character, their stats will be displayed at the top of the screen, but they will not be added to the party. In this way, a player can tap-and-slide on one swordsman, then tap-and-slide on another swordsman. Each swordsman’s stats will be displayed in turn, and once the player makes their decision, they can perform a quick tap-and-release on that character to put them in the party.
This action would seem completely unintuitive, but the player implicitly learns how this works as the game progresses. Eventually, the player will have so many heroes that they will need to scroll through them. But the action of scrolling through heroes requires the player to tap-and-slide on a specific hero, because the scrolling area is the same as the hero selection area. When the player taps on a hero and then slides to scroll, they will subconsciously learn that this action works as a form of soft selection.
Difficulty Spikes and Scrolling
The game design supports this implicit design by pairing these two events together. In the beginning, the player does not need to worry about team compositions, because the content is easy enough that it doesn’t matter. Also, the player does not need to scroll through their heroes, because they don’t have enough heroes to scroll through. When the player needs to learn these things, they happen at the same time: the difficulty gets hard around the same time that the player has too many heroes to fit on a single page.
FEH’s main story has very few difficulty spikes, and is more of a smooth linear progression. The story takes place over chapters, each with five parts. I felt that the strongest difficulty spike in the early game was chapter 6-5, where the antagonist Ryoma locks one of your heroes in a room with him to fight one-on-one. If the player is unprepared, which would be natural since they are new, this can go very poorly. Ryoma uses a sword, so the player should put a lance wielder in the room against him because lances are strong against swords.
If the player fails, they will need to edit their party to put a lancer on their team. This could be the first time they’ve had to edit their team to overcome a challenge, rather than to train new units, and this is also the point when they have too many heroes.
The player starts with 6 heroes, and gain about 50 orbs through the point when they reach chapter 6-5. 50 orbs gets you 12 heroes (there are shenanigans which could reduce this number, but new players are probably pulling every color anyway). Every day, there is a rotating special map which allows the player to gain 2 copies of a character if they win two battles, one on easy and one on hard. Assuming the player has done everything, they will have 20 heroes. If they have played for two days and done everything, they will have 22.
On my phone, the hero selection screen starts to scroll at 20 heroes. However, there is also the undo button, which takes up a spot for a hero. If the player has exactly 20 heroes, they will need to scroll to view their last one. When the player scrolls, thinking of how to beat Ryoma, they will gain a very small, practically imperceptible understanding of how the tap-and-slide gesture enables soft selection.
This could very well be a coincidence, because on some phones with different aspect ratios, the screen starts to scroll at 25 heroes instead. Additionally, there are other ways in which the player’s 50 orbs may not have resulted in 12 heroes (maybe they sniped for a certain color, or they upgraded their castle). If this interaction between chapter 6-5 and scrolling UI was a priority, the designers might have placed Ryoma’s battle later in the story after the player has collected more orbs, or placed more units in the player’s starting barracks so they were guaranteed to have a scrolling UI at this moment. The Ryoma battle/scrolling UI interaction may have been sheer dumb luck, or it may have been decided to be less of a priority when considering the rest of the gameplay experience.
And with every new update, this interaction changes ever so slightly. Now that players can rearrange their party members before a battle starts, it’s much easier to prepare for a battle, so the player might not even lose to 6-5. Players have been asking for this feature for so long, and they think that it is just purely a quality-of-life change. But what if it makes 6-5 too easy, so players never learn the tap-and-slide gesture, and they become frustrated with the team UI further down the road? It’s unlikely, but it’s possible. Game design decisions tend to have much deeper implications than players are aware of: even when they think they are asking for something perfectly reasonable, they might not be aware of how these changes could alter their experience.
Although this tiny moment would be insignificant by itself, as the player progresses, experiencing more difficult content and collecting more heroes, they will continue to engage in the tap-and-slide motion to scroll and view their heroes. These actions become linked so that the player develops a subconscious connection between browsing their heroes and viewing their stats via soft selection. Eventually, the player does not even realize that they are using soft selection, but they do it naturally as they tackle difficult missions that force them to carefully consider their team compositions. In this way, the game design and the UI design synergize to solve a problem that exists on both fronts.