Gamedev Андрей Верещагин
5 444

Создание графики в мобильной RPG Age of Magic

Опыт разработчиков из студии Playkot.

В закладки

24 мая на iOS вышла RPG Age Of Magic о сражениях героев в умирающем фэнтезийном мире. Разработчики игры из компании Playkot написали для DTF колонку, в которой рассказали о том, как создавалась графика и анимация.

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

Как и в любом проекте, работа над локациями, моделями, персонажами и эффектами начинается с текстового описания концепта, референсов и скетча.

Вот, например, арены
Первые скетчи могут быть разными по степени проработанности

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

Отдельную боль вызывает «ровность» земли. У каждого персонажа чётко заданное место на арене и 90% времени персонаж его не покидает. Много внимания мы уделяем тому, чтобы именно на своих заданных местах персонажи не проваливались и не летали. К этим позициям также привязываются эффекты, и тут порой случаются неприятности.

Конечно, такую неприятность легко исправить, но на это тратится время. Главное, чтобы полностью плоская и ровная поверхность земли не смотрелась «плоской», а имела интересный рельеф.

Для минимизации количества технических багов во время работы для всего арта существует суперполезный документ под названием Art Bible. Он содержит в себе требования ко всей графике: силуэты персонажей, общий вид элементов, топология 3D-моделей, текстуры и многое другое.

Пайплайн.

Процесс создания 3D-ассетов персонажей и арен состоит из нескольких этапов.

Концепт-арт от художников, описание от геймдизайнера. Всех персонажей и арены мы придумываем и рисуем исключительно внутри офиса, на стадии 2D-скетчей, не отдавая на аутсорс. Идеи для героев рождаются внутри команды. А некоторые персонажи имеют реальные прототипы внутри компании.

Плутовка Цуна обязана внешностью и характером Вике — Community арт-лиду Age of Magic

3D-скетч, сделанный в Zbrush, Maya или Max. Обычно мы делаем его для персонажей, которых отдаём на аутсорс. Такой подход помогает сократить количество правок, а особенно полезен для арен, так как позволяет сразу настроить положение геометрии под игровую камеру и подобрать общую композицию.

На примере главного меню: концепт, 3D-скетч, финал

Финальный скульпт в Zbrush. Здесь мы смотрим на попадание в образ 2D-скетча, а именно: форму, пластику, проработку.

Пример финального скульпта одного из наших героев

LowPoly. изначально мы ориентировались на 5 тысяч tris (±тысяча) на персонажа (целевым устройством был iPhone 5S), но сейчас мы повышаем лимит до 7 тысяч.

Запечённый заранее Vertex Occlusion учитывается шейдером и улучшает финальную картинку.

Vertex Occlusion

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

Персонаж Лаки

Запекание, текстуринг. Эта часть сильно изменились с момента запуска проекта. Изначально мы «пекли» в XNormal, а текстуринг был сделан в Zbrush (Polypaint), Photoshop, Bodypaint или 3DCoat. Основным требованием было попадание в стиль, и мы не ограничивали художников в инструментарии.

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

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

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

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

Каждая сцена освещена четырьмя источниками света.

  • AmbientLight, использующий заранее запеченный occlusion.

  • KeyLight — основной источник света. Для него эмулируется IndirrectLight, отраженный от арены свет, падающий на персонажей.

  • RimLight — контровый свет для дополнительной подсветки персонажей.

  • FXLight — источник, дающий свет от эффектов, появляющихся на арене.

Для KeyLight рендерится две карты теней. Первая, со статичными объектами, рендерится один раз при старте арены, а вторая, включающая в себя движущиеся объекты (персонажей), рендерится каждый кадр перед основным проходом.

Свет и шейдинг без текстур цвета

Шейдинг. Большинство материалов в игре использует один из двух универсальных шейдеров: шейдер для персонажей и более простой шейдер для арен. Каждый шейдер содержит несколько вариантов для устройств разной производительности.

Вертексный шейдер небольшой: подготавливает вектора для чтения нормалей из normalMap, вычисляет UV-координаты для чтения из карты теней, и считает затухание источников света и силу тумана.

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

Постобработка. После шейдинга накладывается виньетка (затемнение по краям кадра) и происходит общая цветокоррекция картинки: устанавливается уровень чёрного, яркость, тонирование, и насыщенность цветов.

Финальное изображение

Все настройки света и цветокоррекции сцены глобальны и вынесены в один объект, RenderSettings, поэтому мы можем кардинально менять внешний вид всей арены (например из дневной арены делать вечернюю и ночную), изменяя лишь настройки рендера.

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

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

Парящие болота, Чертог королей, Звёздное озеро

Мы активно работаем над уменьшением размера билда. Для этой цели созданы скрипты, которые проходят по всем материалам и объединяют текстуры по каналам. Так Specular Map и Emission будут упакованы в альфа-каналы NormalMap и ColorMap.

VFX

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

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

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

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

