Get best of the week

Creating a design system for the game: a detailed analysis of the approach

My name is Maxim Polstyanaya, I am UI / UX Designer in Plarium Kharkiv. In this article I will share my experience in creating a design system for our browser strategy of the “War of Thrones” , tell you how it all began and what stages we went through.



The team was faced with the task of optimizing graphic elements and developing a convenient project structure.

The game was released in 2012, over time, content and functionality was constantly added to it, new graphic elements appeared. Then each member of the team had his own approach to creating design layouts, work was carried out without the use of guidelines and a library of elements.

After analyzing the project, we identified a number of problems:

  • multiple duplication of interface elements using different designs for the same objects;
  • excessive amount of graphic content, which led to long downloads of windows;
  • the lack of a transparent structure for storing content (for example, now each button has its own logical name, and earlier it was necessary to indicate the existing screen from which the button was taken for a new layout);
  • low speed and accuracy of window assembly.

All this negatively affected the overall style of the game, the size of the written code grew, and this made it difficult to work on the development of the project.

We decided to organize the graphic content. To do this, it was necessary to process the entire UI, and this is more than 1000 screens plus their various states. As a result, through trial and error, we came to the atomic design system .

After going through the UI of the game, we identified the basic indivisible interface particles, of which were the main groups.

1) An element is a basic (indivisible) particle of an interface system that is used to create other functional groups of elements. It can perform various tasks.


Examples of elements: buttons, tabs, sliders, text, and more.

2) Control - a group of elements that can perform the function of control, navigation, data visualization.


Examples of controls: reward, pager, search by coordinates and more.

3) Block - a logically grouped set of elements and controls. The purpose of the block is to group these parts of the interface to perform specific tasks.




Examples of blocks.

4) A template is a group of blocks from which screens are formed for various tasks. Templates can have their own system and construction rules. The purpose of the template is to store the behavior logic for the content inside the template.


Sample template.

5) A screen is a group of templates, as well as a part of the window that we are currently seeing.

6) Window - may consist of one or more screens.

The names of the parts of the interface were chosen so that both designers and programmers used the same concepts and there were no misunderstandings that could lead to errors. The names may vary for your projects. Group names are not as important as their purpose and function.

Window


The game had many windows of various sizes, in which the structure and hierarchy were poorly traced. Their formats were not standardized and could have odd sizes, which made it difficult to work with content. This significantly complicated or did not allow using templates at all, so it took more time to develop.

Having collected all the existing windows, we decided to divide them into three types and set a static width for each of them, as well as a minimum and maximum height. When choosing the sizes, it was necessary to take into account that the same window is used in social networks, a browser and the desktop application Plarium Play , but at the same time the area for game content is different everywhere. We determined the maximum possible size for the window, based on the smallest gaming area (for VKontakte).

The first type of window is the main one. These are the largest windows that are starting for any feature, and also open when interacting with elements of the main screen, including buildings. Windows of other types open inside it - they are secondary. This separation was reflected in the design: in order to better trace the hierarchy, we made the design of the window frames of the second and third types easier. The second type was divided into two subtypes for content of different widths. Typically, the width was set by a block with an existing art or the most loaded information. The sizes and purposes of the windows can be seen in the image below:


Three types of windows: main, internal windows and alert.

Grid


We chose a grid with a 4x4 pixel cell (one module) - it best suited our requirements. With such a grid, you can quickly move elements at distances that are multiples of four, and indent as needed. For example, indenting 4 cells is visually easier than counting 16 pixels. All our elements and blocks were multiples of one module. The grid snap function is another plus of this approach.

For the convenience of layout, we created an auxiliary 12-column grid. She allowed to harmoniously arrange blocks and not to calculate horizontal distances each time. The grid of 12 columns is very flexible, since 12 is divided into 1, 2, 3, 4, 6 and 12 parts. Grid parameters: 12 columns 52 pixels wide, intercolumn - 12 pixels, “ears” - 16 pixels each.


4x4 pixel grid and 12-column grid.

