Привет, Хаброжители! Книга Джейсона Грегори не случайно является бестселлером.Двадцать лет работы автора над первоклассными играми в Midway, Electronic Arts и Naughty Dog позволяют поделиться знаниями о теории и практике разработки ПО для игрового движка.

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

Автономное управление ресурсами и цепочка инструментов

Контроль версий для активов

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

Некоторые команды разработчиков игр используют систему контроля версий исходного кода для управления своими ресурсами. Графические исходные файлы (сцены Maya, файлы Photoshop PSD, файлы Illustrator и т. д.) записываются художниками в Perforce или аналогичном пакете. Такой подход работает довольно хорошо, хотя некоторые команды разработчиков создают собственные инструменты управления активами, чтобы облегчить обучение своих художников работе с ними. Такие инструменты могут быть простыми обертками вокруг коммерческой системы контроля версий или же быть полностью индивидуальными.

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

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

В Naughty Dog мы задействуем запатентованный инструмент, который использует символические ссылки UNIX, чтобы практически исключить копирование данных, в то же время предоставляя каждому пользователю возможность полностью просматривать хранилища активов. Пока файл не извлечен для редактирования, это просто символическая ссылка на главный файл на общем сетевом диске. Такая ссылка занимает очень мало места на локальном диске, потому что это не более чем запись каталога. Когда пользователь извлекает файл для редактирования, символическая ссылка удаляется и ее заменяет локальная копия файла. Когда пользователь завершает редактирование и регистрирует файл, локальная копия становится новой главной копией, ее история изменений обновляется в основной базе данных, а локальный файл снова превращается в символическую ссылку. Такая система работает очень хорошо, но для этого требуется, чтобы команда создала собственную систему контроля версий с нуля. Я не знаю ни об одном коммерческом инструменте, который работает таким образом. Кроме того, символические ссылки являются функцией UNIX — такой инструмент, вероятно, может быть создан с помощью соединений Windows (эквивалент символической ссылки для Windows), но я пока не видел, чтобы кто-нибудь пробовал это сделать.

База данных ресурсов

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

Для управления всеми этими метаданными нужна какая-то база данных. Если мы делаем очень маленькую игру, эту базу данных разработчики могут просто держать в уме. Я как будто слышу: «Помните, для анимации игрока должен быть установлен флаг flip X, но у других персонажей его не должно быть… или… черт… там все наоборот?»

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

База данных ресурсов выглядит по-разному в разных игровых движках. В одном движке метаданные, описывающие, как должен создаваться ресурс, могут быть встроены в сами исходные активы (например, они могут храниться как так называемые скрытые данные в файле Maya). В другом движке каждый файл исходного ресурса может сопровождаться небольшим текстовым файлом, который описывает, как он должен обрабатываться. В то же время часть движков кодируют свои метаданные создания ресурсов в виде набора файлов XML, возможно обернутых в какой-то пользовательский графический интерфейс. Некоторые движки используют настоящую реляционную базу данных, такую как Microsoft Access, MySQL или, возможно, даже такую тяжеловесную, как Oracle.

Независимо от формы, база данных ресурсов должна обеспечивать следующие основные функции:

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

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

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

Успешные проекты базы данных ресурсов

Любая команда разработчиков будет предъявлять разные требования и принимать разные решения в ходе создания базы данных ресурсов. Тем не менее вот несколько проектов, которые хорошо зарекомендовали себя.

Unreal Engine 4. Базой данных ресурсов Unreal управляет их универсальный инструмент UnrealEd. Он отвечает буквально за все: от управления метаданными ресурса до создания актива, макета уровня и многого другого. У UnrealEd есть определенные недостатки, но самое большое его преимущество в том, что он является частью игрового движка. Это позволяет создавать активы, а затем сразу же просматривать их во всей красе — именно так, как они будут отображаться в игре. Игру можно даже запустить в UnrealEd, чтобы визуализировать активы в их естественном окружении и посмотреть, как они работают в игре (и работают ли вообще).

Еще одно большое преимущество UnrealEd — то, что я называю универсальным магазином. Универсальный браузер UnrealEd (рис. 7.1) позволяет разработчику получить доступ буквально ко всем ресурсам, которые использует движок. Наличие единого, унифицированного и логично построенного интерфейса для создания всех типов ресурсов и управления ими — большое достижение. Это особенно верно, если учесть, что данные о ресурсах в большинстве других игровых движков разбросаны по бесчисленным несовместимым и часто непонятным инструментам. Возможность легко найти любой ресурс в UnrealEd — уже большой плюс.


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

