Я не помню ни одного примера, когда попытка разрабатывать игры по «технологии стартапов» приводила к хорошим результатам. В самом неприятном случае в результате выглядящих (на первый взгляд) не очень радикальными изменений была выброшена полуторалетняя работа команды из 50-ти человек. Контент на целый игровой проект А-класса просто исчез!
А что же нужно в таком случае делать?
Все достаточно просто, из-за инерции производства игр (которые, как мы помним, являются по своему классу сложными программными продуктами) пивот можно делать только итеративно, растягивая изменения по времени. То есть тот же поворот на 180 градусов, но выполненный не одним резким движением, а в шесть приемов с последовательными изменениями, реализуемыми по плану.
Как сделать хорошую игру, Способ № 23: На игровом проекте можно сделать радикальные изменения, но делать их нужно по плану и небольшими порциями. Планирование изменений – это критически важная работа, поэтому к ней стоит отнестись с максимальным вниманием.
Вообще излишняя любовь к пивотам характерна для непрофильных инвесторов, и я называю этот процесс «галсированием». И связано это с близким горизонтом планирования, не подходящим для игровой индустрии. Они просто не могут вытерпеть, что игра разрабатывается так долго, и начинают «суетиться» на капитанском мостике. «Билли, долго мы будем вилять, как маркитантские лодки?» – раздраженно спрашивал пират Джордж Мэри и был прав.
Завершая эту главу, я бы остановился на ключевом моменте – ищите те решения, которые могут поменять «правила игры» и оказывают большое влияние на проблемы проекта. Чем сложнее и запущенней проблема, тем более радикальное решение для нее требуется. Это как раз тот случай, когда если «что-то поделать», то и станет «что-то получше», то есть по факту ничего не изменится. Вам надо найти и локализовать проблему, а потом ее решить. И никак иначе!
А уж если говорить о принимаемых управленцами решениях, то я бы выделил отдельный класс «решений, которые победили», то есть оказали очень сильное и долгосрочное влияние на весь процесс. Например, я в начале 2018 года навязал (не бескровно, а в итоге серьезной аппаратной борьбы) всей команде Alternativa Games общую технологическую платформу для всех новых мобильных проектов компании. Ну и потом системно запрещал сильно менять игровую камеру, базовый скелет персонажа и т. д. и т. п. В общем, душнил, как мог, на все деньги. В целом, конечно, 100 % эффективности мы тут не добились, но это решение сэкономило кучу времени и аукалось очень долго – мы периодически что-то притаскивали из старого, а на определенных этапах помощь с родственного проекта была жизненно важна. Например, прототип второго проекта мы запустили просто «на лету» и потом успешно смогли сменить визуальный сеттинг игры уже в процессе разработки. Если бы технологическая база сильно отличалась, это было бы невозможно. Понятно, что дело не в конкретных фактах (они были даны исключительно для примера), а в философии поиска ключевого решения, адаптированного под ситуацию и команду, поэтому, чтобы понять эту систему, нам надо будет немного уйти в теорию.
Если препарировать это решение, то мы увидим, что оно было связано с критичным типом ресурса конкретно для этой компании – ВРЕМЕНЕМ. Решение задавало ограничения, которые в основном экономили команде время. Это было важно именно в контексте команды, не имевшей успешного опыта работы над мобильными проектами и обладавшей ярко выраженной склонностью к перфекционизму. То есть тут успешное решение является производной от верной оценки потенциала команды и ее рисков в контексте будущих проектов. Оно не взялось из воздуха и не было получено путем гадания на внутренностях жертвенных животных. Только трезвая оценка ситуации и аналитический взгляд помогли к нему прийти.
Итого, какова правильная последовательность действий:
1. Анализ команды, выявление ее сильных и слабых сторон.
2. Поиск критичного именно для этой команды ресурса (время, деньги, компетенции, контент, технологии и т. п.).
3. Работа над решениями, оперирующими именно этим ресурсом.
Понятно, что этот гайдлайн не приведет сразу к тому самому решению, но по крайней мере поможет структурировать мысли и работать на более сфокусированном направлении.
Как сделать хорошую игру, Способ № 24: Ищите решение, подходящее конкретно вашей команде в контексте вашего проекта и того рыночного момента, где вы находитесь. Вам необходимо найти ключевую уязвимость всей вашей системы под названием «игровой проект» и ограничить спектр решений только теми, которые воздействуют именно на эту уязвимость.
Мораль сей басни такова: в любой ситуации ищите кастомное решение конкретно под эту команду, пытаясь оперировать ключевым для нее ресурсом (не важно, хватает этого ресурса или наоборот – недостает).
Глава 7. Проект «Дни после»
В отличие от предыдущих частей книги, эта глава посвящена истории всего одного проекта и затрагивает другие только в контексте связи с игрой Days After или «Дни после». Вообще, в рамках этой книги я старался отойти от хронологически стройного повествования о своих проектах и связанных с ними «кейсах», чтобы сосредоточиться на типовых проблемах и поисках тех самых точек, где игра превращается в хорошую. Но иногда история разработки проекта получается такая связная, логически обусловленная и поучительная, что хочется рассказать ее целиком. Поэтому я вынесу все, связанное с игрой «Дни После», отдельно в эту главу.
Это необходимо для того, чтобы показать всю последовательность разработки от идеи до мирового запуска на достаточно показательном примере. В истории игры Days After вы увидите, как именно преломлялись на практике теоретические положения, изложенные ранее, и это, как мне представляется, достаточно интересно.
А поскольку любой проект существует в контексте компании, которая его делает, необходимо рассказать о студии, которая ответственна за эту игру.
С компанией Alternativa Games, создателями блокбастера «Танки Онлайн», я познакомился где-то в начале 2018 года. Надо сказать, что эта история отличается от остальных моих индустриальных приключений тем, что здесь заказчики имели достаточно четко сформулированные задачи и мне не пришлось ничего придумывать и доставать им «жар-птицу», как это ранее частенько происходило. Итак, руководство студии весьма трезво и рационально хотело следующего:
1. Сформировать команду мобильной разработки (до этого проекты студии были на платформах ПК или Web, а единственный мобильный опыт нельзя было назвать удачным).
2. Запустить линейку мобильных проектов и таким образом открыть новое направление.
3. Плавно «посадить» и с минимальными рисками для общественного мнения закрыть один из проектов компании, не показавший желаемые результаты.
4. Регулярно, последовательно и в цифрах убеждать совет акционеров компании в том, что мы все делаем правильно и за мобильными играми будущее.
Отягчающих обстоятельств тут было два: особенности команды и структура управления компанией. С первым все было более-менее понятно: Alternativa Games выросла из небольшой группы энтузиастов, сделавшей блокбастер «Танки Онлайн», разросшейся до 150 человек, но при этом оставшейся очень замкнутой территориально (офис компании расположен в Перми) и по сути не знакомой даже с российской индустрией, поскольку большая часть сотрудников, кроме родной «Альтернативы», нигде не работала. Это порождало определенное недоверие к «чужим» и легкую оторванность от текущих тенденций индустрии, но в целом вполне подлежало корректировке. А вот вторая проблема была значительно серьезнее. Акционеров компании насчитывалось около полутора десятков человек, и там были представлены все типы владельцев игровых бизнесов: визионеры с наполеоновскими идеями, непрофильные владельцы заводов и пароходов, старые и уже отошедшие от дел сотрудники студии и даже политик областного значения. Эта группа товарищей делилась на несколько кланов, цели которых слабо пересекались, а отношения между ними были достаточно натянутыми. Именно для того, чтобы модерировать процесс обсуждения стратегии компании, Alternativa Games и нужны были наемные «варяги» с послужным списком в игровой индустрии.
Итак, нужно было сформировать линейку мобильных продуктов и вывести компанию на новый для нее рынок. Причем сделать это в условиях нехватки подготовленных кадров и ограничения средств, то есть, по сути, без права на ошибку. Именно в таких условиях очень хорошо себя показала методология препродакшена проектов. Уже в рамках первой командировки в Пермь удалось чуть меньше чем за месяц провести цикл подготовки первой игры к производству и получить добро от наблюдательного совета компании, что первоначально руководству студии представлялось совершенно нерешаемой задачей.
Первым мобильным проектом студии был тактический шутер в популярном тогда жанре «королевская битва» с top down камерой, получивший название King Hardcore. Выбор вида камеры определялся опытом команды – часть ребят уже работала над похожим проектом браузерной игры (она называлась Combat Sector), а «королевская битва» была тогда на большом подъеме. Основная идея проекта заключалась в том, чтобы упростить управление персонажем, так как на тот момент мобильные аналоги в полном 3D работали плохо и играть там было настоящим мучением из-за недостатков системы управления.
О ходе разработки King Hardcore рассказывать особенно нечего – все шло в соответствии с планами и без больших отклонений и значительных проблем. Методология запуска проектов и быстрого их доведения до этапа первого результата работала и вызывала умиление как у руководства компании, так и у наблюдательного совета. А команда проекта просто делала версии игры, интегрировала фичи и сдавала этапы, удивляясь, почему теперь вдруг все получается, хотя еще совсем недавно все было долго, мучительно и дорого. Процитирую тут лучше «Остров Сокровищ» Стивенсона: «Я