Star Citizen: Почему Star Citizen Ещё Не Вышел? - Часть 2 | Технические и Менеджерские Грабли

Сегодня мы расскажем вам о проблемах имплементации и рефакторинга игрового ядра и то как технические проблемы повлияли на затягивание разработки игры.

Если вы по каким-либо причинам не смотрели или не читали первую часть, то в ней мы рассказали, почему выбор Криса пал именно на детище Crytek, а не на какой-либо другой игровой движок, плюс попробовали развенчать основные мифы с этим связанные.

Первая часть:

DTF: https://dtf.ru/games/27955-pochemu-star-citizen-eshche-ne-vyshel-vybor-dvizhka-i-put-k-star-engine-chast-1

Youtube: https://www.youtube.com/watch?v=98SQNJal0OA

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

Делать мы это будем по традиции максимально сжато, сухими фактами и цифрами.

Таким образом, на момент начала работы над Freelancer, на счету Криса Робертса:

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

Напомним, что успешный проект с точки зрения геймдева:

Исходя из этих критериев, а также изложенных выше фактов, приходим к выводу, что Крис Робертс ну никак не может быть плохим управленцем. Возможно не идеальным, но, согласитесь, плохой менеджер вряд ли создаст и выведет на рынок более двух десятков коммерчески успешных игр. Притом будет после этого в настолько хороших отношениях с большинством из прежних сотрудников, что те согласятся поддержать его новый проект почти 20 лет спустя. Причем еще до того, как были получены первые миллионы от комьюнити.

Что же в таком случае произошло с Freelancer, спросите вы, если это не ошибки Криса? С Freelancer произошло то, что обычно происходит, когда пересекаются интересы двух сторон с разными точками зрения.

То что он был неплохим геймдевом и менеджером совершенно не делает из него идеального человека. Никто из нас не идеален, иногда случается даже так, что довольно позитивные черты человека в определенных ситуациях становятся для него обузой. Робертс не был исключением. Хотя нет, немного не так - именно его исключительность сыграет с ним злую шутку еще не раз и не два.

Основные черты, которые влияли на его работу и на то, что и как он делал, было две.

В интервью от 1999 года Ворен Спектор, бывший продюсер Origin Systems так вспоминал их знакомство с Робертсом: “Тогда мы оба были на выставке CES 1990 и Крис лично вносил изменения в код и правил демо игры перед показом. Кстати, Крис тогда практически не спал и ночами напролет кодил свой проект. Именно таким сфокусированным и даже немного повернутым на своей цели я его и запомнил.”

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

Отличным примером этому является игра Strike Commander. Крис с самого начала видел этот проект самым технологически продвинутым и совершенным симулятором на рынке. В то время как другие авиасимы, конкуренты детища Криса, использовали спрайты, Strike Commander мог похвастаться передовыми на то время технологиями, доступными только военным и промышленным авиасимуляторам - текстурным маппингом и мягкими шейдерами. Причем это все с рендерингом 3D моделей в реальном времени, к тому же на несколько лет раньше творений Джона Кармака.

Небольшое отступление - почти под каждую новую игру команда Робертса разрабатывала графическое ядро с нуля, опережая конкурентов на годы, что еще раз доказывает несостоятельность теорий критиков, будто Крис не понимал, что делает, выбирая для своего проекта именно CryEngine 3.

Но вернемся к Strike Commander. В планах Криса было агрессивно ворваться на рынок с игрой обладающей невиданной на тот момент графикой, физикой и реализмом. И планы эти были весьма реалистичными, если бы не одно но - цена этой реализации оказалась довольно высокой. Это касалось не только ресурсоемкости проекта, который, перевалив за миллион человеко-часов, опоздал к релизу на полтора года, но также и стоимости оборудования, на котором игра могла запускаться на максимальных настройках. Если перевести требования Strike Commander на характеристики современных ПК, то получится, что для максимально красивой графики вам бы понадобился 8ми ядерный процессор, 32 Gb ОЗУ, RX280Ti и целый Терабайт свободного места на диске.

Тем не менее, после сотен бессонных ночей и декалитров выпитого кофе, проект, который Крис впоследствии назовет “Апокалипсисом Сегодня в Геймдеве” вышел в свет и, невзирая на завышенные рекомендованные требования, снискал мировую славу и как следствие - финансовый успех. Даже спустя два года после релиза Strike Commander, ни один авиасимулятор не мог соревноваться с ним как в технологичности, так и в популярности. После Strike’а Крис выпустил еще несколько проектов, создал свою компанию, в 1997м взялся за Freelancer, а годом спустя начал съемки фильма Wing Commander.

