Всё что стоит знать об Object Container Streaming

Очень подробная и довольно интересная статья о сложностях разработки Star Citizen и Squadrone 42. После прочтения понимаешь с какими трудностями (не афишируемыми) сталкиваются разработчики и пути решения этих вопросов. Огромное спасибо за перевод парням из группы ВКонтакте посвящённой нашей любимой игре.

Статья подготовлена силами Кристофера Болта, Чэда Маккини и Клайва Джонсона. В ней описаны основные этапы и разработки стриминга контейнеров, его составные части и трудности, с которыми столкнулись разработчики.Что такое “Object Container Streaming (OCS)?”

Если коротко, стриминг (потоковая передача) Контейнеров — это общий термин, описывающий все технологии, в сумме позволяющие сделать огромный игровой мир бесшовным, то есть без использования загрузочных экранов.Технические лимиты, которые должен преодолеть OCS?

Чтобы передавать плавную картинку, игровое изображение на экране должно обновляться хотя бы 30 раз за секунду. Для достижения 30 кадров в секунду (FPS), игра должна обрабатывать все вычисления в кадре за 0.033 секунды (33 миллисекунды). Задержки в рамках этого временного отрезка приводят к разрывам и мозг игрока начинает явно различать отдельные изображения.

Ограниченный RAM и скорость передачи файлов

Более того, PC имеет ограниченное количество оперативной памяти (RAM). RAM — очень быстрая память, скорость передачи которой достигает более 20000 Мб/с. Для получения плавных ощущений важно, чтобы вся поступающая информация хранилась в RAM и не обращалась к более медленному жесткому диску. Поскольку RAM ограничена, и ее объемы меньше, чем все те данные, которыми оперирует игра, разработчикам приходится загружать информацию с жесткого диска и замещать ей другие, уже отработанные данные. Это занимает время. Передача всего 10 Мб жестким диском со скоростью 500Мб/с требует 0.2 секунды для загрузки, что равнозначно ~6 кадрам в 30-ти FPS, и приводит к заметным разрывам кадров.

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

Многопоточная обработка

Многопоточность обеспечивает необходимую обработку. За последние 10 лет у каждого CPU появилось несколько ядер. Каждое ядро может выполнять задачи программы независимо от других. Эта (и другие техники, которые опускаются для упрощения понимания) позволяют компьютерам делать сразу несколько вещей одновременно. С точки зрения Object Container Streaming, разработчики могут загружать ресурсы параллельно игровой логике, не оказывая влияния на фреймрейт.

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

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

Поэтому, для корректной программной обработки, необходимо выделять только один путь доступа к менеджеру за раз, следовательно, должны применяться взаимоисключения; если игровая симуляция обращается к менеджеру, то ресурсы не должны подгружаться и наоборот. Ожидание требует времени, из-за чего не получается укладываться в те самые 0.033 секунды, и разработчикам приходится задействовать весь комплекс возможностей многопоточного программирования: находить методы минимального необходимого коммуницирования, при продолжающемся корректном исключении. Если не делать этого, игровая симуляция может ожидать полного трансфера данных, что приводит к тормозам или периодическим вылетам. Более того, вся технологическая цепочка должна разрабатываться вокруг единовременной подгрузки, инициализации и выгрузки данных при минимальном их взаимодействии, влияющем на симуляцию.Разработка OCS до состояния рабочего механизма

Object Container Streaming находился в разработке несколько лет. Некоторые шаги в этом направлении, вроде подключения Network Bind Culling (Сетевой отвязки) были заметны для игроков, другие же, такие как удаление родного для CryEngine скриптового языка LUA и переработка устаревшего кода оказались вне поля зрения пользователей.

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

Основы концепции Object Container Streaming

Некоторые пройденные ранее шаги можно, в целом, отнести к разработке OCS. Примерно 5 лет назад, CIG представили концепт стриминга Контейнеров. Ранее движок поддерживал лишь традиционные “уровни”. Уровнем считается список игровых объектов. Сам по себе игровой объект — это набор ресурсов, обычно именуемый “entity” (сущность). Прежде, чем уровень будет запущен, все сущности должны быть подгружены и инициализированы в оперативной памяти с жесткого диска, что происходит во время загрузочного экрана.

