Как разрабатывают DISTORTION

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

И я был готов. Но это не понадобилось.

Меня встретили люди, которые понимают чего хотят и искренне работают на результат. Поэтому сразу хочу повесить дисклеймер: здесь не будет попыток уличить ребят во всём на свете или поругать игру на чём свет стоит. Я постараюсь проанализировать то, что увидел, с перспективы разработчика и подсветить, что мне показалось крутым, а что – вызвало опасения. Выводы вы уже сможете сделать сами, каждый для себя. Большая часть статьи будет про сами процессы внутри студии, а уже под конец я соберу отдельный раздел про игру.

Как это было

12 апреля к обеду я подъехал в нынешний офис команды Game Are Pioneers. Пока что основная площадь выглядит как такой обширный, но уютный квартирник, но ребята с порога заверили, что это временная дислокация. Они собираются серьёзно скалироваться после ближайших майлстоунов и переезжать в другой город, с более выгодной арендой. К слову, правильное решение для данного этапа. Надеюсь, что ребята не будут фанатично тащить всех в оффлайн, т.к. сейчас огромное количество опытных ребят уже плотно подсело на удалёнку ;)

Диалог я вёл преимущественно с тремя сотрудниками.

Первым был, конечно, Дмитрий Здесев. Руководитель проекта. Внутри его называют и генеральным продюсером, и худруком, и главным дизайнером, но мне показалось, что передо мной всё-таки классический креативный директор. В хорошем смысле. Когда я вошёл в помещение, с ним консультировалась одна из рабочих групп проекта и задавала вопросы, где нужно было принимать решения именно по верхнеуровневому дирекшену, а не деливери. Дмитрий – настоящий творческий ураган. Активная жестикуляция, громкая манера речи и ответы на все вопросы, ещё до того как ты их спросил =)

Когда руководству пришлось отлучится на очередную встречу, у меня была возможность приземлиться в отделе гейм-дизайна и поговорить с местными дизайнерами. Со мной общались Дмитрий Жуков и Максим Шамраев. Очень крутые ребята. Такие обычно проходят любые собесы без тестовых заданий: по тому как они говорят о своей работе, о ходе своих мыслей, сразу становится понятно, что это заинтересованные специалисты. Причём, у них довольно необычная широкая компетенция, но об этом чуть позже.

В чём уникальность подхода студии

Давайте разберём основные откровения, которые меня приятно удивили.

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

"Любая игра существует в контексте. Целевая аудитория привыкла к тому, что действие происходит определенным образом. Если ты делаешь иначе, будь готов, что игрокам это не понравится" (с) Дмитрий Здесев

Причём внутри команды есть своеобразная тендерная система. На основе разных референсов несколько сотрудников могут предложить разные решения. Они могут быть даже быстро запрототипированы. После чего из них выбирается два лучших: основное решение, которое пойдёт в разработку, и запасное. Это позволяет не планировать впритык и иметь пространство для манёвра.

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

Звучит дорого и богато, не правда ли? Пробуют несколько вариантов и выбирают лучший. Но если этим правильно распорядиться, это только сэкономит ресурсы, особенно если есть компетентные люди на прототипировании. Вместо того, чтобы пытаться на бумаге выбрать заранее единственный правильный вариант, тут быстро пробуют несколько и видят на практике, что лучше работает для конкретного проекта. Не все коллективы могут это вывезти, но я не встретил внутри коллектива даже намёка на скепсис по этому поводу.

Тут стоит ещё отметить, что команда пришла к выводу, что им невыгодно пускать в разработку фичи по какому-то универсальному пайпу. Он может немного меняться в зависимости от того, что именно отдаётся в разработку. Как это вывозят? Хорошей практикой, которую в индустрии часто называют релиз юниты или рабочие группы. Суть в том, что под реализацию новой фичи или подсистемы набирается самостоятельная команда из специалистов разных отделов. Она может решить все задачи разработки внутри себя и имеет временного руководителя, назначенного креативным директором.

Что в отделе гейм-дизайна?

А в нём мы как раз смотрели, что сейчас есть. Побегали девочкой-героиней, помахали мечом, постреляли из лука, посмотрели разные виды противников, подбор предметов и т.п. Можно было прикинуть, как работают некоторые кор-механики и как выглядит арт персонажей и окружения.

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

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

Иначе говоря, Game Art Pioneers, может и сами того не понимая, последовали заветам Марка Черни, который в своё время сформулировал методику разработки для внутренних студий PlayStation. И основное правило заключалось в том, чтобы на препродакшене зафиналить "Three C: Character, Camera, Controls", т.е. всё, что связано с управляемым персонажем. Именно поэтому на ранних блокаутах Uncharted 4 вы можете видеть геометрические примитивы, по которым бегает уже финальный Нэйтан Дрейк. Ребята, правда, считают, что у них уже активный продакшен, а не препрод, но сути это не меняет: все ресурсы сейчас идут на механики, а локации под эти механики будут уже собираться после.

