Автор: Джефф Эндрюс (Jeff Andrews)

Опубликовано: 18.01.2013

Изменено: 18.01.2013

Постоянная ссылка

Комментарии [0]

Проектирование архитектуры параллельного игрового движка





Страницы: 1 2 3 4

3.2. Менеджеры


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

3.2.1. Менеджер задач


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

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

На приведенной ниже схеме приводится пример того, как задачи могут быть распределены менеджером задач между потоками для выполнения на 4х-ядерной системе:

Пример пула потоков в менеджере задач
Рисунок 6. Пример пула потоков в менеджере задач


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

Короткое введение в реализацию Менеджера задач можно найти в Приложении Г "Советы по реализации задач".

3.2.2. Менеджер состояний


Управление состояниями – это часть механизма обмена сообщениями, которые позволяет отслеживать внесенные системами изменения и распространять уведомления о них среди других задействованных систем. В целях сокращения числа уведомлений, системы должны быть зарегистрированы в Менеджере состояний для отслеживания нужных им изменений. Данный механизм основывается на так называемой «модели наблюдателя» (observer design pattern), которая более детально рассматривается в Приложении В "Модель наблюдателя". В общих чертах, модель наблюдателя предполагает использование объекта-наблюдателя, который следит за любыми изменениями в субъекте, при этом роль посредника между ними выполняет контроллер изменений.

Данный механизм работает следующим образом:
1) Наблюдатель регистрируется в субъекте, за изменениями которого он планирует вести наблюдение при помощи контроллера изменений (или менеджера состояний);
2) Когда субъект изменяет какое-либо из своих свойств, он направляет уведомление об изменении в контроллер изменений;
3) Контроллер изменений (по сигналу фреймворка) выдаёт уведомление об изменении в субъекте наблюдателю;
4) Наблюдатель запрашивает у субъекта фактически измененные данные.

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

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

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

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

Уведомление о внутренних изменениях UObject
Рисунок 7. Уведомление о внутренних изменениях UObject


3.2.3. Менеджер служб


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

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

Пример работы менеджера службы
Рисунок 8. Пример работы менеджера службы


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

3.2.4. Менеджер среды


Менеджер среды (окружения) обеспечивает функциональность для среды выполнения движка. К числу предоставляемых Менеджером среды функциональных групп относятся:

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

3.2.5. Менеджер платформы


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

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

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

4. Интерфейсы



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

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

4.1. Интерфейсы субъекта и наблюдателя


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

4.2. Интерфейсы менеджеров


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

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

4.3. Системные интерфейсы


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

В системе существует 4 компонента, поэтому системе необходимо реализовать 4 интерфейса - это система, сцена, объект и задача. Эти различные компоненты рассматриваются в разделе 5 "Системы". Системные интерфейсы – это средства доступа к таким компонентам.

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

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

4.4. Интерфейсы изменений


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


5. Системы



Системы – это то, что обеспечивает игровую функциональность движка. Без них движок был бы просто бесконечно зациклен без выполнения конкретных задач. Чтобы избавить движок от необходимости знать обо всех различных типах систем, системы должны реализовать интерфейсы описанные в пункте 4.3 «Системные интерфейсы». Это существенно облегчает процесс добавления новой системы в движок - поскольку движку нет причины знать обо всех подробностях.

5.1. Типы


Движок должен иметь несколько предварительно заданных системных типов, которые подходят для стандартных компонентов игры. Например следующие - геометрия, графика, физика (столкновение твердых тел), аудио, ввод, ИИ и анимация.

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

5.2. Системные компоненты


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

На следующей схеме показана связь между компонентами:

Системные компоненты
Рисунок 9. Системные компоненты


Более подробная схема связи систем с движком содержится в Приложении Б "Схема связи движка и систем".

5.2.1. Система


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

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

5.2.2. Сцена


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

Сцена также предоставляет методы создания и удаления объектов. Ей также принадлежит компонент «задача», который используется для работы на сцене, и предлагает метод его получения.

5.2.3. Объект


Компонент «объект», также называемый «системным объектом», представляет собой объект в сцене и обычно связан с тем, что пользователь видит на экране. Универсальный объект использует системные объекты как расширение своей функциональности, чтобы свойства объектов системы были доступны через универсальный объект.

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

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

5.2.4. Задача


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

Задача также может решить раздробить своё исполнение на подзадачи и спланировать подзадачи в менеджере задач для дальнейшего распараллеливания. Это позволяет движку легче масштабироваться под конфигурацию с несколькими процессорами. Данная техника известна как «декомпозиция данных».

Если сделаны какие-либо модификации над объектами в период обновления задач сцены, то эта информация передаётся менеджеру состояний.


Страницы: 1 2 3 4