Контейнеры объектов — это строительные блоки из которых проектируется уровень. Их концепция в том, что вместо разработки одного большого уровня, разработчики создают небольшие секции. Финальный уровень (или Вселенная в нашем случае) состоит из множества различных Контейнеров. Подобный подход позволяет во время разработки разбивать мир на множество строительных блоков. А стриминг во главе позволяет на ходу загружать и выгружать блоки, пресекая превышения бюджета оперативной памяти, что гарантирует бесшовность Вселенной. Пока Контейнеры объектов не оказывали заметного влияния на игроков (с давних пор, CIG просто подгружали все Контейнеры во время запуска уровня), но они все же стали важной вехой.

LUA и компоненты

С двумя другими необходимостями CIG столкнулись ~2,5 года назад. Первое — они начали удалять скрипты на основе LUA из игрового кода.

LUA — скриптовый язык, который использовался для всех видов логики entity/сущностей внутри движка. Проблема LUA в том, что с ним невозможно обеспечить безопасность мультипотока. Другими словами, пока использовался LUA, CIG не могли исключать загрузку ресурсов параллельно игровой симуляции без сопровождающихся при этом долгих задержек. Такое ожидание требовалось для взаимных исключений, о которых говорилось ранее.

В связи с этим, весь код LUA был заменен на C++, который дает степень контроля, необходимую для предотвращения таких задержек. В то же время, разработчики начали разбивать крупные “монолитные” entity/сущности на компоненты. Компоненты представляют из себя часть определенного игрового поведения. С ними сущность определяется типом компонента, к которому она относится. Без компонентов, все виды различной логики имеют тенденцию чередоваться в очень сложном центральном логическом блоке. Использование компонентов упрощает разработчикам жизнь в области нововведений. Поскольку они разделены на более мелкие части, намного проще заставить их эффективно коммуницировать с игровой симуляцией одновременно подгружая все новые ресурсы. Кроме того, разделение единой игровой логики на управляемые части, позволяет развертывать параллельную инициализацию сущностей.

Сериализированные переменные

Сущности внутри игровой симуляции имеют определенное состояние. В ситуациях вроде сетевого взаимодействия, необходимо сохранять состояние сущности в формате доступном для передачи и распаковки на другой машине. Другая ситуация — сохранение в Squadron 42. Оно требует нечто схожего, отличие лишь в том, что данные сохраняются на диске. В терминах программирования, процесс конвертации состояния, которое может быть архивировано на диске/в сети именуется “сериализацией”. Отсюда и название “Сериализированные переменные”. В этом смысле, разработчики могут брать части сущностей и упаковывать их в специальные объекты, хранящие состояние сущности. При помощи такого метода, разработчики могут унифицировать стиль игрового кода, независимо от того, как будут передаваться сериализированные данные в будущем (что также важно для серверного смешения).

Многопоточная загрузка ресурсов в движке

Помимо ресурсов, относящихся к игре (данные из которых выстраиваются компоненты), движок также поддерживает множество распределенных ресурсов, которые поделены между различными компонентами или даже различными Контейнерами объектов. Эти ресурсы включают в себя объекты вроде текстур и сеток моделей. Движок уже поддерживает потоковую передачу моделей и текстур, что позволяет загружать и выгружать данные GPU для рендеринга в игре. Но для решения задач стриминга Контейнеров объектов, CIG необходимо перейти на более высокий уровень. В контексте OCS, им необходимо загружать объекты в GPU организованным и параллельным методом, так, чтобы все единовременные загрузки Контейнеров могли делиться едиными ресурсами на движке. Работа над этим велась в фоновом режиме около 2-ух лет назад.

Объединение всех частей вместе