Indentation system


For the convenience of the whole team, we decided to indent the system so as not to think about where and what indents / distances to use. This system also helped maintain a consistent style and hierarchy of content within the window. It was easier for programmers to follow guidelines and avoid making mistakes in layout.

We inferred four sizes of indents: 4, 3, 2, 1 module (16, 12, 8, 4 pixels, respectively).
4 modules are the "guard field" of the window, as well as the largest indentation. With the addition of new blocks to the layout (we are talking about nesting), their protective field and indentation are reduced. The smallest distance between the content should not be less than one module, that is, the smallest distance is 1 cell 4x4 pixels. Thus, the content inside the window obeys the proximity rule.. An example of such a structure:


Indentation system.


Indentation system on the example of the “Battle Report” screen.

But in any system there are disadvantages: it is not always possible to follow the indentation by 100% due to certain project limitations. For example, we could not use scrolling in heavily loaded windows due to the large recalculation of data when scrolling. Therefore, in some situations, you had to step back from the system in order to accommodate the required amount of content in one screen. But the principle of proximity was still maintained.

More about templates


Here is an example of one of the templates for which the construction rules were written. Consider the lists - they are used throughout the game and have a very diverse content.


Examples of blocks that make up lists.

Having collected all the varieties, we divided the content into groups with common characteristics:

  1. with icons;
  2. with progress bars;
  3. textual
  4. with buttons;
  5. groups with User control (control of interaction with the player);
  6. mix-group, in which there may be several elements from previous groups.

For each group, we set the building rules, styles, sizes of elements and behaviors. As a result, blocks were recruited from these groups as a constructor. Programmers created presets, and the speed of creating lists has increased significantly.
The basic rules for groups are listed below:


Rules for building blocks.


Varieties of groups and rules for placing elements.

Typography


The project had a huge number of text styles without any clear hierarchy. For example, we counted about 10 shades of red to indicate the same status of a game object.

The main font of the game - Korinna Normal - was difficult to read in a small size. We solved this problem by adding Roboto Medium font for small text.

We selected several text styles, divided them into groups and set the color coding. Thanks to this, we were able to add certain characteristics to the text that was used for the same purpose. It turned out a convenient table:


A table with text styles.

We also developed assembly, construction and use rules for:

  • buttons
  • all kinds of cards (unit purchase card, tournament card and others);
  • tooltips and notifications;
  • progress bars;
  • controls;
  • panels.

?


  1. . . . , .
  2. . , .
  3. . , , .
  4. , 4. , , .
  5. A large amount of content that cannot be replaced in the project, even if it is obsolete . Changing the design of some elements or UX may cause dissatisfaction with players who for many years are accustomed to a certain display interface.
  6. Restrictions on the use of scroll in windows .

To create such a design system will require quite a lot of time and resources, so it is more suitable for large developing projects, which will acquire functionalities and additions.

Due to the large amount of documentation and guidelines, the threshold for joining the system increases, new team members need time to study it, but the result that this approach gives justifies all the resources spent on it.

Total


We have created an understandable and convenient structure for all the graphic components of the project in Confluence.

With the help of guidelines and a library of elements, it was possible:

  • significantly reduce development time and improve the build quality of new features;
  • To simplify the process of creating a design for new members of the UI team
  • reduce the number of questions and improve communication between designers and programmers.

Our team was pleased with the results - the design system lived up to its expectations. She helped solve all our problems in the project, at the same time we “refreshed” the schedule and in some cases improved the UX.

Comparison of screens before and after processing



The combat report window (before / after).


Quest window (before / after).


Window "Abode" (before / after).


Window "Alliances" (before / after).


Window "Shadow market" (before / after).


Window "Magistrate" (before / after).


Window "Magistrate", view the line of construction of troops (before / after).

Copyright [2020] Plarium Global Ltd.
All rights reserved. You are not permitted to copy, reproduce, or make any use
of this article, including any images therein, without Plarium's written permission.

More articles:


All Articles