Времени вести два таких масштабных проекта катастрофически не хватало, но Робертс же не мог передать хотя бы один из них никому другому - он же перфекционист! Раньше у него все всегда получалось, значит и сейчас должно получиться!

Компания Гейтса в то время как раз вплотную занялась разработкой своей консоли, для которой, естественно, нужны были собственные игровые проекты. Желательно громкие. “Мелкомягкие” потихоньку стали присматриваться к разным командам на рынке, дабы заманить их под свое крыло. Не удивительно, что первыми в поле зрения попались конторы, создававшие игры для мирового гиганта, среди которых была и Digital Anvil Криса Робертса. У Microsoft на все всегда был чисто деловой взгляд и игры не исключение. Если они понимали, что игра может продаться тиражом больше 500 000 копий, они сами становились издателем, как было в случае со Starlancer. По поводу Conquest: Frontier Wars и Loose Cannon у Microsoft были серьезные опасения, а потому данные проекты Наковальни были проданы Ubisoft. Что ж до Freelancer, то на его счет у компании были большие надежды, особенно если учесть невиданный на то время размах и свободу действий, которые сулил геймплей проекта, а также его снискавший мировую славу автор. Кстати, это в очередной раз доказывает, насколько Microsoft доверял Крису, его профессионализму и опыту.

Что ж получилось?

А получилось то, что в погоне за собственными мечтами и амбициями, ни Крис, ни Microsoft не поставили игроков в приоритет. Через два года работы над проектом Крис, наконец, сделал свой выбор в пользу фильма. В 1999м году в интервью для GameSpot он сказал, что на тот момент уже вплотную не занимался Freelancer и его разработкой, а лишь следил за концепцией игры и ее соответствию первоначальной идее. Еще через год Крис передал проект Microsoft вместе с компанией после того, как решил перейти из игровой в киноиндустрию. Microsoft же привел в команду Наковальни своих менеджеров и, забыв об обещании Крису следовать концепции игры, в результате обрезал геймплей более, чем на половину, дабы быстрее и без заморочек релизнуть давно обещанный продукт.

Кто же виноват в том, что Freelancer вышел таким, каким вышел? Да все.

Почему история с Freelancer так важна, спросите вы?

Во-первых, это первый бизнес провал Криса Робертса, но никак не менеджерский, ведь он вплотную занимался проектом не более года, максимум полтора. С деловой точки зрения, его ошибкой, и довольно частой, было водрузить все бремя проекта на собственные плечи, в то время как не готовая к свободному плаванию команда с этим не справилась. Во-вторых, теперь вы понимаете, что Freelancer от Криса передалась только общая идея, сюжет, дизайн и видение, а все остальное уже было не его рук дело. В-третьих, нам важно провести несколько параллелей между разработкой Freelancer и Star Citizen. Понять, есть ли у этих двух проектов общие черты, и главное - общие предзнаменования грядущего провала Звездного Гражданина, который вот уже скоро шесть лет прогнозируют критики.

Как же началась история разработки Star Citizen?

В отличии от Freelancer на момент начала работ у Криса не было команды. В отличии от Freelancer у Star Citizen не было бюджета, а еще не было технологий и не было игрового движка. Если беды и растянутый график разработки Freelancer в основном уходили корнями в решение Робертса круто изменить свою сферу деятельности, плюс его самоуверенность, построенную на основе непрерывной истории успеха, то проблемы новой мечты Криса имеют в основном кадровые и в еще большей степени технологические причины. Да-да, вы не ослышались - именно технологические и кадровые проблемы, а не менеджерские, как думают многие, привели к очень долгой раскачке разработки, которая заняла почти два года.

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

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

Эхх, если бы в реальности все работало именно так… Но нет.

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

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

Если перевести все это на язык цифр и финансов, то чтобы найти, принять в штат и обучить 10 разработчиков среднего уровня, со средним окладом в 70 тысяч долларов США в год, CIG инвестировали от двух с половиной до пяти человеко-лет и от 200т до 400т тысяч долларов США. Причем за все это время и деньги эти самые десять кандидатов лишь весьма посредственно могли влиять на эффективность и результативность проекта.

Но самое важное то, что тут нет прямо-пропорциональной зависимости от количества задействованного ресурса. В школьных задачках вам точно попадались вопросы типа - если один маляр красит 100 квадратных метров забора в час, то за сколько времени с этой же задачей справятся 10 маляров? Ответить проще простого, ведь, да?

