О процессе оптимизации игр для разных устройств

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

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

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

Сразу предупреждаю, что я занимался разработкой игр только под ПК и Android, так что я плохо знаком со спецификой других платформ. Но моё образование и специальность позволяют мне корректно оценивать, какие принципы можно экстраполировать, а какие нет.

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

Оптимизация — процесс бесконечный, нет предела совершенству и нет идеальных систем. Потому в хороших конторах оптимизацией в широком смысле начинают заниматься ещё на начальном этапе производства, когда только задумывают игру.

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

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

Впрочем, это всё общие вопросы. Основная работа по оптимизации начинается во время разработки игры. И вот тут есть три подхода к разработке:

Все эти подходы не взаимоисключают друг друга, решения принимаются отдельно по каждой механике и каждому арт-объекту: например, модели могут делать сразу с оптимизацией (требования к ним известны заранее), а проблемы с игровыми механиками откладываются на потом, когда их можно будет протестировать в «боевых» условиях. И у каждого из этих подходов есть не только минусы, но и, как не удивительно, плюсы.

Чем раньше вы начнёте заниматься оптимизацией — тем проще таковая обойдётся разработчикам, поскольку не придётся переключаться между задачами и возвращаться к ним несколько раз. Грубо говоря, быстрее сходить в магазин один раз и купить всё нужное сразу, чем ходить туда несколько раз и закупаться по частям. Ещё это полезно, потому что код на ранних этапах разработки ещё очень гибкий и его легко исправить, в процессе не поломав всё остальное.

С другой стороны, слишком ранняя оптимизация может оказаться лишней. Например, ту модель, которую художник несколько дней оптимизировал до последнего полигончика, в итоге не одобрят и придётся потом переделывать или она вообще может не войти в игру. Либо же, игра сама по себе настолько не притязательна к графике, что нет смысла оптимизировать модели до самого конца и любая детализация пойдёт. А может у вашей игры с самого начала была провальная концепция и дополнительной полировкой вы просто потратили человеко-часы в никуда. Чем позже вы начнёте оптимизацию, тем меньше сил будет потрачено впустую.

Хочу, чтобы вы понимали: нет какого-то шаблона, по которому можно следовать, чтобы избавить себя от проблем. Иначе неоптимизированных игр просто бы не существовало.

Оптимизация — это всегда поиск баланса между двумя противоположностями, каждая из которых работает только в конкретных случаях. Где-то подойдёт одно решение, где-то противоположное. Эти противоположности я и перечислю:

Игры — это в том числе программы, которые постоянно проводят вычисления. Вычисления эти могут быть разными: физика, графика, ИИ, звук, генерация локаций и прочее.

При желании, конечно можно всю игру генерировать в реальном времени, но вообще чем комплекснее задумки авторов — тем больше приходится тратить на них процессорных мощностей, и не всем игрокам эти мощности доступны. В некоторых (не во всех) случаях можно сохранить вычисления заранее (это называется «запечь» или «bake») и использовать их позднее. Например, запечь освещение в текстуры, сохранить результаты столкновений и повреждений в анимационных клипах, составить модели поведения, сделать пререндер катсцен и прочее. Запекание обеспечит максимальное качество при минимальных требованиях к мощностям.

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

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

В эту область входят и различные игровые движки (Unity, Unreal Engine, CryEngine), и инструменты для арт-отдела (Blender, Houdini, Substance Painter), и физические подсистемы (PhysX, Havok, Box2D), и графические технологии (рейтрейсинг, постпроцессинг, тесселяция), и различные библиотеки для сетевых взаимодействий, сбора аналитики, устройств управления, звукового сопровождения, хранения внутриигровых данных и так далее, далее, далее.

Поскольку это быстроразвивающийся бизнес, в этой сфере много конкурирующих продуктов, и отличаются они не только соотношением «цена» — «качество», но и внутренним устройством и списком возможностей.

И, скажем честно, эти инструменты улучшают жизнь больше игрокам, чем разработчикам. Эти технологии хоть и подают себя как «продукт, готовый к использованию», на деле это каша из большого количества различных не очень стабильных разработок, пытающихся одинаково удовлетворить потребности как можно большего количества клиентов.

В этих технологиях часто достаточно багов, неактуальное API, а требуют они к себе максимально бережного отношения, чтобы те не поломались в критический момент, если вы соберётесь сделать что-то нестандартное. Под них приходится специально подстраивать игру, а большинство возможностей из коробки никогда не используются и остаются мёртвым грузом на мощностях. Для их эффективного использования нужно повышать свою квалификацию. А ещё инструменты могут устареть, отчего вы больше не сможете осуществлять их поддержку, поскольку не вы — разработчик технологии.

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

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

