Читать книгу - "Как делать хорошие игры. От идеи до запуска - Петр Прохоренко"

Качество игрового процесса. Также могут быть рассмотрены с точки зрения качества.

• Сложность игры должна возрастать пропорционально развитию игрока по уровням без резких аномалий.

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

• Критичным по уровню качества для нас является первый месяц игры (уточнить по уровням).

• Игра не содержит 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 на самом деле: удержание, количество пользователей, платежи и прочие монетизационные метрики). Здесь мы смотрим каждый день и, если что-то пошло сильно меняться, то смотрим более пристально. Решения по ежедневным метрикам принимать смысла нет – они показывают динамику и процесс в моменте, а не результат. Ну, если это не решение о срочном подъеме упавшего сервера, конечно же. Здесь все тоже может быть на господине аналитике – в случае возникновения значимых изменений в течение дня он должен призвать кого-то из старших сотрудников.