Основа потребовала серьезных усилий, и большая ее часть была незаметна игрокам с визуальной точки зрения, поскольку сами разработчики поставили перед собой такую цель (чтобы убедиться, что все изменения работают корректно). Но все это было действительно необходимой подготовительной работой, продвигая технологию вперед, первые заметные плоды были представлены в 3.3 с выходом Network Bind Culling (сетевого отсечения).

Компонент параллельной загрузки и инициализации

После всей проделанной работы над фундаментом разработчики получили:

  • Уровни разделенные на блоки (Контейнеры объектов)
  • Сущности (как основная часть Контейнеров объектов) работающие без LUA и как компоненты
  • Все состояния работы сущностей организуются при помощи Сериализированных переменных для упрощенной коммуникации по сети
  • Многопоточное создание ресурсов на стороне движка (текстуры, сетки, персонажи и т.д.)

Следующими шагами должно было стать строительство на этом фундаменте. Первой задачей стала загрузка сущностей параллельно игровой симуляции. Этот шаг не включал какую-либо высокоуровневую логику в области загрузки/выгрузки, поэтому представлял из себя весьма тупую стриминговую систему. Тем не менее, это уже уменьшило тормоза (к примеру спавн корабля в процессе игры, как часть симуляции, больше не требует инициализации кода корабельной сущности).
В то же время, CIG имеют примерно от 300 до 400 различных видов компонентов. Если они попытаются изначально исключать их параллельно, то потонут в багах. Поэтому была разработана система, позволяющая постепенно исключать все больше и больше видов компонентов параллельно симуляции. Чем больше типов компонентов CIG обезопасят (избавят от параллельной загрузки с симуляцией), тем меньше игровая симуляция будет тормозить.

Решением стало использование Fibers (волокон)Волокна — это состояние исключения, при котором можно контролировать когда и где может произведено исключение (параллельно загрузке или игровой симуляции).

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

Подготовка к сетевому отсечению (Network Bind Culling)

Network Bind Culling — это то, как CIG называют стриминг (загрузку/выгрузку) объектов на стороне клиента. Разработчики решили сосредоточиться сначала на клиентской части, чтобы улучшить ощущения игроков и продолжать разработку кусками. И чтобы исправить некоторые проблемы в будущем. Но даже фокусируясь на клиенте, они вели подготовительную работу.

Планировщик обновлений для компонента сущностей

CIG необходимо понимать, какие сущности стоит загружать/выгружать в клиенте, основываясь на их дистанции и видимости. К счастью, такая технология была разработана для 3.0. Планировщик обновлений — это система, разработанная для контроля обновлений компонента сущностей. Она основывается на территориальном расположении сущностей относительно игрока. То есть отсекает все те обновления, которые происходят с компонентом на большом удалении. Эту информацию он же передает для Network Bind Culling.

Иерархия принадлежности сущностей/Совокупности сущностей

Еще одной важной проблемой оказалось динамическое группирование сущностей. Контейнер объектов разделяет статичную геометрию уровней и объекты на строительные блоки во время проектирования уровня. Но SC также складывается из динамических сущностей, таких как игроки, корабли (которые выстраиваются из нескольких контейнеров объектов) или торговых автоматов — всего того, что может перемещаться по игровому миру. Кроме того, эти динамические сущности могут объединяться между собой в группы. К примеру, когда игрок подбирает объект, или судно паркуется в другом судне. Все это подразумевает стриминг. В случае с парковкой кораблей, CIG не хотят стримить дочерний корабль прежде, чем материнский, поскольку состояние внутреннего корабля зависит от состояния внешнего. В любом случае, отслеживать такие динамические группы необходимо, когда они формируются или наоборот разделяются. Этот метод называется Entity Ownership Hierarchy (Иерархией принадлежности сущностей). В этой иерархии, CIG продолжают отслеживать зависимости между сущностями. При необходимости, они объединяют их в группы, называемые Entity Aggregate (Совокупности сущностей). Итак, Network Bind Culling обрабатывает совокупности, используя информацию планировщика.

Спавн пакетов сущностей и срез сущностей

