Чем отличается разработка игр от разработки «обычных» ИТ-проектов

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

Разница в том, что делаем

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

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

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

We have to be predictable — сказал мне один топ-менеджер Electronic Arts, и это — чистая правда. Каждый день опоздания с выпуском игры может стоить вам десятки миллионов упущенной прибыли или уходящего впустую маркетингового бюджета. Совмещение несовместимого — неопределенности результата с его предсказуемостью — накладывает отпечаток на производственный процесс.

Классический цикл производства вплоть до запуска игрового проекта выглядит таким образом: Idea Generation, Pre-production, Production, Finaling. Эти стадии отличаются составом команды, артефактами и даже подходом к управлению. Если на этапе Pre-production вполне уместна гибкая разработка, то на этапе Production лучше использовать классические методологии.

Основной принцип — раннее прототипирование. Все, что вызывает вопросы, должно быть реализовано как можно раньше. Это заметно снижает цену ошибки. При этом понятие «раннее прототипирование» надо рассматривать достаточно широко. К примеру, делаем игру типа Diablo. В игре есть риск — получить неинтересную боевку. Для того, чтобы оценить эту самую интересность, надо очень много вложиться в production — надо, чтобы был готов персонаж, чтобы были готовы враги (желательно несколько разных), чтобы была настроена обратная связь — визуальные и звуковые эффекты, чтобы был сделан HUD, чтобы была сделана система ревардов. Причем все это должно быть сделано на уровне качества, близкому к финальному, иначе в комплексе не оценить. Поэтому «раннее прототипирование» — это и alpha-beta-версии, и soft launch. 

Разница в команде

В «обычных» ИТ-компаниях, занимающихся разработкой хоть b2b, хоть b2c софта, привычный состав проектной команды примерно таков: 

  • менеджер (зачастую, он же и product owner);
  • аналитики;
  • тестировщики;
  • программисты; 
  • UI-дизайнеры. 

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

Рассмотрим, для примера, игру типа Clash of Clans. Для производства этой игры потребуются:

  • продюсер или менеджер-проекта (хотя зачастую эти роли разделяют, и не зря); 
  • гейм-дизайнеры (в разработке оригинального Clash of Clans гейм-дизайнеров не было, но это скорее исключение); 
  • команда маркетинга (да-да, на стадии разработки); 
  • хорошие математики для подсчета баланса (могут быть включены в команду гейм-дизайна); 
  • 2D концепт-артисты для отрисовки всех игровых элементов; 
  • 3D моделлеры для моделирования игровых объектов (хоть игра и 2D, зачастую дешевле отмоделить все в 3D, а потом делать в Maya или 3D Max скриншоты этих моделек в нужных ракурсах); 
  • аниматоры — 2D или 3D, в зависимости от выбранной технологии; 
  • художники по спецэффектам; 
  • звукорежиссер или звукоинженер; 
  • технический художник — человек, который собирает воедино труды всех художников и моделлеров в игровую сцену, коммуницирует с программистами;
  • тестировщики; 
  • наконец, программисты (клиентские, серверные, на тулсет и аналитику).

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

Мне приходилось сталкиваться с ситуациями, когда художники с программистами не общались никак, а гейм-дизайнеров ни те, ни другие вообще за людей не считали. Ситуация усугубляется тем, что менеджер обычно вырос из какой-то одной из областей (арт, гейм-дизайн, программирование) и имеет ту же самую «родовую травму» в коммуникациях (автор материала, что греха таить, тоже).

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

Однозначного рецепта, как быть, тут нет. Но общие рекомендации такие:

  • Ничего не делать не получится. Не стоит надеяться, что все организуется само собой, потому что люди, де, адекватные каждый по отдельности. 
  • Основа основ — неформальное общение и горизонтальные связи. Методологии типа FDD (адаптированной), понятие «игровая фича» и ее владелец — очень важные возможные способы, но основное, что надо стараться делать, — всеми доступными методами провоцировать общение между разными специалистами. К таким методам не в последнюю очередь относится правильная рассадка людей в офисе, а именно — люди, которые должны коммуницировать между собой, должны сидеть рядом. И не беда, если получится, что программист сидит ближе к художнику, чем к другому программисту. 
  • Формальные методы. Их успешное применение может привести к тому, что они станут не нужны, но на первых порах они обязательны. К ним относятся собрания, в которых принимают участие специалисты из разных областей, статус-апдейты в почту и многое другое. Ежедневные и еженедельные собрания лидов, спонтанные собрания людей, работающих над одной «фичей» и прочее. 
  • Сильный лидер. Его задача — формирование в коллективе дружественной атмосферы. 
  • Тим, простите, билдинги. 
  • Ну и не бойтесь увольнять. Бывают такие крайние ситуации, когда надо уволить даже сильного специалиста, просто потому, что он делает отношения во всем коллективе просто невыносимыми.

