• Увеличение геймплейной и визуальной насыщенности локаций по мере прогресса игрока. Чтобы поддерживать долгосрочный интерес игрока после освоения базовых игровых процессов, следующие локации создаются более комплексными, предлагающими новые игровые механики и сеттинги. Акцент переводится с количества в качество.
• Выполнение технических требований (количество ассетов, нагрузка по динамическим объектам и спецэффектам).
Жанровые точки фокуса фактически описывают исключения – блоки, которые могут отличаться от среднего уровня качества в ту или иную сторону в зависимости от выбранного жанра. На примере игры Days After такими точками являются:
• Иконки предметов инвентаря – являются крайне важным элементом для вовлечения игрока в жанре, должны быть выполнены на максимально возможном для нас уровне качества. Основные критерии: яркость, «выпуклость», «тактильность» иконок. Манипуляции с предметами (получение, перекладывание) должны вызывать у игрока положительные эмоции. В качестве референсов тут можно взять фишки в топовых матч 3 играх – они создаются по похожим требованиям.
• Юзабилити локаций – особое внимание уделяем правильной организации локаций для максимального удобства использования (единообразие ориентации камеры и развитие локации «снизу – вверх», обусловленность стоящих рядом объектов, интуитивно понятное зонирование локации – очень важно в отсутствии у нас мини-карты отсутствие «спрятанных» от игрока важных для игрового процесса сущностей).
• Персонажи свиданий – являются важными с точки зрения монетизации данной фичи. Персонажи должны выглядеть как живые люди, вызывать у игрока эмоциональный отклик и позитивные эмоции при взаимодействии с ними.
Качество игрового процесса. Также могут быть рассмотрены с точки зрения качества.
• Сложность игры должна возрастать пропорционально развитию игрока по уровням без резких аномалий.
• Объем сюжетного контента соответствует заданным при планировании проекта параметрам. Рассчитывается на игрока со средним уровнем вовлеченности, в дальнейшем игрок переходит к цикличным активностям.
• Критичным по уровню качества для нас является первый месяц игры (уточнить по уровням).
• Игра не содержит paywall, препятствующих прохождению, но не дает бесплатному игроку 100 % контента (часть закрыта сложностью прохождения).
В изначальной концепции Paywall – это экран, предлагающий пользователю заплатить, чтобы получить доступ к расширенному контенту и функционалу. В игровой индустрии используется в контексте не столько самого экрана, сколько как описание ситуации, в которую дизайн игры ставит игрока – без платежа невозможно дальнейшее продвижение по сюжету/локациям/уровням.
Несмотря на некоторую бюрократичность формулировок, эти описания могут помочь вам оценить качество своего проекта непосредственно перед релизом. Достаточно просто сесть и педантично выписать все параметры, а затем честно оценить по ним проект.
Ну вот, собственно, и все. Наш игровой проект прошел все стадии и почти готов к релизу, а текст книги почти подошел к своему завершению. Конечно, всю проблематику игровой разработки невозможно раскрыть в рамках одной книги, тут нужны целые собрания сочинений от разных авторов, чтобы читатели могли насладиться не только сложностью этого рода деятельности, но и противоречивыми теориями от различных экспертов.
Но есть еще буквально две темы, о которых я хотел бы написать, пусть даже и в пунктирном формате «заметок на полях книги». Это планирование запуска проекта и поддержка игры аналитикой. Даже короткие заметки по этим темам, надеюсь, помогут вам в поисках верной дороги уже за релизной финишной ленточкой.
Первым у нас будет план запуска. Точнее, даже так – План Запуска. Это обязательный документ, который должен быть согласован с вашей бизнес-моделью и органично из нее вытекать. Основной принцип при формировании этого плана заключается в его вариативности. Крайне сложно предугадать развитие событий, и ваша задача – создать «дерево вариантов», которое своей кроной точно зацепит ту версию реальности, которая развернется в будущем.
Таким образом, для любого продукта мы формируем несколько сценариев развития событий. Ключевыми показателями, определяющими, по какому из сценариев пойдет развитие, будут являться метрики удержания по 7, 14 и 21 дням. Монетизационные метрики также будут в данном случае определяющими, однако они рассматриваются как вторичные.
Основными этапами запуска продукта являются Secret-launch, Soft-launch и Worldwide launch.
«Закрытый тест»/Secret-launch
Закрытый тест продуктовых фичей и маркетинговых гипотез. Основные задачи:
• Тест основных продуктовых фичей – базовый геймплей и мета-уровень.
• Тестирование гипотез по рекламным креативам.
• Потенциальный тест стоимости привлечения пользователей.
«Мягкий запуск»/Soft-launch
Открытый доступ к заранее определенному набору стран на одной из платформ. В этот период начинается полноценная закупка трафика. Основные задачи:
• Тест основных продуктовых фичей и монетизации, сверка с KPI.
• Разработка маркетинга: креативы, поиск оптимальной аудитории, оптимизация стоимости привлечения игроков.
• Внесение корректировок в существующую стратегию и бизнес-модель продукта.
По результатам первого месяца Soft-launch принимаем решение о дальнейших шагах: открываем больше территорий и готовим к выходу версии на других платформах или продолжаем дорабатывать продукт.
Мировой запуск/Worldwide launch
Полноценный запуск продукта на всех территориях и платформах произойдет только в случае реализации сценариев развития «реалистичный» или «взрывной рост», описанных ниже.
Теперь самое интересное, или возможные сценарии развития проекта. Разумно выделять из всей широкой кроны возможностей несколько наиболее вероятных «веток»:
• Реалистичный вариант.
• Вариант взрывного роста.
• Вариант итерации переделки.
• Вариант сворачивания разработки.
Обычно такого рода документы завершаются тем, что далее описываются все ветви плана с расчетными цифрами по метрикам и затратами в любом из случаев. Это делается уже в контексте цифр, метрик и таймлайна конкретного продукта.
Я бы рекомендовал строить «дерево вариантов», всегда исходя из реалистичной ветви и ответвлений от нее (чуть лучше/хуже и крайние варианты). Практика показывает, что вероятность реалистичного сценария сильно выше, чем любых других, а поэтому он должен быть для вас базовым. Уже в нем игра должна показывать приемлемые финансовые результаты, то есть отбивать свои затраты как на разработку, так и на поддержку. Как вы понимаете, реалистичный в данном случае это не «желаемый», а «очень средненький». Ситуация, когда команда проекта рассчитывает как единственный сценарий только лишь вариант «взрывного роста», немногим лучше полного отсутствия планирования. Это как планировать покупку дома и машины сразу после приобретения пачки лотерейных билетов.
Как сделать хорошую игру, Способ № 31: в прогнозировании строго придерживайтесь проверенного принципа – шансы на реализацию экстремальных вариантов уменьшаются пропорционально увеличению их экстремальности. Как в худшую, так и в лучшую сторону. Если вы прикинули варианты вида «все будет плохо» и «все будет крайне шикарно», то с вероятностью 90 % ваши реальные показатели будут где-то посередине. Исходите из того, что жизнь – это не приключенческий фильм, тут редко происходят драматичные сюжеты и сценарные кульбиты. Обычно все укладывается в типовые усредненные сценарии.
И небольшая заметка относительно того, как построить на проекте «аналитику на минималках». Этот момент достаточно важен для всех небольших команд, потому что запускаться совсем без аналитики нельзя, а до момента, когда у вас появится возможность подключиться к мощным системам издателей, нужно как-то жить и собирать хотя бы самые важные данные. Итак, в этом вопросе нам важно решить следующие задачи:
1. Мониторинг происходящих в продукте процессов.
2. Быстрое реагирование на возникающие проблемы.
3. Системное улучшение продукта на основании данных.
Для первого пункта нам нужна система даш-бордов и специалист-аналитик, следящий за ней (т. к. там надо будет всегда что-то поправить или кастомно сделать).
На самом начальном этапе нам нужно решить все технические проблемы, выбрать инструменты, провести валидацию получаемых данных, все настроить, чтобы было удобно и визуально хорошо.
Для второго пункта нам нужен ежедневный мониторинг дашбордов по нескольким ключевым метрикам (их не больше 6–7 на самом деле: удержание, количество пользователей, платежи и прочие монетизационные метрики). Здесь мы смотрим каждый день и, если что-то пошло сильно меняться, то смотрим более пристально. Решения по ежедневным метрикам принимать смысла нет – они показывают динамику и процесс в моменте, а не результат. Ну, если это не решение о срочном подъеме упавшего сервера, конечно же. Здесь все тоже может быть на господине аналитике – в случае возникновения значимых изменений в течение дня он должен призвать кого-то из старших сотрудников.
Кстати, по критическим ситуациям (те же падение серверов, к примеру) необходимо сразу настроить моментальное информирование технической команды через звонки и СМС – так как сервера особенно любят падать в прайм-тайм США, когда у нас ночь, или в выходные. Ну и провести с людьми работу, заранее пообещать сверхурочные за работу на авариях – возможно, нам придется их дергать регулярно, 24/7.
Для третьего пункта нам нужен этот же аналитик, который делает еженедельный отчет по утвержденному шаблону. Обратите внимание на подачу информации – она уже прошла два фильтра (технический – валидация данных для дашбордов и аналитический – аналитик первично атрибутирует данные и описывает тенденции). Вот по таким отчетам, когда они ведутся каждую неделю, уже можно вести планомерную работу по улучшению продукта, т. к. они показывают долгосрочные тенденции по всем ключевым и различным дополнительным метрикам. Здесь уже начинается зона ответственности продюсера – еженедельный сбор и генерация гипотез и проверка их с помощью данных аналитики. Поэтому аналитик нужен внутри проекта, внешний не сможет оперативно откликаться на все запросы.