Плюсы и минусы своей технологии.
Сейчас большинство игр делается на готовых движках. На рынке их представлено достаточно много, для самых разных жанров. Более универсальные Unity и Unreal Engine активно занимаются маркетингом и следят за своей ценовой политикой. К тому же они представляют довольно удобный инструментарий.
Но некоторые компании всё же предпочитают работать с собственным движком. В их числе и Gaijin Entertainment со своим Dagor Engine, недавно обновившимся до версии 5.0. Благодаря этому, в War Thunder появились новые графические эффекты, а привычные локации стали выглядеть иначе. Креативный директор студии Кирилл Юдинцев написал для DTF колонку, в которой рассказал о плюсах и минусах такого подхода.
Dagor Engine появился в тот же год, что и сама компания. В 2002-м для лицензирования были доступны только Unreal, id Tech и RenderWare. Первые два стоили по миллиону долларов и не поддерживали консоли. RenderWare стоил немногим дешевле, поддерживал консоли, но предоставлял меньшее количество инструментов. Решение о разработке собственного движка было принято быстро — в ту пору это было обычное дело.
К тому же свой движок позволяет добавлять новые возможности сразу, не дожидаясь, пока их поддержка появится у производителей middleware. Dagor одним из первых стал рассчитывать глобальное освещение для локаций на GPU, причём в то время, когда ещё ни один движок не имел таких инструментов. Через некоторое время глобальное освещение начал рассчитывать и Source, и использовал для этого CPU.
Разница в скорости расчётов была впечатляющая: одна и та же городская локация размером примерно 100х100 метров с тем же качеством (количеством отражений, и плотностью лайтмэпов) на CPU считалась бы почти две недели, а Dagor с использованием распределённых вычислений на GPU укладывался в 15-20 минут.
Physically based rendering, micro-shadows, atmospheric scattering, поддержка VR — это только несколько примеров, когда новые технологии интегрировались в движок сразу, как только они появились, а некоторые специально изобретались и внедрялись в DE.
О проблемах собственного движка
Глобальные изменения на рынке могут потребовать значительной переделки движка. Переход восьмого поколения консолей на 64-битную архитектуру потребовал довольно много работы команды. А когда мы перешли от разработки оффлайн-проектов к онлайновым, большим изменениям подверглись физика и игровая логика. Прогресс сейчас только ускоряется, и, если вы решите делать проекты на собственном движке, устойчивость к изменениям архитектуры будет очень важным требованием.
Многие задачи не обязательно имеют решение. В некоторых случаях получается придумать решение самим, в некоторых — придумывают другие разработчики, рассказывают о них на GDC или SIGGRAPH, и их остаётся только внедрить. Иногда это просто, как было с SSAO; иногда невозможно, или не очень подходит для наших игр (и не всегда это можно быстро выяснить). Иногда приходится подождать.
Можно, например, упереться в «железо» пользователей. War Thunder — игра с огромной пользовательской базой, и компьютеры игроков могут быть самыми разными: от офисных ноутбуков до навороченных геймерских ПК. Поэтому если задуманная фича может хоть как-то повлиять на геймплей, то она должна одинаково хорошо работать на разных компьютерах и настройках графики, ведь её нельзя выключить в настройках.
Так в марте Dagor Engine обновился до версии 5.0, и вместе с ней в War Thunder появился реалистичный слоистый туман и дымка. Он мог бы быть добавлен в игру гораздо раньше, вместе с базовым atmospheric scattering, который появился в Dagor ещё два года назад, но статистика по компьютерам пользователей показывала, что время для этого ещё не пришло. А вот atmospheric scattering, разработанный у нас, наоборот, не только существенно улучшил прошлое решение (middleware), но и ускорил игру.
Результаты исследования конфигураций пользовательских ПК, проводимого Steam в 2015 году, показали, что 12 и более гигабайт оперативной памяти доступны только 16% пользователей, а видеокарты с памятью более 2 гигабайт были лишь у 10% игроков.
Какие-то детали, наоборот, ждали новых технологических решений. Раньше в War Thunder трава не отбрасывала тень. Имеющихся алгоритмов сглаживания FXAA и MSAA не хватало для того, чтобы избежать на полях и лужайках ряби и мерцания, которые бы сделали игру не комфортной. В Dagor 5.0 вместо MSAA стал использоваться новый алгоритм сглаживания — temporal anti-aliasing (TAA). Он убрал шум на границах объектов, и теперь трава в War Thunder отбрасывает тень, которую видно даже с большого расстояния без ряби. Это добавляет картинке глубины и реалистичности.
Variance Clipping TAA — это прогрессивный алгоритм, за которым стоят хорошие идеи, появившиеся давно. Но у него тоже есть свои ограничения и проблемы, и наша имплементация учитывает много нюансов, чтобы улучшить результат в нашей игре.
Об алгоритмах сглаживания
FXAA — это алгоритм сглаживания, работающий на результирующей (то есть уже построенной и отрисованной) картинке, который пытается найти и сгладить визуальные грани без учёта глубины и исходной геометрии. Это позволяет алгоритму работать очень быстро и, вместе с этим, делает его совместимым с любым типом рендера, в том числе и с deferred render. Данная технология фактически является стандартом компьютерных игр в настоящий момент.
MSAA — алгоритм, реализованный на уровне видеокарты, сглаживающий геометрические границы объектов за счёт дополнительных сэмплов прозрачности на границе треугольников. Это даёт лучший результат для картинки у силуэтов и далёких объектов, за счёт повышения требований к производительности системы.
Эта технология фактически сглаживает только границы (силуэты) геометрических объектов, не улучшая при этом качество в остальных местах. Кроме того, такая технология на практике с трудом совместима с deferred render, поскольку получение адекватного результата для современного рендеринга требует дополнительных ухищрений, приводящих к дополнительным вычислительным расходам, а также к визуальным проблемам и ограничениям.
TAA — технология темпорального сглаживания. Она берёт в расчёт некоторое количество ранее отрисованных кадров, учитывая расположение пикселей в динамике. Она обеспечит отсутствие «шума» на растительности, плавность граней объектов и добавит деталей на поверхностях. Фактически, ТАА работает как отрисовка картинки в большем разрешении, с последующим уменьшением до размера вашего экрана.
О добавлении в собственную разработку технологий, недоступных в других движках
В Dagor 5.0 добавили технологию расчёта глобального освещения в режиме реального времени. Движок использует его ещё с 2004 года, но в War Thunder он появился только сейчас, с обновлением 1.77 «Буря».
Дело в размере локаций. В большинстве случаев разработчики игр делают предрассчитанные карты (плоские или объёмные) света и теней для локаций. Каждая такая карта занимает место на диске и в памяти, и чем больше локация, тем больше места она займет.
Если в игре есть крупные разрушаемые объекты (а мы хотим, чтобы отраженный от них свет пропадал, когда они разрушены), то задача усложняется — предрассчитать всё не получится, надо будет как-то инвалидировать места где освещение должно поменяться. Динамическая смена времени суток и погода накладывают свои ограничения: необходимо хранить не посчитанный свет, а информацию о том, как свет будет распространяться (посчитать которую сложнее, и она существенно объёмнее).
Средний размер локации в War Thunder 32х32 километра, погода и время суток случайны (начиная с 1.77 она ещё и меняется), и на большинстве из них присутствуют крупные разрушаемые объекты. Карты света и теней для них слишком сильно увеличили бы «вес» игры. War Thunder — онлайн-игра, которую пользователи скачивают из сети.
Несмотря на распространение широкополосного интернета, объём того, что должен скачать будущий игрок, пока ещё сильно влияет на конверсию его в игрока настоящего — чем он меньше, тем выше будет конверсия. Поэтому мы научили Dagor рассчитывать глобальное освещение в реальном времени для игровых карт любого размера.
Это не занимает место на диске, а картинка меняется соответственно окружающей действительности. Такая технология на данный момент не была реализована ни в одном проекте, а предоставляемые движками варианты динамического расчёта ограничены либо по дальности источников света, либо по производительности, либо в них не учитываются протяжённые источники света (например, небо), либо всё же требуют какой-то предрасчёт.
О добавлении новых технологий «впрок»
Я бы не советовал добавлять что-то, что не может использоваться в игре прямо сейчас. Пытаться предсказать будущее — неблагодарное занятие, и если ваш прогноз не оправдается, будет жаль потраченного времени. А вот добавлять технологии, которые работают уже сейчас, и в дальнейшем могут быть улучшены и доработаны, определённо стоит.
В числе прочих новинок версии 5.0 — рельефная детализация ландшафта с помощью алгоритма displacement-мэппинг. Он изменяет саму поверхность объекта, добавляя геометрические детали, в отличие от визуальной иллюзии объёма, создаваемой технологию parallax-mapping, которую раньше использовали в Dagor Engine.
Вдобавок к уже существующим картам (нормалей, транслюценции и цвету поверхности) добавились карты гладкости, карты затенения (ambient occlusion) и карта типов поверхности таких, как трава, камень и песок, которые увеличивают точность изображения и добавляют новый уровень детализации. Знакомые пейзажи теперь выглядят совершенно по-новому.
В будущем эту технологию можно будет менять и дорабатывать, что позволит добиться ещё большего разнообразия пейзажей и детализации поверхностей. Сама по себе технология далеко не новая, но как обычно, есть много нюансов: влияние на подвеску танка, воду и лужи; кроме того, технология для адекватной по скорости имплементации требует DirectX11 (а до 1.77 мы поддерживали Dx9 тоже).
О том, кому и зачем стоит создавать собственный движок
Может показаться, что собственный движок позволит свернуть горы. Он действительно даст команде больше свободы в добавлении в проект новых фич. Однако реализация необходимого минимума и интеграция новых технологий потребует времени. Сроки выпуска игры являются важным условием, ведь предсказать, что будет через два года, которые уйдут на создание своего движка и инструментов к нему — крайне сложно.
В большинстве случаев стоит отдать предпочтение готовым движкам. К тому же, если проект предполагает реалистичную графику и всевозможные эффекты, то много времени придется уделить оптимизации, поддерживаемому «железу», и исследованиям.
Исключением будут случаи, когда вы точно знаете, что своя технология сэкономит время или будет незначительной инвестицией времени в сравнении со своим проектом. Примерами могут стать стилизованные 2D-игры (с векторной или пиксельной графикой), многие «настольные» игры (особенно многопользовательские). Вы можете сделать их на Unity, и, возможно, это неплохой выбор, но вряд ли это даст значительную экономию времени, а свой движок сможет позволить сделать игру, например, быстрее.
Грубо говоря, если вы можете сказать: «Свой движок мы сделаем за два месяца, а игру на нём — за полгода-год», то вероятнее всего это имеет смысл. Максимум что вы потеряете — это два месяца.
Когда движок собственной разработки будет предпочтительным вариантом
Свой движок это не только свои фичи, но и контроль. Когда вы сами написали код, вы сможете легче и быстрее находить причины возникающих ошибок и устранять их. Этим, например, руководствовались разработчики платформера Super Meat Boy. Команда состояла всего из двух человек, но они смогли уложиться в 18 месяцев разработки.
Программист Томми Рефенс уверен, что им в этом помог именно собственный движок. Для дизайнера он сделал удобный инструмент для создания уровней, разработал Flash Exporter, который позволял быстро экспортировать звуки и анимации в одной операции, а возникающие ошибки быстро исправлял, так как представлял, где искать их причины.
Свой движок пригодится в случае работы с онлайн-проектами, которые требуют поддержки на протяжении нескольких лет. Онлайн-игры постоянно развиваются и меняются. Часть этих изменений вы не сможете предусмотреть заранее, потому что ещё нет каких-то технологий или «железа»; или пользователи захотят что-то, чего выбранный изначально движок не умеет. Переезд всего проекта на новый движок займёт время, за которое часть игроков, не дождавшихся желаемой фичи, может покинуть игру.
Если после всего прочитанного вы решили написать собственный движок — дерзайте! Этот процесс мало похож на привычную работу программиста в студии. Он поможет глубже разобраться в процессе разработки игр и точно откроет для вас что-то новое. И, конечно, построить с нуля систему, которая оживёт на ваших глазах. Это особое удовольствие!
Источник: DTF
