Gamedev Андрей Верещагин
14 211

Особенности создания интерфейса для мобильной игры

Принципы и правила работы с небольшими экранами.

В закладки
Аудио

При создании интерфейсов для мобильных игр разработчикам порой приходится идти на компромиссы из-за относительно небольших дисплеев. И речь не только о размерах иконок и окон или об их расположении.

Ведущий UX и UI-дизайнер студии Azur Games Екатерина Кузьмичёва написала для DTF колонку об основных принципах, которыми следует руководствоваться при создании интерфейса для мобильной игры и о том, на что нужно обращать внимание.

Особенности интерфейса мобильных игр

Создание любого интерфейса предполагает комплексную работу с несколькими аспектами: с UX, со стилистикой, с синтаксической структурой, с эргономичностью, с логичностью и многими другими. В этой статье я хочу рассказать об особенностях UI мобильных игр, а также о том, как решаются характерные для этого вида интерфейсов проблемы.

Проектирование интерфейса f2p-игры осложняется тем, что разработчики часто не знают обо всех потенциальных фичах проекта. Развитие игры предполагает приобретение новых функций, о которых неизвестно на начальных этапах проектирования. Именно поэтому очень важно подготовить свой UI к масштабированию.

Мобильная игра — это всегда небольшой размер экрана. В работе приходится подстраиваться под разнообразие этих экранов, которое предлагает мобильный рынок. Хочется угодить каждому производителю, чтобы игрокам было комфортно при наличии любого мобильного устройства. И именно этот фактор является сильным ограничителем в подходе UI-дизайнера к работе.

Проектирование UI — это комплексный процесс, в который вовлечены специалисты разного профиля: информационные архитекторы, художники, верстальщики, собственно UI-дизайнеры, тестировщики. Этот процесс имеет сложности, типичные для каждой из упомянутых специальностей. Но факт проектирования UI мобильной игры сильно осложняется двумя вещами:

  • маленький размер экрана;
  • большое количество потенциальных фичей.

Маленький размер экрана

Реальность такова, что при работе с небольшим экраном мы имеем условно маленький диапазон (по сравнению с десктопными играми) вариантов размера и возможностей расположения элементов. Эргономическая составляющая диктует некоторым элементам UI находиться в определённом месте и быть определенного размера.

Помните мультфильм о купце, который принёс портному маленькую меховую шкурку с просьбой сшить из неё шапку? Потом он вошёл в свой купцовый раж и начал просить сшить две, три, нет семь (!) шапок из всё той же шкурки.

Этот сюжет я пересказываю коллегам и называю его «Притча о юайщике», потому что вижу сходство ситуаций. В мультфильме всё закончилось бодрым нравоучением о том, как плохо быть жадным. В работе UI-дизайнера вводные данные — это условная маленькая шкурка с большим ожиданием. Примерно так воспринимается эта сложная задача и её решение.

Правильно зонируйте

Ключевым принципом является подход: «Одна пользовательская задача — один экран». Этот принцип не нов, но я пишу о нём, поскольку до сих пор встречаются трудности его воплощения. Главным препятствием является нежелание прятать некоторые функции «далеко», за дополнительные клики. Есть риски, что эти клики так и не будут совершены. Кроме того, понятие «одна пользовательская задача» не всегда однозначно определимо. То, что является одной задачей для одного человека, может дробиться на несколько других.

И если мы понимаем, что на нашем экране будет чуть больше, чем одна пользовательская задача, то нужно максимально удобно и логично организовать пространство экрана. В этом помогает понятие зонирования — определение внешнего вида фрагментов UI (зон) со сходными функциями и принципы сочленения этих зон.

Определяем зоны — заводим экранные плоскости, отличающиеся друг от друга, чтобы в дальнейшем оперировать этими плоскостями

Соответствуйте выбранной ориентации устройства

Зоны, определённые проектировщиком, должны организовываться на экране в соответствии с тем, какова выбранная ориентация устройства — портретная или пейзажная. Идея «у нас много вертикали, но мало горизонтали» (или наоборот) определяет работу проектировщика интерфейса на глобальном уровне. Картинка ниже иллюстрирует подобную стратегию расположения элементов UI.

Иногда встречаются мобильные игры в пейзажной ориентации, которые «считают» себя играми в портретной ориентации — именно так там организован контент.