А вот и нет. Реальность очень далека от школьных учебников и вероятность того, что продуктивность 10ти маляров в рамках того же самого задания будет в 10ть раз выше, чем одного, весьма спорна. Эти маляры не роботы, они не могут выполнять одну и ту же задачу с одинаковой эффективностью на протяжении четко выделенного времени. У одного может не хватать нужного опыта, у другого слишком короткие руки и маленький рост, третий вообще филонит и ходит на перекур каждые 5 минут.

А разработка игры это вам не валиком махать и продуктивность людей отличается даже не в разы, а на порядки. Хороший специалист “в соло” может решить условную проблему за день, тогда как целый отдел менее опытных не справится с ней и за месяц. Поэтому рассчитывать, что можно в 10ть раз повысить продуктивность разработки ПО, путем добрасывания 10ти разработчиков в горнило проекта, это все равно как считать, что если одна женщина выносит ребенка за 9ть месяцев, то 9ть женщин выносят того же ребенка всего за один месяц.

В экономике это явление частично описывает теория убыточной доходности - сверх определенных значений факторов или ресурсов, увеличение одного из этих факторов не обеспечивает эквивалентный прирост дохода и продуктивности. Иными словами доход и продуктивность растут медленнее, чем вложенный ресурс. В пример можем привести видеокарты, которые работают в режиме SLI. Многие раньше думали, что удвоив количество графических карт в своем ПК, можно достичь и удвоенной продуктивности. На деле же второй адаптер принесет вам в лучшем случае 70%ный прирост продуктивности, а третий вряд ли сможет повысить планку еще на 40%. То есть, чем больше вы будете увеличивать количество одного и того же ресурса в рамках неизменной системы, тем меньше каждое последующее увеличение будет влиять на продуктивность и конечный результат.

Это так же работает в случае любого производства и не только разработки ПО. Допустим у вас команда в 5-10 человек и вы берете к себе еще одного или двоих. В этом случае ввод новых людей пройдет легко, быстро и уже через месяц новенькие вольются в рабочее русло. Но если в вашу команду в 5-10 человек нужно набрать 300 или 400? Где их найти? Кто и как их будет обучать? Где их рассадить? Просто представьте, что только на одно прочтение тысяч резюме кандидатов в сумме уйдут недели, на собеседования - месяцы, а на адаптацию этих кандидатов - целые годы.

В доказательство того, насколько печальной в CIG была ситуация с кадрами в 2013-2014 годах, приведем несколько цитат из интервью Эрика Киерона Дейвиса, продюсера и директора Лос Анджелесского офиса CIG.

Как вы уже, наверное, поняли из нашего предыдущего пункта, у CIG просто не было другого выбора. Без подрядчиков работа над такими важными для комьюнити модулями как Ангар или Arena Commander начались бы только через год, а то и полтора. Без вклада Behaviour Interactive, Moon Collider, Turbulent и тем более Crytek, CIG не смогли бы начать фазу прототипирования, экспериментов с движком, настроить адекватную работу сайта и обратной связи с бэкерами.

Даже через год работы над проектом, в команде Криса было всего 2-3 разработчика способных работать с ядром игры, и то на довольно примитивном уровне. Во время CitizenCon 2013, сам Крис обмолвился, что весь год они очень тесно работали с Crytek и он лично буквально каждый день мучал их звонками и письмами.

С одной стороны, аутсорсинг многих задач помог CIG быстро начать работу сразу по нескольким направлениям и даже запустить два столь ожидаемых комьюнити модуля. С другой стороны, по мере роста компании и увеличения количества персонала, работа с подрядчиками, какой бы налаженной она не была, серьезно мешала передаче разработчикам CIG всех знаний и экспертиз по технологиям и инструментам игры. Неэффективная коммуникация привела к тому, что еще один подрядчик CIG - IllFonic, разработал FPS модуль Star Marine так, что его невозможно было синхронизировать со всеми остальными модулями Star Citizen. Модели, скелетная анимация, физика движений - все это пришлось переделывать почти с нуля, что и стало причиной задержки релиза Стар Марин почти на полтора года.

После такой неудачи CIG окончательно перенесли всю самую важную работу над проектом внутрь компании, тем более, что собственная команда экспертов по CryEngine как раз перешла к ним из Crytek в начале 2015 года. Все же, повторимся, без подрядчиков и их помощи, CIG еще два года после завершения Кикстартер кампании, рисовали бы концепты, занимались лором и не смогли бы выпустить ни модуля ангара, ни Arena Commander.

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

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

У этой версии развития событий сразу обнаруживается множество нестыковок.

Во-первых, немало перспективных целей были озвучены еще на первых страницах описания проекта, как на Кикстартере, так и на сайте RSI.

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

В-третьих, в сентябре 2013 года CIG провели голосование на сайте и спросили бэкеров, как им стоит поступить с собранными 20тью миллионами долларов США:

