Creating a UI is not an easy task and it is even more difficult if you have to do it for a complex title like a round based strategy game. FIGS explains how they approached this task and how they made up a simplistic and yet easy to understand UI.

[cms]dspYoutube(‘SAABU6h-0Gg’,’580×326′)[/cms]

Amplitude, a young French video game studio, recently released a new title called »Endless Legend«. This was their second major title following »Endless Space«, which was set in a universe of science fiction and whose interface – also designed by FIGS – was praised by both the gaming community and the critics.

With »Endless Legend«, the aim was to achieve an interface that was consistent with the previous game but within a more »heroic fantasy«-style universe. A key question rapidly posed itself: Should we use traditional codes common to the fantasy genre?

We quickly decided we did not want to design an interface using traditional textures of stone, medieval ornaments or even dragons, in spite of the fact that this might be divisive for the gaming community. We preferred to integrate fantasy elements and styles using typography and colors. This was also consistent with the narrative pitch of the game, based on a people from »Endless Space« crashing onto the surface of the planet Auriga.

Once that decision was made we had to do the hard part: Designing an interface with multiple modes of representation that was appropriate to the genre but also provided additional information and new paradigms of interaction that were not present in »Endless Space«. These new elements were linked with a complexity also not present in the previous game: the three-dimensional terrain.

Some design intentions

Respect the narrative positioning of the game between Heroic Fantasy and Science Fiction (Auriga)

Allow highlight textures on artworks and / or DA

Help solidify the identity of Amplitude’s games

Move away from the traditional codes of fantasy games and innovate in the genre

Manage the complexity and what we call »infobesity«

Make it appealing

Put the player in a position of control

Iconographic system

We can start by talking about a component that is essential to the interface: Icons. We wanted to do this using a systemic approach, meaning a graphical system optimized to streamline comprehension by manipulating some of the standard graphic codes used in everyday communication.

The background objectives

Consider pictograms as a simplified form of language. If you can combine a subject with an action, it is easier to grasp the purpose of the UI element while minimizing complexity (fewer signs, less complex symbols). This allows the player to better understand the meaning implied when pictograms are associated with each other.

Modular design of these signs is the key element of this system. Accompanying this logic, some graphic codes specifying categories of pictograms are used. For instance, outline circles contain icons for major actions, smaller orange circles designate actions in the interface panels, filled circles are used for icon notifications or even colors (as used in »Endless Space«) serve to show specific »FIDS« representation (Note: »FIDS« stands for Food, Industry, Dust, and Science – the basic resources of the game).

Main actions have an outline circle

Notification icons use a filled-in circle

In-panel actions are displayed in orange

Out-game menus

Overall, the idea here is to create interface windows using a common basis that also provides additional »landmarks« to the player concerning the spaces where they are located.

For example, the ingame menus have a different look from out-game menus, but only due to a different set of colors. The fundamental rules of design applied to interface panels remain unchanged, regardless of where they are being displayed. It’s the same thing for the modal windows, notification windows, etc. More precisely, it means that levels of transparency, margins, typography, style icons, sizes, spacing / margin (etc.) remain the same for each mode of representation.

So what changed specifically here?

Thus the outgame menus’ interface panels use white at more or less 50 percent of transparency, black button icons, and dark grey texts. In other words, it is as if we varied graphics parameters depending on display context while keeping the same structure rules for all of them.

Here we have introduced the display options in the form of cards. Each card is dedicated to several settings of the same theme. The way the menu splits into cards helps the player identify the group of actions being decided.

Ingame interface

The ingame interface is the most important view, as it is constantly »in contact« with the player. This is because the game is based on a real-time 3D terrain.

This interface is a big dashboard whose layout areas already provide some insight into possible interactions: In the upper part of the screen you can see interface panels which are related to informational items [A & D]; in the lower part, the production elements [B]; on the right edge, the notification area [E] (reduced mode); and in the lower right corner, it shows the »EndTurn«-widget [C] which is mainly related to time and opponent information. The upper right corner is dedicated to the display of current quests and allows quick access to additional related ingame menus.