Игра Gladiator Heroes Clash. Структурные блоки окна складываются друг под другом, что было бы естественным при наличии большего количества места по вертикали

Используйте пространство за пределами экрана мобильного устройства

Не стоит забывать пользоваться пространством за пределами экрана. К нашим услугам всевозможные слайд-панели. Информация на них должна обладать определённым свойством — быть необходимой ситуативно, по требованию. При обращении к этой информации пользователь никуда не перемещается, а значит продолжает находиться в том же контексте, что и был.

Тут важно не забывать о слайд-панелях самой ОС и не конфликтовать с ними

Количественный минимализм

Ещё один принцип проектирования интерфейса мобильной игры звучит как жесткий императив — «ни одного лишнего элемента на экране». До сих пор находится огромное количество мобильных игр с элементами UI, не делающими собственно для UI ничего.

Игра «Великий Султан». Разработчики предпочли сократить заголовок, но сохранить завитки

Среди доводов в защиту подобных завитков можно услышать «это стилистика, завитушка принесла атмосферу фэнтези». Да, резонно, но в условиях решения сложной задачи по приобретению пространства приходится быть требовательнее к элементам на экране.

Носители стилистической идентичности могут в то же самое время выполнять ещё какую-либо задачу, то есть «работать на двух работах». Например, завиток фэнтезийного типа одновременно разбивает пространство на зоны, или «сай-файное свечение» на одних элементах даёт понять, что эти элементы кликабельны в отличие от элементов без свечения. Поместить завиток ради завитка — непозволительная роскошь в условиях работы над интерфейсом мобильной игры.

Тезис «ни одного лишнего элемента на экране» не исчерпывается лишь крестовым походом против условных завитков. Убирание лишних элементов иногда может касаться даже не собственно элементов, а расстояний между ними. Вообще, пространство между элементами — это то, о чём следует думать не меньше, чем над самими элементами. Качество восприятия сложносоставных объектов определяется тем, сколько воздуха в них.

Таблица слева воспринимается гармоничнее, чем таблица справа

Получается некое противоречие, ведь мы знаем, что пространство мобильного экрана невелико, но хорошие воздушные отступы между элементами положительно сказываются на их читабельности. Возможным решением может показаться уменьшение самих элементов. Но это действие под запретом — мельчить на экране мобильного устройства нельзя.

Первое, что стоит сделать для решения задачи приобретения пространства — это внимательно изучить свои элементы. Если какая-либо информация появляется на экране более одного раза, почти наверняка она может быть вынесена за скобки.

Текстовая информация, превратившись в графическую, освободила место

Проверьте: если сложносоставной объект представлен последовательностью элементов, то нет ли возможности какой-либо из этих элементов переформулировать и представить его другим образом?

Выше описаны разумные способы приобретения пространства, интуитивно понятные многим проектировщикам. Теперь настала очередь «читерских». Главное условие их использования — ювелирность исполнения. И постоянное отслеживание воплощения на всех стадиях разработки, поскольку в командной работе всегда происходят коммуникационные потери. И есть опасность осуществления сценария «ювелирность + коммуникационные потери = топорность».

Наложение элементов друг на друга — своего рода использование третьего измерения экрана. Подобный приём не может быть применён к элементам, клики на которые обрабатываются отдельно. Здесь важно определить внешний вид каждого из участников наложения таким образом, чтобы они не мешали друг другу. Например, кто-то из них всегда тёмный, кто-то светлый.

Вкладка «Избранное» не подразумевалась на начальном этапе разработки. Из-за невозможности удлинить таббар мы воспользовались глубиной экрана

Ещё одно использование третьего измерения экрана — «отступы без отступов». Здесь мы пользуемся способностью человеческого мозга самостоятельно дорисовывать образ.

Ходовая единица проекта, многократно встречающаяся в определённом размере, может быть порезана маской сверху-снизу (слева-справа) для какого-то конкретного окна. Её узнаваемость сохранилась: для пользователя это ровно та же самая картинка. Возможная альтернатива этому действию — пропорциональное уменьшение — иногда рискует потерять в площади клика и в целом выглядеть неприглядно.

Итак, перечислим последовательно стратегии, помогающие преодолеть трудности с небольшими экранами.

  • Зонирование.
  • Соответствие выбранной ориентации устройства.
  • Пространство за пределами экрана мобильного устройства.
  • Количественный минимализм.

