лекции на КРИ 2008
Краткие заметки с лекций, которые мне удалось посетить на КРИ 2008 (раньше не мог выложить - работы много):


Экспорт графических ресурсов для Next-Gen платформ
Александр Долбилов, Арсений zeux Капулкин (Creat Studios)

* конечный результат экспорта хранится в memory mapped file
* для сборки данных используется SCons (из-за отслеживания зависимостей)
* как обычно - все оптимизировать на стадии экспорта

Материалы:
* 4 states в материале: alpha test, depth test, culling, --не помню--
* в материалах возможна перегрузка дефолтных шейдеров (phong, blinn, etc)
* указание низкоуровневых параметров alpha-blend (blend func) художники "не осилят"
* поддержка default materials от DCC желательна (быстрее, привычнее), но для Next-Gen надо уже свое, более продвинутое

Текстуры:
* самый тормозной этап - экспорт текстур
* код сборки текстур под каждую платформу - свой, на уровне массива пикселей
* кеширование с помощью md5 в SCons
* текстура разбивается на тайлы 128x128, переупорядочивается
* мипмапы меньше 16x16 собираются в кучу
* текстуры на xbox тупо грузятся и затем помечаются в памяти, как текстура (d3d)
* текстуры на ps3: swizzling; если никак, то pitch толжен совпадать для всех miplevels (вместо 33% получаем overhead +100% на мипы)

Геометрия:
* широко используется collada (проблемы с масштабом, на fcollada забили)
* ColladaFX как средство унификации материалов (нет завязки на DCC, настройка сразу там); проблемы - избыточно, медленно, баги
* ColladaMaya - интерфейс неудобный, проблемы с batch build
* ColladaMax - еще хуже, тонна багов
* чтение из DAE: triangle lists, уменьшение размера вершины (сжатие атрибутов - квантование: float16 вместо float, HEND3N/CMP вместо float3; сжимающее преобразование) - max до 4 раз уменьшение; triangles reordering, потом vertex cache optimization
* анимация из DAE: скелет, локаторы; sampling + сжатие - качественнее, чем кривые


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




Разработка единой технологической платформы
Дмитрий ddima Долгов (1С)

Цели:
* кросс-платформенность
* модульность:
- слотовая архитектура
- легкое подключение и замена модулей
- четко описанные внешние интерфейсы
- жесткая иерархия модулей
* кросс-жанровость и масштабируемость
* распределенная разработка
* быстрое прототипирование

Платформы: PC, PSP
Язык: C++
Ресурсы: 12 человек в 6 городах, 1,5 года разработки
Объем: 10 Мб кода, 300k строк; 6 Мб справки, 300k туториалов
Статус: в настоящий момент многое еще не дописано

* событийные вызовы из ядра могут параллелиться на произвольное количество процессоров
* система подписки
* описание данных - в human-readable ({}) формате
* база типовых заготовок игрового кода (game layer templates)

Dynamic Data Language:
* метаописания - хидеры
* генерация кода по метаописанию
* зависимости между модулями

Билд-система:
* автоматизированный pipeline, логи доступны через интернет, отчеты рассылаются автоматически почтой
* система спецтегов, система их анализа (todo, fixme, bug, etc) и автоматизированной рассылки ответственным
* автоматическая валидация данных на основе per-model описаний

Редактор:
* WYSIWYP, работает по TCP/IP как отдельный клиент (для отладки на консолях)

Суммарный overhead такой универсальности автор оценивает в 10-15%


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




О некоторых особенностях приготовления брюквы
Борис boris_batkin Баткин

* хорошая игра отличается подходом к качеству, есть несколько показательных моментов
* динамический диапазон изображения часто используется на 70%
* имеет смысл контекстная коррекция цвета
* можно настроить гистограммы по разному для разных фрагментов игры, главное - дать крутилки дизайнеру
* не все цвета одинаково полезны, нужно учитывать физиологические особенности человека
* контроль плотности сетки, не допускать субпиксельных полигонов
* высокочастотный шум сетки - еще одно последствие слишком большой плотности полигонов
* sharpen vs anisotropy filtering
* 30 или 60 fps? (особенно под телевизор, задержки до 96 мс)
* обязателен немедленный feedback игры, пусть даже реально действие растягивается на много кадров
* ducking для звука (при воспроизведении речи делаем тише громкие фоновые звуки)
* использование reverb / roomtone в озвучке добавляет реалистичности
* латентность звука тоже есть
* loading screen можно сделать интерактивным
* скорость чтения DVD - 3,5 Mb/s, BD - 10-15 Mb/s; желательно использование HDD для кеширования считанных данных на консолях
* проблемы масштаба = проблемы качества (лучше сделать качественные "3 спартанца", чем трешовые "300")
* что не можешь сделать, не делай

