Trine 4 is a 2.5D side scrolling, physics based game of action, puzzles and platforming with light RPG elements where the player plays as one of Three Heroes, each with unique skills, who make their way through dangers untold in a fantastical fairytale world. It has a distinct and colorful art style and supports up to 4 player co-op both off and online. It was published on PC, PlayStation 4, XBox One, and Nintendo Switch.
UI pipeline upgrade
For Trine 4 the UI artist and I were tasked to make the UI creation process more efficient. We’d worked together already in Nine Parchments and took our learnings with us to this project. As we joined the project early on, we had the opportunity to truly shake things up.
Style guide
Keywords: Style guide, atomic design, UI design, interaction design, accessibility
In past projects at Frozenbyte, UIs were designed as static images and passed onto the programmers. Each was treated as a separate feature and documented and programmed as such. This was also done toward the very end of the production cycle in an ad hoc manner requiring multiple rounds of iteration and causing stress for the designers, artists, and programmers involved.
To solve this issue and to build on the learnings we had during the development of Nine Parchments, I designed a style guide to house all important information on UI elements, with input from the UI artist. This included information such as which colors to use where and how the UI elements should behave and look like in different states. While this guide was mostly decoupled from the technical implementation of the UI, we did include some things, such as a technical documentation of the color system, to help bridge the gap between the guide and implementation.
The guide helped in multiple ways in UI creation. The designers and artists knew what UI elements they had at their disposal – or if they didn’t, they knew to document them – and they only had to document non-constant things, such as sizes etc., of the UI elements for each screen instead of all of the functionality.
The programmers not only knew all the edge cases and other not-so-obvious functions they needed to take into account for any given UI element, but this also helped them design the software architecture of the UI.
This helped streamline the UI design and creation process significantly, by improving communication and shared understanding. This also had the added benefit of improving the accessibility of our games as the UI was more accessible by default as the accessibility features needed to be defined only once for each UI element.
User flows and prototypes
Keywords: UI design, interaction design, user flow mapping, prototyping, accessibility, feature design, user research, expert evaluations, facilitation/communication, leadership
User flows and low-fidelity prototype
As I was involved in the process from the beginning, we started out with wireframes and added UI art to them afterwards. Since we defined each UI elements in the style guide, making the high fidelity mockups of the UI screens was a very straight forward process.
To further improve the process and communication, I created user flows with Adobe XD using the wireframes. This way we had both a place with all the screens as well as an interactive low-fidelity prototype of the entire menu system up very quickly. This helped in communication within the entire development team as we could quickly look up any menu screen and how it was navigated.
Level select menu
One menu required more work, however. The menu selection menu was causing issues for the team initially. In Trine and Trine 2 the menu was just a list, but in Trine 3 – the first game to be in 3D instead of 2.5D – the menu selection was a literal map on a desk the player could run around on. The team wanted something similar, but could not get it to work comfortably. They wanted it to work like the game would – meaning the player could only navigate left or right as they would in the game itself, rather than any direction as they could on an actual map.
When I joined the conversation, the idea of a map was all but abandoned, but I convinced the team to let me take a crack at it. We could not find a shared understanding of it on a whiteboard, so I took to Axure 8 to make an interactive prototype.
By using a mix of concept art made for Trine 4, art from the previous games made by the studio, and temp art, I made a full interactive prototype of the entire menu. After a few alterations, the team was very happy with the prototype and it was implemented almost as is in the game.
The interactive prototype not only helped the design team to lock the functionality of the menu down quickly, it also helped minimize iterations on the implementation as the programmers could refer to the prototype to see the intended functionality of it.
Results
Thanks to these new additions, the efforts in UI creation were frontloaded to design and art and the programmers could implement the menus quickly and confidently with minimal need for iteration. Everyone involved in the UI creation process reported much less stress than in previous projects. The UI creation process was reduced by more than half from approximately 36 man months for Nine Parchments to around 16 man months for Trine 4.
Hear more about the prototypes in the talk I gave at Game UX Summit ‘19.
Expert reviews and accessibility
Keywords: accessibility, feature design, expert evaluations, facilitation/communication, leadership
Everyone on the game team played the game and gave feedback on it. I formalized my approach to this and gave holistic feedback on the overall user experience of the entire game based on my expertise in psychology and Human Computer Interaction.
I also talked to the rendering programmer and together we created some rudimentary filters so anyone could see how the game would look like to someone with color blindness (deuteranopia, protanopia, tritanopia, and monochromatism). I played through the entire game with the monochromatism filter (aka in black and white) and identified multiple cases where key gameplay elements blended to the background and were changed to stand out more.
While this was not a perfect solution, it was a big step forward in the studio’s accessibility efforts.
User research
Keywords: user research, facilitation/communication, leadership
Traditionally user research in the studio focused on ad hoc playtests at the end of the production cycle, when the game looked and felt pretty much like the final game would. The support team would recruit playtesters and moderate the session. The session would include a short introduction, after which the player would play as long as they wanted or had time for, and the entire session would be closed with a short exit interview. The entire session was video recorded and live-streamed so that the designers of the game could go over the material and identify any improvement ideas for the game.
As the designers were very busy, especially toward the end of the production cycle, a lot of the material was never reviewed and thus the research effort wasted.
Together with the playtest moderators, I created a system for them to log notes on the sessions so the designers could get the most glaring issues raised to them quickly. The more the moderators ran tests, the better they could identify potential issues the players encountered.
While this worked and the team felt the research was more effective, it also had unintended consequences. The moderators were not given any guidance by the team on what to look for, so they went on gut instinct, logging issues they guessed were useful as well as very glaring issues (e.g. player falling through the floor). This meant that a lot of potential issues were not logged at all. But as some issues were logged, the designers lost what little urgency they felt about watching the footage themselves.
While the solution wasn’t ideal, it was a step in the right direction, and the work was continued in future game projects.