Вопросы sloa
767

Используете ли вы автотесты при разработке игр?

Небольшой опрос о том, как обстоят в геймдеве дела с автотестами.

В закладки

Здесь находится опрос. Но он пока не работает в приложении.

Используете ли вы автотесты для кода?

Проголосовать
Переголосовать
Показать результаты

Здесь находится опрос. Но он пока не работает в приложении.

Используете ли вы автотесты для игровых ситуаций?

Проголосовать
Переголосовать
Показать результаты

Здесь находится опрос. Но он пока не работает в приложении.

Используете ли вы автотесты для проверки размещения и наличия ассетов?

Проголосовать
Переголосовать
Показать результаты

Здесь находится опрос. Но он пока не работает в приложении.

Если автотесты есть, как часто они запускаются?

Проголосовать
Переголосовать
Показать результаты

Пока у меня сложилось впечатление, что автотесты в ГД считаются чем-то чуждым.

Мне попалось вот это видео от разработчика Retro City Rampage, но то, о чем он говорит - запись ввода - это каменный век по меркам автоматизированного тестирования.

Разработчик использовал специальный режим для тестирования игры

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

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

Материал опубликован пользователем. Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "sloa", "author_type": "self", "tags": [], "comments": 65, "likes": 15, "favorites": 13, "is_advertisement": false, "subsite_label": "ask", "id": 30274, "is_wide": false, "is_ugc": true, "date": "Mon, 29 Oct 2018 01:00:19 +0300" }
{ "id": 30274, "author_id": 15287, "diff_limit": 1000, "urls": {"diff":"\/comments\/30274\/get","add":"\/comments\/30274\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/30274"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 64961 }

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

Популярные

По порядку

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

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

Ответить
1

Мне вообще сама постановка вопроса (почему бы девелоперам не покрывать всё автотестами, тогда и багов в играх не будет) напоминает древний баян с письмом в NASA -- про почему бы им просто не заливать Ментос Колой, чтобы ракета быстро взлетала.

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

Ответить
0

Картинка забавная, но использование автотестов во всей остальной индустрии - уже стандарт. И только в гд, судя по всему, до сих пор дикий запад.

Ответить
2

Нигде это не стандарт. Тесты делают там, где компания может выделить время и русурсы на это. Это явно не про инди.

Плюс, время тестировщиков стоит дешевле, объективно. Поэтому даже крупным компаниям проще платить тестерам, чем тратить время разработчиков на тесты =/

Ответить
1

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

Ответить
0

И как оно? Часто шпыняют? :D

Ответить
0

Пффф... Мне всё же кажется, что с это ситуация из разряда "точить некогда - рубить надо!"

Ответить
1

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

Ответить
0

На интеграцию тесты тоже пишут.

Ответить
0

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

https://twitter.com/themalaru/status/1056328104031989761
А ты вот для этого хотя бы словами тест-кейс опиши :)

Ответить
0

Разместить объект на пути поезда.
Пустить поезд.
Проверить, что объект не покинул заданную зону.
Повторить для всех живых объектов.
А теперь скажи мне, сколько такая проверка займет руками и как часто будет проводиться.

Ответить
0

Разместить объект на пути поезда.

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

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

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

Ответить
0

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

Ответить
0

Вообще, если интересны какие-то эмерджентные события, то у разработчиков Slime Rancher было видео про то как они держали целую ферму компьютеров и круглосуточно отслеживали как новые изменения влияют на игру.

Ответить
0

Кстати, этот тест-кейс можно было бы выявить при помощи матрицы фич которую придумали в CDPR.

Ответить
0

На самом деле что вы тестировать-то ими собрались? В играх ок, ну интеграцию проверите, ну установку игры на жесткий диск. А как вы себе представляете автотесты игрового процесса?

Ответить
0

