Foreword

User Interfaces (UIs) for action-packed gameplay games such as Overwatch and Battlefield are unique in that they must provide the player with all the critical game information, while not distracting them from the gameplay. In this article, I will describe the user experience lessons I learned while creating the combat HUD for the game Dreadnought. By and large, this essay examines in detail how to modify well-known approaches to the analysis of user experience patterns, such as Fitts's law, for their use in HUD action games.

Before starting a detailed review, I must mention the premises so that you better understand the observations made by me over the past two to three years. I will often refer to the concept invented by Jeff Ruskin, the legendary specialist in computer interfaces; in his amazing book “The Humane Interface”, he introduced the concept of “locus of attention”, which I will use without a twinge of conscience so as not to confuse you with other related terms.

In short, the locus of attention determines the physical object or place to which your brain is currently paying full attention, both consciously and unconsciously. Most other terms, such as “focus” or “target”, to a large extent imply a conscious decision to pay attention to a specific place or object. This is an important difference, because the game UI should allow the user to change the locus of attention of the player, without forcing him to do it consciously.

I sincerely recommend reading Jeff's book, because despite its age and new technical improvements, it still brings many discoveries that the user interface designer or user experience can use in modern digital interfaces.

For gaming HUDs, you can apply Fitts law in a modified form

If you are not familiar with Fitts' law , then this is one of the most fundamental scientific methods for estimating and forecasting for almost any interactive element, both physical and digital. Accordingly, it allows you to make relatively accurate predictions about the practicality of using the UI element, even without its use in the design of a menu or game.

The formula defines an easily calculated index of complexity ID; essentially, it means that interface elements that require the user to make a greater distance (indicated by the amplitude A) and also having a smaller size (indicated by the width W) are more difficult to use, i.e. they have a greater complexity index, and vice versa, a low efficiency index. Similarly, shorter distances and larger element sizes result in a lower complexity index. According to Fitts’s law in the Shannon formulation [1], the ID is calculated according to the following formula (see Fig. A).


Fig. A: Fitts law in Shannon's formulation.

I recommend watching a detailed explanation in this video [2] , which illustrates the law well.

Shannon's wording is more focused on the active, conscious use of an interface, physical (buttons on a device or device, levers, etc.) or digital (all standard UI components, such as menus, buttons, sliders, scrollbars, etc.) Naturally , it is less suitable for assessing how effectively the UI works passively, providing information to the user's consciousness, since the player may not actively seek this information. However, as I describe below, this can also be achieved by introducing fairly simple replacements and modifications into the original equation. It should be noted that hereinafter I define both types of UIs, respectively, as interactive (the user presses buttons, etc.) and only informational (the user passively consumes information).

To make significant modifications to the Fitts law, it is useful to observe how the user interacts with interactive and only informational UIs. On the one hand, with the active use of a UI that requires mouse input, the user actually shifts the locus of his attention to the UI element that he selected for interaction. For example, pressing a button or opening a submenu always requires a certain degree of conscious effort, i.e. the required shift of attention begins directly by the user. On the other hand, in order to apply only informationGaming HUD user attention shift should be triggered by the UI. For optimal performance, we first of all strive to create UIs with elements positioned in such a way that they quickly attract the player’s locus of attention on their own, if necessary, but allow him to easily return to the game process after receiving all the information necessary for the game.

In fact, the change in the complexity index that I propose for only the informational gaming UI determines how much the UI element in question is able to shift the locus of attention and transmit information quickly and efficiently so that the player can use it.

It's important to note that I'm talking about action-oriented games such as Dreadnought, whose locus of attention has traditionally been centered on the center of the screen. This is a critical aspect that needs to be considered when developing this type of UI, especially because our brain filters out information at the edges of the visual field; the location of the UI elements on the edges of the screen can lead to a possible decrease in user attention compared to what the designer was aiming for.

Now I’ll dive a little deeper into the actual modification of Shannon’s formulation and its applications. So that Fitts's law is able to predict usability through the complexity index, in the case of only informationalUI we need to replace the original value of the amplitude. To create our field of vision, the eyes move so quickly and randomly that we can ignore the physical distance as a factor; we will replace it with a composite variable, more oriented to the structure of only the information UI.