версия конспекта от Zeux

Клево, очень показательна была тишина в переполненном зале, когда дело дошло до вопросов (в конце концов кто-то выдавил из себя только "а сколько лет надо, чтобы до такого дойти"?).




Управление дизайном проекта
Александр Мишулин (Nival Online)

* основная задача дизайнера - создание, распространение и поддержание видения игры
* основные документы:
- strategic statement -экономическое и техническое обоснование
- vision
* общий vision:
- задает общий контекст общения
- внедряет "здравый смысл" в рамках проекта
* методы распространения видения:
- наличие краткого, легко читаемого видения
- сайт
- постеры
- ролики
* дополнительные разрушители видения - новые проекты, общие социальные явления
* одна из проблем - "пришивание пуговиц" вместо создания целостного проекта
* необходим контроль feature creep
* изоляция внутри цеха дизайнеров - зло
* при иерархической структуре проекта получается "клуб по интересам", хранители видения находятся только в одном месте, что плохо
* agile - переход к разбиению по командам; сложная перестройка, видение отдельных дизайнеров портится, требует большего контроля за "пуля вылетела"
* если менять видение - то сильно, малые изменения - зло; если не менять, появляются бездумные устои ("так принято")


По делу, мне понравилось.




Планирование и организация разработки игрового контента
Александр Шиляев (Wargaming.net)

* менеджмент производства - это производство задач
* артефакты:
- общий репозиторий
- статистика по прежним проектам
- информационная система (у них - TargetProcess)
- time budget (реально доступное рабочее время, коэффициенты эффективности отдельных сотрудников)
* статистика: первые текстуры на 30-40% медленнее, крупные модели - быстрее мелких
* нужно знать отраслевые нормы производительности
* среднесрочный план + 20-30% запас времени
* теоретически уходит 18 часов на текстуру 1024x1024
* подготовка производства:
- соглашение об именовании
- технические спеки
- составление списка объектов
- структура каталогов в репозитории
- каталоги под реф, скетч, требования (создаются для каждого объекта заранее)
- задачи в трекер
* производство
- команде выдается оценка на 20-30% меньше реального срока
- краткосрочный план на 1-2 недели
* периодический анализ фактических данных:
- отчеты из информационной системы
- анализ методами статистики
- анализ индивидуальной статистики по сотрудникам
* регулярное перепланирование
* специфика аутсорса:
- чистое производство
- оптимизация производства за счет опыта
* продуктовая схема
- адаптивный подход
- план меняется по ходу готовности технологий
- концепция "вытягивающей" системы в производственной логистике, JIT
* рефы ищутся сразу
* планируется не то, когда будет конкретный объект, а количество объектов в заданное время
* QA со стороны лидов


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




Стриминг и эффективное чтение с DVD
Роман Лут (Deep Shadows)

* необходима изначальная ориентация движка на асинхронную работу с ресурсами
* стратегия
* уникальные и shared ресурсы, стратегии предварительной загрузки:
1 все ресурсы зоны - уникальны (дублирование, зато эффективнее чтение)
2 некоторые ресурсы - shared (refCount ресурсов)
3 независимый кеш, shared ресурсы загружаются по надобности (в памяти всегда есть уменьшенная версия всех текстур, грузим только то, что надо рендерить)

Streamable resource:
states: unloaded, loaded, loading
StartBackgroundLoad()
Unload()
priority
refCount (для shared)
Lastframeused

3 треда на стриминг:
* loading,
* init (распаковка, инициализация)
* main (финализация ресурсов --не совсем понял--)

Стратегии загрузки:
* по расстоянию
* по видимости
* по триггеру

Независимые кеши:
* на основе статистики
* на основе различных эвристик

Пока ресурс не загрузился:
* используем dummy (для текстур - low-res copy, всегда в памяти - 16x16)
* просто не рисовать, если еще далеко
* звуки, collision mesh - всегда в памяти (все, для чего нет dummy)
* возможно хранить в памяти упакованную версию - например, коллекция текстур (по сути, те же dummies)

Dummies:
* текстура низкого разрешения
* LOD геометрии
* звук низкого bitrate, моно (теоретически)

Фрагментация памяти (не актуально для PC и Xbox360), борьба:
* зона - линейный блок, in-place construction
* разделение памяти на зоны для разных типов ресурсов, custom allocators
* сборка мусора (только с refcount, муторно и не для всех)