Разница в подходе

Игра, в особенности если это своя игра, а не заказной проект — это круто. Это то, о чем мечтало большинство разработчиков в детстве, играя в Doom, или художников, играя в Far Cry и WoW. Но еще это и бессонные ночи, это кранчи, это выходные, проведенные на работе. Причем «добровольно и с песнями». Кранч в игровой индустрии — это не исключение, это правило. И с этим ничего нельзя поделать — из-за той самой неопределенности результата, о которой мы говорили выше. Позволю себе еще одну цитату: «Если вы думаете, что сможете работать по 8 часов и без кранчей — вы пришли не в ту индустрию». Это правило не всегда применимо к другим IT-проектам и другим IT-специалистам.

Разница в культуре разработки

Как ни странно, уровень применения обычных инженерных практик, таких как continuous integration, automated testing, да и вообще тестирование, а иногда даже и просто использование системы контроля версий, в игровой разработке достаточно низок. И тому есть причины. 

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

К примеру, скрестить Jenkins и Unity — задача решаемая, но не совсем простая. Что уж говорить об автоматизации тестирования. В силу этих причин те процедуры, которые можно встретить даже в небольших ИТ-компаниях, в игропроме применяются только в больших корпорациях, да и то не во всех, особенно в России. Эта недооценка, кстати, вызывает взаимное чувство у профильных специалистов (билд инженеров, QA), которые не хотят идти в игропром, где их не будут ценить и будут мало платить.

Разница в технологиях

Игра — сложный и комплексный технологический продукт. В текущих реалиях, как правило — клиент-серверный. Если повезет, то высоконагруженный. Иначе говоря, все эти миллионы треугольников, разваливающиеся на куски дома и сотни тысяч взаимодействующих друг с другом CCU — это все технологически очень сложная задача. Да, и все это происходит в режиме реального времени. 

Можно без преувеличения сказать, что игры во многом — на переднем крае технологий. У этого есть и обратная сторона — тут не любят, да и просто нет возможности использования «высокоуровневых» техник. Начиная с модных языков программирования (до сих пор самый востребованный язык программирования в игропроме — С++), заканчивая даже такими вещами, как использование стандартной библиотеки или специфических алгоритмов и структур данных.

Разница в результате

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

Тема эта очень холиварная и зачастую непростая для понимания даже опытных разработчиков и менеджеров. Я не призываю писать плохой код, не призываю не придерживаться заведенных практик, но всегда помните о цели. Иногда цель «в дальнейшем будет проще поддерживать» — ложная. Давайте делать хорошие игры, а не хорошие библиотеки легкоподдерживаемого кода. То, что придется нанять 50 дополнительных индусов, чтобы выпустить вторую версию игры — не важно, если ваша первая версия заработает $1 млрд. Или 0,1% от этой суммы.

Давайте делать хорошие игры.

#Рынок_игр #разработка #разработка_игр #игровая_индустрия

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

Написать
{ "author_name": "Илья Пшеничный", "author_type": "self", "tags": ["\u0440\u044b\u043d\u043e\u043a_\u0438\u0433\u0440","\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430_\u0438\u0433\u0440","\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430","\u0438\u0433\u0440\u043e\u0432\u0430\u044f_\u0438\u043d\u0434\u0443\u0441\u0442\u0440\u0438\u044f","gamedev"], "comments": 42, "likes": 23, "favorites": 1, "is_advertisement": false, "subsite_label": "flood", "id": 4897, "is_wide": true, "is_ugc": true, "date": "Wed, 03 Sep 2014 12:24:33 +0400" }
{ "id": 4897, "author_id": 3677, "diff_limit": 1000, "urls": {"diff":"\/comments\/4897\/get","add":"\/comments\/4897\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/4897"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199791 }

42 комментария 42 комм.

Популярные

По порядку

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

зачОтно. все именно так и обстоит. прочитал-понравилось

Ответить
2

Хорошая игра — важно. А хороший код — простите, но нет

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

Ответить
1

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

Ответить
0

Тут можно было сказать иначе так:

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

Ответить
2

Очень грамотно описано. Издержки на создание простенькой игры гораздо выше, чем на создание очередного хипстер-сервиса.

Ответить
2

Приятно читать -- внятно и красочно изложено. Спасибо!

Ответить
2

а про сценаристов опять забыли )

