Давайте вернёмся назад к тому моменту, когда было принято решение использовать CryEngine. Многие источники говорили мне, что адаптация игрового движка, рассчитанного на шутеры от первого лица, к требованиям многопользовательской вселенной стало огромной помехой в разработке Star Citizen. Некоторые из них говорили, что гораздо эффективнее было бы создать свой собственный движок.

"CryEngine стал помехой для CIG с самого первого дня", — говорит один источник. "Это отличный движок для разработки только одного типа игр — шутеров. Поэтому, чтобы сделать Star Citizen, им пришлось полностью переписать его.

В ряде случаев переписывание кусков движка имело смысл. Например, сетевой код CryEngine создавался для многопользовательских игр с небольшим количеством участников, не предполагая тысяч игроков. Код ИИ не имеет нативной поддержки задач той сложности, которая необходима для живой вселенной Star Citizen. Система рендеринга была рассчитана на освещение земного окружения, а не космического.

Другие решения, по мнению моих источников, также имеют мало смысла.

"Они хотели совершенно новую систему вида от первого лица. Имея лицензированный CryEngine — движок, который построен с нуля для создания игр от первого лица, они "ободрали" его и стали создавать совершенно новую систему вида от первого лица, хотя в движке уже была одна", — говорит источник из Foundry 42. "Я думаю, это было глупым решением".

"Я помню много совещаний, где мы говорили «У нас есть эти миссии, но нам нужны работающие системы вида от первого лица". Мы видели, как члены сообщества брали материалы из того, что уже было выпущено, вставляли в CryEngine и использовали нативную систему вида от первого лица чтобы собрать уровни. Это был период времени, когда фанаты, имея в своем распоряжении содержимое выпущенных модулей, могли сделать больше чем мы. Мы говорили: "Даже если у нас пока нет технологий, которые мы будем использовать в будущем, мы могли бы просто начать работать, собирая вместе различные элементы". Этого не случилось, и это было плохо.

Удаление систем вида от первого лица, которые были в CryEngine изначально, выглядит странным решением, но Робертс говорит, что это было необходимо для его планов по унификации видов от первого и третьего лица.

"В большинстве FPS вид от первого лица – это руки, летающие перед камерой, а вид от третьего лица – это совершенно другой набор предметов и анимаций. Это хорошо работает для игр с видом от первого лица, особенно однопользовательских. По этой же причине в том же Crysis анимации в одиночной игре отличаются от анимаций в многопользовательской игре. Это справедливо и, например, для Call of Duty".

Другими словами, анимации, которые вы видите от первого лица, отличаются о тех, которые видят другие игроки, смотря на вас. Вы можете понять, что имел в виду Крис Робертс, если посмотрите на GIF-ку, выложенную Олли Моссом (Olly Moss), в которой демонстрируется анимация персонажа с видом от третьего лица в игре Firewatch:

В Star Citizen Крис Робертс хочет использовать единый набор моделей и анимаций вне зависимости от того, какой вид вы используете.

"Это огромное техническое испытание", — говорит он. "Всего несколько людей делают это, и, конечно же, не с тем качеством, что делаем мы. С CryEngine или Unreal вы не можете получить единые анимации "из коробки".

Одной из крупных причин задержки было фундаментальное изменение в CryEngine — переход от 32-битных расчётов к 64-битным. Это позволило движку гораздо точнее отслеживать положение объектов в игре, что необходимо для огромных открытых пространств. У CIG возникли проблемы, когда они попытались создать такое окружение с использованием 32-битного отслеживания.

"Мы столкнулись с различными их проявлениями. Например, с дрожанием интерфейса или прыжками корабля по всему экрану вокруг заданной точки", — говорит Ник Элмс (Nick Elms), креативный директор Foundry 42. "Один только переход с 32-битной на 64-битную точность был огромным покрытием "технологического долга". Это колоссальная работа под капотом двигателя, но этот переход позволит команде шагнуть от крошечного пузырька, в котором мы тестировали космические бои (Arena Commander), до этих огромных пространств, в которых вы можете летать теперь. Ещё недавно такое считалось невозможным".