Для начала, интересная корреляция: чем быстрее программы, написанные на языке, тем сложнее им пользоваться. Python может выучить любой желающий, С++ до сих пор остаётся одним из самых сложных для понимания среди С-подобных языков, в то же время по некоторым тестам разница в производительности между ними отличается в 80 раз в пользу второго.

Если говорить о программах, то программистам приходится выбирать между производительностью и стабильностью. Например, различные проверки корректности входящих данных (самая частая — проверка на null) и обработчики исключений могут занимать вплоть до нескольких процентов мощностей, 99% времени они излишни. В то же время, без этих проверок программисту намного труднее найти и исправить потенциальную ошибку.

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

Это уж я не говорю о различных хаках (в том числе ассемблерных) и тяжёлых математических алгоритмах, заметно ускоряющих игру, но превращающих код в нечитаемый набор букв.

Ну и самое главное: если вы разрабатываете игру, ваше время крайне ограничено. У вас нет времени писать её несколько лет в свободном темпе, индустрия слишком быстро растёт и игры слишком быстро перестают быть актуальными.

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

Поэтому у вас нет возможности оптимизировать в игре всё, придётся сделать ставку на ограниченное количество подсистем. Каждая подсистема может дать прирост в свободных мощностях, причём заранее неизвестно, какой (впрочем, опыт и знание информатики тут отлично помогают). Так что окажется ли ставка успешной — покажет только время.

Оптимизация, как вы уже поняли, затрагивает все компоненты игры. Хотя все эти компоненты неразрывно связаны, условно их можно поделить на следующие группы:

Тут всё понятно: в игре есть разные виды ассетов, как например текстуры, модели, звуки, анимации, и чем меньше они по объёму — тем быстрее компьютер будет их обрабатывать (в первую очередь тут имеется в виду скорость загрузки ассетов в память и на игровой уровень).

Схитрить через программный код тут особо не получится: контроль ресурсов полностью на стороне движка и железа. Поэтому кроме как уменьшать объём ассетов и многократно их переиспользовать, выхода особого и нет. Не требовать же поголовного использования SSD?

Создавать сами ассеты не очень тяжело, особенно сейчас: есть очень много удобных инструментов создания ассетов для любых задач, даже бесплатных. Однако эти инструменты очень расточительны. На примере 3D-моделей, легко слепить модель с помощью скульптора и автоматически сгенерировать для неё текстурную UV-развёртку, но в ней будут тысячи лишних (мало влияющих на качество отображения) точек, а процент используемого развёрткой пространства будет в районе 40-60%, что потребует использования текстур более высокого разрешения.

Процесс оптимизации ассетов заключается в исследовании ассетов на предмет неэффективно занимаемого места и устранении этих мест. Где-то это устранение дубликатов с помощью создания одного универсального ассета или генератора, где-то это сжатие или удаление того, что точно никто не увидит вблизи, где-то это объединение разных сущностей в одну универсальную.

Намеренно не пишу «код», потому что чаще всего дело не в коде, если вы его, конечно, более-менее умеете писать. Но оптимизация кода тоже входит в этот пункт.

Современные игровые движки бережно поделены на независимые друг от друга компоненты, как например физика, графика, менеджмент объектов, воспроизведение звука, вспомогательные алгоритмы для интеллектуальных агентов и прочее. Код этих компонентов зачастую уже оптимизированы донельзя и содержат внутри себя огромное количество настроек, влияющих на их использование и в том числе на расход мощностей. Работа игрового программиста — правильно настроить эти компоненты.

Например, если у нас тысячи физических объектов, можно поделить их на группы (слои), объекты в которых будут взаимодействовать только с соседями по группе. Если у нас тысячи объектов с одинаковыми моделью и материалов, можно включить для них батчинг, чтобы те не перезагружались в памяти при каждой новой отрисовке. Если у нас много однотипных пересоздаваемых объектов (например снаряды), можно их все создать единожды заранее и переиспользовать, а нагружать систему постоянными созданием и удалением объектов в реальном времени.

Инструменты для всего этого уже доступны, писать почти ничего не надо (но иногда надо, да). В тех случаях, когда нужно создавать новые игровые подсистемы, уже вступает в дело полноценный код — и вот тут стоит быть осторожнее. Задача программиста тут заключается в поиске многократно повторяющихся с одним результатом вычислений. Либо результаты этих вычислений кешируются, если они полезны, либо эти вычисления устраняются, если их результат бесполезен.

Для начала, можно поискать задачи, которые не требуют выполнения в каждом кадре, а, например, достаточно одного раза в секунду, как проверка доступности сети. Если у нас алгоритмы поиска (пусть будет поиск пути), мы можем добавить упрощений, которые будут заранее сужать пространство перебора. Где-то можно понизить точность вычислений. Для каждой задачи свои решения.