88% опрошенных, а это было не много, не мало, почти двадцать одна тысяча бекеров проекта, проголосовали за третий вариант. Именно поэтому Крис и не останавливал сбор средств, после получения заветных двадцати миллионов. Именно поэтому новые фичи добавлялись в лог проекта на протяжении нескольких лет. Но главное то, что именно после этого голосования CIG отказались делать сингл с мультиплеером и решили создавать целую вселенную и воплотить мечту Криса в реальность. А значит Star Citizen - ни как сингл, ни тем более как ММО не могли появиться ни в 2014м, ни в в 2015м, как утверждал и планировал Крис до проведения этого самого опроса.

Фактически это продолжение истории предыдущего мифа, но критики так часто его вспоминают, что мы решили их разделить.

Итак, многие знатоки и гуру разработки современных игр утверждают, что CIGам стоило сперва сделать и выпустить небольшую четко ограниченную версию продукта, который бы обеспечил игроков достаточным перечнем основного геймплея, а потом добавлять новые модули и расширять этот контент последующими патчами. В качестве примера приводится такой проект как Элит Денжерос. Дескать, вон Фронтиры быстренько организовали все те же 20-30 миллионов и уже через четыре года после анонса, релизнули готовый продукт на рынок, который заработал им по самым скромным меркам от 120ти до 150ти миллионов долларов США за более чем 3 миллиона проданных копий игры.

Соответственно, CIGам стоило делать то же самое и идти тем же путем - у фанов была бы игра, у разработчиков честно заработанные, а не выпрошенные у бекеров деньги за корабли, и проект ждало бы светлое будущее.

Чудесно, правда? А вот и нет.

Давайте вспомним, когда вышло последнее глобальное обновление данной игры? Конец 2015 года, то есть через год после релиза. Иными словами, за три года в Элите не появилось ни одного существенного патча - кораблики, новые возможности гринда и прочие финтифлюшки мы в расчет не берем. Напомним еще и обещания Фронтиров, которые рисовали фанам красочные полеты в атмосферах газовых гигантов к 2017му году, посадки на планеты земного типа, годом позже, и наконец возможность передвигаться в мире в качестве аватара человека, а не космического корабля. Исходя из дорожной карты игры эти нововведения появятся еще нескоро. Но почему так произошло? Все же очень красочно начиналось, именно так как хотело комьюнити - сперва играбельный геймплей, а потом адд-оны расширяющие его. Что пошло не так?

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

Постараемся объяснить это на более простом примере. Архитектуру программного решения можно отдаленно сравнить с архитектурным планом здания. Если вы заложили в план проекта возвести особняк, то построив его, ваш проект будет наилучшим образом выполнять функции особняка для вашей семьи. Но что если ваши потребности вырастут? Хорошо, вы внесете изменения в план, проведете перерасчет конструкции и добавите пристройку или же еще один этаж, или увеличите чердак.

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

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

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

Напомним, что CIG адаптировала свой FPS модуль на протяжении полутора лет, чтобы имплементировать его во все аспекты движка. Это же касается и прочих его составляющих, о которых мы уже упоминали в предыдущем видео. Вся эта работа была проделана для того, чтобы заложить как можно более основательную базу для такой амбициозной игры и создать максимальный запас масштабируемости и гибкости. Иными словами, после результатов упомянутого нами голосования и непрекращающегося финансирования, CIG поняли, что им придется строить не особняк и даже не многоквартирный комплекс, а самый высокий в мире трехкилометровый небоскреб, который остальные компании не только не взялись бы строить, но даже проектировать. Естественно, что Крис и его команда основательно принялись за фундамент и подготовку к строительству. А это, как вы понимаете заняло намного больше времени, чем если бы они строили по принципу Фронтиров. Бекеры же теперь могут быть уверены, что неудачи постигшие разработчиков Элиты будут минимизированы.

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

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

У CIG же не было ровным счетом ничего. Ни команды, о чем мы вам уже говорили, ни технологий, ни денег. Если вы считаете, что качественные игровые проекты топ уровня с современной картинкой и продуманными механиками стоят недорого, то вспомните такие игры как ГТА5 - 265 миллионов, обе части Дестини, общий бюджет которых перевалил за полмиллиарда, или Рэд Дед Редемпшн 2, бюджет которой по последним слухам может достигать 300т миллионов. Да что говорить - помните почти ежегодные поделки Колл Оф Дьюти, которые в одно время порядком поднадоели игрокам? Так вот, каждая часть этой серии стоила никак не меньше 100та миллионов, и это были игры созданные на коленке, существующими командами и с использованием уже существующих инструментов и технологий.