После корректного отслеживания совокупностей сущностей, CIG все еще нужно было разработать способ эффективного спавна большого количества совокупностей на клиенте. И также необходимо удостовериться, что сущности могут спавнить корректно на сервере. К примеру, что корабли спавнятся с присоединенным вооружением/двигателями вместо спавна по частям. Для достижения этого, разработчикам необходимо объединять сущности в пакеты. Для каждого спавна сущности на клиентской машине, сервер отсылает срез сущности, содержащий нынешнее ее состояние. Это упрощенный объем Сериализированных переменных, относящихся к сущности. Срезы также используются для сериализации постоянства или сохранений в Squadron 42. Поскольку спавн в клиенте происходит асинхронно и требует времени, CIG столкнулись с тем, что срез устаревает по отношению к серверу быстрее, чем клиент успевает заспавнить сущность. Для исправления этой ситуации, сервер отправляет вторую пачку срезов. Эти вторичные данные, помогают клиенту исправить расхождения, внося коррективы в симуляцию, завершая процесс сетевого спавна.

Отсечение сериализированных переменных

Завершая разработку 3.0, CIG прорабатывали различные необходимые части, но не все из них были завершены. Тогда же были представлены планеты и основные локации вроде Levski и GrimHex. В то же время они обновили отсечение для Планировщика компонента сущностей. Несмотря на то что система помогла с серверной производительностью, клиент все еще оставался необоснованно перегруженным, поскольку не было системы, определявшей какую именно информацию должен получать клиент. Кроме того, каждый компонент должен был запускать свое обновление при получении новой сетевой информации, что приводило к серьезным затратам производительности. К примеру, когда игрок «А» на Levski, а игрок «Б» на Olisar, игрок «Б» получал обновления всех NPC на Levski, если игрок «А» оказывался поблизости. В связи с этим было решено создать систему, которая бы фильтровала обновления в зависимости от близости сущностных совокупностей. Благодаря чему, игрок «Б» из предыдущего примера перестал бы получать обновления NPC на Levski до тех пор, пока не оказался поблизости к шахтерской станции. Разработка такой системы, которую назвали Отсечением сериализированных переменных, дала заметный прирост производительности на стороне клиента. Кроме того, это стало первым настоящим тестом запуска игровой симуляции лишь части Вселенной на стороне клиента. Изначально это должно было быть в 3.0, но появилось в 3.1.

Подключение Network Bind Culling

Через несколько лет, CIG смогли собрать результаты проделанной работы. За все это время было сделано:

  • Уровни разделенные на блоки (Контейнеры объектов)
  • Сущности (как основная часть Контейнеров объектов) работающие без LUA и как компоненты
  • Все состояния работы сущностей организуются при помощи Сериализированных переменных для упрощенной коммуникации по сети
  • Многопоточное создание ресурсов на стороне движка (текстуры, сетки, персонажи и т.д.)
  • Многопоточное создание большинства типов компонентов
  • Передача информации между игроками вблизи при помощи Планировщика обновлений
  • Возможность отслеживания динамических групп сущностей (Совокупностей сущностей)
  • Эффективные методы спавна Совокупностей на клиенте
  • Первое использование игровой симуляции на клиенте при помощи отсечения Серилизированных переменных

Используя все подготовительные этапы, представленные выше, CIG смогли разрабатывать Network Bind Culling (Сетевое отсечение). Подобно тому, как движок отсекает лишнее для клиентов при помощи сервера, также сущности будут загружаться/выгружаться на клиенте. Другими словами, Сетевое отсечение изменяет правила, так что каждый клиент имеет только представление о гораздо большем виртуальном игровом мире, в то время как с Отсечением сериализированных переменных каждый клиент имеет полное представление, но выполняет только частичные обновления своего локального виртуального мира. Это дает несколько преимуществ, наиболее заметное — производительность. Поскольку каждый клиент имеет гораздо меньший набор данных, каждая локальная операция, стоимость которой зависит от количества объектов, становится быстрее. Это также помогает с другими процессами, которые не могут быть отсечены средствами Serialized Variable Culling. Еще одна выгода в том, что клиент использует гораздо меньше памяти, поскольку должен сосредотачиваться лишь на оперативной памяти, а не на всей Вселенной. Для большинства клиентов это сильно повысило производительность с релизом 3.3.