Инструментарий эффектов

Отдельно стоит рассказать о внутреннем инструментарии, для создания, настройки и тестирования эффектов. Художники по эффектам могут открыть любую арену, выбрать персонажа (или подключить нового в режиме игры) и сразу же просмотреть сколько угодно раз, в том числе и покадрово, любой эффект или подключить новый.

Каждый персонаж содержит менеджер эффектов. Все эффекты завязаны на события в анимациях персонажей. Есть гибкая настройка целей, по которым должен срабатывать эффект: сам персонаж, один враг или все враги, все союзники, центр арены и так далее.

Далее настраивается тип эффекта. У нас есть механики простого эффекта без цели, механика снаряда, луча, и ещё несколько. Каждый тип содержит свой набор параметров, таких как: имя пустышек внутри персонажа, куда должен цепляться эффект, время жизни эффекта, после которого нужно удалить его и так далее. Зачастую, при создании эффекта, приходится комбинировать типы друг с другом, включать одни внутрь других.

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

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

В пайплайне разработки эффектов, для прототипирования шейдеров мы использовали ShaderForge (версии Unity 2018 года с редактором шейдеров «из коробки» тогда ещё не было). ShaderForge помогает ускорить процесс, когда надо быстро получить и протестировать необходимую механику для какой-то части эффекта, смещение текстуры по времени или от цвета вершин, её искажения по другой текстуре или по полярным координатам и тому подобное. И если эта механика подходит, то тогда мы оптимизируем шейдер по коду для дальнейшего использования.

В отличие от старых версий, где приходилось писать дополнительные скрипты для контроля каких-то параметров, сейчас сама система частиц в версии Unity 2017 года позволяет делать очень много. Наконец-то позволили раскрыть её потенциал такие возможности, как использование мешей вместо билбордов и настройка их ориентации, в том числе по вектору скорости (тут вспоминается много боли в старых версиях), или проигрывание анимированных атласов на мешах вместо частиц.

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

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

В результате из 3D-редактора были взяты два меша вороны: с опущенными крыльями и с поднятыми. Вектор смещения для каждой вершины из одного кадра в другой был записан как цвет для этой вершины.

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

Другое применение эффекта — можно надуть персонажа и взорвать его. Такой изощренный способ смерти был реализован у Библиотекаря.

Финальный вид эффекта

Некоторые локации поставили ещё одну интересную задачу: показать глубину и толщину воды и льда. Лёд — это непростой для рендеринга материал, он полупрозрачный, имеет объём и неоднородную внутреннюю структуру (трещины).

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

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

Немного про анимацию

Всё начиналось с кастомных ригов. То есть с ригов, которые собирались полностью руками. С нуля. Да, возможно работало не совсем так, как надо, но зато мы пришли к пониманию того, каких моментов стоит придерживаться, где можно сократить количество костей, а где, наоборот, добавить. В данный момент, большая часть ригов персонажей основана на авториге advanced skeleton. Многие его недолюбливают — и напрасно. В основном ругают за то, что он тяжелый, много лишнего, но на самом деле, всё ненужное можно отключить при сборке рига.

Хотелось бы сказать о его плюсах:

  • базовый скелет собирается крайне легко;

  • чтобы добавить кость для пропсов, оружия или ремней, достаточно вложить её в иерархию заготовки;

  • не надо думать об ориентации костей;

  • в любую цепочку костей в готовом риге можно нажатием всего одной кнопки добавить атрибуты переключения между координатами, ik/fk, перекручивание, сгибание.

Если вам доводилось работать с мобильными играми, то вы наверняка сталкивались с ограничением в 50 (иногда 48) костей на персонажа. Это требование, конечно, справедливо, если у вас на экране находится действительно много персонажей, но у нас их не более 11, а значит им можно и пренебречь И всё же, надо держать в голове, что «чем меньше, тем лучше». В среднем у нас 50-60 костей на персонажа, только если это не эпичный босс с кучей деталей. В таких случаях их количество может перевалить за сотню.

Все персонажи экспортируются в Unity с одинаковой (насколько это возможно) иерархией и неймингом костей.

Совет: иерархию всех костей лучше хранить на одном уровне, без вложений друг в друга.

Сам же пайплайн анимации не отличается от большинства проектов.

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

Совет: во время анимации мощного и размашистого удара мечом, лучше менять ноги в один-два кадра.

Базовая атака Атилеса

В отличии от игр от третьего лица или платформеров, где персонаж постоянно бежит или ходит, в Age of Magic главное внимание следует уделить idle-анимации персонажа, так как в этом состоянии мы его видим большую часть времени. Через анимацию мы стараемся передать характер персонажа, который нам описали. Здесь опираемся на текст и на силуэты и позы, которые пришли от художников.

Есть ещё одна очень важная для каждого из героев анимация — анимация смерти. В неё также можно внести частичку характера, и, кстати, у неё не очень жёсткие ограничения по продолжительности, а значит можно разгуляться по полной.