Как мы уже упоминали выше, даже наличие внушительного бюджета еще не означает, что игровой проект будет разработан быстро и сдан в срок. Все ту же ГТА5 делали 5 лет силами свыше тысячи разработчиков. Вышеупомянутая Ред Дед Ридемпшн 2 увидела релиз только спустя долгих 10 лет. Такие технологически заурядные проекты как ТЕС Онлайн, Тим Фортресс и Фоллаут 3 разрабатывались по 8 лет каждый и только Морровинд можно было назвать в некотором роде революционным для своего времени. Спор, Л.А. Нуар, Стар Крафт 2 и Киберпанк провели по семь лет на наковальнях игровых кузней, причем последний использовал уже готовые наработки двигателя Ред Энджин. Наконец, Дьябло 3 создавали аж долгих 11 лет. Да, проект дважды менял фокус и концепцию, что отразилось на сроках, но тем не менее, суммарно процесс занял больше десятилетия. Как видите, наличие неограниченного бюджета с начала разработки довольно посредственно влияет на дату релиза игры. Для сравнения, Star Citizen находится в разработке вот уже 5 лет и 11 месяцев.

Второй важный фактор - делать работу, располагая на нее бюджетом в полной мере, не так уж и сложно - главное перед стартом все правильно распланировать. Короче говоря, если ваш менеджер проекта знает, что делает, правильно заложил риски, распланировал время и ресурсы, считайте, что значительный шанс на успех у вас уже в кармане.

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

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

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

Спросите у любого Проджект Менеджера, хотел бы он управлять и нести ответственность за проект с постоянно растущим, не фиксированным бюджетом, финансированием растянутым на несколько лет, и абсолютной неопределенностью ни в его периодичности, ни в завершении? Скорее всего, 95 из ста вам ответят нет, а оставшиеся 5 хорошо подумают прежде, чем браться за такую авантюру.

Наконец, напомним, что исходя из наших расчетов, которые недавно были подтверждены реальными цифрами налоговых деклараций, CIGам едва хватает доната на покрытие своей операционной деятельности. Исходя из всего вышесказанного, вряд ли кто-то в схожих условиях смог бы добиться лучшего результата, тем более во времена провалов проектов со значительно более стабильным и внушительными финансированием, вроде Масс Эффект Андромеда, или той же Дестини 2, которая принесла издателю на порядок меньше прибыли, чем ожидалось ранее.

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

Итак, конец 2013-го года. Ангарный модуль ушел в релиз, фанаты пока довольны. Собрано свыше 20ти миллионов долларов, прошел первый CitizenCon и нужно двигаться дальше. А именно - расширять возможности движка, исходя из пожеланий граждан о большой и живой вселенной, делать прототипирование по созданию локаций, инструментов, взаимодействий игровых модулей, попутно создавая единую архитектуру огромного решения под неофициальным названием Стар Энджин. Вот только есть одна небольшая проблема - у CIG нет в команде ни одного высокоуровневого специалиста по CryEngine 3.

Разработчики Криса не могли решать сложных задач и не знали особенностей игрового ядра. На самом деле, каждый специалист, который разбирался в CryEngine 3 на нужном CIG уровне работал в Crytek. Работа посредством консультаций почтой и телефоном была неэффективной, потому Crytek выделил своего особого представителя для поддержки CIG - Шона Трейси. Будучи весьма ценным экспертом широкого профиля по движку, Шон заложил необходимые основы по планированию будущей архитектуры и создания дорожной карты апгрейда ядра, а уже через год полностью перешел в структуру CIG.

2014-2015 годы были самыми сложными для Crytek, и CIG которым крайне не хватало специалистов, моментально переманили почти два десятка ключевых инженеров и архитекторов движка в свою команду. Это, несомненно, было чуть ли не самым важным и правильным менеджерским решением Криса за всю историю проекта. Тут стоит упомянуть, что в 2014 году в технологическом плане CIG по факту все еще топтались на месте. Шон не мог закрыть все направления, хоть и работал на износ - ему банально не хватало квалифицированных людей. С другой стороны, художниками, авторами и дизайнерами была создана целая вселенная Star Citizen. За год с небольшим было прописано абсолютно все до мельчайших деталей от лора, инопланетных рас и истории ОЗИ, до экономики, геймплейных механик и всего сюжета Эскадрильи 42. Многие детали дизайна и концептов, которые нам по крупицам выдавливают на протяжении нескольких лет, были готовы уже тогда, но не было команды способной имплементировать эти ассеты в игровой движок.

