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

1. Арт-пайплайн на 50 гигабайт Андрей Аксенов shodanNOSPAM@NOSPAMshodan.ru КРИ’2006

3. Занимательная нумерология ресурсы игры– как в окончательных, так и в промежуточныхформатах (нежатые текстуры и анимации) исходники– рабочие файлы художников (*.max, *.psd, *.tga ит.д) CVS – размер модуля на сервере checkout – размер локальной рабочей копии

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

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

6. Нумерология reloaded • в золотом билде • 3264 модели • 2392 статические • 872 анимированные • 8941 анимация • 2097 текстур • из них 528 генерируемых (спекание, DXT сжатие) • 78 карт (включаятитры иобучение) • size does matter! • накладывает технические требования • накладывает организационные требования

7. Пайплайн Магии Крови • тотальный контроль версий • использование “плоской”VFS • отсутствие билдов • в ходе ежедневной разработки • “тонкий” тулсет • утилиты для обработки данных, а не данные, подготавливаемые для утилит • игра – тоже утилита! • текстовые файлы везде, где можно

8. Контроль версий • CVS • правильная модель (без блокировок) • свободный, стабильный, достаточно быстрый • удобный GUI для дизайнеров (TortoiseCVS) • изначально существовал для кода и ресурсов • внедрен для рабочих материалов художников • через 1 год после начала разработки • “сломались” на 8 GB рабочих материалов • сливаемых вручную на одну машину... • 2 дня перехода • 3 дня подчистки багов

9. Контроль саботажа • человек слаб • некоторым простым правилам (пример: именование файлов) художники (наши)следовать неспособны • простейший фильтр CVS коммитов на сервере (проверка имен на корректность) • проверять целостность можнои жестче • например, запрещать удаление текстур, на которые есть ссылки в картах • НЕ было реализовано, так как проблем такого рода было немного • your artists may vary!

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

11. Виртуальная файл-система • можно грузить ресурсы из обычной FS • для ежедневной разработки • можно грузить ресурсы из PAK-файла • для золотой версии • все имена файлов уникальны • хорошо – можно произвольно перемещать ресурсы, делать любую ручную группировку • плохо (?) – нет автоматическойгруппировки по связям • плохо – пересканирование директории ресурсов при каждом запуске утилиты или игры • либо 768+ MB памяти для кеширования на уровне OS • либо использовать спецутилиту-генератор кеша FS

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

13. Текстовые файлы • так называемая “консоль” • общий парсер текстовых файлов • в котором каждой подсистемой регистрируются собственные обработчики команд • используется для карт, prefabs, настроек мешей... • хорошо – упрощается нестандартная обработка • FAR и макросы в большинстве случаев • изредка, мини-скрипты на perl • плохо – непродуманный формат • не было возможности автоматически добавлять-убирать-менять параметры • расширяемая консоль была сделана слишком поздно

14. Текстовые файлы – пример 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 } ... }

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

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

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

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

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

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

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

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

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

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

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

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

27. Время, вперед • обычная сборка – 1.5-2 часа • 40-60минут на извлечение из CVS • 10-20 минут на компиляцию игры и утилит • 20-30минут на компиляцию патчей к моделям • 5-10 минут на создание PAK • золотая сборка – вся ночь • за счетоптимизации времени загрузки • создание логов загрузки – по 1-3минуты на карту, около 100 карт – до 5 часов • итого до 7 часов

28. Разработка иперерывы на чай • запуск игры • от 10 секунд до 2-3 минут в debug • в случае “холодной” медии • в случае “холодных” загружаемых на стартересурсов • 10-20 секунд в final • загрузка игрового уровня • от 30 секунддо 3-5 минут в debug • 20-60 секунд в final • оптимизация заметна на глаз • ориентировочно 10-30%

29. Bureaucratic common sense • балансировка загрузки –все, что могут делать художники, делают художники • вопиющий пример: занесение ресурсов в CVS • ответственность – кто ошибся, тот исправляет • иерархия – если “некому” чинить, чинит лид • или, конечно, назначенный им человек • специальные полумеры перед золотом • ВСЕ коммиты художников во ВСЕ модули CVS проверялись 2-мя программистами • часть ошибок была поймана в ходе проверок • часть – нет

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

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

32. FIN