Поскольку так много всего в движке было заменено, и обновления от различных студий продолжают выходить, это означает, что большая часть работы должна быть переделана. "Что-нибудь изменяется, и тогда ломается то, что вы уже сделали. Поэтому нужно вернуться назад и выполнить работу снова и снова", — говорит мне источник. "Вот почему нужно убедиться, что инструмент написан и завершён до того, как вы начнёте создавать игру. Ставить это в вину CIG было бы несправедливо, поскольку фактически каждая игровая студия страдает от этой проблемы. В данном случае негативный эффект так сильно выражен из-за масштабов игры и количества доработок".

"Я изо всех сил старался сделать из этой технологии что-то работающее, доказать концепцию, над которой я работал, и это безумно расстраивало. Потому что одно дело – ходить на работу и не работать, потому что вам не хочется быть там. И другое дело — любить свою работу".

Для многих в британской студии это стало шоком, особенно для разработчиков, пришедших из TT Fusion.

"Мы только что пришли из вселенной Lego, где новые игры выходили буквально каждые четыре – шесть месяцев", — говорит Эрин Робертс. "Там (в ТТ) был совершенно иной стиль разработки, потому что они использовали двенадцатое поколение движка, в который даже не приходилось заглядывать первые три месяца разработки проекта. Тогда как тут инновации случались каждый день, и возможности движка постоянно расширялись в различных направлениях, чтобы мы могли получить то, что нам необходимо".

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

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

Крис Робертс понимает разочарование дизайнеров, но утверждает, что работа должна быть сделана.

"Не существует движка, который бы делал то, что нам нужно", — говорит он. "Если бы он существовал – мы бы его лицензировали. Поэтому нам пришлось значительно переделать то, что было. …Сейчас у вас есть пространство для путешествий в миллионы километров и дальность прорисовки в сотни тысяч километров. Вы не можете сделать это на 32-битном движке, и не важно, используете ли вы Unreal, CryEngine или Unity. Поэтому мы должны были внести все эти изменения. Да, вы можете взять СryEngine и просто что-нибудь сделать, так же как в Unreal или Unity, но это не будет работать так, как нам нужно".

"Я не думаю, что было бы лучше, если бы мы просто взяли Unreal 4. Я вижу, как расстраивает людей перевод движка с 32 бит на 64, но я не могу оглянуться назад и сказать: "С Unreal такого бы не случилось". Нам пришлось бы сделать это несмотря ни на что. Люди в индустрии, да даже наши сотрудники – дизайнеры и художники, не являются технически грамотными … они знают только свои инструменты".

Один из источников считает, что с ростом бюджета и масштабов проекта всё меньше смысла использовать CryEngine как основу игры.

"Изначально планировалось собрать $500 000 и просто сделать на CryEngine духовного наследника Wing Commander. Это была абсолютно разумная концепция. Но потом стало приходить больше денег, и Крис Робертс начал давать прессе обещания, которые он не обсуждал с командой разработчиков. Не знаю, было ли всё это в его планах, но на тот момент, когда он давал различные интервью и обещания на видео во время PAX, у команды не было возможностей всё это реализовать".

"Было понятно, что CryEngine не подходит для этой задачи", — продолжает источник. "Он был хорошим выбором для проекта, который хотели сделать за $500 000, и разработчикам нужны были технологии. Вы не можете создать движок за $500 000, но можете сделать это со $100 миллионами. Чтобы сделать Star Citizen, нужны собственные технологии. Многое из случившегося было связано с переписыванием CryEngine под нужды проекта. Очевидно, это всё замедлило".

Ещё один источник рассказал, что другой проблемой с CryEngine было наличие в нем множества незадокументированного кода, унаследованного от предыдущих версий. Стоял вопрос: "Что мы можем выкинуть из старого CryEngine, и если мы будем добавлять что-то своё, не окажут ли другие компоненты негативного эффекта?" Это как зайти в магазин инструментов после торнадо — да, вы сможете найти где-нибудь молоток, но для этого нужно перерыть кучу мусора".

Огромное количество основных компонентов CryEngine всё ещё переписываются. Например, сетевой код. Однако не все мои источники согласны с тем, что выбор CryEngine был ошибкой. Один из них согласен с Крисом Робертсом в том, что с Unity или Unreal были бы те же проблемы. Можно подумать, что для CIG было бы правильнее создать свой собственный движок, однако в начале проекта, когда его масштаб был куда меньше, это было неразумно.