Ответить
0

Внесем их в группу гейм-дизайнеров, ок? :)

Ответить

Комментарий удален

1

Конкуренции нет, если сравнивать с обычным ПО.
У вас есть один гмайл, одна ОС, один календарь, одна ЦРМ, один сервис для бухучета. У очень малого количества ниш есть чего-то по два (в основном месенджеры и соцсети).

У игр, если игра хорошая, то ее купят и позже, когда пройдут ГТА 5.
Тут конкурент это конкурент на неделю.

Ответить
1

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

Ответить
1

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

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

Ответить
1

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

Ответить
2

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

PS Я не беру в расчет CoC или Boom Beach — я в ф2п не понимаю, поскольку не ЦА. Я скорее про приставки и стим.

Ответить
0

ритейловые издатели не согласятся с вашим подходом к конкуренции)

Ответить
0

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

Ответить
0

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

Ответить
3

Очень поверхностное утверждение

Ответить
1

Брр. Вы точно занимаетесь играми?

Ответить
1

чувак просто ведёт блог про игру Rust, он не её разработчик и даже не тестер :)

Ответить
0

думаете бейдж ошибочно выставлен юзеру как разработчику rust? я что-то даже не подумал что речь может быть об этом, подумал о каком то другом расте)

Ответить
0

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

Всё равно, что я сейчас блог по half-life 3 забубеню на WordPress и радостно припишу его рядом с именем :)

Ответить
0

Ваша фантазия и реалии рынка могут быть осень далеко друг от друга.

Ответить
0

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

Ответить
0

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

Ответить
1

Ох как знакома проблема непонимания между членами команды тех/арт отдел. Потому считаю что мой рост в ГД из тех.дизайнера(скриптование/сборка сцен/нарезка текстур) дал очень хорошие возможности по налаживанию коммуникации между этими отделами.

Ответить
1

Очень хороший текст. Спасибо.

Ответить
0

Что такое обычный ИТ-проект?

Ответить
1

Наконец-то :))
Только не обычный, а "обычный". Не бывает же, скажем, обычных музыкантов. Или программистов.

Ответить
1

Я к тому, что есть разница между сверлом по металлу и сверлом по дереву, как и в подходах сверления. Заголовок не удачный, статья интересная.

Ответить
0

*..всегда есть и она очевидна..

Ответить
0

Один вопрос - а проекты автора статьи можно увидеть?

Ответить
0

Можно :)
FIFA Street (PS3, X360)
Sims 4 (PC)
Wheels of Destruction (PS3)
Smash Cars (PS3)
Wakeboarding HD (PS3)
Alone in the Dark (NDS, PSP) - не вышел, отменили
ATHF (PS2)
Coded Arms Contagion (PSP)
American Chopper 2 (PS2, XBOX, NGC)
American Chopper
Smash Cars (PS2)
Ну и по немногу - FIFA13, 14 и еще несколько
Это из игровых. Возможно, я что-то забыл

Ответить
1

А ваша роль в них?

Ответить
1

Снизу-вверх: программист, страший, ведущий, со-продюсер, продюсер, продюсер внешних команд

Ответить
0

Зачот.

Ответить
0

Я сорри, не очень в курсе, в мало что играл из списка - а что-то из этого фритуплей?

Ответить
0

Good point :)
Думаю читатели скажут спасибо, и мы сможем заметно повысить качество материала, если вы дополните положения статьи, основываясь на вашем опыте.

Ответить
0

Я просто уточнял для себя, потому что мне показалось, что в статье идет речь о законченной разработке коробочного продукта прежде всего. По сути о пайплайне изготовления контента. А фритуплей он не только про контент, он про то как "продать" контент и как сервис строить постоянно работающий - в этом его индустриальная уникальность.

Ответить

Комментарий удален

0

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

Ответить
0

Варианты решения местами там предложены. Не для всего правда. Но тут каждая тема - отдельная большая статья.

> Мне кажется большинство различий актуальны

> скорее для российского геймдева, на западе же...

Вы удивитесь :)

Ответить

Комментарий удален

0

Хорошо все описано

Ответить
0

"К примеру, скрестить Jenkins и Unity — задача решаемая, но не совсем простая. "

Почему?

Ответить

Комментарий удален

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": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "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" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "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": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&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": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } } ]
Нейронная сеть научилась читать стихи
голосом Пастернака и смотреть в окно на осень
Подписаться на push-уведомления