Ну, у тестов, с точки зрения проекта, есть четыре цели: спецификация, документация, страховка и локализация.
Спецификация: до начала разработки мы создаём тест, который объясняет, как оно должно работать.
Условный геймдиз рисует уровень, по которому будет бегать условный супер Марио и отдает его кодерам. И они твикают код до тех пор, пока он не начнет работать как надо.
Документация: тесты должны объяснять, как проект работает, или должен работать. То есть каждую новую механику имеет смысл оформить в виде демонстрационной камеры, в которой она демонстрируется и проверяется.
Страховка: то есть тесты должны вовремя сообщить нам что что-то сломалось. В идеале - до внесения изменений. Поэтому имеет смысл оформлять найденные и типичные баги и проблемы отдельными тестами, чтобы они не вылезли снова.
Ну и наконец локализация. Если тесты показывают что что-то сломалось, они должны также показывать, что и где надо чинить. Тут лучше смотреть по структуре проекта.
Плюс интеграция. Большие готовые игровые сценарии тоже надо проверять хотя бы на позитивный сценарий.
Я думал о том, что можно сделать дерево с несколькими исходами, позитивными и негативными, и сделать алгоритм, который пройдет по нему до каждой конечной точки по очереди.

Ответить
0

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

Ответить
0

В мире сейчас куча свободных фреймворков для тестирования, бери - не хочу. Про сложность обычно говорят те, кто неосилил. хех

Ответить
0

Ну да, действительно. Там же ИИ встроен, который за вас все тесты напишет.

Ответить
7

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

разве что на стадии некоего прототипа без лишних сущностей. но и там скорее речь будет про шустрого бота из talos principle как простую экономию времени (аналогия с цифровыми шахматами), нежели про привычные автотесты из it. иначе же — слишком много переплетенных механик и ассетов, чтобы лепить автоматизацию поверх этого и каждый раз грустно перезапускать после правки в коде/дизайне/геймдизайне/балансе/этсетера.

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

Ответить
0

дока

Простите.

Ответить
5

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

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

Ответить
0

неоптимизированные аналоговые куски мяса перед экранами

Отлично, этим я и заменю термин "человек"

Ответить
3

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

Ответить
0

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

Ответить
5

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

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

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

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

Ответить
1

да, "qa engineer walks into a bar..."

Ответить
–1

И тем обиднее наблюдать, как QA в индустрии считается аналогом разнорабочего на стройке -- случайный студентик/студенточка с улицы, которому сказали "на, покнопай, чтоб не падало", плюс еще за пиццей можно гонять :)

Ответить
1

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

Ответить
2

Я смутно подозреваю, что автоматизаторы как раз и ценятся, потому что воспринимаются как технические кадры, которые имеют специальные знания о технологии, с мудрёными фреймворками работают и код -- это вам не по экрану мышкой кнопать!

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

Ответить
0

Автоматизаторы ценятся из-за практики continuous integration and delivery, которая сейчас в моде.
https://ru.m.wikipedia.org/wiki/Непрерывная_интеграция

Ответить
0

То есть, для того, что девелопер и сам проверит, поклацав после внедрения.

Или забудет. Особенно если надо срочно, а все и так уже на ногах еле держатся.

Ответить
3

запись ввода - это каменный век по меркам автоматизированного тестирования.

Отчасти, чтобы на тестах была обычная человеческая реакция с ошибками и прочим, а не идеальное управление от ИИ

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

Черный ящик же - не все тесты должны знать правила игры

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

Т.е. ты фактически предлагаешь написать игровой ИИ. Ну-ка навскидку 10 игр, где ИИ играет хорошо и не попадает в нелепые ситуации, несвойственные людям?)

Ответить
0

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

Ответить
0

Ну так и твои тесты тоже не очень устойчивы. Придется проверять, что тест по-прежнему проверяет то, что он должен проверять (т.е. выполняет ли он кейс). А разработка такого теста будет много сложней

Ответить
3

Мне кажется, что игры просто созданы для автоматизированного тестирования

Игры хуже всего подходят для автоматизированного тестирования. Зависит от жанра, конечно. Но это ну никак не может быть проще, чем делать тесты на софт

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

Ответить
2

Очень обширный вопрос.
1. Unit тесты должны быть обязательными для онлайн проектов.
2. Большие онлайн проекты должны быть частично автоматизированы ботами, которые обвешаны маячками и логами.
3. Вся веб обвязка в виде магазинов, порталов и тд должна быть автоматизирована классическими средствами (Selenium)
4. Геймплей - только ручками. Тк тестирование на позитивный сценарий это макс 5% от тестирования функционала. Все прочее - это тестирование на негативный сценарий. А это врятли поддается автоматизации либо потащит за собой уйму трудочасов и тучу сотрудников.