"Я раньше создавал движки. В Digital Anvil мы писали движок с нуля, и я делал то же самое по возвращении в Origin", — говорит Робертс. "Проходило два года, прежде чем мы могли показать жизнеспособный видимый результат. Когда мы начинали этот проект, я подумал, что не хочу терять те самые два года".

"Я подумал, что будет проще взять CryEngine или какой-нибудь другой движок. Если бы мы собрались делать простой шутер от первого лица, у нас бы не было этих проблем и испытаний. Но в таком случае мы бы не собрали таких денег. Нам их давали именно потому, что мы хотели раздвинуть границы".

Производственные дебри

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

Различные источники говорили мне, что с самого начала разработки Star Citizen был чётко определён высокоуровневый план развития проекта, но не было разбиения на задачи.

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

Источники говорят, что такой организации задач не случилось, и в приоритете было всё. "Если в приоритете всё — значит приоритетов нет. Если приоритетов нет — значит вещи будут сделаны, когда будут сделаны. Какие-либо этапы становятся бесполезными".

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

"Большинство координаторов и продюсеров не имеют достаточного опыта в такого рода разработке, поэтому они не знают, что на самом деле достижимо".

Если художник, инженер или дизайнер говорит: "Это займёт пару дней", а на самом деле занимает месяц, продюсер не может правильно оценить время, поскольку не понимает сколько его нужно. Или же они не учитывают скорость работы этого сотрудника и его способность справиться с задачей и просто говорят: "Хорошо, если ты так считаешь – так и запишем".

Создание игр, особенно таких больших как Star Citizen — это сложное производство, в котором ни один из разработчиков не работает сам по себе. Это значит, что если задача требует больше времени, чем запланировано, то задержки коснутся не одного разработчика, а целого ряда людей. Один корабль в Star Citizen делается группой людей — от концепт-художника до 3D-художника, художника по текстурам, технического дизайнера и множества других. То же самое касается создания персонажей, предметов, окружения. В результате одной проблемы в производственном цикле модели персонажей создаются шесть месяцев вместо положенных трёх.

"Было много документации", — говорит источник. "Слишком много. Просто катастрофическое количество документов и данных, многие из которых противоречили другим. Иногда документы были старыми, а иногда кто-нибудь работал над тем, что уже было сделано кем-то другим. Бывало так, что двое людей делали одно и то же, не предупредив друг друга, в результате чего получались две совершенно разные вещи, которые должны делать одно и то же. И так было во всех студиях".

Игровая разработка не начинается с идеального производственного процесса (pipeline), она начинается с изучения лучших из имеющихся практик. Но по словам Джонса, для CIG это было «идеальным штормом»:

2Мы были растущей компанией с новыми технологиями, состоящей из нескольких студий. Вы пытаетесь создавать различные штуки, но это трудно, когда одна половина студии отвечает за одну вещь, в то время как за другую вещь отвечает другая студия в другом часовом поясе".

В конце 2014 года Робертс рассказал мне, что хочет объединиться со своим братом Эрином, и сказал: "Это не сработает, если мы будем продолжать в том же стиле".

Братья сделали шаг назад и посмотрели, какие в целом проблемы с производством были у компании. "Оценив результаты работы, мы обнаружили, что британской офис работал гораздо более стабильно", — сказал мне Крис Робертс. Он присмотрелся к тому, как Эрин управляет британской студией, и понял, как заставить команду придерживаться их производственного плана, и как сотрудникам производственного отдела контролировать трудовой процесс. Пока Foundry 42 была новой студией, ядро команды состояло из людей, много лет проработавших вместе в TT Fusion над играми Lego.

—Вместе они сделали так много, потому что были необычайно организованы", — объясняет Робертс. "Иногда у них было шесть месяцев на создание чего-либо".

Робертс постановил, что все студии CIG должны перенять британские методы работы. Это решение приняли не все:

"Изначально созданием кораблей занималась лос-анджелесская студия, но они не справлялись, и британцы были недовольны. Так что мы перевели эту часть разработки в Великобританию, после чего парни из Лос-Анджелеса почувствовали себя приниженными и расстроились", — говорит Робертс. "Это повлекло за собой неприятные последствия, несколько человек уволилось".

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