Размер зоны определяется доступной памятью и скоростью передвижения игрока - упираемся в скорость чтения с диска

Параметры DVD:
Seek 170-230 мс (full-stroke) / 110-150 мс (1/3),
Spin-up (после остановки привода) - 2800 мс,
layer change - 75 мс (актуально для двухслойных дисков)

Пути оптимизации:
* компрессия
* групповые файлы (минимальный блок - 2 кб, на мелочи много съедается)
* кеширование на HDD (есть специальная библиотека)
* уменьшение длины seek:
- зависимые файлы кладем близко
- перетасовка очереди загрузки (среди ресурсов с одинаковым приоритетом) для минимизации seek - самое эффективное!
- групповые файлы, не нужно seek на подкаталоги ("честная" FS создает неслабый overhead)

Xenus2:
* эвристики (грузим сразу то, что может быстро понадобиться):
- автомобиль + взорванный вариант
- оружие + гильзы
* групповые файлы (по типам), 100 Мб - 2 Гб
* зависимые файлы:
- группировка по типу (текст, геометрия)
- строится граф зависимости, затем - его минимизация генетическим алгоритмом, 2-24 часа на групповой файл; решение - в файл, используется для оптимизации паков


Было интересно, особенно благодаря наличию конкретных цифр.




Практика портирования 3D-шутера на платформу PlayStation 3
Артем cppguru Пальвелев (Saber Interactive)

Объем работы:
2 человека, 10 месяцев работы над портом, всего 4 года на проект
700k строк C++

Основные отличия консолей:
* byte ordering
* выравнивание данных (совместимость с middleware, производительность может варьироваться на порядок)
* pointer aliasing

Platform-specific код:
* syscall wrapper (I/O, sync)
* rendering
* save/load
* fmod
* gamespy

Multithreading:
* 2 HW threads (PPU) + 6 SPU
* PPU: render, update, animation
* SPU: fmod (2), havok

Графика:
* Cg шейдеры
* low-level API, напрямую помещает токены в буфер команд
* менеджмент видеопамяти и ресурсов - вручную

FS & packs:
* pack - zip файл
* 1 pack per level + initials
* async, less seeks
* стримящиеся звуки не в паках
* звуки кешируются на HDD
* игре доступно 1 Гб системного кеша (который затирается следующей игрой) и 7 Гб инсталлируемых данных

Память:
* 209 Мб системной и 224 Мб видео
* имелась статистика по потреблению памяти подсистемами
* тюнинг:
- звуковые банки в видеопамяти
- часть вертексных данных хранится только в видеопамяти
- художники тюнят разрешения текстур
* allocations:
- dlmalloc (1 мкс на каждую)
- фрагментация - имеется пул свободной памяти
- per-frame allocation можно и на консолях, но осторожно
* статистика:
- +16 Мб под статистику в дебаг-билдах
- для каждого блока - __FILE__, __LINE__
- в констуктор передаюся данные о модуле
- полный дамп по кнопке
- тулза для сравнения двух дампов и определения утечек
* видеопамять:
- alloc: top += block
- defrag on level unload
- часть данных постоянно загружена (ui, etc)

Профилирование:
* профайлеры от Sony и SNS
* собственная кросс-платформенная тулза для сбора статистики


Консоли глазами писюшников оказались не такими ужасными, есть жизнь на марсе.




Как закалялся Crysis, эволюция разработки
Тимур Давиденко (Crytek)

Начало разработки - 2004 год
1,7М строк C++
40 программистов (50% движок, из них 5 только на тулзы)

* scrum, спринты по 2 недели, отдельные бранчи
* раз в 2 недели - 2 дня на стабилизацию
* perforce, 147000 ревизий (на вопрос, почему не svn: "ну он же бесплатный, стремный поди")
* TIFF как промежуточный формат текстур, в custom fields - информация для конвертации
* endianness ресурсов конвертится при финальном экспорте
* в разработке используются только официальные билды (нумерованные), в них есть информация о ревизии
* 8-12 человек на QA
* специальный список рассылки для crashes, т.к. в трекер вбивать было долго
* данные уровня пересчитывались ночами, с утра всем на машины копировались свежие билды
* ubershaders, 3M комбинаций, 5 dual quad cores, 2-3 часа компиляция
* автоматизированное тестирование и профилирование
* своя система сборки на JavaScript с фиговым кешированием (адский NIH дитектед!)


Снова смешанные чувства - крутой проект все-таки выпущен, но создалось такое впечатление, что если бы туда не вкладывались деньги чемоданами, результат при таком подходе был бы другим. Подробнее: http://zeux.livejournal.com/49453.html