Арт-пайплайн на 50 гигабайтАрт-пайплайн на 50 гигабайт

Андрей Аксенов

shodan NOSPAM@NOSPAMshodan.ru

КРИ’2006

Занимательная нумерологияЗанимательная нумерология

Модуль CVS checkoutРесурсы игры 12.5 GB 2.8 GB

Исходники графики игры 34.0 GB 17.1 GB

Исходники графики роликов 31.2 GB 13.1 GB

Озвучка диалогов 3.4 GB 0.4 GB

Всего 81.1 GB 33.4 GB

Всего без учета роликов 49.9 GB 20.3 GB

ресурсы игры – как в окончательных, так и в промежуточных форматах (нежатые текстуры и

анимации)

исходники – рабочие файлы художников (*.max, *.psd, *.tga и т.д)

CVS – размер модуля на сервере

checkout – размер локальной рабочей копии

Занимательная терминологияЗанимательная терминология

арт-пайплайн– процесс внесения в игру ресурсов,

создаваемых художниками• модели• коллизионные модели• анимации• текстуры• системы частиц• камеры• шрифты• и прочие визуальные настройки

Устройство пайплайнаУстройство пайплайна

зависит от ряда факторов техническая часть

– требования тулсета– предоставляемые тулсетом возможности

• поддерживаемые форматы? структура расположения файлов? билды? “как увидеть модель в игре”?

организационная часть– принятые в компании правила добавления

и редактирования ресурсов• кто? куда? какие требования? кто проверяет?

“кто виноват и кому править”?

НумерологияНумерология reloaded reloaded

в золотом билде– 3264 модели

• 2392 статические• 872 анимированные

– 8941 анимация– 2097 текстур

• из них 528 генерируемых (спекание, DXT сжатие)– 78 карт (включая титры и обучение)

size does matter!– накладывает технические требования– накладывает организационные требования

Пайплайн Магии КровиПайплайн Магии Крови

тотальный контроль версий использование “плоской” VFS отсутствие билдов

– в ходе ежедневной разработки

“тонкий” тулсет– утилиты для обработки данных, а не

данные, подготавливаемые для утилит– игра – тоже утилита!

текстовые файлы везде, где можно

Контроль версийКонтроль версий

CVS– правильная модель (без блокировок)– свободный, стабильный, достаточно быстрый– удобный GUI для дизайнеров (TortoiseCVS)

изначально существовал для кода и ресурсов внедрен для рабочих материалов художников

– через 1 год после начала разработки– “сломались” на 8 GB рабочих материалов– сливаемых вручную на одну машину...– 2 дня перехода– 3 дня подчистки багов

Контроль саботажаКонтроль саботажа

человек слаб– некоторым простым правилам (пример: именование

файлов) художники (наши) следовать неспособны простейший фильтр CVS коммитов на сервере

(проверка имен на корректность) проверять целостность можно и жестче

– например, запрещать удаление текстур, на которые есть ссылки в картах

– НЕ было реализовано, так как проблем такого рода было немного

– your artists may vary!

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

может ли вас уничтожить “пожар”?– мы пережили 4...

еженедельный полный backup– 140 GB CVS, 50 GB архив– минимум 2 копии, на сервере и внешнем носителе– CD/DVD сбоили КАЖДЫЙ раз– внешняя копия ТОЛЬКО на HDD– внешняя копия хранится ТОЛЬКО вне офиса

ежедневный инкрементальный backup– измененные за последние 30 часов файлы– до 1 GB– минимум на 2 разных машинах в офисе

паранойя окупается

Виртуальная файл-системаВиртуальная файл-система

можно грузить ресурсы из обычной FS– для ежедневной разработки

можно грузить ресурсы из PAK-файла– для золотой версии

все имена файлов уникальны– хорошо – можно произвольно перемещать ресурсы,

делать любую ручную группировку– плохо (?) – нет автоматической группировки по

связям– плохо – пересканирование директории ресурсов при

