Почему Star Citizen Ещё Не Вышел? | Выбор Движка и Путь к Star Engine. Часть 1

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

Итак сумма озвученная Крисом для создания игры составляла на тот момент 2 млн. долл. США. Первым этапом и целью кампании были доступ к мультиигровому модулю догфайтинга, а также пакет синглпроекта Эскадрильи 42 с 30тью миссиями, то есть изначально проект планировался как сингл с мультиплеерной составляющей.

На старте краудфандинга, Крис даже не мог ожидать, что игровое сообщество, которое в основном состояло из игроков Фрилансера и фанов Винг Командер, до 19 ноября 2012 года, выпишет ему кредит доверия в сумме 6 млн. долл. США. По мере роста бюджета росли и расширялись цели игры, нарастая и наслаиваясь на первичную идею будто снежный ком. После финиша кампании на Кикстартере в декабре она переросла в целую вселенную с 70ю звездными системами и 50 миссиями в рамках Эскадрильи 42. С годами фандинга, который был перенесен на сайт проекта, сумма стремительно росла и на день выпуска данного видео она составила более 194 миллиона долларов США.

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

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

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

Именно таким образом, сингл проект с мультиплеером и превратился в целую Вселенную, о которой Крис Робертс мечтал более 20 лет.

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

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

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

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

Таким образом, разработка началась в 2013 году именно после завершения Кикстартер кампании в декабре 2012, а не в 2011, когда Крис впервые представил свою идею игры и проекта широкой публике. Старт разработки в 2011 году, вероятно, один из самых известных мифов проекта.

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

На самом деле не было таких движков, нет до сих пор, и вряд ли скоро появятся. Так в 2016 году на Ситизенконе CIGи объявили о наличии своего движка под названием Star Engine.

Star Engine - это глубоко переработанная версия CryEngine3. В начале 2015 года CIGи отказались от последнего, а именно речь идет о версиях билдов 3.7 и 3.8. Этот отказ сопровождался тем, что было сложно интегрировать изменения CIG в новые версии CryEngine. Разработчики достигли такой точки, когда интеграция стала достаточно сложной, потому что они уже внесли слишком много изменений для своей игры. В принципе не имеет большого значения, какие именно изменения были внесены разработчиками в ядро, если те были сделаны с учетом целей и потребностей проекта и не зависят от внешних факторов. Но когда приходит обновление с фундаментальными апдейтами архитектуры от самого поставщика движка, получается, что обе версии расходятся настолько сильно, что не могут быть интегрированы чисто технически.

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

Это стало одной из причин почему CIG отказались от последующих обновлений CryEngine и отдали предпочтение Lumberyard.

Вторая причина - это то, что основное ядро Lumberyard основано на CryEngine. Amazon одной лицензией получил полный доступ к технологиям Crytek. Немаловажно и то, что сам движок, его загрузка и использование для создания игр - бесплатны, ведь Амазон берет плату только за использование их облачных сервисов. Подробнее о Lumberyard и причинах перехода на него мы расскажем чуть позже.

Нет, не было и нет до сих пор. Любой FPS движок из коробки по сегодняшний день изначально не заточен под ММО.

Вообще-то процесс частичного преобразования фпс движка для добавлений фунций ММО возможен на любом движке, но тут мы точно столкнемся с рядом проблем. Первая из них - финансовая. Лицензии именитых движков не позволяют купить и просто пользоваться ими. После релиза проекта от разработчиков требуются отчисления процента от продаж создателям движка, которые стартуют с 3-5% и зависят от объемов продаж игры.

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

Начнем с того, что любой ФПС движок изначально не разрабатывался и не будет разрабатываться для ММО. Для ФПС важен именно ФПС, простите за каламбур, а также максимальная детализация картинки в рамках небольшой, пускай и ладно скроенной локации для нескольких десятков игроков. Даже увеличение игровых карт вдвое или втрое существенно повлияет на нагрузку серверов, быстродействие сетевого кода и наконец, на сами клиенты.

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

Давайте же вместе вспомним нашумевшее интервью Джейсона Шраера о причинах провала Масс Эффект Андромеда, в котором автор очень детально описал с какими сложностями столкнулись Байовер, переводя сперва Драгон Эйдж, а потом и Масс Эффект на Фростбайт.

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

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

В результате мы получили, что получили - две Экшн-РПГ, заточенные под ФПС, а не классические РПГ, как прославленные предки обеих серий.

Теперь рассмотрим движок Юнити - тут все коротко, он недостаточно быстр и мощен ибо использует C # (СиШарп) или JavaScript (Джаваскрипт), а не С++ (СиПлюсПлюс), как во всех остальных производительных играх. 64-битный редактор на Unity появился только к середине 2014 года наряду с глобальным освещением в реальном времени. Вообще большинство дополнительных фич у Юнити платные и это притом, что доступ к исходному коду закрыт. Потому Юнити в нашем случае отпадает чуть больше, чем полностью.

Наконец АнрилЭнжин. Великий и ужасный.

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

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

Наконец Анрил4 не бесплатный и Эпики просят существенный процент от дохода студии либо издателя

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

Lumberyard, унаследовав ядро CryEngine, после приобретения был примерно наполовину собран заново программистами Амазона. Переход на Lumberyard с CryEngine был абсолютно логичен. Зачем платить за то, что идет бесплатно от Амазона, да еще с использованием их сервисов и ресурсов по выгодной цене? Даже если писать игру на другом движке, то все равно придется арендовать сервера у кого-то. И, скорее всего, это будет тот же Амазон из-за приемлемой цены и почти неограниченных возможностей масштабирования объемов и мощностей, а также огромным опытом сотрудничества с игровыми разработчиками и издателями, который трудно переоценить.