Amplitude A in this case will determine the strength of the visual indication or signal change. It is useful to think of this amplitude A as a way of describing the signal-to-noise ratio of our brain. The stronger the change in the appearance of the element, the more likely the shift of the locus of attention to it.

This also explains why Adefined as a composite variable consisting of several parameters and variables: because the brain’s interest in visual input signals can be activated by changing size, color, movement, noise, etc. object. For example, in the case of a HUD, A may include factors such as percentage of contrast, increase, decrease, or difference in color or brightness changes, or simply a change in size within the HUD; anything that can lead to an increase or decrease in visual stimulation and is a measurable action, which, in turn, can attract the user's attention.

All of these factors can be multiplied to provide a better understanding of their actual effect on the element complexity index. If greater accuracy is required in determining which of the visual indicators makes the greatest changes in the amplitude, the same formula can be applied with only one isolated parameter as the amplitude. This, in turn, will determine the weight of each variable affecting the A .

Along with the amplitude, it is necessary to introduce a new variable in the formula: the distance D, which is the distance from the main locus of attention of the game to the element in question. The main locus of attention is the area of ​​focus of your choice that the player should pay full attention to most of the time. In games of the FPS and TPS genresit will most likely be the center of the screen. To obtain predictable results corresponding to the accuracy of the original formula, we need to divide the distance by the composite amplitude.


Fig. B1: Modified wording of the Fitts law for use in gaming UIs.

So we get two important benefits. Using empirical measurements, we can conclude that the UI components located closer to the main locus of attention significantly attract the temporal shifts of the locus of attention. In addition, the closer this widget is to the current locus of attention, the more we reduce the actual amplitude for registering the widget with the visual cortex, which allows the player to remain focused on the gameplay.

In fact, there is a very simple experiment that allows you to experience these effects yourself. All that is required for him is time and one helper. An experiment will require your full attention to one subject or task, so the two of you can try to do it while you work. The assistant should wait until you are fully focused on your chosen task. Then it should start shifting your locus of attention with low amplitude. You will come to the conclusion that when an assistant tries to attract your attention with a low amplitude, being on the periphery of your field of view, it may take some time to attract attention. However, if it is closer and its amplitude is huge, it can even scare you. Therefore, there is an optimal zone of best perception,

To vividly illustrate this rather boring topic, I will demonstrate two striking examples in which the combat UI of the game Dreadnought significantly benefited from the redesign of the UI components to reduce the complexity index. The first elements that I want to talk about are the two most critical UI elements of the entire HUD: “health” and the energy of the player’s ship. In our initial prototype, we placed both elements at the bottom of the screen. We did so, trying not to get too far away from the usual patterns for FPS players; also, due to the proximity to the player’s locus of attention, the elements were better seen in the heat of battle. (see Fig. C1)


Fig. C1: The initial location of the UI components for health and weapons.

But our internal testing made us doubt the sufficient visibility of the element. Our team members began to ask the indicators to move to a place more familiar to the “health” indicators in first and third person shooters, namely to the lower left and right corners of the cone of visibility. So we realized that, despite our hopes for an improved layout of UI elements, we did not get the expected result; they were not good enough to be stronger than the habits of experienced players.


Fig. C2: An approximate area requiring elevated levels of amplitude to shift the locus of attention. Green and blue indicate areas that the player actively views with intense gameplay, red indicates an area in which they are most likely not to notice changes.

This made our team think about a more careful assessment and predictions of the effectiveness of elements of only the information UI, which led us to the conclusions indicated in this article. In particular, we began to solve the problem by testing ways to arrange UI elements in such a way that they overpowered the habits of experienced players and provided an improved user experience for casual or completely inexperienced players.

We settled on a solution that supported the feeling of commanding a large spaceship, both thanks to a stronger visual style and increased usability. Moving the elements to the place where they are always visible gave us the opportunity for a short time to change the locus of attention from the battle itself, without affecting the quality of the game. In a nutshell, we located two arcs in the area in which the moving sight of the ship is in the most intense moments of the battles. (see Fig. D1)


Fig. D1: Improved widget "health" and energy.

