Отчет о КРИ2008 – 3

x-posted from zeux.livejournal.com

Последняя порция отчетов про доклады.

8. Как закалялся Crysis. Эволюция разработки
9. DirectX. Цели на будущее

8. Как закалялся Crysis. Эволюция разработки (день третий, 16:00, Сатурн)

Второй из лучших докладов. Лид программист рассказывал про разработку – рассказывал про всякое, честно и без рекламы :)

40 программистов, 20 игровой код и 20 движок примерно.

Для игрового кода – SCRUM. Спринт длиной 2 недели. Команда разбита на группы, спринт – per group, группа состоит из людей, работающих над одной фичей – это не только программисты, а и артисты.
Для R&D SCRUM не взлетел совсем, потому что во-первых редко есть одна цель для всей команды, а типично есть один человек, который работает над одной подсистемой, другой над другой, etc., во-вторых большую часть занимает оптимизация и отладка, которая не вписывается в SCRUM. Используется ad-hoc схема.

Изначально пытались сделать большой план на все, он достаточно скоро начал очень сильно отличаться от реального положения дел, на него забили.

Размер репозитория – 600 Gb, из них 60 Gb – репо для кода. Кода всего 1.7 миллионов строк.

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

Шейдеры тоже убер, на игру порядка 3 миллионов (если я правильно запомнил…) комбинаций. Шейдеры собираются на 5 8-core (2 CPU, 4 core per CPU) машинах, полная сборка кеша идет 2 часа. Если кеш не собран, идет компиляция на лету, вроде.

Есть централизованные билды. Билд – это актуальный образ игры (exe + данные) и редактора. Размер билда – гигабайты (около 6-8 Gb вроде). У каждого билда есть уникальный номер.

Билды собираются на специальном фарме, там несколько 8-core машин, у каждой 4 Gb RAM + 2 или 4 Gb RAMDISK для временных файлов – сильно ускоряет компиляцию. Билды для сборки кода не используют IncrediBuild. Это т.н. full build, он делает clean checkout, и собирает все. Есть еще fast build, он забирает только новые файлы.

Система контроля версий – Perforce для всего. Изначально был SourceSafe для кода и AlienBrain для данных, потом для кода перешли на perforce, потом и для данных тоже из-за того, что база alienbrain корраптилась периодически. Perforce на Windows Server не взлетел, пришлось ставить линукс – из-за количества одновременно открытых хендлов. Я как-то упустил момент про количество бранчей, кажется таки есть основной бранч, но каждая группа работает свою итерацию (2 недели те) в своем, и мержит.

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

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

Скорости сети не хватает, чтобы утром все смогли забрать билд за вменяемое время, поэтому билд после сборки автоматически копируется на компьютеры.

Используются pak файлы, и в билде все ассеты в пак файлах. Если художник хочет редактировать ассеты, он достает их из сорс контроля, если путь от фолдера до файла в FS и до файла в пак файле совпадает, то берется файл из FS. Таким образом художник тестирует измененные ассеты в билде, затем коммитит ассеты – они попадут в следующий билд.

Редактор является оболочкой над игрой, и соответственно требует ресурсов сильно больше. Из-за этого редактор перестал влезать в память. На 32-bit OS для 32-bit приложения доступно порядка 1.7 Gb памяти, на 64-bit OS для 32-bit – порядка 3, этого все равно было мало для некоторых уровней. Решение – весь тулсет работает в 64-bit. Игра также поддерживает 64-bit, Crysis – одна из первых игр, умеющих нативно работать в обоих режимах.

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

Обязательное требование – отмапленный рабочий диск в J:\, это позволяет избавиться от проблем с абсолютными путями (абсолютные пути к ресурсам совпадают на разных компьютерах).

9. DirectX. Цели на будущее (день третий, 17:00, Галактика 4+5)

Последний доклад от Чаза. Было еще два, меня на них не было. Чаз рассказывал про светлое будущее, в этот раз обошлось без особых проблем – доклад он знал :)

Тут было очень много всякого про GPGPU, про то что Direct3D как платформа победила всех в области parallel computing, и лет через 5 direct3d-style computing будет везде, ну и еще очень много всякого.

В качестве дополнительного реквеста от девелоперов было названо более внятное multi thread поведение – возможность разные части запускать параллельно.

Еще девелоперы не любят проблему с комбинаторным взрывом числа шейдеров, и ее собираются решать – правда, как, Чаз не сказал :) (в ответ на мой вопрос сказал, что как только будет что анонсировать, они сразу же…)

Были вопросы про то, когда будет тесселяция не через хаки – тесселяция кажется скорее всего будет в следующем API. Следующее API не будет требовать Windows 7 – по кр. мере, сказано было, что они постараются, чтобы новое API работало как на текущей OS, так и на OS предыдущего поколения.

Был, ээээ, странный (это эвфемизм, да) вопрос про generic shadowing solution в DX Next. Кажется, не будет у нас такого! (thank god)