iOS Game : Menu UI / UX
September 16th, 2014I’ve been working with a loose deadline of around late october release, so with that in mind I’ve also had to make some tough choices about the viability of some of my design choices.
I’ve been working to refine the visual style for the actual gameplay to the UI. I’ve also explored different avenues for progression, and by extension, menu functionality. In my last post I showed some concept work on the new menu visual style as well as the node based upgrade system.
Here’s the image of the full PSD as I worked to map out how sprawling the node system would be and help figure out just how many icons I would need to create. I also created all iterations of the elements I would need to build the node network.
As you can see, it’s actually a fairly substantial network of nodes. I really love upgrade tree’s and interconnected node systems but after looking at this I started to have genuine concerns about the amount of time it would take to create quality icons that accurately represented not just an individual element that was to be upgraded but the progression variants as well all while being readable on a small scale. I’m only one person and this would eat a large chunk of time out of my schedule, not to mention having to build out the interconnected node system functionality in Unity.
I was also concerned about the usability of this on the iPhone. Perhaps with the ability to zoom in and out and see the entire tree, people would understand what they were looking at and how everything connected. I built some tests in Unity to see how they played on the phone. You can see it in action in the video below.
I added a slight angle and 3D depth to each node to create parallax movement as you scroll around. This helped to give the illusion that the icons were more 3D than they really were. The 3D angle was something I had wanted to experiment with as some of my early sketches were based off the idea of a 3D space where the upgrade icons would be connected to their corresponding part on the ship.
The info box was also put in to play around with having context boxes show up when a node is clicked to give you all the pertinent information about purchasing that upgrade as well as the actual purchase button.
Designing a usable interface for phones and touch screens poses some interesting and somewhat unique problems over say a computer with cursor input. There are no “hover” states that can be used to have contextual information shown. Some examples of contextual information being a simple highlight of a button as you roll your cursor over it. Something as small as that can indicate that an element is a clickable object over just a background decoration. On a phone, you only have the moment of touch /click. Anything clickable needs to visually communicate that it is an interactable element that can be clicked on, just from its presentation on the screen.
The lack of a hover option meant that having a node grid alone was not enough information for a user to know what they should be “purchasing” or even if they wanted to “purchase” a particular upgrade. They needed information on the cost as well as what the upgrade actually did. This meant that the menu couldn’t be just a simple grid of icons where users would simply tap an icon to upgrade. There had to be an intermediary step between clicking an icon and purchasing the upgrade, which is where the modal box came in. The user would tap an icon, then have an information box show up giving them all the information they needed as well as a way to purchase the upgrade and finally a way to close the modal whether they purchased the upgrade or not. Figuring out each of these individual steps was important in understanding the functionality and user flow of the upgrade node system.
Seeing as there would be so many steps between the user finding the desired upgrade and being able to purchase said upgrade, the node grid itself needed to convey as much information as possible without relying on the modal. The grid itself needed to convey which upgrades the user already had, which upgrades were available to them, and what upgrades were unavailable. The grid also needed to convey the relationship between each upgrade and how they could unlock the upgrades they may want.
I created a visual language for both the nodes and connections to help convey all this information.
After all of this exploration, through visual design and functional tests, I re-evaluated the node system. I played a bit with my older system on my phone a bit, that just had 5 simple upgrade buttons that would increment the level of the upgrade. It was simple, fast, and easy to use. The problem that the current scroll system had that the node system was fixing, was the granularity of upgrades. In the simple system upgrading, say, the missiles with one button would affect multiple aspects of the missile without the user knowing it, such as firing more missiles at once as well as making the explosions bigger. The simple system also did not appear to have a cap and could thus be upgraded indefinitely.
Looking at the two different solutions I decided to merge the two solutions. The linear vertical scrolling system worked well for communicating similar information as well as being easy to use and understand. I decided to break the upgrading down into more top level upgrades. Instead of a single upgrade for each level of stat, there would be a top level upgrade that could be upgraded multiple times but have a visible cap as well.
This system uses a similar visual style while making all the information easier to find and simpler to use. The only issue is that with the expanded upgrades came an increased scroll length. My solution to this was found along with a way to unify the menu system as a whole. A way to navigate to the map / level selection screen as well as access any options.
There is less scrolling and when in the upgrades you can swipe left or right to get to the other upgrades as well as tap the nav tabs.
It’s not complete and I still need to make non-FPO icons but in terms of usability as well as viability, I believe I am on the right path.