Игры на «Медузе»: как мы их придумываем, делаем и переиспользуем

Этот текст написал директор по инновациям «Медузы» Султан Сулейманов.

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

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

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

Дарвиновская теория игр

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

Как и в настоящем естественном отборе, не каждая игра доживает до второго или третьего этапа. Общая логика такая: если мы делаем игру на один раз, никакая админка ей не нужна: редактор может сдать тексты в табличке, дизайнер — нарисовать макет, а разработчик все это внедрит в игру своими руками. Тогда, разработчику приходится не только прорабатывать всю игровую логику и писать код, но и вносить в него тексты (иногда много текстов).

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

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

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

Этап 1. Новая механика

Подготовка

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

В любом случае дальше начинается обсуждение, цель которого — максимально подробно описать игру, которую мы хотим получить. Даже если мы делаем, скажем, «свой Flappy Bird», нам нужно проговорить каждую деталь: каким должен быть главный персонаж, как выглядят препятствия, что они символизируют? Что будет, если игрок врежется в столб, — а что, если он дойдет до конца? И есть ли вообще в игре конец? Наконец, что мы покажем человеку, чтобы он захотел поделиться своим результатом с друзьями в соцсетях?

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

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

Главная составляющая шаблона — список из 54 задачек (или «тудушек»), каждая из которых должна достаться кому-то из команды. Задачи разбиты на девять блоков, выполняемых последовательно. Вот эти блоки:

• Сбор требований и подготовка к проекту
• Контент
• Дизайн
• Разработка
• Техническое тестирование
• Редакционное тестирование
• Финальные правки
• Запуск
• Финал

Сначала идет блок общих задач по проекту: выбрать роли (кто будет дизайнером? Кто разработчиком? Кто менеджером?), финализировать описание, выставить дедлайны. Отдельная задача звучит так: «Идея согласована с главредом». Это итоги горького опыта: несколько раз мы брались за игру, забыв обсудить ее непосредственно с редакцией, и затем ее приходилось переделывать или выбрасывать.

Следующий блок задач связан с контентом: написание, согласование и корректура текстов. Когда они готовы, к работе приступает дизайнер. О том, как устроена работа дизайнера, рассказывает арт-директор «Медузы» Настя Яровая.

Дизайн

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

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

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

Хороший пример — игра про детство в 90-е. Чаще всего в играх мы работаем с рисованной графикой, а тут наш дизайнер Ярик использовал свой семейный архив с записями из 90-х. Получились коллажи одновременно со стилизованными и документальными фотографиями.

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

Разработка

Обычно разработчик приступает к работе, когда уже готов макет, — хотя иногда он может попробовать собрать прототип заранее. В списке задач для разработчика не только создание самой игры, но и проверка отправки статистики, заполнение метаинформации на странице, необходимой для ее корректного отображения в соцсетях, и другие детали. О том, как происходит процесс создания игры, рассказывает разработчик «Медузы» Алексей Прилепский.

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

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

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

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

После того, как игра готова

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

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

Выдыхаем?

Почти! В первые часы мы следим за статистикой игры — «полетела» она или нет. К сожалению, предугадать результат почти никогда не получается. То, на что мы потратили две недели кропотливого труда, может с треском провалиться. А тест, собранный за пять минут, — неожиданно выстрелить.

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

Этап 2. Повторное использование механики

На этом этапе мы не будем останавливаться подробно — только расскажем про нюансы. Главный из них такой: у редакции редко получается придумать игру, которая будет работать точно так же, как предыдущая. Даже если мы снова возвращаемся к «своему Flappy Bird, но про оскорбление власти», возникают детали, которые нужно явно проговорить в описании проекта: если на столбах теперь оскорбления, а не сердечки, как они должны выглядеть? Как вообще вписать текст на вертикальные столбы? Как теперь считать очки? В первой игре — про 14 Февраля — нужно было продержаться 24 уровня, символизирующих 24 часа. А как теперь? Таких нюансов может набраться много, и то, что редактору кажется мелочью, может потребовать пары дней работы разработчика.

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

Этап 3. Перенос игры в «Монитор»

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

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

О каких механиках идет речь?

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

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

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

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

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

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

Опрос — это механика, где нет правильных ответов и страницы с результатами. Читатели просто отвечают на серию вопросов, а мы анализируем их ответы.

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

Перенос механики в «Монитор» тоже происходит через Basecamp, но шаблон немного отличается — в нем, например, появляются пункты, связанные с API нашей админки. Дальше слово снова берут арт-директор Настя Яровая и разработчик Алексей Прилепский.

Дизайн

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

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

Разработка

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

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

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

Результат

Как мы уже упоминали, результат переноса механики в «Монитор» — в удобстве создания новых материалов. Круг причастных сужается до 2–3 человек: редактор пишет тексты (часто это вопросы, варианты ответов и результаты), заказывает фотографии или иллюстрации у фотодирекции и арт-дирекции, а затем отдает результат редактору.

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

Если вы соберетесь делать игры в своем медиа, учтите следующие моменты:

• За любым интерактивным форматом стоит работа целой команды. Важно синхронизироваться и все обсуждать.
• Лучше один раз потратить больше времени и сил, чтобы довести до совершенства и автоматизировать удачную и перспективную механику. Потом вы сэкономите в разы больше. Например, в конце 2018 года мы придумали игру, в которой читатель мог узнать, совпадает ли его позиция по разным вопросам с позицией Владимира Путина. Создание первой игры с нуля заняло четыре дня. Когда мы решили сделать еще пару подобных игр, на них ушло еще по паре дней. После этого мы поняли, что это долгоживущая механика, и занялись ее переносом в «Монитор». Разработка удобной админки заняла еще 10 рабочих дней, зато теперь редактор может сам собрать игру за 10 минут. С апреля 2019 года мы выпустили 14 таких игр, а значит, сэкономили примерно три недели рабочего времени разработчика.
• Соотношение трудозатрат и результата — непредсказуемая вещь. Мы до сих пор не умеем предугадывать, что действительно понравится читателям. Но все равно важно анализировать, проводить работу над ошибками и помнить о балансе: лучше не делать очень сложную игру на тему, которая едва ли заинтересует многих читателей. Либо делать, но заранее договориться, что мы не ждем от нее больших охватов. И тем более не стоит сразу пытаться переносить новую механику в админку: лучше потратить время и сделать две-три игры «вручную», посмотреть на реакцию и затем уже решать, планируете ли вы ставить производство таких механик на поток.

Читайте другие материалы о «Медузе» в нашем блоге. И конечно, играйте в игры.

Султан Сулейманов