Если разработчик UI мобильного проекта грамотно распоряжается своим экранным пространством, то он приобретает большую свободу в других аспектах.

Большое количество потенциальных фичей

Основной геймплей вашего проекта — это сердцевина, которая может обрасти метагеймплейными фичами в каком угодно количестве. В этом заключается суть развития проекта. И каждая вводимая фича должна органично вписываться в имеющуюся систему, быть её логичным продолжением.

Можно выделить четыре группы стратегий, помогающих работать над UI растущих проектов.

  • «Хрустальный шар».
  • Стандарты и шаблоны.
  • Гайд.
  • Навигационная свобода.

«Хрустальный шар»

Представьте, что вы работаете над UI игры какого-то определённого жанра. Если это не первая в мире игра-представитель этого жанра, то у вас есть великолепная возможность ознакомиться с играми-предшественниками. И почти наверняка большая часть фичей из этих игр будет и у вашей игры. А это значит, что на начальном этапе проектирования своего UI вы сразу учитываете всю сумму этих фичей. Отсюда и название этой стратегии — «Хрустальный шар», вы заглядываете в будущее и готовитесь к нему.

В каком-то смысле любая разработка придерживается стратегии предсказывания фичей, ведь существуют планирование и дорожные карты. Но при работе с UI это предсказывание должно стать очень конкретным. Вплоть до того, что вы размещаете в своих макетах прототипы пока ещё несуществующих фичей, резервируете для них место. И чтобы не запутать самого себя и ваших коллег, чётко разграничивайте актуальные на данном этапе сущности от тех, которые появятся потом.

Разумеется, наступившее будущее будет не таким, каким вы его ожидали. Потому что рабочие процессы внесут свои коррективы, некоторые фичи так и не будут введены. Но ваша подготовленность в любом случае облегчит вам работу.

Стандарты и шаблоны

Если новые функции структурно похожи на уже имеющиеся, пользователю будет легче в них освоиться. Его внутренний диалог «а, я понял, здесь всё работает так же, как в мастерской» (например) — это хороший шаг на пути к пониманию. То есть при проектировании UI новой фичи не стоит изобретать велосипед — лучше воспользоваться имеющимся решением.

А это значит, что нужно иметь некоторое количество шаблонов, с помощью которых генерируются новые макеты. В идеале, услышав от продюсера описание фичи, UI-дизайнер сразу представляет, каким конкретно шаблоном он воспользуется.

Но работая с шаблоном не стоит забывать и о «разрыве шаблона». Стройные ряды однотипных окон могут сыграть с вами злую шутку, ваши фичи могут потерять свою индивидуальность. Поэтому после того, как вы воспользовались конкретным шаблоном, подумайте о том, что станет отличительным маркером этого фичи, её изюминкой.

Имеющийся шаблон позволяет генерировать новые окна, но с уточнениями

Гайд

Важность ведения гайдов сложно переоценить — это альфа и омега дизайнерских процессов. Но также это и необходимый участник масштабирования, поскольку в нем задокументированы правила расширения проекта.

Хороший гайд знает всё о крайних случаях, о пустых или слишком длинных списках. В хорошем гайде наглядно показаны все возможные сочетаемости всех элементов и все возможные состояния всех элементов. В общем, гайд знает ответы на все вопросы.

Но этот всемогущий гайд не отлит в чугуне и не возвышается на пьедестале. Он создаётся по принципу прецедента, то есть время от времени обновляется с появлением новых функций в вашей игре.

Фрагмент гайда

Навигационная свобода

Если однажды в вашей игре появятся кланы, чат, сезонные распродажи и тематические ивенты, нужно, чтобы пользователь смог туда пройти.

Потенциально мест, куда может захотеть переместиться пользователь, бесконечно много, поэтому нужен «бесконечный коридор». Конечность экрана кажется проблемой на пути решения этой задачи.

Чтобы преодолеть эту проблему мы можем:

Расширить экран с помощью свайпа. В игре «Star Wars Галактика героев» в центральной части главного экрана установлены объекты для взаимодействия, являющиеся по сути пунктами меню. Естественное движение свайпа обеспечивает быстрый доступ к этим пунктам.

