Почему Star Citizen Ещё Не Вышел? | Выбор Движка и Путь к Star Engine. Часть 1 Кратко:
Миф Первый: Есть лучше и проще движки, и не нужно было бы так долго переписывать CryEngine 3.
На самом деле не было таких движков, нет до сих пор, и вряд ли скоро появятся. Так в 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.
Миф Третий. CIGи все равно просчитались с CryEngine, ведь его пришлось сменить на Lumberyard.
Lumberyard, унаследовав ядро CryEngine, после приобретения был примерно наполовину собран заново программистами Амазона. Переход на Lumberyard с CryEngine был абсолютно логичен. Зачем платить за то, что идет бесплатно от Амазона, да еще с использованием их сервисов и ресурсов по выгодной цене? Даже если писать игру на другом движке, то все равно придется арендовать сервера у кого-то. И, скорее всего, это будет тот же Амазон из-за приемлемой цены и почти неограниченных возможностей масштабирования объемов и мощностей, а также огромным опытом сотрудничества с игровыми разработчиками и издателями, который трудно переоценить.
Все мы помним, что Амазон - гигант с капитализацией свыше 700 миллиардов долларов США, получающий сверхприбыли во многих отраслях. Теперь пробующий себя и в игровой - выкупив у Crytek движок за $50млн, что не дало последнему окончательно уйти в небытие, и существенно доработав его, превратив в еще один источник дохода.
В то же время Crytek это компания на пороге банкротства, которая еле сводит концы с концами и задерживает выплату зарплаты сотрудникам. За последние 6 лет Crytek закрыли большинство своих офисов, чтобы оптимизировать расходы. А теперь представьте на секунду, что ваш многомиллионный проект, спонсированный комьюнити, зависит от сложного, дорогостоящего и ресурсоемкого решения, поддержка и развитие которого выглядит несколько туманно по причине серьезных финансовых трудностей у провайдера этого самого решения.
Представили? Вот вам еще одна причина перевода ядра Star Citizen на Lumberyard, а также переманивания ключевых сотрудников Crytek для последующей работы над движком. Выводы - выбор движка CIGами был верным, а переход на Lumberyard в конечном счете тоже оказался верным решением.
С другой стороны, это ни в коем случае не значит, что разработчики не столкнулись с проблемами или все сделали безошибочно, совсем нет. Но обо всем по порядку - сперва закончим с мифами.
Миф Четвертый. Star Citizen не нуждался в полном переходе на 64бита и это было необдуманное решение, повлекшее ненужные расходы, усилия и время.
Одним из больших фундаментальных изменений Стар Энжин стала поддержка 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 бита позволил не только эффективно использовать ресурсы аппаратной части, но еще и увеличил размеры одной карты до невероятных размеров.
Полный текст часть 1 по ссылке:
https://dtf.ru/games/27955-pochemu-star-citizen-eshche-ne-vy...
Star Citizen: Почему Star Citizen Ещё Не Вышел? - Часть 2 | Технические и Менеджерские Грабли Кратко:
Сегодня мы расскажем вам о проблемах имплементации и рефакторинга игрового ядра и то как технические проблемы повлияли на затягивание разработки игры.
Миф первый - За такие бабки можно было нанять +100500 разработчиков и давно все сделать.
Многие критики, почему-то считают разработчиков программного обеспечения чем-то вроде ресурса, или стройматериала будь-то кирпич, швеллер или газоблок. И если купив достаточное количество кирпичей, можно построить особняк любой планировки, значит и с проектом точно так же - просто поедь в какой-нибудь софт-магазин, где продают готовых к использованию разработчиков, купи тысячу другую нужных тебе, закинь в проект, чтобы работали с утра до ночи, и рецепт успеха готов.
Эхх, если бы в реальности все работало именно так… Но нет.
Первая проблема - поиск и наличие кандидатов на рынке труда. Отсутствие профильных специалистов на первых этапах фактически связало команду проекта по рукам и ногам. Те восемь человек, которые начинали в 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.
Вспоминая начало 2015 года, когда я присоединился к команде, мы все очень боялись потерять даже одного человека. Уход одного-единственного дизайнера, захотевшего рисовать очередной костюм Железного Человека сопровождался задержкой. Что уж говорить о потере инженера, на котором держались наши основные техпроцессы - это было настоящим ударом и часто влекло серьезные простои работы всей остальной команды.
Тогда мы были очень сфокусированы каждый на своей части работы. Причем многие отвечали сразу за несколько направлений одновременно. Уже позже, когда мы выросли и расширились, то смогли правильно и равномерно распределять задачи и нагрузку. Перестали зависеть от того, кто из сотрудников уволится, заболеет, или его, вдруг, собьет автобус.
Для сравнения, если вы придете на работу в Activision, то там вам дадут все что нужно для создания игр. Когда мы начинали, то в основном искали людей и брались за все задачи подряд. То есть, мы не игру делали, мы строили компанию, разрабатывали процессы и создавали инструменты, чтобы потом начать создавать эту самую игру.
Миф Второй - сотрудничество со сторонними командами было большой ошибкой 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тью миллионами долларов США:
Прекратить сбор средств, выпустить обещанную часть контента и потом возобновить сбор
Прекратить сбор после 20ти миллионов, начать разработку обещанного сингла, но продолжить сбор средств для следующей перспективной цели из списка
Не прекращать сбора средств вовсе. Начать разработку, но при этом добавлять новые цели и фичи с постепенным наполнением бюджета.
88% опрошенных, а это было не много, не мало, почти двадцать одна тысяча бекеров проекта, проголосовали за третий вариант. Именно поэтому Крис и не останавливал сбор средств, после получения заветных двадцати миллионов. Именно поэтому новые фичи добавлялись в лог проекта на протяжении нескольких лет. Но главное то, что именно после этого голосования CIG отказались делать сингл с мультиплеером и решили создавать целую вселенную и воплотить мечту Криса в реальность. А значит Star Citizen - ни как сингл, ни тем более как ММО не могли появиться ни в 2014м, ни в в 2015м, как утверждал и планировал Крис до проведения этого самого опроса.
Миф Четвертый - CIG все делают неверно. Сперва надо было выпустить небольшую часть контента, а потом добавлять новый контент адд-онами.
Фактически это продолжение истории предыдущего мифа, но критики так часто его вспоминают, что мы решили их разделить.
Итак, многие знатоки и гуру разработки современных игр утверждают, что CIGам стоило сперва сделать и выпустить небольшую четко ограниченную версию продукта, который бы обеспечил игроков достаточным перечнем основного геймплея, а потом добавлять новые модули и расширять этот контент последующими патчами. В качестве примера приводится такой проект как Элит Денжерос. Дескать, вон Фронтиры быстренько организовали все те же 20-30 миллионов и уже через четыре года после анонса, релизнули готовый продукт на рынок, который заработал им по самым скромным меркам от 120ти до 150ти миллионов долларов США за более чем 3 миллиона проданных копий игры.
Соответственно, CIGам стоило делать то же самое и идти тем же путем - у фанов была бы игра, у разработчиков честно заработанные, а не выпрошенные у бекеров деньги за корабли, и проект ждало бы светлое будущее.
Чудесно, правда? А вот и нет.
Давайте вспомним, когда вышло последнее глобальное обновление данной игры? Конец 2015 года, то есть через год после релиза. Иными словами, за три года в Элите не появилось ни одного существенного патча - кораблики, новые возможности гринда и прочие финтифлюшки мы в расчет не берем. Напомним еще и обещания Фронтиров, которые рисовали фанам красочные полеты в атмосферах газовых гигантов к 2017му году, посадки на планеты земного типа, годом позже, и наконец возможность передвигаться в мире в качестве аватара человека, а не космического корабля. Исходя из дорожной карты игры эти нововведения появятся еще нескоро. Но почему так произошло? Все же очень красочно начиналось, именно так как хотело комьюнити - сперва играбельный геймплей, а потом адд-оны расширяющие его. Что пошло не так?
Ответ прост - архитектура движка Кобра попросту не позволила масштабировать и расширять функционал проекта дальше, а разработчики, упершись в технологический потолок этой самой архитектуры, не смогли использовать ограниченные ресурсы для создания обещанных фич.
Постараемся объяснить это на более простом примере. Архитектуру программного решения можно отдаленно сравнить с архитектурным планом здания. Если вы заложили в план проекта возвести особняк, то построив его, ваш проект будет наилучшим образом выполнять функции особняка для вашей семьи. Но что если ваши потребности вырастут? Хорошо, вы внесете изменения в план, проведете перерасчет конструкции и добавите пристройку или же еще один этаж, или увеличите чердак.
Но что делать, если ваша семья на протяжении поколений разрослась до нескольких десятков или сотен человек? Добавлять пристройки, этажи и чердаки раз за разом не получится - не выдержит фундамент, или стены, или почва, к тому же надежность конструкции будет под большим вопросом. У вас просто не будет иного выхода, как создавать новый архитектурный проект с нуля и строить для всех просторный многоквартирный комплекс или небольшой поселок.
Архитектура программных решений в чем-то схожа с нашим примером. Без внесения в архитектуру заблаговременных возможностей масштабирования и предусмотрения игровых фич наперед, рано или поздно вы упретесь в такие ограничения, которые нельзя будет исправить обычной пристройкой.
Фронтиры встали на известные грабли быстрого вывода продукта на рынок. Они адаптировали движок для базового геймплея в рамках симуляторного управления кораблем, а также, на первый взгляд, широкого спектра игровых фич. Хотя на самом деле при близком рассмотрении, эти фичи являются довольно поверхностными и не обеспечивают глубины погружения ни в одну из основных игровых механик. В конечном счете, за что бы не брался игрок в Элите, дабы провести время с удовольствием, это довольно быстро надоедает.
Напомним, что CIG адаптировала свой FPS модуль на протяжении полутора лет, чтобы имплементировать его во все аспекты движка. Это же касается и прочих его составляющих, о которых мы уже упоминали в предыдущем видео. Вся эта работа была проделана для того, чтобы заложить как можно более основательную базу для такой амбициозной игры и создать максимальный запас масштабируемости и гибкости. Иными словами, после результатов упомянутого нами голосования и непрекращающегося финансирования, CIG поняли, что им придется строить не особняк и даже не многоквартирный комплекс, а самый высокий в мире трехкилометровый небоскреб, который остальные компании не только не взялись бы строить, но даже проектировать. Естественно, что Крис и его команда основательно принялись за фундамент и подготовку к строительству. А это, как вы понимаете заняло намного больше времени, чем если бы они строили по принципу Фронтиров. Бекеры же теперь могут быть уверены, что неудачи постигшие разработчиков Элиты будут минимизированы.