Transverse to this overall layout, the panels at the top and bottom of the screen space can be read from aggregate information to detailed information as the eye moves from left to right. For instance, in [A] we start with the info panel and overall controls (general resources, access to game menus, etc.). Then gradually, from the left to the right, we see information related to the empire, the regions, the cities and finally to the management of individual FIDS.

In this view, we have also introduced the first elements of our formal language: The set of colors associated with interactions (signs and feedbacks), iconography position within panels, items with set margins in order to better present levels of detail, etc. This is a space where we need to combine many signs dedicated to the game contents, including user interaction with specific levels of distinctions (»Is that an element that can be manipulated, or is it informational, or both?«). Work on contrasts and overlaid panel backgrounds is essential to manage the issue of readability based on sets displayed in the background; this is constantly evolving depending on the choices made by the player or merely the change of seasons. In this case it is necessary for typographical indications to be legible on a bright background (snow), a saturated background (desert), and stand out from dense graphic details. And yet the 2D cannot be too intrusive because the terrain features (such as units, buildings etc.) must remain easily recognizable by the player.

About the EndTurn-widget

The »EndTurn«-module is a widget combining the notions of time and opposing players (factions). It also toggles the display of FIDS and hexagons on the 3D terrain. As it also tracks time, one of its main functions is highlighting interactions and information concerning game turns. Another aspect related to time management is the prediction of seasons (changing weather conditions).

The ground

We had many exchanges with 3D artists and the art director of Amplitude about the appearance of the ground. The general idea was to bring a different energy to the representation of the terrain compared to how it is seen in other games in the genre. We knew that this research would target the presentation of the 3D terrain itself, but did not know if it would also be applied to the »fog of war« or to an unzoomed view of the map.

We first ran tests that explored the Delaunay triangulation algorithm, combining it with color effects and lights to bring an unusual, attractive visual appearance. These tests went well, so we dug a little deeper by using another approach that worked on the animation of 3D mesh vertices. The idea was to use a simple 3D primitive as a polymorphic material, animating the vertices to introduce additional data (e.g. identifying a type of terrain).

By animating vertex positions and manipulating color, we established a simple parametric method that let us easily display a ground type (a desert, an ice floe, a rocky mountain, etc.) from the same basic material and create a kind of morphing form transition while changing the ground state. These tests confirmed what we had hoped to prove: Animation could re-interpret static information when a simple graphic was not enough.

Info on ground values

Our experiments extended to the representation of FIDS values for the map hexagons. Early research used graphic representations in three dimensions (like vertical gauges anchored in the ground) displayed directly on hexagons; to test this we developed some quick and dirty prototypes that simulated changes of camera angles, roll, different fields of view, etc. The testing showed that despite the graphic potential of these gauges, they were not an efficient solution as it was difficult to accurately read the value of a specific FIDS. We therefore changed course, displaying simpler information by using a text field encrypted directly on the hex. As always, we did a lot of trials to find the best balance between visibility and accuracy.

One of the strengths of the 3D terrain lies in how it aggregates – or conceals – information depending on the player’s level of zoom. Starting from the highest level of detail, as the player zooms out the representation of information related to a hexagon will change, becoming simpler and more iconographic. This »info-morphing« is done in real time.

Ingame menus

The player enters these spaces through the 3D terrain panel interface (top left of the screen). Screens from the ingame menus are interfaces that handle additional complexity or detail in terms of player/system information. Most are management interfaces and their looks are different, although all share the same graphic codes. The visual aspect is also a fundamental point of these menus, which can be displayed on a background (behind the shader) that ranges from very light to dark depending on where the player is located on the 3D terrain. The question of readable typography and the transparency of backgrounds (etc.) must therefore be put into perspective with the density of the information present on the screen.

In continuity with the out-game areas and the ingame interface (linked via the 3D terrain), one of the objectives was to implement a specific style for these areas while adhering to the graphical codes that were used in other areas. Here background UI panels are more transparent, and use some shades of grey according to their hierarchical level while dynamic texture is used to form an animated background designed to better identify the ingame areas.