Ещё один важный компонент, тоже лежащий в поле обязанностей программиста, это грамотная работа с комплектующими устройства.

Создатели комплектующих тоже не зря едят свой хлеб и постоянно встраивают в устройства какие-то супер-технологии, которые потенциально могут использовать разработчики игр. И действительно, зачем скурпулёзно оптмимизировать тысячи ассетов, если можно решить проблему динамическим разрешение игры и использовав программный апскейл?

Работа с комплектующими одновременно проще и сложнее, чем оптимизация кода. Сложнее, потому что требует дополнительного изучения специфики устройств и технологий (а этому никто нигде нормально не учит — прогресс слишком стремительный). Легче, потому что один раз настроил и забыл.

Такие технологии ранжируются по доступности. Какие-то из них доступны только на ограниченном наборе комплектующих. Какие-то — уже общепринятый стандарт. Какие-то применяются на уровне драйверов. А какие-то можно использовать только при ручной настройке и многократных консультациях с разработчиками комплектующих.

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

Если у вас нет времени и средств на оптимизацию, всегда можно воспользоваться старым добрым «вырежем из игры» или «упростим». Пожалуй, это — самый лёгкий и доступный способ оптимизации игр.

Не стоит думать, что упрощение дизайна — это вредный и ленивый метод. Все разработчики игр пользуются им в той или иной степени, потому что фантазия геймдизайнеров воистину неукротима и где-то сказать себе «стоп» всё же придётся. Планы на игру обязаны соотноситься с возможностями команды, а на этапе планирования игры крайне сложно всё предусмотреть.

Какие-то механики можно заменить на альтернативные, если они требуют слишком большой работы. От создания каких-то ассетов можно отказаться. Уменьшить количество уровней и их разнообразие. Под оптимизацию может пойти всё.

Как и любая деятельность, оптимизация стоит недёшево. И над ней тоже можно схалтурить. Давайте обсудим, сколько это стоит.

Главная цель оптимизации — сделать так, чтобы игра стабильно работала. И интересы игроков в этой формуле находятся в странной суперпозиции. С одной стороны, стабильность игрового процесса нужна прежде всего игроку, который платит за продукт и волнуется за его качество. С другой стороны, ничто в игре не застраховано от оптимизации и в конечном счёте урезание игры вредит игровому процессу и опыту игрока.

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

Так, игровые ресурсы можно сжимать автоматическими утилитами, ухудшая их качество. Игре это поможет, а вот игроку будет не очень приятно. Код можно чинить «костылями», то есть решать проблемы не комплексно, а мелкими затычками, которые могут и будут порождать новые баги в отличных от задуманных игровых условиях. Технологии можно вставлять как попало, из-за чего они будут легко ломаться (и ломать следом всю игру), стоит запустить игру на непредусмотренном оборудовании.

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

На примере обработки игрой 3D-моделей, все волшебные хаки, которые бы экономили на отрисовках десятки процентов мощностей, как например куллинг и батчинг, уже давно интегрированы в движок и включаются одной галочкой. Если этого не хватило, придётся улучшать модели, тратя на каждую по несколько суток, но получив по 1-2% прироста мощностей на каждой. И то же самое со всеми остальными игровыми компонентами.

Однако оптимизация в конце концов творит чудеса и я верю в то, что любую современную игру при некоторых ухищрениях и ограничениях можно было бы запустить даже на PS3, дав разработчикам достаточно времени на оптимизацию. Но в этом нет смысла: зачем тратить сотни тысяч долларов на оптимизацию игры для платформ десятилетней давности, если и таких платформ на руках осталось мало, и их пользователей вряд ли интересуют новинки?

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

Если конкретный разработчик не работает по конвеерному принципу, клепая по продолжению каждый год, каждую новую игру ему приходится писать с нуля и для каждой заново проводить процесс оптимизации. Разработчики работают в коммерческом секторе, а не в научном, и серьёзными наработками почти не делятся (хотя бы потому, что эти наработки чаще всего не приспособлены к продаже). Такие тяжёлые компоненты для игр, как например ИИ, всегда приходится делать самим. Осуждать кого-то, что 20 лет назад в какой-то чужой игре всё было сделано на порядок лучше, смысла не имеет.

Надо ещё понимать, что процесс оптимизации — не из самых приятных. Это крайне монотонная и скучная работа, которую можно сравнить с уборкой помещения. И чем больше ей заниматься, тем менее выгодной для разработчика она становится: каждая следующая оптимизация длиться дольше, но эффект даёт меньше. Люди идут в игровую индустрию всё же творить, а не подчищать косяки. Любые сэкономленные мощности в итоге всё равно отправятся в работу на новые фантазии авторов.

