Type of Project:
UI/UX Redesign of the game Atlyss
UI/UX Redesign of the game Atlyss
Project Duration:
~1.5 months
~1.5 months
Tools Used:
- Adobe Photoshop (Creation of Assets, Drawing and Painting)
- Adobe Illustrator (Specific Vector Work)
- Figma (Sitemap, User Flow, Wireframing, UI Design, Prototyping)
- Adobe Photoshop (Creation of Assets, Drawing and Painting)
- Adobe Illustrator (Specific Vector Work)
- Figma (Sitemap, User Flow, Wireframing, UI Design, Prototyping)
Introduction
Atlyss is an indie action role-playing game developed by Kiseff and published under the name KisSoft. It's a game I particularly enjoy playing due to its fun and responsive combat mechanics, as well as its nostalgic aesthetics, which resemble an MMO from the 2000s.
Atlyss is an indie action role-playing game developed by Kiseff and published under the name KisSoft. It's a game I particularly enjoy playing due to its fun and responsive combat mechanics, as well as its nostalgic aesthetics, which resemble an MMO from the 2000s.
However, after playing a few sessions of it both alone and with friends, I noticed that a recurring struggle was interacting with the game's UI. While functional, its design is unintuitive, inconsistent, and often unclear. Some friends of mine would struggle to find commonly used menus, and certain UI elements that served completely different purposes looked too similar.
As a regular player of action RPGs, I felt this was a good opportunity to redesign the game's UI and propose a better, more intuitive approach to the user interface, while giving it a makeover with an aesthetically pleasing art style that fits the game's theme and direction.
Redesigning the UI for a whole game would be an enormous feat, one that is not viable in this case. Therefore, for this project, I prioritized the main screens related mostly to single-player gameplay. The title screen and other menus were left out.
Identifying Issues
The first steps I needed to take in this project were to list down the steps and tasks I needed to accomplish, create a schedule based on that, and, most importantly, identify the issues I wanted to address.
While I faced several issues during regular gameplay, I was not paying close attention to them nor writing them down. Therefore, I had a couple of gameplay sessions with the sole goal of observing UI issues and writing them down.
Here are a few of the issues I identified:
- Design Inconsistencies (multiple typefaces being used, buttons that look like other static elements, etc.)
- Lack of clarity and intuitiveness on how to use the HUD and access menus (lack of labels, prompts, and unintuitive designs).
- Critical elements are too close to the edges of the screen, far from the focal area of the gameplay (center of the screen).
- Unnecessary information cluttering the screen (we don't need to see how many items we have in our inventory at all times).
- Lack of clarity and intuitiveness on how to use the HUD and access menus (lack of labels, prompts, and unintuitive designs).
- Critical elements are too close to the edges of the screen, far from the focal area of the gameplay (center of the screen).
- Unnecessary information cluttering the screen (we don't need to see how many items we have in our inventory at all times).
Although I observed other issues that could use some improvement, I limited myself to these, which I judged to be of higher priority over the others.
NOTES MADE ON TOP OF ORIGINAL HUD.
Research and Design direction
Now that I had a clear goal in sight, I began researching. I gathered all the screenshots I took of the game's UI and saved references of interfaces from other games for inspiration.
I also decided to define a solid direction for the visual aesthetics of this project, taking inspiration from Celtic patterns, materials and architectures. Considering the fantastical and bucolic theme of the game, I thought this was a fitting choice.
Information Architecture
For me to have a clear idea of what screens needed to be designed, I started by creating a sitemap of the game. Then, to know what elements needed to be designed and how, the creation of a user flow was essential to understand all the steps players would take to complete tasks in the game's interface.
Atlyss's sitemap for this project
User Flow
The user flow was essential for me not only to understand how players would interact with the game's interface, but also the scope of the project and how much I would be able to tackle. Some of the screens laid out in the diagrams below were not designed as they were out of scope of this type of project, but the main ones were finalized.
Below is a compressed version of the full user flow, showing the main screens and interactions. I'll be breaking them down further in this case study.
Compressed view of this project's user flow.
Overall Taskflows
Below are the taskflows for most of the interactions players would have with the game's interface during gameplay. Compared to the inventory, these taskflows are simpler, involving fewer steps.
Inventory Taskflows
Inventory management and loot are core parts of action RPG games. Therefore, the taskflows for this system are much more involved, containing far more steps than the other interactions. Atlyss has 3 different types of items, all with slightly different flows.
OVERALL USER FLOW
Here's a full overview of this project's user flow. These are only the main tasks that players would be handling in-game. Some other tasks were left out for scope reasons.
Overview of the entire user flow for this project.
Exploration
With the information architecture figured out, I was ready to move on to some sketching. I started by wireframing on paper, exploring a few different layout ideas for the game's HUD and in-game menus.
I then moved on to Figma to create a low-fidelity wireframe based on the sketches I had done. Since a good chunk of the exploration had been done on paper, it was mostly a matter of translating it into a digital format.
Low-Fidelity Wireframe
Concept Art
I wanted to make a hand-painted UI for this game, meaning that I took some time to develop static concepts of the interface in Photoshop, where I painted most of the assets used in this project. Many of the icons used in this project were taken directly from the game's wiki page, but some new ones had to be created, and others were redone from scratch due to low resolution.
I started with perhaps the most important element of the HUD, which is the central piece where the player's skills, health, mana, experience, and quick slots are. My goal was to take some creative liberties and align the design more with the design direction I established, while also trying to keep it close to the original idea.
Rough concepts for HUD elements
Final concept for central HUD element
(The HP and MP text was created through the modification of the "Nightmare Hero" typeface).
(Skill icons taken from the game's wiki page)
For the central HUD element, I made some significant modifications to the original layout. For starters, I incorporated the quick slots that were originally on the bottom right corner of the screen to the top of the central bar, which should allow players to more easily see what items they have in the quick slots.
The other change I made was to move the level number right next to the experience bar to ensure natural mapping. While players could easily deduce that the number next to the health was representative of their level, the placement was odd. Placing it right next to the experience bar will ensure no confusion.
Finalized concept. Not all elements were polished as they were either a repetition of other assets already done or were going to be done in Figma.
Concepts for some menus. Final changes and details were done in Figma afterwards.
Asset Creation
Most of the assets were created during the concept stage. When approved (by me), I would export the separate parts that compose that UI element and bring them over to Figma to add the final touches and make them into interactable components.
New HUD icons created by me. Most of them were redesigned from scratch, except the money bag, which was redrawn in higher resolution.
Stats icons. Most of them were existing icons redrawn from scratch in a higher resolution. The axe icon was completely redesigned, and the shield and skull icons were designed by me from scratch.
UI Kit created in Figma to easily assemble UI elements and menus.
High-Fidelity Wireframe
At this point, I had all I needed to create the final designs, which were the rough layout done in the low-fidelity wireframe, the assets created during the concept stage, and the components built in Figma with those assets.
It got to the point where building and experimenting with designs in Figma was faster than Photoshop, rendering the concept stage officially concluded.
Attribute cards that appear when the player hovers the mouse over an item in their inventory.
Side-by-Side Comparison
Below is a comparison between the original UI of the game (Left) and the new, redesigned one (Right).
Takeaways
This project was quite the lengthy one, but a fantastic opportunity to learn more about UI/UX Design for games, especially for those with hand-painted assets and action RPGs. Going through a project like this makes it very clear which approaches work and which ones don't.
In this project, I have confirmed that starting by figuring out the information architecture of the game helps to determine the scope of the project, takes less effort than starting to design UI elements, and saves tons of time later on. This is not the first project that I started by figuring out a sitemap and a user flow before moving on to the visuals, yet it confirms this feeling I've been having.
In this project, I have confirmed that starting by figuring out the information architecture of the game helps to determine the scope of the project, takes less effort than starting to design UI elements, and saves tons of time later on. This is not the first project that I started by figuring out a sitemap and a user flow before moving on to the visuals, yet it confirms this feeling I've been having.
During the process of putting together the prototype, I had a version of the interface that was not good. To have an appealing slide effect in and out, I left two vertical frames at both edges of the screen. Those frames served absolutely no purpose other than making the animation look good, and during gameplay, it was subtracting from the player's experience. That's something I was able to confirm through A/B testing, where users claimed to feel claustrophobic with those frames and wanted to have more screen space dedicated to gameplay.
Therefore, I can safely say that the main takeaway from this project is that all elements on screen need to serve a clear purpose. If they're not serving any, you're better off without it.