К счастью для CIG и несчастью для Crytek, финансовые проблемы последней привели к массовым увольнениям и значительному падению мотивации среди оставшихся. Именно тогда Крис, как с помощью Трейси, так и самостоятельно, перетянул разработчиков CryEngine в команду CIG. Важно отметить, что это были совсем не рядовые программисты, а техлиды, директоры разработки и архитекторы, иными словами, настоящие эксперты по CryEngine, люди которые изначально его создавали и развивали.

Фактически только с весны 2015 года началась активная работа по рефакторингу, а именно внутреннему преобразованию ядра и его программного кода с целью изучения и подготовки к оптимизации, модернизации и прочим апгрейдам. Весь процесс рефакторинга и модернизации, включая переход на 64 бита и удвоенную точность стоил CIGам больше 3х лет и усилий тридцати-сорока инженеров высокого класса. Для сравнения, переход на Ламбрярд, с которым критики CIG связывают затягивание сроков разработки, занял у команды всего одну неделю.

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

Первый пример это унификация камеры и модели персонажа в FPS режиме как от первого, так и от третьего лица. В 99% современных шутеров при переключении камеры вида на самом деле происходит не перемещение вида, а реальная смена 2х разных типов персонажа, которые отличаются взаимодействием анимации, моделью, камерой и прочими мелочами. Иными словами, если посмотреть на вид от первого лица со стороны, то вы бы увидели, что оружие намертво прикреплено справа к голове персонажа, ног у него как таковых нет, а тело является параллелепипедом и попросту летает над поверхностью будто на гравиподушке. Остальные игроки в одной с вами сессии видят ваш аватар от 3го лица, но правда в том, что оба аватара не синхронизированы. Например пули на самом деле вылетают из ствола от первого лица, но от третьего это заменено простой анимацией, дабы имитировать движения аватара от первого лица.

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

В Star Citizen оба вида изо всех камер, модели персонажа, а также анимации взаимодействия являются одним и тем же аватаром с одними и теми же физическими атрибутами. Что от первого, что от третьего лица игрок управляет единым аватаром. Любое действие проделываемое вами с видом из глаз, другие видят со стороны именно в той самой анимации и с теми же атрибутами, что и вы. Именно такой подход позволит различить игрока просто идущего с оружием в руках, от игрока целящегося из него в вас, и быстро, а главное правильно принимать важные решения в игре.

Кстати именно эта унификация и стала причиной задержки Стар Марин, когда студия IllFonic сделала FPS модуль и его аватаров “по старинке”. И CIG, сперва потратившим несколько месяцев на унификацию аватара в игре, пришлось потом потратить еще год на исправление ошибок подрядчика.

Вторым примером сложности переделки CryEngine 3 может послужить выпиливание функции “Use” из игрового движка. Перед стартом работы над Item 2.0 и новой функцией взаимодействия с предметами и объектами, сперва нужно было удалить все присутствие более старого варианта взаимодействия, который игроки прекрасно помнят еще с первой части Кризиса. Вот только “Use” был настолько глубоко интегрирован в ядро, его модули физики и графики, анимацию, модели персонажей и абсолютно все объекты, с которыми игрок вступал во взаимодействие, что команде Трейси пришлось потратить более семи месяцев на искоренение данной функции. Вдумайтесь только - сами создатели движка прокопались в нем более полугода, чтобы начать имплементацию Item 2.0 и предоставить его нам уже в патче 3.0. Признайтесь, кто из вас там плакал о задержке Альфа 3.0?

В 2015 году CIG открывают офис во Франкфурте, а с ним получают доступ к единичным в мире специалистам и экспертам процедурной генерации окружений и локаций. Марко Корбетта, лидер направления и тех директор CIG, в свое время наделал немало шуму вот этим роликом, демонстрирующим не только процедурно сгенеренный город, но еще и полностью разрушаемое окружение в нем.

Кто такой Марко Корбетта? Это лид программист и технический директор в таких проектах как Far Cry, всех частях Crysis, а также Ryse: Son of Rome. Его мастерство с CryEngine можно сравнить разве что с мастерством Джимми Хендрикса с гитарой. Корбетта также создал свой собственный движок Equinox, а после упомянутого демо, которое позволяло генерить огромные высоко-детализированные пространства, да еще и без существенных нагрузок на оперативную память, мог подарить Crytek значительное преимущество над конкурентами.

Но не тут то было. Все, затаив дыхание, ждали вторую часть Crysis и то, каким будет выглядеть открытый Нью Йорк, созданный структурно-процедурной системой Корбетты, которая позволяла, к тому же, динамически генерировать и детальные интерьеры помещений. И вот игра вышла, но без использования наработок Корбетты. Прошло еще три года, но и в третьей части идеи Марко не прижились. Сейчас довольно сложно сказать почему так произошло, но факт остается фактом - Crytek, нашедши золотую жилу, попросту прошли мимо нее, даже не попытавшись рискнуть использовать новую технологию и подход в левел дизайне.