Разработчики игр для консолей могут рассчитывать на технологии, доступные на этой консоли. Более того, их бодро к этому подталкивают, а если это внутренняя студия, то ещё предоставляют консультации по их внедрению. Само оборудование тоже тщательно исследовано вдоль и поперёк, известны его сильные и слабые стороны и как их эффективно использовать.

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

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

Тут двоякая ситуация. При прочих равных тяжелее, потому что намного больше конфигураций железа, на которых что-нибудь может поломаться или не хватить мощностей по самым разным причинам. Но жизнь всё таки немного сложнее.

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

Во-вторых, у консолей закрытая экосистема, поэтому если появились какие-то проблемы — тут придётся курить мануалы или общаться со специалистами из других игровых студий. Специалистов по ПК же миллионы и почти на любой вопрос можно найти ответ в поисковике за минуту.

В-третьих, для игр на консолях всё таки присутствуют стандарты качества, выставленные компанией-разработчиком консолей. Если ты не оптимизировал игру для консолей (а это сразу будет видно) — это твоя вина. С другой стороны, пользователи ПК любой косяк будут валить на своё железо и при необходимости, пусть и сквозь слёзы, но пойдут его обновлять. К багам и проблемам с оптимизацией они тоже относятся более терпимо.

Поэтому всё зависит от того, кто ваш работодатель, какой у вас бюджет и какой с вас спрос.

Начнём с того, что разные платформы типа ПК, консолей и смартфонов сильно различаются по архитектуре, ведь формат устройства диктует его внутреннюю архитектуру. Для ПК важна сборность и кастомизируемость, для телефонов и портативных консолей — время работы без подзарядки, а для стационарных консолей — максимальная производительность при минимальной цене.

Дело даже не в мощностях, дело во взаимосвязи компонентов и их возможностях. Это как сравнивать автомобиль и байк: оба вроде бы ездят на топливном двигателе и примерно на тех же скоростях, но устроены совершенно по-разному. Я не буду тут долго распространяться об этом, потому что я плохо разбираюсь в конкретике. Но просто скажу, что даже просто запустить программу для одной платформы на другой — уже нетривиальная задача, которая может потрепать много нервов.

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

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

Впрочем, если игру получилось успешно запустить на всех платформах, то дальше дело пойдёт намного проще, хоть и есть различия, зависящие от жанра и класса игры. Платформер с пиксельной графикой оптимизировать чаще всего вообще не надо, он и так работает отлично в виду отсутствия высокополигональных моделей и сложных графических эффектов. С сетевыми играми проблем больше, но наработок в этом деле достаточно, больших проблем возникнуть не должно. Если же это ААА-проект на грани возможностей устройства, портирование игры может занять столько же времени, сколько и её разработка.

По сравнению с кроссплатформой, платформа одна и та же, поэтому проблем должно быть меньше. Но для каждой конфигурации (точнее, семейства конфигураций — никто не будет перебирать десятки тысяч вариантов) игру всё равно придётся конфигурировать отдельно.

Во-первых, не все такие умелые геймеры и могут правильно подобрать себе настройки графики. Подавляющее большинство просто запускает игру и сразу жмёт кнопку «Начать». И если игра к этому не будет готова — виноватым окажется разработчик.

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

В-третьих, на всех обещанных спецификациях игра обязана стабильно работать, иначе придётся возвращать деньги. Так что неправильно выставленные минимальные требования могут изрядно потрепать вам нервы.

На ранних этапах разработки — механики. Одна единственная конкретная механика — не такая уж и требовательная штука. Но чем их больше — тем меньше ресурсов распределяется по ним как масло по хлебу тонким слоем. Механики — обособленные друг от друга единицы, у каждой из них свой массив кода и свой набор ресурсов, они почти не пересекаются и оптимизация каждой из них не влияет на остальные. А ещё механики должны быть согласованы между собой, это требует ещё больших усилий.

Если не могут вырезать механику, режут её широту. Если это езда на авто, упрощают физику авто и ограничивают места, в которые можно заехать. Если это боёвка, режут разнообразие атак. Если это NPC, ограничивают количество их действий, чтобы они например только ходили по округе и ни на что не реагировали.

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

А действительно ли эти игры не самые передовые? Решает не только качество, но и количество. Возможно, в игре большие и просторные локации, много графических эффектов или сущностей, десятки ожидающих использования механик или же она использует в фоне какие-то специфические вычислительные алгоритмы. Взять тот же Minecraft: вроде бы такая непритязательная к графике игра на самом деле постоянно хранит в памяти и обрабатывает десятки тысяч сущностей.

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

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

#лонг #оптимизация #разработка