Все собранные анимационные файлы собираются в префаб персонажа с довольно простым контроллером.

Пример типичного анимационного контроллера персонажа в игре

Катсцены

Уникальной составляющей нашей игры являются катсцены между актами.

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

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

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

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

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

#опыт #арт #графика #мобайл

{ "author_name": "Андрей Верещагин", "author_type": "editor", "tags": ["\u043e\u043f\u044b\u0442","\u0433\u0440\u0430\u0444\u0438\u043a\u0430","\u0430\u0440\u0442","\u043c\u043e\u0431\u0430\u0439\u043b"], "comments": 17, "likes": 58, "favorites": 31, "is_advertisement": false, "subsite_label": "gamedev", "id": 21041, "is_wide": true, "is_ugc": false, "date": "Mon, 11 Jun 2018 11:17:21 +0300" }
{ "id": 21041, "author_id": 22254, "diff_limit": 1000, "urls": {"diff":"\/comments\/21041\/get","add":"\/comments\/21041\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/21041"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 64954, "possessions": [] }

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

Популярные

По порядку

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

"Мы активно работаем над уменьшением размера билда. Для этой цели созданы скрипты, которые проходят по всем материалам и объединяют текстуры по каналам. Так Specular Map и Emission будут упакованы в альфа-каналы NormalMap и ColorMap."

Степень сжатия альфа канала зависит от формата текстур которые используются(якрий пример 1 битная альфа, которая отвечает только за Есть Спекуляр/Нет спекуляра). Никто не мешает хранить текстуры в РГБ канале с таким же количеством бит. Поэтому некорректно приводить в пример "уменьшение размера билда" - это делается для уменьшения количества вызовов прохода рендера (DrawCall/SetPass), каналы будут браться из одной текстуры и соответственно в этом будет экономия. А чтобы экономить именно "размер билда" - гораздо эффективнее хранить спекуляры и эмиссии в файлах - которые меньше по размеру: 128*128 вместо 1024*1024(для эмиссии очень часто такого уменьшения достаточно без потери качества, со спекуляром сложнее, но он тоже поддается уменьшению без потери визуального качества от эффекта).
За АО в вертекс колоре отдельное спасибо) но можно не забывать о том что есть ещё и РГБ цвет и в него можно запекать колорблидинг, а не просто чернобелое затенение как в случае с АО.
В целом было интересно, почаще бы выкладывали подобный материал для просвещения независимых разработчиков у которых нет возможности обучаться в рамках студий :)

Ответить
4

Мы используем текстурную компрессию с фиксированным размером на пиксель (PVRTC 4bpp, ETC2 8bpp), т.е. перенос спекуляра в альфа канал не влияет на её размер, а значит уменьшает общий. )
Для сценариев, когда нам нужно больше 2х дополнительных каналов, используем дополнительную текстуру, меньшего разрешения.
Основной шейдинг у нас однопроходный, т.е. "уменьшения количества вызовов" не происходит, максимум можно получить - выигрыш в количестве чтений из текстуры. Но, учитывая префетч, вероятность "почувствовать" его на практике очень мала.

Ответить
0

я бы это добавил в статью )

Ответить
0

По возможности будем дополнять в комментариях )

Ответить
4

Очень красивые персонажи. И концепция, и реализация.

Ответить
2

Крутая статья. Арт в игре, конечно, топовый.

Ответить
2

Хорошо и красиво сделанная игра) Прям статью приятно читать.

Ответить
0

Ещё одна красивая, но беспонтовая гриндилка с пылесосом для бабла.

Ответить
1

Хорошая статья. Вроде и реклама, а много полезной информации.

Ответить
1

Ребята молодцы) и статья хорошая

Ответить
0

Пардоньте, а про какую Art Bible речь идет? Внутреннюю или же это как-то массовый продукт на книжных/диджитал полках?

Ответить
0

Внутренняя, описывающая стилистические и тех особенности для создания ассетов.

Ответить
0

Жду не дождусь, когда Юнити сможет эмитить анимированные меши в партиклах. Надоело придумывать обманки и плясать с бубном, чтобы это реализовывать :).

Ответить
0

Что даже ассетов таких нет в юнитисторе? В УЕ4е же такая функция есть из коробки, емнп.

Ответить
0

Ассеты может и есть, но они имеют привычку переставать работать при портировании игры на другие платформы. Например с ПК на мобилки. Поэтому подход пуристский с эффектами. Почти все на дефолтных шейдерах и минимум скриптов :). Это тот еще челлендж.
Можете читнуть статейку по эффектам, что я писал тут. Кликнув на мою аватарку - там все будет.

Ответить
0

Даже персональный хейтер появился - сразу видно, определённый уровень набит)

Ответить
–1

Playkot написали для DTF колонку, в которой рассказали о том, как крали персонажей для очередной дрочильни для телефонов отовсюду :)

Ответить
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-уведомления