Kwalee

Case study

Platform Mobile

Role UI Artist

Timeframe 5 Day Task

Disclaimer: This speculative project was undertaken as a case study of Kwalee, a game studio known for producing and publishing mobile games. Specifically the test served as a proposed UI overhaul for an existing game “Dream Build Solitaire”. The work produced was created for practice and as a test of software and creativity. This case study showcases work produced in Photoshop and Unity.

Task 1: UI Mock Up

Task 1 served as a form of art style comparison, which tested how well I could use an example wireframe of a daily reward system pop-up to create all necessary UI assets for the screen from scratch. The goal of the task was to see how well I could match the existing design style of the game when creating a brand new screen state.

Research begun with an analysis of the current version of the game, in which I sourced reference images of iconography and screen states to break down the core design rules artists at the company used.

Below you will see the original wireframe and reference images taken directly from Dream Build Solitaire.

Wireframe for the daily reward system - provided by the team at Kwalee.

Screenshots taken directly from “Dream Build Solitaire”

With reference images sourced, I started creating individual elements using the pen tool in photoshop. I did this by creating a base shape then mask compressing highlights and shadows drawn on separate layers, this allowed me to come back and make changes . Most of the UI Assets were simple to recreate this way; certain assets did require subtle gradients, and others required drop-shadows in order to assist the illusion of a slight 3D perspective. Upon completion of polish and touch-ups I converted all UI elements into smart objects.

Below you will see the proposal for a new clean and legible layout, as well as a display of layer hierarchy.

Reflection

I was pleased with the outcome of this task, it had been a few projects since I last used photoshop, and I was happy to return to the software and produce what I believe to be an accurate creation of a daily rewards system page in the same style Dream Build Solitaire uses. If I spent more time on this task there are a few changes I would make, although the style is simple I believe the original art style has small elements of detail which could be added to this mock up; additionally, I would have liked to play around with the idea of making the page tabs on the left the same colour as the claim buttons to create a more universal affordance that anything light blue is interactable, at least for this UI screen. Looking back on the reference images, it does seem like the whole app primarily uses light green buttons, although there are exceptions for social media buttons and the occasional blue button is used, which could have been utilised more in this proof of concept.

Task 2: UI Retheming

Task 2 was more a test of creativity, as well as a way to assess how well I could move between styles. The task itself was to retheme the pop up for a “pre level boosters” screen. The new theme was based around the idea of ‘Cursed Ruins’; additionally the style had to change to be different from what is already in the game style.

Below you will find the reference for the “pre level boosters” screen used in game:

“Pre level boosters” screen found in Dream Build Solitaire

I started the task by generating and sketching up some ideas for what the iconography and overall design could look like. These key elements would help shape the overall atmosphere of the screen. My thinking behind this task was to break down what a “cursed ruin” theme could be. If someone thinks of ruins they typically think of ancient Greek, Roman or Egyptian ruins, however I ruled these options out. Most are overused, however, my main thinking behind this was a concern about what they represent and how well they could be interrupted as “cursed”. Greek and Roman ruins, for me, are awe inspiring and artistic. Roman mosaics and Greek statues don’t speak to me as signs of a cursed landscape, but instead as a testament to societies that once thrived. Egyptian ruins spoke more to me, as there are plenty of pop-cultural references to Egyptian curses, haunted tombs and disturbed burial grounds. However, I settled on researching Aztec ruins due to the culture that society once had, beliefs around sacrifice, and the atmosphere they hold.

I then broke down what “cursed” would feel like and what it represents. Many people associate cursed with magical or ancient, which both felt relevant to this task. Abandoned settings can also feel cursed as if they have been left untouched for a reason. I therefore started drawing up ideas for what some of these UI elements could look like with a theme concerning abandoned Aztec ruins.

Below you will find some examples of my initial sketches as well as a test for a base-line colour palette.

Initial sketches I produced in Photoshop.

With the research and sketches completed I had a good idea for how the final design would turn out, and I then got to work creating these assets in Unity. In regards to style I thought I could build on the style the game has. I believe for the target audience a simple style is essential, however I made changes outside of a colour scheme. When creating the assets I set up rules that outlines would not be used, buttons would all use gradients and one colour style to help with affordances, and finally if detail can be added in anywhere without clustering the UI screen or pushing too far from a simple three-tone design, then it should.

Below you will see the final proposal I made for this task. Many changes and tweaks were made before it could get to this point, mostly through changing the colour scheme instead of the overarching shape or design.

Reflection

Overall I was very pleased with the outcome of this project, I believe it fits the theme that was outlined in the task well. I do believe improvements could be made, particularly regarding the colour scheme used for interactive UI elements; there were a handful of iterations regarding this and in comparison to earlier stages I do believe this version succeeded at drawing attention to what could be interacted with, however some further advancements could take this mock-up further. Additionally, although the style has many elements that were different to the style used in game, I believe the whole screen’s style could have had been pushed further to make it more distinct. I wanted to keep the scene colourful, due to the target audience of the app, but on reflection a darker theme could have fit better with the atmosphere of the game, which in retrospect would potentially be marketed at a new audience altogether. Either way I was pleased with the outcome produced.

Task 3: Implementation & Animation

The final task was more-so a test of knowledge with Unity. For this task I had to recreate the assets for a Settings page, implement the assets in Unity, organise the hierarchy, and use RectTransform to allow responsive design. Once this was completed I then moved on to animating button states, as well as adding subtle particle effects to help make the scene feel more alive when users interacted with it.

Below you will find the reference for the “Settings” screen used in game:

“Settings” screen found in Dream Build Solitaire

Once the assets were set up in Unity with RectTransform, I moved on to creating four stages for each button in scene:

  1. Idle Animation - where the buttons slowly and subtly grow in scale and the colour slightly changes.

  2. Click Animation - where the button scale quickly shrinks and returns to normal when clicked.

  3. Hover Animation - where the button scale quickly grows to when hovered over.

  4. Disabled - where the button can appear to be disabled if toggled

These four animations were applied to every interactable button in the scene. There are instances where changes had to be made, for instance when you click on the “close” or “quit” button, the pop-up menu disappears. This followed a slightly different approach to animating as I did have to write a small script to make this happen.

After the animations were made I also added particle systems to both sides of the screen. These were not intended to draw attention away from the main UI, hence why they were positioned in dead space. Finally I added a “shimmer” animation to the title card of the screen, this helped provide feedback to the user that the screen was responsive to help dismiss any notion that the screen was frozen.

Below you will find a quick one minute screen recording which shows off hierarchy, animations, the animator, which assets were implemented, and how the scene plays:

Reflection

I was happy with the end result for this task. The last time I used Unity was for terrain painting 3D models across a landscape, so I didn’t have a lot of up-to-date knowledge for UI Implementation which required some re-education. With that being considered I was happy to meet the requirements of the task, and I believe that although this type of screen typically would have minimal animations, the ones created do demonstrate the type of animations I could produce. On reflection there are areas of improvement, for instance I believe the hover animation could be tweaked to stay idlily hovering as long as the mouse remains on the button, this is Definity something I would implement going forward.

In summary, I am happy with all three tasks and the outcomes produced, especially in a tight deadline of five days outside of work hours. I was able to brush up on old skills, create new ones, and I truly believed I met the brief on all accounts, producing quality game ready assets.