Спроектировать сквозные переходы. Это актуально для смежных по смыслу фичей. Вообще если в какое-то окно пользователь может попасть строго через одну дверь, то это не очень хорошо для юзабилити. Если конечно речь не идёт о парадной двери.

Фрагмент информационной архитектуры условной игры. Красными пунктирными стрелками показаны сквозные переходы

Самое главное в процессе создания любого UI — это своевременный контакт с потенциальным пользователем. Очень важно на каждой из стадий разработки получать фидбек чтобы убедиться, что вы не увлеклись упрощением и ничего не потеряли.

Делать UI мобильных игр сложно. Часто нужно учитывать большое количество параметров и удовлетворять большому количеству условий. И иногда это взаимоисключающие условия. Надеюсь, что описанные в этой статье стратегии помогут другим разработчикам при проектировании UI.

#основы

{ "author_name": "Андрей Верещагин", "author_type": "editor", "tags": ["\u043e\u0441\u043d\u043e\u0432\u044b"], "comments": 30, "likes": 107, "favorites": 287, "is_advertisement": false, "subsite_label": "gamedev", "id": 44813, "is_wide": true, "is_ugc": false, "date": "Sun, 31 Mar 2019 12:15:55 +0300" }
Подкаст: эмоциональное
выгорание на работе
Слушать фоном🎧
{ "id": 44813, "author_id": 22254, "diff_limit": 1000, "urls": {"diff":"\/comments\/44813\/get","add":"\/comments\/44813\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/44813"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 64954, "last_count_and_date": null }

30 комментариев 30 комм.

Популярные

По порядку

Написать комментарий...
11

Таблица слева воспринимается гармоничнее, чем таблица справа

Мне вот наоборот справа больше нравится)

Ответить
0

Да ну, слеплено как-то. Вы же на телефоне будете это смотреть.

Ответить
0

На вкус и цвет. Я просто не люблю, когда слишком много пустого пространства. На мобилах это могу оправдать лишь тем, что есть шанс миссклика, когда элементы близко.

Ответить
2

И это конечно, и видно всё-таки лучше.

Ответить
0

Справа лучше, если эту статистику игрок будет видеть постоянно. Меньше усилий - сразу нужная информация по нескольким пунктам.

Ответить
0

Gabe, когда hl3 выйдет?!

Ответить
0

Мне тоже справа нравится. И паре знакомых программистов тоже. А вот почти всем остальным кого я знаю - нравится слева...

Ответить
7

А можно чуть подробнее про пример с вкладкой Избранное? Пытался понять разницу было/стало с учётом вводной про глубину, но не смог :(

А статья годная :) единственно что, я бы добавил схемы зон комфортного нажатия на мобильных устройствах. Бывает крайне полезно накладывать их поверх дизайнов

Ответить
4

Огромное спасибо за статью, пригодится — как раз корплю над мобильным интерфейсом :)

Ответить
4

Хороший UI - минимум UI .

Хотя кто то считает что любая игра - это набор UI шек.

Если честно шаблоны мобильных юи сильно привязаны к тому памяти игр - и я встречал очень мало проектов которые за эти шаблоны вылезали, но они как правило и были самыми запоминающимися .

Ответить
0

В идеале - да ... но все-таки «минимум» зависит от разных факторов, в числе которых непосредственная «насыщенность» игры и коммерческие цели, которые в нее заложены.

Ответить
4

"Разработчики предпочли сократить заголовок, но сохранить завитки"
Тут скорее всего как всё было. В английском языке фраза "Ежедневные Задания" звучала бы как-нибудь: "Daily Missions" или "Daily Quests", что занимает меньше места. Ну и чтобы не было этой пустоты по бокам, были влеплены завитки. А поскольку локализация обычно в последний момент делается, то не стали переделывать интерфейс ради русского языка, проще было сократить. На английском всё красиво должно быть.

Ответить
0

Да, это первая же и логичная мысль - разработчики не стали менять UI под локализацию.

Ответить
1

На мой взгляд - часть решений просто абсурдные и противоречат всем "канонам" типографики и верстки. Кнопки местами скомканные, слипшиеся. В примере с плюсами, есть ощущение, что область тапа некомфортной стала, что смертельно для мобилок. Из неплохих решений (однако крайне очевидных для любого человека, работающего с текстом (даже не дизайнера вовсе)) - изменение настроек и немного обрезанные картинки мехов.