This allowed us to greatly reduce the actual size of the elements, because now they are still most of the time much closer to the player’s circle of attention; we also increased the signal-to-noise ratio using color arcs to better signal a critical decrease in “health” or energy. This, in turn, helped bring the amplitude closer to the required levels without straining the player’s vision; we managed to snap the element to the area at a minimum distance from the main locus of attention. In addition, users were able to quickly respond to certain situations in battle. (see Fig. D2)


Fig. D2: Improved components are located closer to the center of the main locus of attention.

As shown in Fig. D3, we were able to significantly reduce the difficulty index. Improvements of no less than 400% were achieved by combining amplitude improvements of approximately 4.5 times the amplitude used for the old component, as well as optimizing the layout.


Fig. D3: Relative values ​​of the complexity index of old and new components of “health” and energy. The lower the value, the better.

The third component was the weapon display. We took a similar approach to fix it; finally we got a HUD, which became balanced in terms of better visual display, as well as greater efficiency in transmitting the necessary information to the player.

First, we placed it in the lower right corner, as is the case in many games. Many of the alpha players, testers, and developers have reported that they don’t know exactly why the weapon starts reloading at a particular point in time; it also took a long time to check the remaining ammunition. This greatly reduced their ability to win the current battle.

To increase the effectiveness of the component, we decided to separate the UI of the main and additional weapons in separate visual areas; we placed them right next to the indicators of “health” and energy, which I wrote about above.


Fig. E1: New weapon display layout.

In addition, we no longer constantly show the name of the weapon, only when switching weapons or spawn during the game. This allowed to free up about 60% of the space occupied by the original components, and also provided the opportunity to constantly inform the player about the current state of both sets of weapons; now it’s much easier to determine which one is active; we also achieved increased signal amplitude when displaying messages about reloading any weapon.


Fig. E2: All components are clearly located in our optimal cone of visibility.

And finally, we made it possible for players to respond more quickly to signals when they select the “sniper scope” mode of a weapon. Since it reduces their visibility in the game, we wanted to give them more information about the current state of their ship. To do this, we moved all the elements located around the locus of attention, even closer to the center. Now even players of the sniper class can more quickly than before react to possible threats nearby.


Fig. F1: Sniper scope mode for increased readability in high focus situations.

Honestly, I didn’t have this equation yet when we applied the last iteration of our HUD; however, I do not want to discredit the value of our assumptions, as we clearly see improvements in player comfort after these changes.

Be that as it may, I was always worried that our understanding of this problem was very limited, to say the least. Therefore, I began to look for possible scientific explanations. I think that the acquired knowledge will make the planning and design stages of the next projects less tiring and will most likely lead to predicted results.

And the last thing I wanted to mention: finding a good balance of layout and size is critical. Of course, the increased amplitude and size of the components will increase the usability of these components, however, this, in turn, may reduce the usability of the others; this is a delicate balance, although the tools I mentioned can make it easier to get good results.

Habit, you know where the door is! But don’t forget to come back later!

It should be noted that the material in this section is based on my own experience, and there are many different views on this topic, they all have their pros and cons. I will not have for you answers to all questions related to only informational UI.

Often, the location of fairly important UI elements is based on familiar patterns. This is not necessarily very bad, but habits can impede the implementation of improved UI / UX patterns and their adoption by the wider community of game developers. Using these patterns, we can easily parallelize tasks that would otherwise require much more time. However, this is a double-edged sword: users can greatly benefit from the use of improved user experience patterns, but if developers decide to adhere to inefficient but common UX standards, we will see how players mastering the new genre experience more difficulties than usual.

I clearly adhere to a reliable rule: if an experienced and sophisticated game developer can get used to and master a new pattern very quickly, experienced players will also almost never experience problems with it. The worst mistake you can make is to assume that your users will not cope. Never consider them foolish or even stupid. Just by watching how amazing moments arise in many multiplayer games when players find ways to play in a way that isn’t provided by the developers, you can understand that this is the best example showing the willingness of players to such difficulties. In the end, we are simply striving to make the game more accessible to all players, and new players benefit most from UX enhancements.

To give an example from practice, I will take advantage of the most striking case, which, in my personal opinion, is one of the biggest failures in the oldest of the genres of the history of video games: a strip of health in first-person shooter games.

