Арт-пайплайн на 50 гигабайт Андрей Аксенов shodan NOSPAM shodan.ru КРИ2006

Занимательная нумерология МодульCVScheckout Ресурсы игры12.5 GB2.8 GB Исходники графики игры34.0 GB17.1 GB Исходники графики роликов31.2 GB13.1 GB Озвучка диалогов 3.4 GB0.4 GB Всего81.1 GB33.4 GB Всего без учета роликов49.9 GB20.3 GB ресурсы игры– как в окончательных, так и в промежуточных форматах (нежатые текстуры и анимации) исходники– рабочие файлы художников (*.max, *.psd, *.tga и т.д) CVS– размер модуля на сервере checkout– размер локальной рабочей копии

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

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

Нумерология 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" build_container_event "" build_objectflag 1 build_properties build_objectname "Container object# 3" 0 build_end_container "Bookstore" fxmaterial_specular { flags = 2 alphacut = alphagen = { min=0 max=1 noiseamp=0.2 periodmin=1 periodmax=2 } texDiffuse = { name="japan_bark_snow.dds" target=0 }... }

The Bloody Toolset набор узкоспециализированных утилит каждая утилита – отдельное приложение основные утилиты (рацион художника) –плагин для 3D пакета (MAX, MAYA) экспорт моделей, коллизий, анимаций средства для проверки ошибок в моделях –редактор моделей –редактор систем частиц –редактор prefabs –редактор игровых карт –редактор интерфейсов –редактор персонажей

The Bloody Toolset – 2 дополнительные утилиты для художников –редактор шрифтов –генератор деревьев распределений вероятности (для эмисии партиклов) –генератор covering boxes (для теней) ряд системных утилит –генератор кеша файлсистемы –сборщики билдов, PAK файлов, и т.п. –ряд конвертеров –и прочие редкости

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

Путь коллизии для статических моделей –вручную упрощенная геометрия исходной модели, моделируется в MAX –экспортируется в собственный бинарный формат –связывается с моделями в редакторе prefabs для персонажей –в МК – повсеместно сферы, расставляемые в редакторе prefabs и сохраняемые в патч –можно использовать bone-boxes

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

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

Путь текстуры все текстуры сохраняются в DDS все обычные текстуры должны быть сжаты в DXT1 или DXT5 –экономим диск и видеопамять –NV плагин для Photoshop все спекаемые текстуры должны быть несжатыми (ARGB8) –в МК это bump и specular текстуры (спекаются в общую bump.rgb + specular.a) –автоматически спекаются редактором моделей при сохранении патчей

Путь игровой карты карты генерируются случайно –хорошо – replayability –плохо – очень сложный в разработке инструментарий (и редактор карт, и игра) регионы и эффекты –случайно расставляемые регионы –жестко заданные эффекты статические модели, prefab-ы (в частности здания), некоторые NPC, генераторы монстров, контейнеры, шрайны, высотные эффекты, материалы поверхности, дороги...

Не-арт пайплайн (скрипты) LUA 2,463,591 байт, строки, 388 файлов перезагружаются на лету –в 0 кликов, по факту изменения файла интегрирован LUA отладчик, которым никто не пользуется –95% багов и так ясны –5% багов решаются при помощи отладочного вывода из скриптов –за счет перезагрузки на лету поставить отладочный вывод – 1 клик

Picker навел мышку – написало, на что –и в редакторе карт, и в игре в МК – работает по коллизиям –показывает имя файла коллизии, prefab-а –лучше работать по визуальной геометрии нужен для исправления ошибок художников начиная с определенного объема – жизненно необходим когда моделей за 1000, опознать любую по внешнему виду не способен никто

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

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

Время, вперед обычная сборка – часа –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 sense балансировка загрузки – все, что могут делать художники, делают художники –вопиющий пример: занесение ресурсов в CVS ответственность – кто ошибся, тот исправляет иерархия – если некому чинить, чинит лид –или, конечно, назначенный им человек специальные полумеры перед золотом –ВСЕ коммиты художников во ВСЕ модули CVS проверялись 2-мя программистами –часть ошибок была поймана в ходе проверок –часть – нет

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

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

FIN