Ответить
0

Статья очень полезна, многим разработчикам будет полезно. Ещё вот интересно, зачем разработчики каких-нибудь стратегий или игр на донат, сразу вываливают все функции и возможности на игрока. Тот же Star Wars мобильный, зачем наполнять весь этот бар ненужными персонажами, но делать их типа недоступными (как вариант их можно изначально убрать, а потом по ходу открытия добавить). Таким образом игрок не будет всё время видеть то, что ему недоступно (но тогда с другой стороны у него не будет мотивации что-то открыть). Но меня лично это напрягает. Это даже можно "сюжетными заданиями" обусловить как-то, типа если игрок выполнил определенное задание, по освобождению персонажа и тот появился на главном экране. Приятно, виден прогресс и до этого не раздражало. Но многие разработчики идут по более простому пути.

Ответить
2

Чувство прогрессии. Если игрок видет, что что-то не открыто, что какая-нибудь цель не достигнута, то есть шанс, что он вернётся и продолжит изучать игру.

Ответить
1

зачем наполнять весь этот бар ненужными персонажами, но делать их типа недоступными

Именно для того, чтобы сразу ввести игрока в курс дела. Многим не нравятся куцые/простые игры, поэтому такие приёмы нацелены на хардкорную аудиторию, а казуальщики-минималисты всё равно отвалятся.

Ответить
0

Делать UI мобильных игр сложно

А под пеку проще? Рисовать кучу ненужных, бесполезных элементов

Ответить
1

Везде своя специфика и свои сложности. Сложно и то и то)

Ответить
0

Боги! У этого лонг-рида есть аудио версия!

А можно сделать это стандартом DTF и обязательным требованием для матрасов текста превышающих N знаков? Ну дядя глав-ред, ну позязя!

Ответить
0

Тут очень хорошо материал сверстан - много картинок с комментариями. Я их посмотрел и остался доволен.

Ответить
1

Всё сделано для "клиента".
Как, собственно, и интерфейсы. В итоге годная вёрстка, и аудио-версия, и пикчи — всё это следы проф-деформации автора,)

Ответить
0

"Ведущий UX и UI-дизайнер студии Azur Games Екатерина Кузьмичёва написала для DTF колонку об основных принципах" а статью запостил совершенно иной человек, меня всегда это смущает, вот и теперь я не могу понять кто автор статьи и материала в ней. Почему Екатерина сама не разместила статью на DTF?

Ответить
0

Почему смущает? У нас оба сценария работают. Кто-то постит сам сразу, а мы подхватываем и редактируем. Кто-то сначала советуется — тогда мы помогаем сделать текст лучше и выводим сами. Тут кому как удобнее :) Мы-то всегда рады помочь с текстом.

Ответить
0

Так основная причина, по большей части - вывод в соц. сети?

Ответить
0

Нет, соцсети тут ни при чём — это просто дополнительный канал распространения материала, не стоит на него ориентироваться. Я же говорю — тут кому как удобнее. Просто если принести текст сначала нам, то мы можем его вернуть, попросив что-то переделать, дополнить и тд. Если сразу запостить, то мы будем работать с тем, что есть.

Ответить
0

Понятно. Ещё уточнить хотел, а в каких случаях авторство статьи меняется? К примеру, в этой статье я перестал быть автором. Я не против, собственно, просто хотел уточнить, когда редакторы просто правки вносят, а в каких случаях авторство меняют.

Ответить
1

Если мы сильно переделываем материал (и от автора там ничего не остаётся почти), то ставим «спасибо за наводку». Лайки в таком случае идут автору в карму.

Ответить
0

Меньше шанс, что захейтят.

Ответить
0

Игра «Великий Султан». Разработчики предпочли сократить заголовок, но сохранить завитки

На самом деле, это предпочли сделать локализаторы. В оригинале написано Daily Rewards, так как этот текст там помещается спокойно.

Ответить
0

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "clmf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fjog" } } }, { "id": 10, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "clmf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-250597-0", "render_to": "inpage_VI-250597-0-1134314964", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=clmf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudo", "p2": "ftjf" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fzvc" } } } ]
Узнавайте новости о мостах
Санкт-Петербурга первыми
Подписаться на push-уведомления