Все мы помним, что Амазон - гигант с капитализацией свыше 700 миллиардов долларов США, получающий сверхприбыли во многих отраслях. Теперь пробующий себя и в игровой - выкупив у Crytek движок за $50млн, что не дало последнему окончательно уйти в небытие, и существенно доработав его, превратив в еще один источник дохода.

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

Представили? Вот вам еще одна причина перевода ядра Star Citizen на Lumberyard, а также переманивания ключевых сотрудников Crytek для последующей работы над движком. Выводы - выбор движка CIGами был верным, а переход на Lumberyard в конечном счете тоже оказался верным решением.

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

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

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

По факту было внедрено много изменений для поддержки больших пространств. Фактический максимум - это цифра в километрах с 18тью нулями, которая поддерживается с точки зрения пространства.” Тут в игру вступает предел вычислений с плавающей точкой. 64-битные вычисления позволяют увеличить объем памяти и увеличить виртуальное адресное пространство, что делает возможным создание большой вселенной в Star Citizen. Ведь 64-разрядные вычисления начинают бить по ограничениям памяти аж на 16ти Эксабайтах, или же примерно 18ти миллиардах Гигабайт, чтобы было понятнее.

Ведущий разработчик и техлид Шон Трейси в интервью сказал: “Это одно из самых больших изменений, которые мы сделали для реализации планет и пространственного позиционирования. Я думаю, что с первой системой, которую мы собираемся сделать, с "квантовым прыжком" потребуется около 45 минут, чтобы пересечь всю систему. И это только одна система, если вы хотите думать о системах как о самих уровнях или локациях. В течении 45 минут квантового путешествия, что является фактически реалистичным значением 20% скорости света, не будет никакой нагрузки. И мне даже страшно представить, насколько это большое пространство. Физику тоже необходимо было переработать для возможности поддержки больше битов в памяти. Говоря о рефакторинге не обязательно должен быть переработан весь движок. В движке был материал, который уже был 64-битным. Что нам действительно было нужно, так это изменить физику и позиционирование.”

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

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

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

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

Вы когда-нибудь задумывались насколько велик мир РПГ игры, в которую играете? К примеру, карта всем известного World of Warcraft составляет 130 квадратных километров, а самый большой игровой мир у Elder Scrolls II: Daggerfall - 100 000 квадратных километров.

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

Единственным способом решить проблемы с объемами игрового мира было перевести движок на удвоенную точность. Сегодня в Star Citizen создается мир с картами диаметром в 10-15 миллиардов километров или 70-100 астрономических единиц каждая, а сам масштаб объектов и локаций составляет 1 к 6ти от реального. Чтобы было более понятно какие это масштабы, приведем в пример нашу Солнечную систему, которая может полностью поместиться на одной из карт Star Citizen, причем в реальном размере.

К сожалению CryEngine не мог справиться с этой задачей - его тулсет был предназначен для маленьких локаций. Максимальный размер карты в Cryengine 3 составлял 64 километра на 64 километра максимум. Но даже этот результат требовал сноровки и немалых усилий, ведь интерфейс редактора имел жесткие ограничения, например координатные поля X, Y, Z цельного блока не могли превышать даже 10-ти километров.

Едем дальше. В Cryengine 3, как и в любом движке с базовым тулсетом, небо это обычный скайбокс. То есть часть этого самого куба пространства с ребром в 10 километров, играющая роль горизонта, с натянутой на его внутренней стороне текстурой неба. Солнце, облака и атмосфера это банальныє спрайты, то есть небольшие картинки поверх статичного двухмерного фона. Наблюдение спрайта в трёхмерном пространстве под несоответствующими углами приводит к разрушению иллюзии. Напомним, что спрайт это ничто иное как двухмерная проекция трехмерного тела или эффекта, который с целью экономии ресурсов перевели из 3Д в 2Д так, чтобы разница была незаметна игроку. То же самое касается и таких эффектов как погода, смена дня-ночи и дождь. Всё, что мы видим в 99ти процентах игр - это банальный фейк. Солнце краснеет по скрипту, плоские спрайты-облака ползут по плоской текстуре-небу и окрашиваются тоже по скрипту в зависимости от позиции плоского спрайта-солнца, которое “ходит” по этому небу. Дождь, туман, ветер - все это заскриптованые спрайты со сменой цвета окраски неба и облаков.

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

А нужно создать не одну, а сотню вот таких же звездных систем?

Представили?

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

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

Какой был выход у CIG? Только один - создать все нужные инструменты под себя и по факту дописать еще 70% кода к существующему игровому ядру, а также создать необходимый набор инструментов процедурной генерации. Причем делать это пришлось с абсолютного нуля, ведь до CIG больше такого никто не делал - банально не было такой необходимости. Посудите сами, какому адекватному разработчику современного “Трипл А” ФПС движка придет в голову создать вот это:

Инструментарий позволил CIGам создавать карты, а именно планеты и спутники от 200 до 2000 км в диаметре, каждую можно обойти пешком, или же облететь и объехать на транспорте. На такой карте нет невидимых стен, недоступных точек или загрузочных экранов.

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

К любому светилу или объекту на небе можно на самом деле долететь и высадиться на нем в любой точке его поверхности - если только это не звезда. И это касается ЛЮБОГО ОБЪЕКТА, от газового гиганта, до малюсенького астероида, размеров которого едва хватит, чтобы поместить на нем ваш двор.

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

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

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

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

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

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