Avowed - UX Conversation System and Subtitle
Back in the beginning of 2021, Avowed was revisiting its Conversation System and Subtitle for the game and I had a chance to design out the whole feature all together.
UX - Conversation System and Subtitle
Avowed - First Person Action RPG
Team
Conversation Strike Team consisted of:
Game Director
Lead Narrative Designer
Gameplay Programmer
UI Programmer
UI Artist (myself)
Issues
Under the new direction, Avowed is now a game with less focus on gameplay and more on character interaction/development, so their old Conversation Response Layout no longer serves their best interest (see below for the screenshot of the old layout).
I identified the problems as:
Their old Diamond Button Layout is hard to read for players since their eyes have to search for the beginning of the text = Slower reading speed.
The layout gets visually inconsistent when it has fewer than 4 options.
The button layout feels unnatural on the keyboard.
Face button input has less need since we are focusing more on conversation engagement (fast button input is not required).
Diamond Button Layout is technically hard to adjust for multi-lines or enlarged text in UE4.
The subtitle has the speaker's name and their dialogue in the same white color which makes it hard to distinguish each.
Old Layout: Diamond Button Layout was hard to read each Player Response Options.
Old Layout: It visually gets less consistent when it displays less than 4 Player Response Options.
“How can we make a conversation system that feels natural and engaging where players feel they are making an impact on the game?”
Goals
To have an intuitive, easy-to-follow Conversation System, both for Xbox and PC platforms.
Coming up with a layout that is more versatile with the number of Player Response Options (2 ~ 4 or more options, requested by the director).
Identify the character limits and maximum number for Player Response Options where the player feels they are making an impact on the game without sacrificing too much screen space.
Account for “the worst case scenario” where localization and large text size can still be applied and don’t distort layout and functionality.
Make it Accessible.
Research
To start off, I started looking at how other competitive titles are handling their Conversation System and the pros and cons of their layout. Since I already knew our Player Response Options were going to account for more than 4 options at times for Avowed, this helped me to narrow down our layout options.
Also, it was important for me to stick with ‘what’s already invented’ rather than ‘re-inventing the new wheel’ to avoid any potential friction for the players. Conversations will be the main focus for Avowed, and this is to ensure that players can go in-and-out of the conversations in a stress-free environment.
During the competitor research, the Microsoft UR Team helped me tremendously by providing their Competitor Analysis Reports and Survey Results where I was able to refer back and make data-driven decisions on the maximum number of Player Response Options and character limits.
Solutions
Groundwork: After the research phase, I went to my sketchbook and post-it notes for a quick idea gathering. This process helps me to reorganize my thoughts and come up with what I need to include in my mockups before I go digital. I also created a quick user flow that I shared with my team early on and iterated upon feedback. It is less pretty, but post-it notes and erasable colored pens (I use Frixion pens from Pilot) allowed me to quickly rearrange the flow and adjust it on the go.
Layouts: I came up with a couple of layout options that both could achieve our primary goals, but have slightly different characteristics when it comes to the layout aesthetic and character limits for each option (ie. Side List Layout allows to stack up more options, but it can easily go double lines where Center List Layout can still have it one line). I shared this with the team and after going through a couple of iterations, we decided to go further with Side List Layout since it doesn’t block the center character, and the eyes flow naturally with the Western reading system (left to right).
Layout 1: Side List Layout
Layout 2: Center List Layout
Defining the Details: Once the layout is determined, it is time to fill in the details. I reorganized my Figma mockups and added more variations to cover most of the cases for Side List Layout, including character limit, how to accommodate different font sizes and localization. This was also a time for me to figure out what kind of information I wanted to handoff to engineering, such as…
Player Response box should be 190px above the bottom of the screen to avoid overlapping with subtitles, especially in XL size.
Player Response box should be anchored to the bottom, then grow taller towards the top to accommodate more options.
Player Response box's width is 660px, but the font size and how many lines will determine the height.
We can predict a use case of a scroll bar (more info below). For this case, when font size is larger than Large, and options are more than 5 in double lines, it is likely to appear.
Scroll bar: To avoid covering too much of the screen, we determined 520px max height for the Player Response box. Anything taller than this will accompany a scroll box. In general, it would be best if we don't show the scroll box as a default option, but in the case of a larger font or localization, we will still have a system to support it.
Truncated/Expandable Options: Similarly, in the case of text bleeding into the third line, especially in different languages, we have a way to support them. Truncated/Expandable Options will show only 2 lines of text with "..." at the end. Once it's hovered/selected, it expands to show the whole text. If you hover away from the selection, it goes back to the truncated double-line option. With the sample text that I used (50-54 characters in English), the truncation should only happen in other languages such as German, in XL-sized font. So it is likely to be used for only rare occasions, but it is important to have the system in place.
Subtitles: After talking to the Lead Narrative Designer, our new character limit for Subtitles is 100 characters max for NPC dialogues and 20 characters max for speaker/character name (space and double colon included). So in total, it became a 120-character limit for Subtitles in English. This impacted our sample text in German, so I widened the default text box max to be 1200px wide in Normal text, up to 170 character limit to be safe so that it will stay in 2 lines maximum.
Also to broaden the accessibility, I suggested Player Assignable Colors for Speaker Names per their types and Subtitle itself. This is to further customize the game to the Player’s preference, and they can choose from 6 preset colors.
The text backer opacity is also adjustable in the Settings menu to further customize the game. This could help the contrast of text and legibility (default is set to 80%).
Core Loop Flowchart
Conclusion
Through this process, I was able to complete a thorough competitor research with the great help of the Microsoft UR Team, came up with a solution that is intuitive and easy to follow which accommodates more player options, defined the design details and system that also accounts for various localization cases and accessibility. By completing this, I was confident that I minimized any potential major risk and it was ready for in-engine prototype implementation. One last missing step was User Testing after implementation, but Obsidian Entertainment decided to discontinue my employment before it happened, so unfortunately I could not be a part of the development any longer. Fortunately, I could see a glimpse of my work in their shipped version of Avowed, so I hope it went smoothly after my departure!