Также во все производственные процессы была добавлена управленческая иерархия. Так, например, Натан Дирсли (Nathan Dearsley) возглавил создание кораблей, Франческо Рокучи (Francesco Roccucci) – разработку искусственного интеллекта, а Ян Лейлэнд (Ian Leyland) возглавил создание арта локаций.

"Полученные результаты чётко описывают ответственность каждого с точки зрения того, кто что должен делать", — говорит Тони Зуровек. "Я думаю, это заметно снизило количество стычек среди сотрудников. Если оглянуться назад и посмотреть на то время, когда мы создавали Arena Commander, мы увидим, что на кухне было много шеф-поваров; все они наступали друг другу на ноги, что приводило к недовольству одних студий другими.

Пол Джонс, арт-директор в Foundry 42 говорит, что новая структура даёт ему личные преимущества:

"Изначально я был сильно перегружен, пытаясь справиться со всем, что связано со Squadron 42, а это различные области арта и концепт-арта, – говорит он. – Во время разговора с Эрином я как-то сказал, что не могу заниматься всем и сразу. Мы обсудили это и пришли к выводу, что необходимо лучше распределить нагрузку внутри студии".

Увольнения

Были и жертвы реструктуризации – значительная часть остинской студии была уволена.

Когда была основана остинская студия, туда активно нанимали дизайнеров, художников, инженеров – всех, кто был необходим для создания Star Citizen. Как мы видели, было много причин для того, чтобы разработка осуществлялась различными студиями. Сегодня же Остин сконцентрировался на серверной инфраструктуре, поддержке пользователей и разработчиков в других студиях.

"Части остинской студии, в которых был смысл, например, инженеры серверной инфраструктуры, команда Постоянной Вселенной и тому подобные, так и остались в Остине", — объясняет Зуровек. "Что же касается остальных отделов, было решено, что лучшая возможность показать себя — присоединиться к коллегам в других студиях".

Некоторыми сторонними наблюдателями эта реструктуризация была воспринята как закрытие остинской студии.

"Люди психовали, говоря: "О, вы её закрываете, это катастрофа", — вспоминает Зуровек. "Но это не было катастрофой. Вы пытаетесь тратить каждый доллар максимально эффективно. Ирония в том, что вы принимаете трудное решение, а публика вас не понимает, потому что не имеет всей информации. И единственное, что вы слышите: "Они уволили дюжину человек". Это правда, но вы упускаете тот факт, что в немецком отделении Foundry 42 сейчас работает 50 (76 на момент перевода) сотрудников, и британское постоянно нанимает новых".

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

"В то время, когда я там работал было, кажется, две волны увольнений: от шести до, наверное, 15 человек. Кто-то этого заслуживал, кто-то нет. Способ, которым это сделали в последний раз, был ужасен. В других местах, откуда меня увольняли или где я работал, во время увольнений проходило два собрания. Все приглашались на одно из них, и вы никогда не знали, попадёте ли вы в группу увольняемых или нет. В индустрии это стало шуткой: вы заходите в комнату и получаете выстрел в затылок — вы никогда не знаете, что произойдёт. Но в CIG руководство село в одном из офисов и вызывало туда сотрудников по очереди в течение шести часов. Вы понятия не имели, вызовут ли вас, но каждый, кого вызывали, получал пулю в затылок. Было не по себе, когда вы встречались с вашим руководителем, и он уверял, что вы в безопасности. Потому, что даже он не знал этого. Затем вызывали следующего за вами, вы встречались глазами, и там читалось: "О, я так сожалею". Это худший способ разобраться с увольнениями. Они делали это не для того, чтобы посеять тревогу, но я был удивлён. Никогда не видел, чтобы так поступали".

Затем я поговорил с Крисом о сокращениях и реструктуризации. Он утверждал, что это было необходимо.

"Вы делаете это для того, чтобы образовалась правильная атмосфера в компании", — говорит он. "Да, для их резюме это выглядит нехорошо, но они могут не соответствовать требованиям. Иногда бывает так, что вы нанимаете кого-то, а через месяц или два вынуждены его уволить. Это довольно трудно, ведь вы нанимаете людей не для того, чтобы их увольнять. Такого не бывает. Увольнять всегда трудно".

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

Продолжение следует...