Перейти к публикации

Акция на Годовщину Star Citizen

Читать...

Распродажа Crusader Mercury Star Runner

Читать...

Заработал обмен вещей из VD на UEC

Читать...

Руководство для писателей и Лорострой

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

DRAKE KRAKEN - мобильная станция

Drake Kraken - это капитальный корабль, на котором есть место для парковки и хранения нескольких средних кораблей (вплоть до размера Фрилансера) и транспортировки их по Вселенной.
Читать...

Star Citizen: Почему Star Citizen Ещё Не Вышел? - Часть 2.02

Star Citizen: Почему Star Citizen Ещё Не Вышел? - Часть 2.01

 

 

Миф Пятый - За столько денег игру давно можно было бы завершить и выпустить

В первом мифе мы уже рассказали вам о сложностях расширения и масштабирования команды разработки и о том, что никакие деньги не позволят создать экспертизу из ничего, а продуктивную и прибыльную компанию за несколько месяцев. Тут же мы остановимся именно на финансовой составляющей 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, которая принесла издателю на порядок меньше  прибыли, чем ожидалось ранее.


 

Миф Шестой - CIG на самом деле ничего нового в техническом плане не придумали. Все это есть и в других играх

Мы намеренно упустим все сказанное в первой части нашего видео и остановимся на самых интересных моментах борьбы разработчиков с 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 построена следующим образом:

  • Stackless Python использовался для создания логики и клиента и сервера.
  • SQL Server
  • Blade сервера с SSD для высокого отклика
  • Кластеры прокси серверов - Публичный сегмент серверов EVE - которые отвечают за обеспечение соединения по сети напрямую с игроками и обеспечивают связь игрока с другими серверами.
  • Кластеры системных серверов - это рабочие лошадки  Tranquility. Разделенные на 90-100 групп каждая из которых обслуживает две ноды. Нода это серверный процесс сильно нагружающий процессор и исполняется на одном физическом ядре. Есть некоторые системные сервера, что обслуживают лишь одну очень посещаемую систему, например  Jita, Motsu и Saila.
  • Сервера баз данных - этот слой обеспечивает постоянство вселенной EVE Online. Работающие сервера активно взаимодействуют с базой данных, и почти все что можно сделать в игре сохраняется здесь. Благодаря SSD дискам, это позволяет выдерживать огромный поток данных генерируемых Tranquility.

 

По факту 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.

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

 

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




Отзывы пользователей


Хорошая компиляция, жаль этот труд оценят лишь те кто знаком с проектом 

Поделиться комментарием


Ссылка на комментарий
Поделиться на других сайтах


Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас

×