top of page

Tactical Game

Guiding the player though

complex interfaces.

THE STARTING POINT

Tactical strategy games pose a challenge for both, designers as well as players. A multitude of possible interaction steps might overwhelm and distract from the one relevant piece of information you need to score in the game.

It's somehow discouraging, I'm afraid,

I'll pick the wrong action and mess up.

[Quote from early user testing]

In the initial stage of the prototype, game designers offered a multitude of available skills and actions to the player, all at the same time. Having no clear priority caused some extent of confusion among players.

THE SETUP

In order to create a suitable prototype in the later stages and also to being able to visually communicate with the developers from the very beginning, I created a fictive game-scene in Autodesk Maya. It was mainly shapes and silhouettes, briefly occlusion-rendered, but it was sufficient to use it as a basic setup for my further work here. 

game_3D.JPG
game_renderings.jpg

Next step, was to add a very rough interface overview, based on the current design, such as initially envisioned by the developers, with all the information, they planned to show on screen. This rudimentary information-blocking already illustrated the visual clutter and made the screen pretty overwhelming. So this became a good starting point for me, to negotiate the amount of information shown on screen simultaneously.

overall_GUI.jpg

Then I sat with the designers and made a first take on prioritizing the skills and actions - at least from developer's perspective.

cmd_prio-list.jpg

WHAT DO THE PLAYERS THINK?

For this project, we aimed for two personas, one on "brand expert" level and the other one on "genre expert" level, because - apart from the fact that we saw them as our main user group, we believed that we could learn the most from those two complementary user behaviors. We conducted surveys to access demographic data and ran semi-structured interviews to access more personal, qualitative information for our personas.

(The persona sheets below deliberately do not show faces here, but for actual development, we of course had them included.)

cmd_personas.jpg

The next step was to gather some actual user data to find out, what priorities our actual users have and compare that with our own expectations.

cmd_charts.jpg

Core UX User Requests

Gameplay User Requests

Data was sampled from 16 people within the target user group

THE CONTEXTUAL APPROACH

Based on the user expectations in terms of player experience and the designers envisioned gameplay, I defined a set of UX goals for the upcoming iterations of the interface:

1. Display specific information when the player needs them.

(This way, we can avoid clutter and don't overwhelm the player.)

2. Make use of information hierarchy to determine what exactly the player needs to know in each interaction step in order to perform the actions as well as possible.

3. Guide the player through the interaction process by visually available functions.

 

 

 

 

 

The next step was to apply those principles to the three game-modes that players can access and switch between seamlessly during gameplay. The difficulty here, was to find out, which pieces of information were relevant in which step, as well as to decide, which ones needed to be shown on screen permanently and which ones should be context sensitive.

game_userjourney.jpg
cmd_overview_screens.jpg

LET'S REDUCE THAT COGNITIVE LOAD!

The next big challenge was to tackle the overload of possible actions displayed to the player constantly on the screen. According to game designers, all of them top priority one! So I decided to go even more player-centric and try to group those information, in order to decrease those "Prios-1" to a reasonable amount that would be easier to remember and add familiar lables to the overall categories. The more familiar the label, the easier it is, to associate the right actions with it, and we all know - recognition over recall, right?

Grouping Information_cmdr.png

ERGONOMY TIME

Now before jumping right into designing accessibility and ergonomics of controls, it was necessary to check back the with user preferences of platforms and genres to figure out their expectations in terms of controls and overall playability of our game. A quick look at our persona-preferences lead us to the assumption that our players prefer consoles and among those, the XBox One. So with that in mind, I did a first research on controls accessibility.

range of axis.jpg
cmd_hand_controller.jpg

Among the fingers and overall, the thumb is unique, since it has the only saddle-joint in the whole human body that can actually move 360°, so it has naturally the widest movement-area to cover. This is also represented in the controls of the pad and additionally lead to the assumption that circular/round would be some of the most natural and comfortable movements for the thumb to perform.

The next step prior to designing specific controls, was about adding some more ergonomic principles - namely, Fitts's Law, the useful all-rounder :)

fittss_law.jpg

The conclusion of this research on ergonomics was that we should go for a radial menu to display the options to the player that would be accessible at any point, without forcing the player to navigate to a specific point on the screen.

ITERATIONS, ITERATIONS,...

Okay, radial sounds cool, right? But what about the mapping? We had four - turned five during the iterations - main categories to be placed and ideally accessed fast by the players. So as next step, I created four rough prototypes with different mappings and went on testing. Here, I wanted to find out, which categories were accessed the most and which placement on the radial menu, users regarded as the most suitable.

mapping_layouts.jpg
cmd_mapping_results.JPG

I liked the 1st prototype the best, however the option to reload with two different movements, like in 3rd one was pretty cool.

[Quote from user testing]

Testing shown that players mostly use the options of "Combat" and equally access the inventory or use the overview-mode to get a better picture of the situation, which helps them to evaluate the whole situation. The least used action was "Wait". They also reported to be the first layout to feel more natural, however some expressed the wish to double-map the "Reload"-action possibly to an additional button on the controller.

radial_GUI.jpg

HIGH FIDELITY AT LAST

Finally I was at the point, where I could move to a higher polished visual prototype that would illustrate my research and testing to the development team. I created fours high fidelity mockups for the three game-modes with context-sensitive display of options and actions that were to serve as a summary and inspiration for the UI Artists.

tactical_mode_GUI_v1.jpg
tactical_mode_GUI_v2.jpg

Tactical Mode Ver.01

Tactical Mode Ver.02

overview_mode_GUI_v1.jpg

Overview Mode

targeting_mode_GUI_v1.jpg

Target Mode

LESSONS LEARNED & NEXT STEPS

The main take-away in this project was for me, to help designers prioritize the functionality of actions. It was a delicate balancing between user needs and respecting the complexity of the aspired design, trying to find the middle ground. Sitting together and discussing with game designers was a very valuable lesson for me, because it not only improved our communication, but also helped us to see the product from different perspectives, compromise and work together to achieve the most satisfying user experience within such a complex genre, such as tactical strategy.

I finished my involvement in this project by creating a small UX-bible as a handover with my research and mockups for the UI artists that were to make the interfaces final and polished. User testing with actual in-game interfaces is still to come.

Commander_doc.jpg
bottom of page