Конечно, у подхода Unreal есть и серьезные недостатки. Например, все данные ресурсов хранятся в нескольких больших файлах пакета. Эти файлы — бинарные, поэтому их нелегко объединить с помощью пакета контроля версий, такого как CVS, Subversion или Perforce. Это создает серьезные проблемы в том случае, когда более одного пользователя хотят изменить ресурсы, которые находятся в одном пакете. Даже если пользователи пытаются изменить различные ресурсы, одновременно только один пользователь может сохранить изменения в пакете, поэтому другому приходится ждать. Такую проблему можно смягчить, разделив ресурсы на относительно небольшие детализованные пакеты, но полностью устранить ее нельзя.

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

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

Движок Naughty Dog. Naughty Dog хранит свои метаданные ресурсов для игры Uncharted: Drake’s Fortune в базе данных MySQL. Для управления содержимым базы данных был написан пользовательский графический интерфейс. Он позволил художникам, дизайнерам игр и программистам создавать новые ресурсы, удалять существующие, а также проверять и изменять их. Этот графический интерфейс был важнейшим компонентом системы, поскольку освободил пользователей от необходимости изучать тонкости взаимодействия с реляционной базой данных с помощью SQL.

Исходная база данных MySQL, используемая в Uncharted, не умела давать полезную историю изменений базы данных, и у нее не было хорошего способа откатить «плохие» изменения. Также она не поддерживала редактирование одного и того же ресурса несколькими пользователями, и ее было сложно администрировать. С тех пор Naughty Dog отказалась от MySQL в пользу базы данных активов на основе XML, управляемой в Perforce.

Builder — графический интерфейс базы данных ресурсов Naughty Dog — изображен на рис. 7.2. Окно разбито на два основных раздела: слева — древовидное представление данных, показывающее все ресурсы в игре, справа — окно свойств, позволяющее просматривать и редактировать ресурсы, выбранные в дереве. Дерево ресурсов содержит папки для организационных целей, так что художники и дизайнеры игр могут организовать свои ресурсы так, как считают нужным. В любой папке можно создавать различные типы ресурсов (включая акторы и уровни), а также подресурсы, из которых они состоят (в основном меши, скелеты и анимации), и управлять ими. Анимации также могут быть сгруппированы в псевдопапки, известные как пакеты. Это дает возможность создавать большие группы анимаций, а затем управлять ими как отдельной единицей, что позволяет не тратить время на перемещение отдельных анимаций в дереве.


Конвейер подготовки активов, используемый в сериях Uncharted и The Last of Us, состоит из набора конвертеров ресурсов, компиляторов и компоновщиков, запускаемых из командной строки. Движок способен работать с самыми разными типами объектов данных, но они упакованы в один из двух видов файлов ресурсов: акторы и уровни. Актор может содержать скелеты, меши, материалы, текстуры и/или анимацию. Уровень содержит статические фоновые меши, материалы и текстуры, а также информацию о макете уровня. Чтобы создать актор, нужно просто ввести ba название_актора в командной строке, чтобы создать уровень — ввести bl название_уровня. Эти инструменты командной строки запрашивают базу данных, чтобы точно определить, как построить рассматриваемый актор или уровень. Сюда включается информация о том, как экспортировать активы из инструментов DCC, таких как Maya и Photoshop, как обрабатывать данные и упаковывать их в двоичные .pak-файлы, которые могут быть загружены игровым движком. Это намного проще, чем во многих других движках, где художники должны экспортировать ресурсы вручную — это трудоемкая, утомительная и чреватая ошибками задача.

Преимущества дизайна конвейера ресурсов, используемого Naughty Dog.

• Детализованные ресурсы. Ресурсами можно манипулировать с точки зрения логических объектов в игре — сеток, материалов, скелетов и анимации. Эти типы ресурсов довольно хорошо детализованы, поэтому у разработчиков почти никогда не бывает ситуаций, когда два пользователя пытаются редактировать один и тот же ресурс одновременно.
• Необходимые функции (и не более того). Инструмент Builder предоставляет богатый набор функций, которые удовлетворяют потребности команды, но Naughty Dog не тратили впустую ресурсы, создавая функции, которые им не нужны.
• Очевидное соответствие исходным файлам. Пользователь может очень быстро определить, какие исходные активы (собственные файлы DCC, такие как файлы Maya .ma или файлы Photoshop .psd) составляют определенный ресурс.
• Легко изменяемый способ экспорта и обработки данных DCC. Просто выберите необходимый ресурс и измените настройки его обработки в графическом интерфейсе базы данных ресурсов.
• Легко создаваемые активы. Просто введите ba или bl, а затем имя ресурса в командной строке. Система зависимостей позаботится обо всем остальном.
• Конечно, цепочка инструментов Naughty Dog имеет и некоторые недостатки.
• Отсутствие инструментов визуализации. Единственный способ предварительно просмотреть актив — загрузить его в игру или средство просмотра моделей/анимации (что на самом деле является просто специальным режимом самой игры).
• Инструменты не полностью интегрированы. Naughty Dog использует один инструмент для разметки уровней, другой — для управления большинством ресурсов в базе данных и третий — для настройки материалов и шейдеров (это не является частью интерфейса базы данных ресурсов). Сборка активов производится в командной строке. Было бы немного удобнее, если бы все эти функции были объединены в одном инструменте. Тем не менее Naughty Dog не планирует ничего делать, потому что выгода, вероятно, не оправдает связанные с этим расходы.

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

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

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