каждом запуске утилиты или игры• либо 768+ MB памяти для кеширования на уровне OS• либо использовать спецутилиту-генератор кеша FS

Скажи билдам Скажи билдам ““нетнет”!”!

“сборка уровня” для загрузки карты в игру не требуется

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

ограничение регулярные проверки “всего”

– есть батч-загрузка всех карт– есть проверка ссылок по всем ресурсам

требуется сборка финального (золотого) билда– ряд окончательных оптимизаций ресурсов делается

только в ходе этого процесса

Текстовые файлыТекстовые файлы

так называемая “консоль”– общий парсер текстовых файлов– в котором каждой подсистемой регистрируются

собственные обработчики команд– используется для карт, prefabs, настроек мешей...

хорошо – упрощается нестандартная обработка– FAR и макросы в большинстве случаев– изредка, мини-скрипты на perl

плохо – непродуманный формат– не было возможности автоматически добавлять-

убирать-менять параметры– расширяемая консоль была сделана слишком

поздно

Текстовые файлы – примерТекстовые файлы – пример

build_start_container "furniture_act3_servant02" 30.0 7.0 3.0

build_container_event ""

build_objectflag 1

build_properties 2.283112 0.790283 16.470825 1.0 0.0 0.0 0.0

build_objectname "Container object# 3" 0

build_end_container "Bookstore"

fxmaterial_specular {

flags = 2

alphacut = 128

...

alphagen = { min=0 max=1 noiseamp=0.2 periodmin=1 periodmax=2 }

texDiffuse = { name="japan_bark_snow.dds" target=0 }

...

}

The Bloody ToolsetThe Bloody Toolset

набор узкоспециализированных утилит каждая утилита – отдельное приложение основные утилиты (рацион художника)

– плагин для 3D пакета (MAX, MAYA)• экспорт моделей, коллизий, анимаций• средства для проверки ошибок в моделях

– редактор моделей– редактор систем частиц– редактор prefabs– редактор игровых карт– редактор интерфейсов– редактор персонажей

The Bloody Toolset – 2The Bloody Toolset – 2

дополнительные утилиты для художников

– редактор шрифтов

– генератор деревьев распределений вероятности (для эмисии партиклов)

– генератор covering boxes (для теней) ряд “системных” утилит

– генератор кеша файлсистемы

– сборщики билдов, PAK файлов, и т.п.

– ряд конвертеров

– и прочие редкости

Путь моделиПуть модели

моделируется и анимируется в MAX экспортируется в собственный

бинарный формат материалы и локаторы настраиваются

в редакторе моделей– настройки сохраняются в отдельный

текстовый файл (патч)– иначе при правках и повторном экспорте

MAX модели они будут потеряны– в ходе сборки золотого билда патчи

вкомпилируются в бинарные модели

Путь коллизииПуть коллизии

для “статических” моделей– вручную упрощенная геометрия исходной

модели, моделируется в MAX– экспортируется в собственный бинарный

формат– связывается с моделями в редакторе

prefabs для персонажей

– в МК – повсеместно сферы, расставляемые в редакторе prefabs и сохраняемые в патч

– можно использовать bone-boxes

Путь анимацииПуть анимации

отдельные анимации (ходьба, атака, и т.д.) хранятся в отдельных MAX сценах– можно хранить в отдельных BIP– плагин умеет грузить и экспортировать BIP

экспортируются в промежуточный бинарный формат (без сжатия)– вопрос настроек сжатия – удобнее работать

с промежуточным файлом, чем переэкспортировать

– промежуточный формат можно прозрачно подгружать и в игру, и в утилиты

Путь анимации Путь анимации – 2– 2

при экспорте можно указать скелет из другой MAX сцены (т.н. global skeleton)– т.к. в разных сценах может быть разная

привязка после экспорта сжимается в

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

контролирует качество– экономим диск и системную память

Путь текстурыПуть текстуры

все текстуры сохраняются в DDS все “обычные” текстуры должны быть

