Доброго дня всем!
С момента анонса Backside прошло уже достаточно времени, но, достижениями мы делиться не спешили, как можно заметить по новостной ленте.
В первую очередь, это вызвано тем, что достижений-то особо и нет. Вернее, нет таких, которыми можно было бы громко и наглядно похвалиться. Однако, на месте мы не сидим, и командой было принято решение поделиться наработками. Ну что ж… Начнём.
Насколько вы можете помнить, мы анонсировали работу над Backside под Unreal Engine. Пожалуй, позволю себе некоторые технические подробности, которые рядовому пользователю могут быть не интересны, но, тем не менее, знакомство с нюансами движков *ЗА РАМКАМИ* селлер-фич и другого подобного маркетингового хлама, летящего тебе в лицо с каждым анонсом UE или Unity -
С момента анонса Backside прошло уже достаточно времени, но, достижениями мы делиться не спешили, как можно заметить по новостной ленте.
В первую очередь, это вызвано тем, что достижений-то особо и нет. Вернее, нет таких, которыми можно было бы громко и наглядно похвалиться. Однако, на месте мы не сидим, и командой было принято решение поделиться наработками. Ну что ж… Начнём.
Насколько вы можете помнить, мы анонсировали работу над Backside под Unreal Engine. Пожалуй, позволю себе некоторые технические подробности, которые рядовому пользователю могут быть не интересны, но, тем не менее, знакомство с нюансами движков *ЗА РАМКАМИ* селлер-фич и другого подобного маркетингового хлама, летящего тебе в лицо с каждым анонсом UE или Unity -
во-первых: составило значительную часть нашей работы на данный момент;
во-вторых: позволило и нам принять более взвешенное решение, и вам объяснит в чем же именно дело и почему так вышло.
во-вторых: позволило и нам принять более взвешенное решение, и вам объяснит в чем же именно дело и почему так вышло.
Итак, у УЕ (Unreal Engine) в преимуществах: наниты, люмен, значительно более красивый рендер из коробки и полнофункциональная система блюпринтов (Zero-coding так называемый). Уверен, что большинство из вас об этом слышали, но что это значит конкретно для нас и для любой другой инди команды, которая только начинает осваивать 3д игродел?
Основная полезность нанитов лично для нас – не в миллионах полигонов (что в общем-то дурной тон, и таковым останется еще достаточно долго, особенно учитывая что они не могут полноценно работать со skeletal мешами, а по сути – с любой костной анимацией), а в том, что они позволяют отказаться от использования LOD (level of detail – простым языком - разные модели для разного уровня детализации, когда деревья становятся плоскими вдалеке) моделей для окружения. В целом это потенциальная экономия до 20-30% времени работы над каждой моделью, по крайней мере для текущего уровня нашего художника. Это значительный вклад, и в целом, серьезный аргумент в пользу УЕ в нашем случае. Аналогичная ситуация с люменом, он позволяет полностью отказаться от использования лайтмап (карт освещения, для имитации более красивого освещения в игре, без лишней нагрузки на железо) и кропотливой работы со светом, теперь можно просто раскидать источники по сцене, чтобы добиться нужного эффекта, что, в целом, было бы весьма полезно и удобно для процедурной генерации. Обе эти технологии, конкретно нашей команде дают не «ультрасовременный АААА уровень графики» (с) и вот это вот всё, а значительный выигрыш по времени и трудозатратам, причем именно в области 3д графики, где у нас пока что просадка. Так что выбор очевиден… Вернее…
Основная полезность нанитов лично для нас – не в миллионах полигонов (что в общем-то дурной тон, и таковым останется еще достаточно долго, особенно учитывая что они не могут полноценно работать со skeletal мешами, а по сути – с любой костной анимацией), а в том, что они позволяют отказаться от использования LOD (level of detail – простым языком - разные модели для разного уровня детализации, когда деревья становятся плоскими вдалеке) моделей для окружения. В целом это потенциальная экономия до 20-30% времени работы над каждой моделью, по крайней мере для текущего уровня нашего художника. Это значительный вклад, и в целом, серьезный аргумент в пользу УЕ в нашем случае. Аналогичная ситуация с люменом, он позволяет полностью отказаться от использования лайтмап (карт освещения, для имитации более красивого освещения в игре, без лишней нагрузки на железо) и кропотливой работы со светом, теперь можно просто раскидать источники по сцене, чтобы добиться нужного эффекта, что, в целом, было бы весьма полезно и удобно для процедурной генерации. Обе эти технологии, конкретно нашей команде дают не «ультрасовременный АААА уровень графики» (с) и вот это вот всё, а значительный выигрыш по времени и трудозатратам, причем именно в области 3д графики, где у нас пока что просадка. Так что выбор очевиден… Вернее…
Нам так казалось. И вот почему:
Во-первых, несмотря на полноценный релиз 5й версии движка, на деле, УЕ5 всё еще находится в процессе разработки. Причем, чуть ли не по всем направлениям сразу. И это отвратительно. Слышать бы вам крики Тиэ, нашего художника, когда при переезде с 5.0 на 5.2 эпики просто выпилили старую систему ретаргета анимации (на разбирательство с которой тоже было потрачено время, кстати (если грубо, ретаргетинг - это функционал, позволяющий использовать анимации одной модельки на другой)) и перешли на
концепцию IK-chains для ретаргета, которая способна решать эти задачи, но по-другому. И осваивать её нужно заново, то и дело натыкаясь на подводные камни, в новой для себя системе, по которой еще и инфы толком нет.
концепцию IK-chains для ретаргета, которая способна решать эти задачи, но по-другому. И осваивать её нужно заново, то и дело натыкаясь на подводные камни, в новой для себя системе, по которой еще и инфы толком нет.
И раз уж речь зашла об анимациях и скелете, нам в высшей степени не понравилась общая идеология работы со скелетами в анриле. Фактически, для УЕ это полностью уникальная сущность со своими правилами, законами, ограничениями и зависимостями. И вроде бы всё ничего, но если вам вдруг понадобится изменить длину бедер, например, или размер любой другой кости, то это делается достаточно костыльным методом, причем КАЖДЫЙ КАДР. Вы перехватываете аниматор, и на КАЖДЫЙ кадр анимации вносите корректировки в размер и положение костей. Что в общем-то само по себе тоже не так страшно, но анекдот в том, что ИК (Инверсная кинематика - в общем смысле то, что позволяет выставлять ноги на неровной поверхности как надо, и попадать, например, анимацией подбора предмета в сам предмет, вне зависимости
от его положения, и, само собой, попадать выступающими частями тела в нужные отверстия, когда присутствует разница в росте, и т.п.) подгонка в это время работает в немного другом месте и относительно независимо. Понимаете, да, в чем дело? В дополнение - в последней версии анрила, которую мы трогали – система ИК была внедрена в новом формате, свой full-body IK, который тоже новая система и её надо отдельно изучать. И, если честно, так везде, куда не ткнись: от версии к версии пропадают, появляются или переименовываются ноды, исчезают или перемещаются переключатели в интерфейсе, какие-то функции редактора. И в целом сейчас УЕ содержит в себе хвосты чуть ли не двадцатилетней давности – независимые и невзаимозаменяемые сущности с
разными параметрами и полностью самостоятельные. И тут же рядом с ними внедряются абсолютно новые системы и идеи, с которыми тоже фиг знает, как работать.
от его положения, и, само собой, попадать выступающими частями тела в нужные отверстия, когда присутствует разница в росте, и т.п.) подгонка в это время работает в немного другом месте и относительно независимо. Понимаете, да, в чем дело? В дополнение - в последней версии анрила, которую мы трогали – система ИК была внедрена в новом формате, свой full-body IK, который тоже новая система и её надо отдельно изучать. И, если честно, так везде, куда не ткнись: от версии к версии пропадают, появляются или переименовываются ноды, исчезают или перемещаются переключатели в интерфейсе, какие-то функции редактора. И в целом сейчас УЕ содержит в себе хвосты чуть ли не двадцатилетней давности – независимые и невзаимозаменяемые сущности с
разными параметрами и полностью самостоятельные. И тут же рядом с ними внедряются абсолютно новые системы и идеи, с которыми тоже фиг знает, как работать.
Помимо прочего, анрил сосредоточен на удобстве левел билдинга, и других сопутствующих плюшках, и частенько можно услышать, что это движок для дизайнеров (в более общем смысле). Да чего уж там, у них в принципе одна из основных веток развития это HD визуализация. Синематики, промо и вот это вот всё. И это не плохо, но из этого следуют некоторые трудности. Нынешний анрил из коробки имеет огромное множество удобных инструментов и фич для работы с предетерменированным левел билдингом и геймдизом. (Вот тут ставим ручками камень, вот тут ставим конкретного персонажа, а тут лампочку, и т.д.) НО!
В нашем проекте огромный упор делается на генерацию именно во время работы игры (в рантайме), будь это собирание самого осколка из условных тайлов, или собирание НПС путем модификации его костей, чтобы из одного базового скелета получить мужчину, женщину, дварфа и лолю. И вот эта сторона в анриле на данный момент поддерживается откровенно слабо. Всё, что может потребоваться для решения задач, выходящих за рамки простого билдинга игры из набора ассетов, на деле – решается самостоятельным исследованием и самописным кодом, причем, зачастую, вслепую, ибо ассеты у анрила закрытые, а те, кто работают с движком на высоком уровне (читай серьезные команды) - не спешат делиться своими наработками, что в целом понятно.
Так что после трех месяцев мытарств мы решили для проверки попытаться пройти такой же путь на Unity, и о чудо:
Универсальные сущности, функционал которых реализуется через компоненты (которые просто дополнительные параметры, накидывающиеся на те же самые сущности). Для примера – Юне глубоко пофиг, масштабируешь ты условный камень, или условную руку персонажа, для неё это сущности одного порядка, и работает она с ними соответственно.
Свободный доступ к генерации и кастомизации в рантайме, опять же, начиная от полного искажения скелетов персонажей (как, например, в PlayHome,
или CustomMaid3D), и до чего угодно, что мы вообще способны придумать.
Огромнейший пул обучающего материала, и готовых решений, из которых (за счет открытости) можно делать собственные выводы и находить решения для наших задач.
или CustomMaid3D), и до чего угодно, что мы вообще способны придумать.
Огромнейший пул обучающего материала, и готовых решений, из которых (за счет открытости) можно делать собственные выводы и находить решения для наших задач.
Удобная система взаимодействия с анимациями и их корректировкой, опять же, прямо на ходу, да и в целом тот же ретаргетинг (Юне глубоко параллельно какой там скелет у модельки, она использует собственную надстройку, аватар, и если ты указал, что это гуманоид и вот это гуманоид - то и двигать по гуманоидным анимациям она их будет одинаково. Ну просто потому, что люди так или иначе гнутся в одинаковых местах, не бывает двух локтей на одной руке и т.п.).
Да даже отсутствие бинарников в коде проекта позволяет гораздо удобнее работать с гитхабом, вызывая гораздо меньше конфликтов при параллельном изменении файлов.
В общем, для конкретно *нашей* задачи, и конкретно *в нашей* же ситуации, Юня оказалась гораздо более удобным инструментом, чем УЕ. Не буду перечислять ВСЕ плюсы, которые она предоставляет, но они есть и кроме вышеозвученных (например, гораздо более низкие системные требования к машине конечного пользователя, ибо наниты и люмен хотят обязательный ссд, DX12 и версию винды не ниже 20H2).
Но, не обходится и без минусов, само собой.
Во-первых, результат рендера юни «из коробки» нам не нравится от слова совсем, и тут еще предстоит очень сильно заколебаться, разбираясь, а как же всё-таки получить тот визуал, который хочется. Например, universal render pipeline (URP, тот тип рендера что мы сейчас используем в проекте) не умеет в подповерхностное рассеивание (если грубо, это эффект свечения кожи на просвет) по умолчанию, и для этого надо писать свой шейдер, который при этом, будет учитывать еще и общее количество требований к редактору персонажа, таких как кастомизация татуировок, макияжа и т.п.
Во-первых, результат рендера юни «из коробки» нам не нравится от слова совсем, и тут еще предстоит очень сильно заколебаться, разбираясь, а как же всё-таки получить тот визуал, который хочется. Например, universal render pipeline (URP, тот тип рендера что мы сейчас используем в проекте) не умеет в подповерхностное рассеивание (если грубо, это эффект свечения кожи на просвет) по умолчанию, и для этого надо писать свой шейдер, который при этом, будет учитывать еще и общее количество требований к редактору персонажа, таких как кастомизация татуировок, макияжа и т.п.
В противовес анрилу – LOD для моделек всё-таки придется делать ручками, и еще предстоит куча возни с лайтмапами, что становится особенной задачей для генерируемого окружения. Так же возникают вопросы оптимизации, ибо окклюжен (удаление объектов вне поля зрения) для недетерменированного уровня, тоже не просто галочка в инспекторе (подвижки и решения в этом направлении есть, ничего невозможно, но сложнее, чем казалось на первый взгляд). Однако, тут перевешивает количество доступных обучающих материалов. В целом для любого затыка, который у нас возникал, решение находилось за два-три вечера, в отличие от УЕ, с проблемами которого мы
бились иногда неделями.
бились иногда неделями.
В конкретные технические вопросы и проблемы вдаваться не вижу смысла, но в целом, нам оказалось гораздо удобнее работать с юней, так что да, Backside переезжает на Unity (Правда вы могли узнать об этом еще из обзора на Демона
Охотника от Мистера Маффина).
Охотника от Мистера Маффина).
Теперь, собственно, о том, что же мы сделали. Наш программист M1kEk1M написал систему генерации осколков из больших гексов, которая позволяет нам не только рандомно натыкать разноцветных тайлов, но и управлять взаимозависимостями между ними (например, что возле деревни есть поля, башня эльфов всегда находится в лесу и на таком-то расстоянии от деревни и т.п.)
И сейчас ведет работу над контроллером персонажа. К нему у нас очень высокие требования, хочется, чтобы персонаж управлялся удобно и отзывчиво, но при этом живо, чтобы от боя был импакт. И для этого требуется учесть множество нюансов, начиная от хитлага (реакция анимации на попадание) и
заканчивая инпут буффером. Наконец-то началась работа над полноценным диздоком, куда мы потихоньку стягиваем все наши идеи, наброски и таблицы из кучи других мест, куда их раскидывали раньше. Окончательно определен приоритет систем друг над другом, что для нас первоочередная цель, а что – дополнительная, что от чего должно зависеть для создания нужного впечатления, и в каких местах мы готовы пойти на уступки, а в каких нет. И да, главным приоритетом стал мир. Жители осколков должны сами добывать себе еду, реагировать на происходящее, и распространять слухи. Причем ключевой целью лично для меня, как тимлида является не «создание вида деятельности» (как в том же Скайриме, где НПС готов полдня рубить дрова, чтобы в его трупе не оказалось в итоге ни дров, ни топора), а полноценная симуляция этой деятельности. Что-то уровня Кенши или Римворлд, для примера. Когда поселенец делает то, для чего имеет инструменты, локацию и цель. У нас уже есть схема психики, отвечающей за реакции на действия игрока, и, скажу вам, выглядит это крайне многообещающе, хотя, вероятно, при дальнейшем её расширении придется выкатывать пошаговый прототип для тестов. Так
что подробнее узнаете позже.
заканчивая инпут буффером. Наконец-то началась работа над полноценным диздоком, куда мы потихоньку стягиваем все наши идеи, наброски и таблицы из кучи других мест, куда их раскидывали раньше. Окончательно определен приоритет систем друг над другом, что для нас первоочередная цель, а что – дополнительная, что от чего должно зависеть для создания нужного впечатления, и в каких местах мы готовы пойти на уступки, а в каких нет. И да, главным приоритетом стал мир. Жители осколков должны сами добывать себе еду, реагировать на происходящее, и распространять слухи. Причем ключевой целью лично для меня, как тимлида является не «создание вида деятельности» (как в том же Скайриме, где НПС готов полдня рубить дрова, чтобы в его трупе не оказалось в итоге ни дров, ни топора), а полноценная симуляция этой деятельности. Что-то уровня Кенши или Римворлд, для примера. Когда поселенец делает то, для чего имеет инструменты, локацию и цель. У нас уже есть схема психики, отвечающей за реакции на действия игрока, и, скажу вам, выглядит это крайне многообещающе, хотя, вероятно, при дальнейшем её расширении придется выкатывать пошаговый прототип для тестов. Так
что подробнее узнаете позже.
Так же, мы определились с системой прогрессии и прокачки персонажа - прокачиваться будут те характеристики, которые игрок использует, никакого опыта и уровней. Однако, существует предел, до которого можно прокачать характеристику самостоятельно. Для дальнейшего прогресса придется исследовать мир и искать учителей и тренеров. Помимо этого, так же есть ветка так называемой «сквозной прогрессии», которая в целом отражает степень крутости вашего персонажа, или, скорее даже, общий этап игры на котором он сейчас находится, от бомжа до полубога (или даже полноценного бога), и она не будет зависеть от характеристик героя.
Еще мы за это время определились с боевой системой. Поскольку мы достаточно отчетливо понимаем объем предстоящей работы (особенно в плане анимаций, если делать отдельные для каждой руки), но интересную и разнообразную боёвку хочется - бой будет построен на использовании
комплектов оружия. Например – топор и щит, это полный класс оружия, со своими стилями (изучаемыми как раз у мастеров) стойками и предсказуемыми для игрока реакциями на нажатия кнопок (для примера ПКМ – блок, ЛКМ – удар, зажатие ЛКМ – тяжелый удар, однако правильная по времени последовательность действий образует комбо, часть которого может быть защитной, а часть атакующей), но при этом что щит, что топор – независимые предметы и экипируются не комплектом, и игрок может, оставив старый щит, взять в руки другой топор, покруче. В остальном – бой в каком-то смысле ближе к соулслайкам, а конкретнее: расход выносливости на действия и непрерываемые анимации (так что игрок должен думать, что делать, а
не просто спамить атаки и уворачиваться на реакции), игрок быстро умирает и
быстро убивает (чтобы опять же, не превращать любую стычку в закликивание).
комплектов оружия. Например – топор и щит, это полный класс оружия, со своими стилями (изучаемыми как раз у мастеров) стойками и предсказуемыми для игрока реакциями на нажатия кнопок (для примера ПКМ – блок, ЛКМ – удар, зажатие ЛКМ – тяжелый удар, однако правильная по времени последовательность действий образует комбо, часть которого может быть защитной, а часть атакующей), но при этом что щит, что топор – независимые предметы и экипируются не комплектом, и игрок может, оставив старый щит, взять в руки другой топор, покруче. В остальном – бой в каком-то смысле ближе к соулслайкам, а конкретнее: расход выносливости на действия и непрерываемые анимации (так что игрок должен думать, что делать, а
не просто спамить атаки и уворачиваться на реакции), игрок быстро умирает и
быстро убивает (чтобы опять же, не превращать любую стычку в закликивание).
Важным элементом боя является и грамотное управление союзниками в бою. Кто-то может отвлечь на себя противника, кто-то стрелять издалека и т.п. (Для этого, кстати, мы пришли к концепции колеса команд и ограниченного количества спутников, так что каждому можно будет непосредственно во время боя отдать конкретную команду или изменить её, а не настраивать «формат поведения»). Максимальное количество спутников определится по результатам тестирования модели управления, когда она будет более или менее готова.
В более техническом плане, в самой Unity подготовили
базу для редактора персонажа – переключение каблуки/не каблуки для одной и той же модели (то есть с сохранением непрерывности текстуры чулков, например, цвета кожи без швов и т.д.), размеры груди и других интересных частей тела, смена макияжа, одежды и других штук, так чтобы это выглядело бесшовно и не вызывало клиппинга (проваливания юбки в задницу, например). Разобрались как Юня работает с IK и результат нас более чем удовлетворил.
базу для редактора персонажа – переключение каблуки/не каблуки для одной и той же модели (то есть с сохранением непрерывности текстуры чулков, например, цвета кожи без швов и т.д.), размеры груди и других интересных частей тела, смена макияжа, одежды и других штук, так чтобы это выглядело бесшовно и не вызывало клиппинга (проваливания юбки в задницу, например). Разобрались как Юня работает с IK и результат нас более чем удовлетворил.
Как вывод – ведется активная препродакшн работа. Ещё раз повторюсь, мы прекрасно, *ПРЕКРАСНО* понимаем масштаб проекта и своих амбиций по его поводу, и именно поэтому сейчас всё происходит именно так. Планирование, схематика, освоение инструментария. Да, это занимает крайне много времени, с вашей точки зрения так тем более, но, прошу понять и простить. В потенциале - грамотно построенная сейчас база сэкономит нам в разы больше времени в будущем, исключив переделки и атавизмы, набросанные когда-то давно или то, что игра на определенном этапе рассыпется и придется начинать почти с нуля. Подход из разряда «Ща запилю по-быстрому, чтобы показать, а потом уже сделаем нормально» - не наш выбор.
Да, полотно вышло немаленькое, но мы решили более подробно рассказать вам, что происходит и почему так долго. Надеемся, что нам это удалось. Огромное спасибо всем вам за поддержку, и то, что остаетесь с нами на этом непростом пути! Очень приятно, когда твоя работа и твоё творчество кому-то интересны и важны. Всем добра и до связи.
Удачи вам.