Microsoft XNA. XNA — это набор инструментов для разработки игр от Microsoft, предназначенный для ПК и платформ Xbox 360. Несмотря на то что Microsoft прекратила поддержку проекта в 2014 году, он все еще является хорошим ресурсом для изучения игровых движков. Система управления ресурсами XNA уникальна тем, что использует системы управления и создания проектов среды IDE Visual Studio для управления и создания активов в игре. Инструмент для разработки игр XNA, Game Studio Express, — это просто плагин для Visual Studio Express.

Конвейер подготовки активов

В разделе 1.7 мы узнали, что данные о ресурсах обычно формируются с помощью таких современных инструментов создания цифрового контента (DCC), как Maya, ZBrush, Photoshop или Houdini. Однако форматы данных, используемые этими инструментами, обычно не подходят для игрового движка. Поэтому бо'льшая часть данных ресурсов передается через конвейер подготовки активов (asset conditioning pipeline, ACP) до применения игровым движком. ACP иногда называют конвейером подготовки ресурсов (resource conditioning pipeline, RCP) или просто цепочкой инструментов.

Каждый конвейер ресурсов начинается с коллекции исходных активов в собственных форматах DCC (например, файлы Maya .ma или .mb, файлы Photoshop .psd и т. д.). Эти активы обычно проходят три этапа обработки на пути к игровому движку.

1. Конвертеры. Нам нужен какой-то способ преобразования данных из родного формата DCC в формат, которым мы можем оперировать. Обычно это достигается написанием специального плагина для данного DCC. Работа плагина заключается в экспорте данных в отдельный промежуточный формат файла, который можно передать на более поздние стадии конвейера. Большинство приложений DCC имеют довольно удобный механизм для этой цели. У Maya их целых три: C++ SDK, сценарный язык под названием MEL, а также совсем недавно появившийся интерфейс Python.

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

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

3. Компоновщики ресурсов. Иногда необходимо несколько файлов ресурсов объединить в один полезный пакет перед загрузкой игровым движком. Это имитирует процесс компоновки объектных файлов скомпилированной программы C++ в исполняемый файл, поэтому данный процесс иногда называют компоновкой ресурсов. Например, при создании сложного составного ресурса, такого как 3D-модель, нам может потребоваться объединить данные из нескольких экспортированных файлов сеток, нескольких файлов материалов, файла скелета и нескольких файлов анимации в один ресурс. Не все типы ресурсов нужно компоновать — некоторые активы готовы к использованию в игре после экспорта или компиляции.

Зависимости ресурсов и правила сборки. Подобно компиляции исходных файлов в проекте на C или C++ и затем связыванию их в исполняемый файл, конвейер подготовки активов обрабатывает исходные активы (в форме файлов геометрии и анимации Maya, PSD-файлов Photoshop, необработанных аудиоклипов, текстовых файлов и т. д.), преобразует их в готовую для игры форму и затем связывает в единое целое для использования движком. Как и исходные файлы компьютерной программы, игровые активы часто имеют взаимозависимости. (Например, меш ссылается на один или несколько материалов, которые, в свою очередь, ссылаются на различные текстуры.) Эти взаимозависимости обычно влияют на порядок, в котором активы должны обрабатываться конвейером. (Например, может понадобиться построить скелет персонажа, прежде чем мы сможем обработать любую из его анимаций.) Кроме того, зависимости между активами говорят нам, какие активы необходимо перестроить при изменении конкретного исходного актива.

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

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

Об авторе

Джейсон Грегори работает в игровой индустрии с марта 1999 года, а карьеру программиста начал еще раньше — в 1994 году. Первый опыт программирования игр получил в компании Midway Home Entertainment (Сан-Диего), где занимался играми Hydro Thunder 2 и Offroad Thunder, а также создавал системы анимации под Playstation 2/Xbox для игр Freaky Flyers и Crank the Weasel. В 2003 году Джейсон перешел в Electronic Arts, где занимался разработкой игрового движка и технологией геймплея для Medal of Honor: Pacific Assault и работал ведущим инженером в Medal of Honor: Airborne project. В настоящее время Джейсон является ведущим программистом в Naughty Dogs Inc., где на момент написания книги он и его коллеги занимались разработкой The Last of Us: Part II для Playstation 4. Он разрабатывал игровой движок и средства геймплея для игр серии Uncharted и для The Last of Us на PS3 и PS4.

» Более подробно с книгой можно ознакомиться на сайте издательства
» Оглавление
» Отрывок

Для Хаброжителей скидка 25% по купону — Game

По факту оплаты бумажной версии книги на e-mail высылается электронная книга.