сжаты в DXT1 или DXT5– экономим диск и видеопамять– NV плагин для Photoshop

все “спекаемые” текстуры должны быть несжатыми (ARGB8)– в МК это bump и specular текстуры

(спекаются в общую bump.rgb + specular.a)– автоматически спекаются редактором

моделей при сохранении патчей

Путь игровой картыПуть игровой карты

карты генерируются случайно– хорошо – replayability– плохо – очень сложный в разработке

инструментарий (и редактор карт, и игра) регионы и эффекты

– случайно расставляемые регионы– жестко заданные эффекты

• статические модели, prefab-ы (в частности здания), некоторые NPC, генераторы монстров, контейнеры, шрайны, высотные эффекты, материалы поверхности, дороги...

Не-арт пайплайн (скрипты)Не-арт пайплайн (скрипты)

LUA 2,463,591 байт, 71464 строки, 388 файлов перезагружаются на лету

– в “0 кликов”, по факту изменения файла интегрирован LUA отладчик, которым никто не

пользуется– 95% багов “и так” ясны– 5% багов решаются при помощи отладочного

вывода из скриптов– за счет перезагрузки на лету поставить отладочный

вывод – “1 клик”

PickerPicker

“навел мышку – написало, на что”– и в редакторе карт, и в игре

в МК – работает по коллизиям– показывает имя файла коллизии, prefab-а– лучше работать по визуальной геометрии

нужен для исправления ошибок художников начиная с определенного объема – жизненно

необходим когда моделей за 1000, опознать любую по

внешнему виду не способен никто

СборкиСборки

автоматизированный процесс– почти полностью– отдельная конфигурация кода (debug, release, final)– “во времена затишья” обязательно ломается

компиляция final можно собирать разные виды сборок

– полная игра, обрезанная версия, патч можно контролировать опции сборки

– наличие читов и отладочного кода– наличие защиты– оптимизация загрузки– язык

Этапы сборкиЭтапы сборки

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

– создание логов загрузки ресурсов для каждой карты– переупорядочивание общего списка ресурсов

создание финального PAK файла

ВремяВремя,, вперед вперед

обычная сборка – 1.5-2 часа– 40-60 минут на извлечение из CVS– 10-20 минут на компиляцию игры и утилит– 20-30 минут на компиляцию патчей к

моделям– 5-10 минут на создание PAK

золотая сборка – вся ночь– за счет оптимизации времени загрузки– создание логов загрузки – по 1-3 минуты на

карту, около 100 карт – до 5 часов– итого до 7 часов

Разработка иРазработка и перерывы на чайперерывы на чай

запуск игры– от 10 секунд до 2-3 минут в debug

• в случае “холодной” медии• в случае “холодных” загружаемых на старте

ресурсов– 10-20 секунд в final

загрузка игрового уровня– от 30 секунд до 3-5 минут в debug– 20-60 секунд в final– оптимизация заметна на глаз– ориентировочно 10-30%

Bureaucratic common senseBureaucratic common sense

балансировка загрузки – все, что могут делать художники, делают художники– вопиющий пример: занесение ресурсов в CVS

ответственность – кто ошибся, тот исправляет иерархия – если “некому” чинить, чинит лид

– или, конечно, назначенный им человек специальные полумеры перед золотом

– ВСЕ коммиты художников во ВСЕ модули CVS проверялись 2-мя программистами

– часть ошибок была поймана в ходе проверок– часть – нет

ВыводыВыводы

необходим тотальный контроль версий– история ревизий, откаты, ветки, и т.д.– автоматический контроль целостности и резервное

копирование– на порядок меньше ошибок слияний

необходима разнообразная поддержка со стороны тулсета и игры– уметь “точечно” редактировать нужный ресурс– уметь грузить промежуточные форматы– уметь перезагружать на лету все, что нужно

редактировать интерактивно– обеспечивать всю необходимую отладочную

информацию– обеспечивать разумную скорость загрузки и работы

Выводы – 2Выводы – 2

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

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

FIN