Custom made screens

Each screen is a response to a specific action of the player under specific conditions. Some of these screens are list-based interfaces, other consist of quick interactive or other panels with unique field interactions that can be in two or three dimensions (for example the Diplomacy area). So ingame menus consist of: Science, Self, City Trading, Empire Management, Diplomacy & Negotiations, Heroes, Army … Together they form what could be called a management interface.

Some of these ingame menus went through many stages of pre-design prototyping. The initial Science menu concept was more advanced than the final version; it included the possibility of dynamic reordering of the technologies, filtering based on the gaming profile, multiple parallax scrolling, etc. However, due to time implementation constraints the technical scope of this menu was reduced. With hindsight, we had to make these different divided spaces homogeneous so they would be more easily identifiable by the player.

Another aspect of our graphics research related to the visual environment within the menus. We worked on the creation of a dynamic graphical effect (shader) dedicated to all the background planes in the game menus. This shader is involved in the identification mode ingame menu and also allows the player to create a dark atmosphere (in the heroic fantasy spirit) while improving the readability of game information.

Using the shader gave us background contrasts with the real scenery (3D terrain) if the 3D terrain was affected by a winter metoclopramide, it has an impact on the overall record. To precisely define the rendering shader in the final game (and to the Amplitude developers), we worked on several customizable prototypes (speed, density, color …).

The battle mode

Battle mode is complex. In spite of the many levels of information required it has to be intelligible and easily manipulated by the player.

One aspect of this complexity is the amount of information that must be shown on the screen whether on the terrain, on the units in a specific mode (to show the tactical choice for example), or even in the 2D interface.

This required a typology of signs and feedback to implement an easily identifiable system and a robust classification shared by different display spaces (3D, 2D UI). In short, a vocabulary of signs common to different displays.

Beyond this issue are constraints like readability of the number of units and the different camera angles potentially visible depending on player actions.

Modal windows

For »Endless Legend« we were keen to establish a consistent and logical structure for modal windows as a series of two or three rules.

The first rule is to blur the context from which the player invokes the modal content. The second rule concerns the way we view this content: We start by cutting the visual blur of the starting context to bring up a panel presenting a component, the information, or a relevant menu.

Finally we can highlight the type of the content displayed using a basic color code in the background. Green is for rewarding or informative messages, orange for simple interactive content (enter the name of a file, for example), and red for a message concerning potential danger or failure or a critical alert. In most cases this is a view of whole configuration menu. The color of the recess in the middle of the window depends on the type of message: Green for a positive one, red for critical action and orange when an interaction is needed (e.g. text entry).

Notification windows

Windowed notifications are actually triggered by the player character from notification icons that appear on the right side of the interface in the 3D world view. They are fixed modules dedicated to specific subjects and are constrained in time (such as battle events, for example).

As mentioned just above, these notification panels have different features depending on the context and the number of potential interactions. For instance, it may be a simple display artwork evoking the transition to a new Science era or a dashboard of battle parameters; enabling or disabling the activation of an army; the possibility to classify armed groups or tactical choices or visualization of relative strengths, etc.

To define the graphical DNA of these display types, the idea was to use a standard »old paper« type of texture that would clearly differentiate them from other types of displays. This paper texture is not trivial; it can subtly bring in codes from games of this genre without risking cliché, and creates a clear boundary between these areas and others.

Tutorial system

Possibility for the player to proceed randomly

Tracking previous stages completed by the player

Maintaining a sequence in instructional interactions

When a narrative message is addressed to a player more of an indication to run, the two are combined in the window. The narrative message is always located just below the avatar.

A button to collapse / expand the narrative message the player manually. Automatically when you open a new message, a timer is initialized and can collapse the narrative content automatically after a few seconds (time to be determined according to the length of the message). In the case of long narrative indications / interactive, an elevator can be displayed. Possibility to reduce any window via the button at the top right.

Laurent Herbet

Further reading on MakingGames.biz