Ответить
1

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

Ответить
1

Потому что за это не платят. Менеджеры частенько по рукам бьют, если ты заикнёшься про тесты или рефакторинг, ибо "а как же фичи?!".

Ответить
0

Когда же начнут бить по рукам менеджерам?))

Ответить
0

Когда хомяки поумнеют и перестанут скупать дерьмо на волне хайпа.

Ответить
0

Ну. Это мы уже проходили при обвале индустрии в 80е .

Ответить
2

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

Ответить
0

На твиче был чувак один, как ни зайду, пишет автотесты.

Ответить
0

Думаю, очень сложно их писать, вот и не пишут

Ответить
0

В gamedev все просто, пока по фану - это не баг, и наоборот. Поэтому формально потестить можно только часть систем.

Ответить
0

Всё же относительно игр нет лучше теста, чем обученный биоробот.

Ответить
0

Удалено

Ответить
0

О, адепт автоматизированного тестирования. Привет. Вот тебе две задачки на автоматизацию.
1. Проверить генератор псевдорандома на соответствие заданному распределению.
2. Проверить, что некоторое событие происходит с вероятностью 0.01% при условии выполнения игроком определенной последовательности действий.

Ответить
0

1. Взять сразу проверенный и не городить велосипедов.
2. Триггерить событие руками по специальному счётчику, если оно не выпало по рандому. Все равно игроки "честный" рандом не любят.
А дальше просто выполняем операцию 10000 раз и смотрим что все в порядке.

Ответить
0

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

Ответить
0

> 1. Взять сразу проверенный и не городить велосипедов.

Хорошо бы, но нет. Способ задания распределений у ГД столько же, сколько этих самых ГД. Так что обвязку вокруг генератора с равномерным распределением писать приходится в каждом отдельном случае. И это НЕ тестируется. Ни автоматически, никак. И это у меня еще максимально упрощенный и абстрагированный пример целого класса задач, которые приходится решать.

> 2. Триггерить событие руками по специальному счётчику, если оно не выпало по рандому.

Нет. Таким способом данный функционал не проверяется.

> Все равно игроки "честный" рандом не любят.

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

В разработке скольки выпущенных игр вы участвовали?

Ответить
0

Из комментов Сида Мейера и том, как он добавлял рандом в Цивилизацию. Или вы о гемблерах а не геймерах? Эти может быть и любят.
И нет, я не участвую в разработке игр, иначе бы я тоже тут в комментах писал "Автотесты? Зачем? Что за глупость? У нас есть Паша, он всё проверяет".
И почитайте что-нибудь про deterministic rng, у меня есть чувство, что ваш ответ где-то там.

Ответить
0

Собственно про рандом видео выше в посте. Посмотрите его. Там товарищ много говорит именно о том, как оседлал рандом.

Ответить
0

Смотрел. Не оседлал. Он писал игру вокруг автотестов по сути. Забавный подход, возможно работает для мелких мобильных казуалок, но что-то крупнее так не пишется. И да, это тот случай, когда плохие тесты хуже, чем отсутствие оных. Так что это не пример годного промышленного подхода, а пример странного эксперимента со странными же выводами, типа тетриса на брейнфаке.

Ответить
0

Мне нравятся слова "промышленный подход" в этом контексте.

Ответить
0

Да, игрострой - это промышленность. Как кино, театр и прочий энтертейнмент.

Ответить
0

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

Ответить
0

1. Это зачем xor или mersenne-twiester насиловать? При желании проблем нет - вопрос только в точности определения.
2. Тут вообще проблем никаких. С другой стороны Именно в геймдеве это может не иметь смысла, потому что более приятен и понятен для игроков псевдорандом (по типу шансов башей в доКе2 и т.п.).

Ответить
0

> 1. Это зачем xor или mersenne-twiester насиловать? При желании проблем нет - вопрос только в точности определения.

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

> 2. Тут вообще проблем никаких.

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

Ответить
0

Если честно - в шоке от результатов теста. Теперь понятно почему "кранчевание" от Rockstar на 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-уведомления