What goes into an Inventory
Hello, my name is Jacob, and I’m going to talk a bit about user experience in our upcoming game, City of Fragments.
City of Fragments, like a lot of role-playing games, has a lot database information being tracked behind the scenes. Character stats, story progress and inventory items are all examples of information stored in data structures. Choosing just how that information is expressed to the player is important, and I strive to make it engaging. The user interface also needs to prioritize the most relevant information for player at any given moment. The Inventory screen (shown in the video above) provided an interesting design challenge: inventory management is one of the more complex aspects of our game, and I needed to find a way to express that information in a manner that was easy to understand, and easy to interface with. Ideally, it should look pretty cool too.
Having an attractive interface goes a long way into getting a player’s attention, but it’s also really important to make sure there’s a sense of consistency in all the game’s elements. In City of Fragments there are couple of design pillars I adhere to when creating new elements for the game:
A hand-drawn, comic book inspired aesthetic - punchy line art, vibrant colors, handwritten fonts and a visual style that’s easily associated with City of Fragments. Whenever I draw something new for the game, I make sure it looks like it belongs with everything that came before it.
Accessible, clearly indicated functions - make sure the player knows when they need to provide input, and what that input will do. I want players to spend time thinking of what they want to do, not how to do it.
Maintaining visual hierarchy - keeping important information where it’s easiest to access, and dynamically altering that hierarchy as the moment-to-moment situation demands. If there’s a prompt visible to the player, it had better be relevant to what they are doing.
There are a lot of ways to create a visual hierarchy in images, usually by contrasting the size, s h a p e , color or style of individual elements. Obviously
Arranged in a Row
I’ve designed the interface to scale with the number of characters in the player’s control. Depending on where the player finds themselves in the game, they will be controlling between 1 and 4 characters, each with their own inventory. The interface needs to read well within that range. I also wanted to limit the number of player inputs required to interact with the inventory. It’s already fairly complex, I didn’t want to turn it into a jumble of sub-menus for the player to get lost in. With that in mind, I had to answer a few questions:
How many characters are there, and which ones are they? I’ve got them shown in portraits tiled horizontally across the top of the screen. Using the same bright red as the rest of UI for their backdrops, and using high-contrast art to grab the player’s attention. They should be the first thing a player sees (highest in hierarchy).
What items are each of the characters using? I created a descending ladder of icons attached to each of the portraits, where a series of 4 labelled hexagons indicate the type of item (in text) and provide a picture the equipped item (if any). They are dark enough to contrast the backdrop, but the overall grey coloring keeps them from overpowering the portraits they’re attached to (second in hierarchy).
How does the player interact? The keyboard (or gamepad) bindings are indicated at the bottom left and right of the screen, and grouped by function. Control bindings that deal with inventory itself are grouped on the left hand side, whereas the controls listed on the right take the player away from the inventory screen. Most (Western) players will read left-to-right, top-to-bottom, and while these functions stand out and are easily read against the backdrop, they will likely be noticed after the portraits and item slots (third in hierarchy).
What elements are interact-able? I’ve used a simple highlight on both the item images and the associated label to draw attention to the active elements of the interface. Additionally, when there is an item in the selected slot, a brief summary of that item’s properties is also written out alongside its image. The selected slot, while highlighted, still only occupies a single hexagon of many. Even with a single character, that’s 1 of 4 hexagons highlighted. Without player input, it’s likely to be the last item read - however, as soon as the player begins interacted, the highlighted hexagon changes in coordination with their input, and the sudden movement and contrast bounce it up to first in visual hierarchy.
Room for More
Of course, everything changes once the player chooses to equip one of their items to the selected slot. At this point, an entirely different set of information is needed, and new design problems are presented. I needed to pull a list of items suitable the the selected category from our item database and present them to the player.
I opted to slide all unnecessary information off the screen to the left, slide the new information in from the right - and slightly re-position the portrait of the character being managed. Also, I change their portrait art to a picture of them rooting through their bags / luggage space to reinforce the idea of the player rooting through their extra items.
The key-binding control prompts at the bottom of the screen also change to reflect the new ways the player can interface with the inventory.
The portrait and key-bindings aren’t the focus at this point however, and fall into secondary consideration (and hierarchy). The new focus is the list of available items that pops up on the right side of the screen.
I keep at my second design pillar here (keeping things clear and accessible), and I avoid as best I can just having a wall of text for each item. I use large drawings for each of the items, a large block-font for their names, pictographs that tie them into existing game systems and a layout that divides the information up into image, description, and quantity. The active item is also highlighted.
The final piece of the puzzle, is keeping everything responsive. When the player presses a button, something happens immediately. Players can button mash and make as many inputs as they’d like, and the interface will keep up.
Packing it up
Games are complicated, and making them is hard. Still, an inventory system isn’t anything new. In fact, they’ve appeared in so many games over the years, and in so many forms, it’s often easy to just take them for granted. This write up started with a 20 second video of my inventory system in action. It runs smoothly, has a consistent art style and a clean presentation - but none of those things just happen on their own. There’s consideration that goes into every step, and often a lot of iteration as well.
Even though all of a game is essentially User Experience at work, the Interface in particular can often make or break things. It’s about minimizing the barrier to entry and letting players do the things they want to do, without stumbling over the how. Much like a good reading font, solid UI design should largely fall to the background of the player’s notice. Without an in-depth look at the elements in the UI (such as the one I’ve written here), a player likely won’t give it much thought - so long as it’s doing what it was designed to do.