Но система имела гораздо более важное преимущество: она отвязала клиент от контента Вселенной. Теперь он получает только небольшой набор сущностей, необходимых для ситуации. Клиент больше не зависит от количества сущностей, расположенных во Вселенной. Теперь он зависит только от локации и окружения (к примеру пустой космос и населенный город). Поэтому разработчики могут наполнять мир, не беспокоясь о клиентском состоянии. За исключением того, что сервер пока еще подгружает всё сразу и от этого страдает его работоспособность. И хотя плохая производительность сервера не влияет на FPS клиентов, она вызывает рывки при перемещении объектов (так как, вероятно, клиент и сервер не соглашаются с положением объектов). Это все еще является серьезной проблемой, но что должно быть излечено серверным стримингом контейнеров.

Разработка серверного стриминга контейнеров объектов

С введением Сетевого отсечения, фокус сместился на внедрение SOCS — Server Object Container Streaming (стриминга Контейнеров на стороне сервера). Базовая концепция в том, что при отсутствии персонажей вблизи объекта, CIG могут «заморозить» состояние объекта. И вместо того, чтобы хранить замороженную сущность в памяти (что требует ресурсов), разработчики могут сериализировать ее состояние и сохранять в таком виде в базе данных. Пока клиент передвигается по виртуальному миру, сервер обновляет свое видение базы данных, чтобы восстановить объекты, находящиеся в непосредственной близости, а также высвободить и сохранить ненужные сущности. Здесь SOCS и Network Bind Culling начинают работать рука об руку. База данных содержит всю Вселенную в замороженном состоянии. Сервер обладает лишь небольшим набором загруженной Вселенной; другими словами, всматривается в базу данных. У клиента также есть только подмножество всех загруженных сервером объектов, имеющих представление о виртуальном мире сервера. По этой модели, CIG могут оставлять все то, что находится вдали от игрока в замороженном состоянии, и такие сущности не будут влиять ни на производительность, ни на память. У этой модели есть некоторые исключения вроде симуляции Subsumption (отвечающей за искусственный интеллект), но эта тема вне данной статьи. Когда SOCS будет завершен, у разработчиков появится технологическое решение для масштабирования контента на сервере. Это значит, что они смогут наполнять мир намного более масштабно, в то время как серверная производительность будет зависеть только в местах с активными игроками (а эта область гораздо меньше, чем вся Вселенная). Однако, серверный стриминг приносит за собой дополнительные проблемы.

Определение состояния

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

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

Менеджер стриминга сущностей/StarHash/StarHash Radixtree

Другая проблема возникает, когда CIG выгружают все объекты и сохраняют их в базе данных. Необходим способ пространственного определения сущностей, близких к клиенту. Поэтому, важно разработать схему, которая позволит хранить огромное количество сущностей при достаточном количестве пространственной информации. Для этого был адаптирован алгоритм GeoHash (используется в картографических приложениях для поиска мест вокруг пользователей) который для нужд CIG был расширен в масштабах (нынешний виртуальный мир требует больше данных, чем реальная земля) и переведен в 3D пространство. Разработчики назвали его StarHash. StarHash дает эффективные инструменты для хранения сущностей, с точки зрения удобства поиска всех сущностей в заданной области пространства, для использования структур данных, называемых RadixTree. Менеджер стриминга сущностей — это управление логикой запросов StarHash-RadixTree для запуска загрузки и выгрузки объектов на сервере в зависимости от позиций всех подключенных клиентов.

Идентификатор локации