Это не отменяет, конечно, того факта, что арт окружения студия вынуждена готовить сразу, в параллель. Это вполне понятная несостыковка, т.к. блокаутами деньги привлекать сложно: нужно показывать инвесторам что-то более понятное.

Гейм-дизайнеры в студии, по факту, обладают компетенцией технических гейм-дизайнеров. Они все обладают навыками прототипирования. Могут залезть в блюпринты или анимационные блюпринты, а могут и закодить что-то. Они разбираются в том, как работают мувмент системы, настройка навигации и логики противников, подгрузка локаций и т.п. Чистых писателей ТЗ, заказывающих и настраивающих отдельные инструменты в движке, тут нет.

Хорошо ли это? И да, и нет. На моей памяти таким студиям не хватает людей, которые не отталкивались бы от теха, а заказывали бы фичи, отталкиваясь в первую очередь от запросов рынка. С другой стороны, ребята, с которыми я говорил, Дмитрий и Максим, кажется, сохраняли видение продукта, когда говорили о нём, и не сильно тонули в техническое исполнение. Возможно, они смогут всё вытащить, разве что, упустив пару потенциальных крутых ГД на рынке, которые не работают с кодом. Время покажет.

А что с левел-дизайном?

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

Как я писал выше, в этом году команда будет активно переделывать боевую систему. Как только с ней всё устаканится, они планируют существенное расширение, которое включает 10-15 левел-дизайнеров.

В игре будет открытый мир с отдельными регионами. То есть будет экран с картой мира, где можно выбрать, в какой регион переместиться. А уже в рамках каждого региона уровень будет строиться по принципу открытого мира, с точками интереса и возможностью пройти из любой точки в любую точку. Регионов, если не ошибаюсь, планируется 8. Причём все области нужны из соображений сюжета, а не, скажем, количества классов героев.

Есть ли в команде нарративные дизайнеры?

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

И тестировщики есть?

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

Есть ли тут риск? Безусловно. Я не могу сказать, что на рынке нет проектов, которые так бы довели игру до релиза, раскачав QA отдел ближе к сертификации на разные платформы. Но практика показывает, что грамотный QA (не тестировщик, а именно QA, это другой грейд всё-таки) может помочь с этапа написания задачи. Он должен понимать структуру проекта и видеть уже на уровне идеи, что есть конфликты систем или недостаток описания в ГДД. Это бесценные люди, но их стоит взращивать и вовлекать в проект как можно раньше. Тут я за ребят боюсь. Они пока уверены, что всё гуд, но скалироваться я бы рекомендовал сразу с QA, а не ждать пока ружьё выстрелит в ногу.

Ну, может, хотя бы в контроле версий и таск-менеджменте что-то не так?

Тут ситуация не идеальная, но вполне стабильная.

Для контроля версий ребята перепробовали, кажется, все возможные опции. Причём пробовали не только разные СКВ, но и разные клиенты в рамках каждой. Остановились в итоге на Perforce. Им нравится нативная поддержка Epic Games и рекомендованные ими решения. Удобная система лока файлов. Возможность адекватно разводить как ветки, так и целые потоки. Структура бранчей, к слову, вполне разумная.

Единственное, где я там увидел потенциальный риск – все мержи в общий поток производятся вручную. На данном этапе это ещё ок, а вот когда студия разрастётся вдвое, решать будет поздно. Это одни из самых классических граблей независимой разработки. Ребятам нужно искать подходящий CI/CD инструмент до того, как их станет много.

Чуть более простым языком для тех, кто не понимает, о чём я: в разработке, особенно крупной, принято отдавать ветки со новым функционалом специальному серверу, который уже проведёт все нужные валидации (проверит, что нет сломанного контента) и сам сформирует порядок, в котором он будет вливать все эти многочисленные ветки от кучи разработчиков.

А таск-менеджмент у ребят на прикольном этапе. Мне прям нравится то, что я увидел и услышал. Они также въедливо перепробовали все возможные решения: от физической доски на стене до всяких Jira, ClickUp, Trello и пр. В итоге они сформировали в письменном виде то, что хотят от системы менеджмента задач, нашли подрядчика с хорошим продуктом и сделали заказ на его адаптацию под их нужды. Это... крайне основательно. Вопрос в том, насколько быстро они получат, что хотят, но сейчас у них нет бэклога на несколько лет вперёд, так что, кажется, можно и поэкспериментировать.

Небось документацию не ведут?

