Designing UI For Hybrid Genre Games

www.gamesfoundry.com

When we first sat down to design the UI, we gave a lot of consideration to the types of players that would be experiencing Folk Tale, and the information needs each of their play-styles has. Combining the genres of city building, real-time strategy, and RPG, there was a risk of information overload and failing to deliver a positive gaming experience. Players gravitating towards the action found in the RTS aspects of the game might be put off by the depth of information a strategy-biased city-builder player might be accustomed, or the level of character detail and customization enjoyed by the RPG player. We set about analyzing the aspects of game play from each genre that would feature in Folk Tale, thought patterns players would have during decision making, and key data and functionality required to reach and execute those decisions before categorising everything into tiers. 

Starting Simple, Iterating, and Ramping Up At The End

Being acutely aware that games attempting to span multiple genres sometimes strive to achieve too much, development of Folk Tale is deliberately an iterative process. Features are added and removed on the premise of natural fit, or dropped entirely if time pressures mean they are unrealistic to implement. An example that springs to mind was whether or not loot would fly out of corpses as 3D objects ( diegetic ), or if the player would loot by opening an inventory comprising of icons ( non-diegetic ). The UI demands of each implementation are very different, and regularly shifting design goals present a challenge for interface design tasks running in parallel. Rather than invest time in painting pretty UI early on, we adopted a simple vector-shape based approach to block out UI. Not only did this enable us to get any early feel for how much screen real-estate would be occupied, it allowed us to quickly test the flow of interaction. One of the early prototypes featured a "bottom heavy" design, occupying the entire lower section of the screen. We soon realized this was too clunky with a lot of wasted space. The decision to throw it out was made easier by the limited time spent on the layout.

Commercial Reality

As it turns out, decisions affecting other areas of development were causing anticipated slippage and resulted in a commercial decision for demo that the loot system would be non-diegetic, thereby reducing the burden on the 3D art team who's time was required elsewhere. The decision coincided with Jen joining the team as concept artist, and she kindly agreed to hand paint a consistent set of icons for loot and skills before resuming normal duties post Kickstarter.

Icon Design

Layered Icon Workflow

With iteration and change inherent in our development methodology, Jen and I designed a layer based production approach to icons, separating out background ( typically a gradient fill ), background fx ( swirls, magic sparkles, smoke ), mid-ground icon and halo, foreground fx, highlight and rim light. This would allow easy re-coloring should it be later required. To support re-framing, Jen would also paint complete objects rather than taking the shortcut of painting only the visible parts of a fixed composition. And finally it made sense to work at a higher resolution and resize down to the final icon size ( a consistent 47x47 pixels used in all UI windows ) to future proof for devices with ever increasing display resolutions such as iPad 3 and 4. 

Designing For Accessibility

Learning from web accessibility initiatives, there are a number of simple things we added during interface design to help improve accessibility. Simple things like providing a pause button and subtitles during cut scenes, and allowing players to experience play at their own pace and difficulty can increase satisfaction instead of contributing to frustration. Gaming has it's own set of accessibility requirements beyond those of the web, such as keyboard remapping and mouse inversion to help left-handed Gamers. While budget may prevent us from doing all that we can especially for demo, accessibility certainly factors in every design decision.

Painting The UI

With the important decisions made and the feature set frozen for beta, we were able to commit to the final paint over. With a tight budget prior to our Kickstarter campaign, we aren't able to add all the functionality we have planned for the final UI ( such as customization ), but hopefully we've added enough to effectively communicate what you can expect in the final release.

Spacial Elements And Data Tiers

With so many data generators existing in the game world ( characters, buildings, natural resources, interactable objects ), an early part of the design process involves looking at use-case scenarios to identify data and functionality the player needs to support decision making and execution. Where data is required from an object, data generators are assigned as spacial elements on demand, projecting their data from the 3D game world onto a 2D UI plane that sits beneath the main UI, and only for the duration they are within the camera frustum and within range. The moment a spacial element leaves the camera frustum or goes beyond a distance threshold, the element is recycled in a UI object pool.

Consider a zoomed out panorama that takes in most of the village. It represents a macro view of world events where the player is most likely occupied with big decisions such as town planning or the movement of groups of characters. Taking the latter as our use-case, if the player is moving a group of characters from one location to another, they aren't interested in the detail of each character. We can discard irrelevant data and functionality such as character attributes, names, and access to individual characters skills. In fact, the use-case simply requires that we communicate which units are selected. We can still communicate valuable information in a condensed space for other use-cases ( for example if this was a combat manoeuvre ), so each character receives a mini-status icon above their heads showing the characters health and power, and in some situations an icon showing what that character is up to if it is something important. It's better to provide the player with a visual cue with shape and color than to display text indicators. So for wounded characters, the health bar should change to red instead of green instead of showing "13/50".

Advancing the game a little, the player issues a group move command, and then decides they want one of the characters to split from the group and go somewhere to be trained in a profession. The use-case changes, requiring more UI to execute the decision. Have I selected the right character? Are they a peasant without an occupation? Are they busy doing something of value and should not be interrupted? Do I need to take corrective action before sending this character for training, such as healing them? These are all potential thought patterns that occur within milliseconds, and our goal is to make sure the data required to answer those questions is immediately available, and unpolluted by anything irrelevant. We still show the mini-status bars to indicate which character is selected, but the more detailed action bar for the character pops up showing a zoomed in portrait for visual confirmation that the correct player was selected, name, level, key skills and commands. We haven't overwhelmed the player with data such as character attributes or inventory, because it would be irrelevant to the use-case. Tiering data in this way allows us to quickly match information to use cases.

I hope you've found this blog an interesting insight into the thinking and workflow that has gone into designing the Folk Tale interface.  If you have any questions or comments, I'll be happy to answer them below or on our Facebook page.

Beta Signup and Monthly Newsletter

To keep informed with our progress and upcoming Kickstarter campaign, you might like to consider applying for beta and opting in to receive the monthly email newsletter.