In many, if not most of the old and new FPS, creators place a health display in the lower left or lower right corner of the screen; as we found out in the first part of this article, this greatly complicates the shift in the locus of attention to this widget in the face of intense action-gameplay.

As you can see (Fig. G1), they are clearly located outside the “cone of attention”, which we considered conditionally optimal for our game (see Fig. C2). In any case, I do not want to say that this is necessarily a bad place, but you should always think about the consequences of using this provision, and also check whether this provision meets the requirements that you set together with the developers of the game.


Fig. G1: UI health widget in popular FPS games.

Keep in mind that very often a meta-solution is used to reduce interference: remember the post-effects at the edges of the screen - for example, drops of blood on the “camera lens” when health drops to a critical level; you can see examples of this in Figure G2 Depending on their strength, this can lead to other problems: adversely affect the perception of the game by users with physical limitations, such as color blindness. Meta-solutions, such as the aforementioned, generally work quite well, but they also raise the question: are they really more convenient than the health strip itself; and if so, is this indicator necessary at all? Popular games, such as Call of Duty, seem to be confidently answering this “no.” However, if you need it, you can think about your own location and size of the energy strip.


Fig. G2: Meta solutions for displaying low health in modern FPS.

I invite all game developers, UX experts, and UI artists to collect all elements that have popular uses or familiar patterns in other games; the fact is that they may overlap with the type of game you are developing; analyze these elements, be honest and open, if you find flaws in examples of their use.

If you have doubts about meeting the requirements of a component’s performance level, assign it another design iteration. Be patient and adamant, use the knowledge of Fitts law and other UX patterns to find a way to create a component with a lower complexity index. If you have reached the prototype test stage, let your team test it. Very often, elements have popular solutions, so at first a new design may cause rejection at first. This feeling can even affect you: it’s very easy to fall into the trap of “this is always done like that!”. Try to resist the urge to simply return the old component, and experiment a bit first.

I observed this effect last year when we iterated over the development of a weapon display. I think it contains one of the important aspects for finding the best UX pattern, as well as for quicker adaptation of users to UX patterns.

The most important part is an attempt to outwit the brain and make it partially abandon the usual. By testing two versions of the UI element in parallel, we were able to remove the entry barriers mentioned above. Ensure that the testing cycle randomizes the use of one of the options. This will lead to the fact that our brain will not be able to constantly apply the skills learned earlier, due to the various requirements for the UI player.

A key indicator now will be checking how long the process of returning a player to familiar behavior takes; usually the best UX pattern is one to which the player returns more easily and reaches the comfort zone much faster than a weak design. This is a fairly simple and quick way to find the best solution optimized for the requirements of your own game.

Prototypes are vital

This may seem elementary for many of us, but I still think that prototypes are an underused tool in game development, so I want to make a couple of hints about why you should try to introduce them into your development cycles.

I can’t express how important it is to have a working HUD prototype as soon as possible if these elements are used in your gameplay. This is a great way to determine the cutoff point for a player’s data: “more” doesn't always mean “better” when it comes to an extremely fragile ecosystem of space-limited UI screens. Early prototypes can give you a clear and precise indication of what helps or confuses your user base.

Early prototypes are by far the best tool at your disposal when it comes to building a good UI. Report to your team the installation that the prototype should functionally work in accordance with the requirements, but not as polished as the final product. Although this is obvious, I often had situations where employees thought they needed “final art” for prototypes; this is pretty stupid: employees who create certain details of the game should have more than enough abstraction skills to understand that the part works without completely polishing all the icons and elements. Smoothing flaws at this stage should be relatively simple compared to a UI close to its final shape. The ability to make changes quickly, until your games are perceived to be perfect,

Conclusion

In conclusion, I want to say: I am glad that we created such a functional and understandable HUD, despite the fact that sometimes it needs to display a lot of data. Although I did not have much knowledge to support it, because it was my first experience in this genre of games, I am pleased with the received tools that I use in future projects.

I also realize that not every genre can and is capable of accepting such optimizations of the gaming UI; however, I am absolutely sure that every game developer and UX expert can draw certain conclusions from these tools that will improve the player’s perception of both the UI and the game itself.

References

[1] Bits per second: model innovations driven by information theory

[2] Mouse Pointers & Fitts's Law - Computerphile