Знакомство. Часть 2. Системный подход к обучению геймдеву

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

Вспоминая, как в конце 1990-х надо было "доставать" программные продукты и туторы чуть ли из под полы, сегодня остается благодарить Всевышнего за развитый и дешевый интернет, а также большой выбор путей решения одной и той же задачи хоть в программировании, хоть в моделировании. Шутка ли: "движок" Unreal образца "нулевых", за который нужно было отдать несколько сот тысяч долларов, и не обладавший и сотой доли современного функционала, сейчас бесплатен и окружен "пачкой" других бесплатных программных продуктов (да-да, Блендер тоже бесплатный, за что спасибо тем же "Эпикам").

Итак, базисом обучения геймдеву послужили олдовые знания пакетов 3d-моделирования, что предопределило целевую функцию - создание трехмерной игры. А это, в свою очередь, предопределило выбор в пользу "движка" Unreal Engine 4. Вишенкой же на этом торте послужили блупринты: система нодового программирования, ибо погружаться в полноценное ООП со знаниями синтаксиса и морфологии С++ не хотелось (и не было бы времени).
И сразу купируя возможные возражения о неоптимальности разработки игры исключительно блупринтами парирую следующим образом: во-первых, после общения со спецами по движку и языку программирования пришло понимание, что для инди-проекта, в котором не будет множества хардкорных интеллектуальных систем вроде продвинутого AI, симуляции жизни и прочих прелестей ААА-проектов, вполне годная и даже более предпочтительная тема делать всё силами блупринтов; во-вторых, есть ряд проектов, уже выпущенных в "Стиме" которые вполне годно работают, не вызывая никаких отрицательных эмоций по поводу оптимизации и адекватности работы игры (из последнего примера: игра Gravulse, выпущенная нашим соотечественником).

Для создания годного контента было решено полностью освоить пайплайны разработки ассетов игры. Так, в случае наиболее важных и заметных 3d-моделей придерживаюсь комбинированного подхода: часть делается в упрощенном формате (в основном -- декорации, неигровые элементы), другая часть -- с полноценным ААА-пайплайном (концепт, сбор рефов, запекание нормалей с хайполи на лоуполи и т.п.). Это должно, с одной стороны, обеспечить хорошее качество картинки при экономии времени разработки игры в целом.

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

Системный подход в обучении геймдеву предполагает полноценное понимание всех аспектов работы любого игрового элемента. Например, в процессе создания модели "Хаммера" изначально не было представления, что из себя этот "Хаммер" должен представлять как игровая сущность. Если это декорация, то достаточно сделать модельку с PBR-материалами и экспортировать в "движок". Но если игрок им может управлять, то это уже предполагает соответствующую настройку уже на стадии 3d-моделирования, причем в зависимости от тех инструментов "движка", которыми он будет настраиваться (если это стандартный компонент транспорта, то надо его верно ориентировать по осям координат, сделать настройку колес; если это самодельный блюпринт, то стоит все движущиеся части экспортировать отдельно по частям с соблюдением пивотов).
На первый взгляд всё кажется запутанным и сложным, но при первых же опытах работы в Unreal Engine с экспортом несложных объектов (в моем случае это были бочки, дорожные пропсы), "баловством" с встроенной физикой приходит осознание, как и что должно быть в игре.

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

Еще до того, как узнал о возможности Unreal Engine автоматически настраивать LODы, постарался сделать это самостоятельно. Ничего сложного нет, но трудозатраты и затраты времени достаточно ощутимы. И здесь тоже большую часть можно отдать на откуп "движку", делая ручную оптимизацию только для самых важных моделей (персонаж, оружие, ключевые противники и пропсы).

Другой важной составляющей оптимизации является работа со светом и тенями. И здесь тоже можно всецело положиться на инструменты движка: крутилками/вертелками настраивая нужный вариант любого источника света.

Много памяти забирают PBR-материалы, так что стоит внимательно их использовать. Здесь на помощь приходят атласы, тримы на стадии текстурирования готовых моделей, а также создание и настройка материалов в самом "движке". Очень помогает переиспользование (реюз) готовых ассетов, но это тоже надо уметь правильно делать: одни и те же камни сразу бросаются в глаза, если они лежат одинаково недалеко друг от друга. Однако, работая с масштабированием, поворотами и комбинированием объектов, можно добиться потрясающих результатов.

Звуки и саундтреки в wav-формате вполне могут "скушать" оперативную память. Выход: переформатировать всё, что звучит в ogg-формат и стараться все обрезать на стадии монтажа. И, как в случае с ассетами, звуки тоже можно и нужно комбинировать, настраивать.

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