А вот, представляете, ведут. Причём у них отдельно фиксируются концепты на этапах ресёрча, затем ГДД. На их основе уже пишут ТЗ. Да даже документация по онбордингу есть с руководством по использованию проекта и настройкой клиента Perforce. Да, кто-то не забыл про документацию при формировании новой студии. И такая студия в РФ теперь нашлась.

Промежуточный итог

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

Итак, что мы имеем из явных плюсов? Тут я резюмирую то, что озвучил выше, и добавлю некоторые детали, которым не нашлось пока места в статье:

• Ребята въедливо работают с рефами;
• Для каждого запроса готовят несколько решений вместо одного и выбирают лучшее;
• Всегда имеют запасной план реализации на каждую фичу;
• Формируют под каждую новую фичу/подсистему самостоятельную рабочую группу;
• Все ГД имеют навыки прототипирования;
• Ребята сперва финалят персонажа игрока, а потом уже берутся за локации;
• Контроль версий выбрали вполне осознанно, и работают над улучшением процессов;
• Таск-менеджер так и вовсе заказывают свой;
• Адекватно собраны команды нарратива, арта и дизайна;
• Не забывают про документацию;
• Полностью расписан UX интерфейсов.

А теперь про возможные риски:

• Недоукомплектованы отделы LD и QA;
• Очень смелые большие амбиции;
• Креативный директор довольно плотно вовлечён в ГД отдел. Это может как дать более стройный вижен, так и мешать стабильной разработке. Время покажет, какой вариант перед нами. Возможно, я зря беспокоюсь, но на мой взгляд безопаснее сохранить высокий уровень принятия решений на уровне директората. Иначе график рядовых исполнителей придётся подстраивать под креативного директора, что не всегда работает;
• Нет автоматизации мерджей в Perforce;
• Нет списка возможных левел-геймплейных механик. Есть план и рефы, но пока не ясно, с чем придётся работать ЛД, когда их наймут;
• Нет автоматизации пересборки обновляемых сущностей типа навмеша. Справедливости ради, это в планах, просто пока не реализовали;
• Нет ГД, которые бы не опирались на технические возможности, а писали бы ТЗ, исходя исключительно из запросов рынка. Это не всегда нужно, но может быть полезно. Плюс, если сделать обязательным требованием работу в движке, можно упустить крутых ГД;
• Тестирование происходит преимущественно силами разработчиков;
• В двухнедельном спринте только два дня отведено на багофикс и плейтест. Как следствие, плейтест происходит далеко не всегда;
• У ребят постоянные показы. Да, дизайнеры даже сказали, что им это нравится, держит в тонусе. Но опыт подсказывает, что лучше эту практику прерывать на длительные периоды, чтобы дать команде поработать без лишних глаз через плечо. Да, я очень рад, что попал к ребятам, просто переживаю за них.

Будущее DISTORTION

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

Игра планируется в сеттинге эпического фэнтези. Игроку будут доступны 8 героев, между которыми можно переключаться в бою. Одновременно в пати можно брать до 4 героев. Личности героев постараются сохранить в тайне так долго, как это возможно, т.к. по ним можно делать выводы о сюжете. Это решение может поменяться!

На мировой карте можно будет быстро перемещаться между 8 регионами. Каждый из регионов сделан по принципу открытого мира. Сюжет проведёт игрока через все эти локации.

Боевую систему, если позволят ресурсы, хотят сделать максимально уникальной. У персонажа планируется одна единственная шкала – выносливость. Если её мало и герой получил пробитие доспеха – смерть. Стамина будет расходоваться буквально на всё, от бега до боевых действий. Помимо стандартных уворота, кувырка и блока планируется ещё возможность оттолкнуть противника. Хотят также систему расчленёнки для большего правдоподобия.

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

В левел-дизайне, когда уже наберут большую команду ЛД, есть желание отталкиваться от частоты механик в God of War (2018). Да, там другая структура локаций, но суть в том, что там достаточно контекстных интеракций типа подняться по верёвке, перепрыгнуть через препятствие, протиснуться между скал и т.п. Это ребята хотят использовать в качестве рефа для будущих ЛД.

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

Релиз не стоит ждать раньше 2026 года, поэтому ребята не спешат занижать себе минспек (минимальные системные требования). На стороне GPU к их релизу уже вполне может быть стандартным минспеком не GTX 1650, а RTX 2060. Компромиссов по графике пока не предвидится, так что ждём отличную графику.

Как-то так. Что думаете? Я пока настроен позитивно, криминала никакого не увидел. Продукт, правда, пока тоже на очень ранней стадии. Ребята уже предложили мне приехать где-нибудь через полгода, просто чтобы увидеть прогресс на деле. Хотели бы почитать такой материал осенью? Давайте обсудим в комментариях.