Последней важной проблемой стал спавн локаций. Для спавна игрока, игровой логике необходим SpawnPoint (точка спавна), которая тоже является сущностью. Но загружаются сущности только если игрок находится рядом, поэтому для спавна игрока нужно спавнить другого игрока, чтобы загрузить SpawnPoint. Поскольку точки спавна также нельзя исключить из стриминга (они являются частью более крупных конструкций вроде космических станций) было найдено иное решение. CIG предусмотрели двухфазный процесс спавна. Когда игрок подключается, система определяет индентификатор локации (Location ID). Локация является высокоуровневым представлением точки в космосе. Так что сначала подгружаются все сущности в этой точке, вместе с которыми появляется и требуемая SpawnPoint. После этого можно спокойно возрождать игрока на его точке. В заключение, логика стриминга переключится на игрока с идентификатором локации и базы данных будут перемещаться вместе с ним.

Продвижение в текущей работе

На момент написания статьи, завершена не вся работа по SOCS. Уже внедрен Менеджер стриминга сущностей и логика StarHash. Близится к завершению и скоро будет доделана работа связанная с ID локации. По этой причине, серверный стриминг уже может использоваться в определенных ситуациях. И это демонстрирует все проблемы с отсутствующим Определением состояния и всеми областями, которые CIG еще предстоит исправить. Уже известно большинство проблем, работа по исправлению продвигается активно.

Следующие шаги

При первом запуске SOCS работа не прекратится. Начальная итерация позволит разработчикам масштабировать контент на сервере, но все еще останутся моменты, требующие доработки.

Межсессионное постоянство

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

Серверное смешение

С серверным стримингом, одиночный сервер отвечает за управление базой, следящей за всеми клиентами. Несмотря на то, что SOCS должен улучшить производительность сервера (поскольку загружается меньше объектов), он в конечном итоге не решит проблему большего числа игроков на сервере. Вот тут-то и вступает в дело Server Meshing (серверное смешение). В этой концепции вместо того, чтобы один сервер управлял всеми событиями, CIG будут распределять отдельные события по нескольким серверам. Такой подход позволит уменьшить суммарную нагрузку на каждый используемый игрой сервер. После помещения этих серверов на различные машины, разработчики получат хороший способ увеличения лимита игроков. Для реализации серверного смешения, они будут опираться на то, что делают сейчас: сущности будут перемещаться между серверами, используя сериализированный код, зависящий от кода полученного от SOCS, и убеждаясь, что располагаемые сущности могут быть правильно сохранены на другом сервере.

Поддержка редактора

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

Поддержка Squadron 42

Наиболее простой дополнительной задачей в этом направлении станет Squadron 42. В одиночной кампании роль сервера исполняет сам клиент. Поэтому для него будет использоваться тот же код, что используется на серверах Star Citizen. По факту это уже сделано для внутренних нужд. Так как SC и Sq42 делят между собой схожую программную базу, исправления SOCS окажут влияние на оба продукта.Заключительные слова

Кристофер Болт (автор статьи) надеется, что это введение в курс дела дало полезное объяснение многолетнего путешествия под названием «Object-Container-Streaming» и понятное объяснение всех технических проблем, с которыми CIG пришлось столкнуться и преодолеть в этом путешествии. Он также просит простить его за пропуск большинства технических деталей, поскольку изложение всего этого превратит эту статью в целую книгу. И он думает, что лучше написать технологию, чем написать книгу о технологии, которую CIG хотят создать. Спасибо, что нашли время, чтобы прочитать это.

Кристофер Болт

Источник: https://vk.com/@starcitizen

logo

ПОХОЖИЕ СТАТЬИ

Расписание на неделю

Расписание на неделю

Привет всем. На этой неделе команда сообщества находится на Gamescom  в Кёльне, где представляет Star Citizen. В этот раз у нас нет выставочной площадки, но если кто-то из вас собирается в Кёльн, можете присоединиться к нам на одном из четырех Bar Citizen, которые будут проходить по вечерам...

Творчество пользователей Star Citizen

Творчество пользователей Star Citizen

Сегодня утром на Reddit наткнулся на очень качественно сделанный видео ролик от пилотов Star Citizen. Некоторые пользователи шутят, что "Quantum Dream" (название видео), теперь стоит ждать на Netflix. https://youtu.be/BmRTgOMBFXY

Концепт Vulture

Концепт Vulture

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