К счастью, еще через два года Корбетта, его наработки, а также его партнер по все той же самой демке перешли в CIG. Результатами их кропотливой работы вы могли любоваться как в прошлом, так и в этом году. Вся процедурная генерация локаций от планетарных биом Hurston, до мегаполисов ArcCorp - заслуга команды Марка Корбетты. Именно в Star Citizen его кропотливый труд и поистине визионерские идеи не были отложены в ящик и забыты, а наоборот получили второе рождение и неимоверное, буквально фантастическое развитие.

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

Как и у любого шутера от первого лица 2010-2011 годов у Crysis 3 были минимальные сетевые возможности, которые ограничивались поддержкой мультиплеера на относительно небольших картах для одного-двух десятков игроков. В который раз повторимся, что остальные движки-конкуренты CryEngine обладали схожими, если не такими же ТТХ сетевой архитектуры. То есть, по факту готового сетевого решения для FPS ММО ни у кого из прямых конкурентов не было и быть не могло. В то же время у проекта Криса были сразу две большие технологические проблемы - чрезмерная детализация, как визуально, так и геймплейно, плюс огромные объемы пространств наполненные множеством ассетов с этой самой детализацией.

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

«Система зонирования - это лучший способ, который мы придумали для хорошего пространственного разделения наших данных. Мы пытаемся объединить многие подсистемы в одну систему, потому что в большинстве движков есть отдельная система секционирования для рендеринга, обновления свойств и система сетевого трафика. Идея состоит в том, чтобы поместить все это в одну зону, которая может быть использована для рендеринга, для визуальной окклюзии, для обновления, для сети. Зоны контента разделяют вещи по контейнерам, которые являются логическими, так что зоной может быть «орбита Терры», или это может быть зона, в которой есть Терра и станции и корабли вокруг нее.

С этой целью зоны внутри кораблей, станций и окружающих планет создадут иерархические структуры данных, которые не ограничиваются стандартными размерами. Это обеспечивает большую гибкость в движке, что в конечном итоге помогает в потоковой передаче данных для больших объемов пространств. Система зон позволяет CIG перемещать космические корабли, которые содержат многочисленные комнаты, NPC и различные объекты как один «главный» элемент.»

Игра будет разделять на сегменты все пространство, которые могут содержать, скажем, десять кораблей. Эти данные передаются клиенту и обратно, причем каждое судно обновляется как единое целое. Уверены, что вы уже поняли, что речь шла об OCS или Object Container Streaming, который позволил стримить контейнеры с объектами в реальном времени, наперед предопределяя очередь загрузки/выгрузки ассетов для каждого отдельного игрока, что значительно снизило нагрузку на клиент. Этот шаг привел к поистине революционному повышению FPS на 200% для средних ПК и почти на 300% для топовых машин в патче 3.3.5.

А как же другие масштабные ММО решают проблемы Big Data, то есть огромных объемов данных, по-нашему? Возьмем, к примеру, EVE Online.

Платформа EVE построена следующим образом:

По факту EVE управляет огромный, находящийся в Лондоне, суперкомпьютер Tranquility, весом в две с половиной тонны, с двумя сотнями активных серверов, четырьмя сотнями ядер общей частотой более 1го Терагерца и почти восемью Терабайтами оперативки. Через некоторое время Tranquility был дополнен Serenity, расположенным в Китае, а также Singularity - тестовым сервером.

Возможности сетевой архитектуры и кода EVE Online действительно внушительные. Она позволяет содержать почти 8000 звездных систем, свыше 300 000 активных игроков и более 60 000 игроков одновременно. А в одномоментном инстансе одной звездной системы могут играть до 3-4 тысяч игроков одновременно. Хотя “играть” это несколько преувеличенное определение.

Почему?

Потому что при одновременном участии нескольких сотен игроков, например, в одной битве, мощностей серверов недостаточно для обеспечения плавного и комфортного геймплея. С целью облегчения задачи для Tranquility в операциях в секунду, ССР пошли на несколько хитростей. Во-первых, такая перегруженная звездная система отрезается и дистанцируется от остальных систем и серверов, чтобы не влиять на работоспособность соседних инстансов. Во-вторых, в этой системе, после достижения определенного уровня трафика, а это случается в среднем при цифрах в 300+ игроков, включается режим TD. Time Dilation или иными словами. Замедление Времени позволяет значительно растянуть течение времени в такой системе, максимум до 10% от реального и позволить серверу эффективнее обрабатывать массивы данных без угроз для пакетов быть потерянными. Правда при достижении общего количества игроков до более чем 3 тысяч не спасает даже TD и сервер буквально захлебывается немыслимыми объемами данных.

