Стадия 3: Релиз / Оперирование Если для платной игры - релиз, обычно, означает перевод основной команды на новый проект (или дополнение к игре), то для f2p - релиз это только начало. Для пейдовой игры нормально отбить 50% в первый месяц продаж. Для f2p игры - нормально сидеть год в soft-launch (обычно это запуск на несколько стран, а не на весь мир) и медленно разгоняться, хотя и “взрывных” историй тоже хватает.
СтратегияНа мой взгляд это ключевой момент - понимает ли команда куда, в глобальном смысле, должен двигаться проект. Это вопросы уровня “Какой должна быть игра через год?”, самый простой и бесполезный ответ - “Надо повышать метрики!”, но делать это можно 100500 способов, поэтому будет отлично, если есть стратегия/визионерство на этот счет. Иногда это звучит сверх-амбициозно, например на guns of boom это кратко звучало как “сделаем лучший мобильный соревновательный командный шутер”, уже из этого синтезировался роадмап, который описывал развитие проекта. Стратегия развития очень важна для банальных вопросов типа "какая идея лучше/хуже?" и позволяет сохранить целостность проекта.
Если вы вдруг играли в star wars jedi fallen order - это, на мой взгляд, пример игры в котором про идею игры забыли. В игре намешан паркур с дарксоулсом, невнятной РПГ системой и поломанным восприятием джейдайского боя. Можно понять как так получилось (игру в принципе не планировали как ААА, это была игра Б класса, к которой внезапно пришел Дисней), но нельзя простить.
Live-opsХороший лайв-опс может разогнать игру до топов. Плохой - убить потенциально годный проект. История знает много и тех и других случаев. Сегодня data-driven design (ddd) должен составлять минимум 50% всего что делается на проекте.
ddd - когда вы принимаете решения толкаясь от данных. Например “у нас в обучении после 5го шага уходит 20% игроков, давайте его переделаем” или “на 15ом уровне игроки сильно замедляют прогресс, давайте ускорим их”. АБ тесты - часто про ddd. Типа сделаем несколько разных вариантов и протестируем что лучше.
Чем более крупный проект - тем больше ddd, и наоборот. Объяснение очень простое - data-driven дизайн позволяет существенно снизить вероятность ошибиться и когда ошибка может стоить лишние несколько сот тысяч $, а порой и больше - лучше двигаться осторожнее. Но надо помнить что ddd не везде применим - он отлично работает на “эволюцию” - когда надо что-то улучшить, но плохо подходит для дизайна каких-то крупных вещей. Т.е. когда вы захотите добавить в игру огромных летающих динозавров - вам едва ли пригодится ddd, только в каких-то абстрактных размышлениях уровня “в нашу игру в среднем играют 20 минут, а мы хотим 25, давайте добавив больших летающих динозавров”.
Кстати, именно из-за ddd подхода - игровая индустрия одна из немногих, которым так же нужны специалисты по высоконагруженным системам, ибо данных по игроку собирается больше чем банк собирает данных по своему клиенту :)
В оперировании так-же дико важно держать темп. У вас может быть замечательная игра, но если в ней редко проходят изменения - игроки не смогут в нее играть долго. Нужно всегда подбрасывать дров в топку игрового интереса. Например в fortnite постоянно работают над очередным баттл-пассом, это необходимость. Значимая часть сил разработчика уходит на постоянное создание движа - поэтому не рекомендуется выходить в полноценный live-ops если игра сырая. У вас банально будет уходить много сил на поддержку движа, а сама игра при этом будет развиваться медленнее.
КомандаВероятно самые большие перетурбации в команде идут в момент релиза, елси до релиза - у вас была команда разработчиков, то на релиз к ней присоединяются:
-Маркетологи
-Аналитики
-Саппорт
-Комьюнити менеджеры
-Администраторы (поддержка инфраструктуры по всему миру обычно требует отдельных людей)
Внутри команды перестраиваются процессы. Если на этапе разработки - не критично что-то не успеть сделать, что-то оставить в сыром виде, то теперь - нет. Это все ставит высокие требования к профессионализму команды, планированию спринтов итд. Команда в лайв-опс, обычно, живет в более высоком темпе, нежели команда в предпроде.
Самое важноеНельзя забывать про деньги. До выхода - команда сжигает деньги проекта. Релиз - долгожданный момент и самое время выйти в операционный плюс! Если этого не произошло, возможно игра рано вышла из предпрода, потому что косты на поддержку команды обычно увеличивается (вследствии ее роста), а плюса все нет :). Если за несколько месяцев ситуация не улучшается - то это может быть причиной к закрытию проекта или сокращению команды на нем до необходимого минимума (поддержка текущей версии). Рынок действительно иногда может удивить, например была история с одним проектом - который на тестах показывал отличные метрики, но после выхода в релиз оказалось что маркетинг не может масштабироваться больше определенной суммы (сейчас не помню какая именно, но что-то в духе 150к в месяц), а такие суммы не интересны компании. При этом сделать в таком случае что-то сложно: вы можете изменить метрики проекта, но не рынок. Проект пришлось прикрыть.
Ну и иногда звезды складываются и проект стреляет - обычно это сопровождается всеобщим ликованием и быстрым усилением команды. На стрельнувшем проекте можно держать штат х2 от необходимого (но не нужно :) ), чтобы просто покрыть риски и делать ЕЩЕ больше. Если проект стрельнул - он сможет кормить команду и еще парочку таких же в течении нескольких лет и все снова по кругу.
Следующая часть будет про “Один спринт из жизни продюсера”, возможно последняя. Если есть вопросы - обязательно спрашивайте :)
Не смотрел, но гляну.
В том году ко мне два раза на более-менее серьезных щах обращались с авточессом: один раз руководство внутри компании «давай на хайптрейн запрыгнем» и один раз какие-то ноунейм ребята искали инвестора с экспертизой. Оба раза я был против.
Авточесс, на мой взгляд, имеет один сильный минус - игра не имеет хорошей реиграбельности. Очень быстро (для кого-то это 20 партий, для кого-то 50) игрок понимает паттерн и дальше играет по скрипту. Отчасти мои размышления подтверждаются онлайном dota:Underlords - он сильно упал.
Кроме того, для мобильной игры - очень длинные сессии. Это решабельная проблема, но она есть.
Как итог я думаю что авточесс как он был в оригинале - делать не надо. Но можно взять кор «собирание комбинаций + автобатлер» и как-то хорошо это переосмыслить.
P.s. Мне лично авточесс помог - я в это время работал над одним из прототипов (к сожалению не могу рассказать пока) и взял некоторые концепции.