Что же может противопоставить Star Citizen такому неоспоримому лидеру как EVE Online? У решения ССР есть ощутимое слабое место - это ограничения собственного аппаратного решения, которое создавалось специально под нужды EVE. Конечно же, теперь популярность EVE постепенно снижается и ССР вряд ли потребуется резко масштабировать серверную составляющую проекта. С другой стороны, случись такое сейчас, исландцам пришлось бы здорово вложиться в аппаратную часть, а именно добавить больше физических ядер, дисков и памяти.

У проекта Криса нет таких ограничений. Единственный физический сервер Star Citizen - это билд сервер, который был собран с одной целью - хранить и тестировать последние билд версии обоих игровых проектов. Характеристики этого сервера ровно наполовину уступают Tranquility, кроме одной - объём игровых данных, который на данный момент исчисляется почти двумя с половиной терабайтами данных, что на 70% превышает объемы всей EVE Online. Заметим, что это на этапе ранней Альфы, когда в Постоянной Вселенной нет и одной целой звездной системы. Сколько же места займут 100 или 200 таких систем, можете себе представить?

Игровые же сервера Star Citizen находятся на облаках Amazon Web Services, который располагает более полутора миллиардами серверов во всех частях земного шара. Это позволяет значительно оптимизировать время отклика серверов и распределить трафик. Но главное то, что AWS дают возможность буквально в считанные минуты масштабировать количество виртуальных машин, серверов, пространства и вычислительной мощности, чтобы выдержать даже такую нагрузку, которая последовала бы за резким скачком онлайна с десятков тысяч до нескольких миллионов игроков. Сравнивать такие масштабы с Tranquility, это как сравнить обычный двигатель внутреннего сгорания и высокотехнологичный двигатель гоночного прототипа или болида Формулы 1.

Идем далее. Сервера EVE Online по большому счету статичны. Каждый системный сервер включает в себя две-три звездные системы. Для густонаселенных систем выделяют отдельные сервера, но принцип один и тот же - сервера редко масштабируются, так как равномерно распределенная нагрузка не вызывает такой потребности. Да, во время возникновения активного трафика в системе, или событий вроде значительных баталий, такой сервер отрезается от остальной вселенной и включается TD, но при этом масштабируемость самого сервера остается фактически неизменной.

В Star Citizen поместить всю звездную систему на один физический сервер невозможно. Это невыполнимая задача чисто с технической точки зрения - слишком велики объемы данных, возможно даже до нескольких десятков Терабайт. Но как, в таком случае реализовать задумку, чтобы все игроки без исключения находились в одном и том же инстансе и могли беспрепятственно взаимодействовать друг с другом? В EVE все находятся на глобальных серверах Tranquility и Serenity, разделенных на звездные системы под-сервера, а переходы между серверами для игроков играют роль межсистемные прыжки, создавая иллюзию бесшовности вселенной EVE. В Star Citizen же одну звездную систему и даже одну планету нужно будет разделить на несколько десятков серверов, дабы оптимизировать нагрузку на сеть и архитектуру.

Тут на помощь придет Server Meshing - это на 100% динамически изменяемая, гибкая архитектура, которая задействует свои ресурсы именно там, где это нужно и именно настолько насколько этого требует приложение. Иными словами, если в необитаемую звездную систему, поддерживаемую десятком серверов в какой-то момент ворвется вандуульский, а потом и имперский флоты, то к системе мгновенно подключатся еще несколько десятков, а то и сотен серверов, которые станут обрабатывать возросшие массивы данных и предоставлять трафик. Правда делать они это будут не во всей системе распределенно, а точечно, именно в месте самого большого скопления кораблей и игроков, в то время как остальные сервера будут находиться в режиме ожидания, поддерживая существование остальных ассетов данной системы. Как только битва закончится, дополнительные сервера будут отключены и архитектура вернется в свое первоначальное состояние, как это было до баталии.

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

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

На данный момент есть только один проект, который испытывает схожий подход - это Dual Universe, но масштабы пространств и детализация окружений с ассетеми там намного скромнее. К тому же внедрение технологии дальше тестов пока не зашли. Уверены, что эти факты уже сами по себе дадут вам хотя бы приблизительное представление о том, какие сложные технологические задачи стоят перед разработчиками Star Citizen.

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

На сегодня все. Спасибо, что дотерпели до самого конца.