3Д-движки. Как создают вселенные в видеоиграх

Либо-либо. Всем привет! Меня зовут Самат Галимов и это подкаст «Запуск завтра». Как технический директор я пытаюсь разобраться, как устроены сложные и интересные штуки. Я зову профессионала, с которым можно поговорить простым человеческим языком. Сегодня мы будем говорить о видеоиграх, а точнее, о игровых движках. Вы наверняка играли или хотя бы слышали о последних популярных видеоиграх, например Last of Us, по мотивам которой сняли одноименный сериал на HBO и он стал одним из самых популярных в истории HBO. Red Dead Redemption примерно года полтора-два назад. Все игры строятся на каком-то игровом движке. Сегодня мы разберемся, какие возможности игровые движки предоставляют создателям игр и с какими трудностями сталкиваются люди, которые программируют такие движки. Поговорим мы об этом с человеком, который занимается разработкой игрового движка для одной из самых популярных игр на планете. Это подкаст студии Либо-Либо. И сделали мы его совместно с сервисом онлайн-образования Яндекс.Практикум. У Практикума есть курсы по разработке, по анализу данных и по английскому языку. А на эту черную пятницу Практикум дарит 20% скидку на все курсы в рассрочку или в кредит. Условие одно. Нужно пройти бесплатную вводную часть курса до 30 ноября. И ещё, Яндекс.Практикум не отстаёт от последних трендов и у них появился ИИ-помощник. Яндекс.GPT будет на связи днём и ночью и поможет объяснить простыми словами задания или сложные термины. В общем, поможет вам в обучении. Все ссылки в описании к этому эпизоду.

Привет, меня зовут Денис, я программист графики.

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

Вопрос, конечно, сложный. Тут смотри, как рисуется картинка в фильмах. Там есть неограниченное время. Мы каждый кадр генерим оффлайн. Мы можем, допустим, потратить сутки на то, чтобы сгенерить кадр, вылезать его, там будет у тебя супер реалистичное освещение. В играх самое главное проблема в том, что мы хотим получить картинку близкую к той, что мы получаем в кино, чтобы она была реалистичной, но при этом мы хотим это получить 30 или 60 раз в секунду. То есть одну картинку у нас время 33 миллисекунды. Или если 60 FPS хочешь, то есть 60 кадров в секунду, то это бюджет кадра 16,6 миллисекунды. И ты можешь себе представить 16 миллисекунд, допустим, и 24 часа в кино. И при этом картинка может получаться в принципе похожей, допустим, если смотреться в играх, в современных играх, очень красивая картинка.

Слушай, тут надо обозначить масштаб. Потому что я sysadmin, и я привык, что запрос к веб-сайту— это примерно 200 миллисекунд. Ну там, типа, в среднем. Очень хороший сайт может начать загружаться через 100 миллисекунд. Но 16 миллисекунд— это вообще на границе осознаваемого.

Да, да. То есть это очень мало. И в игре, получается, что нам надо для того, чтобы сделать, вот как ты описал, просто лес какой-то, просто персонаж стоит, ничего не делает, даже со статичной камерой. то тогда нам нужны к минимуму 3D-модели этого всего, то есть нужно замоделить этого персонажа в каком-то софте, допустим, в Maya, в 3D Max, или можно купить, допустим, это сейчас есть всякий Marketplace, где можно покупать готовый контент 3D-модели. То же самое касается леса, допустим, там ты купишь деревья или там замоделишь сам, у тебя там в игре, если лес какой-то хочешь разнообразный, тебе там нужно 10 видов деревьев минимум. Потом что-то там должно быть на земле тоже. То есть тебе нужны 3D-модели, допустим, камней там, каких-нибудь мха там разбросанного и так далее, текстуры для них, материалы для этого всего. Это только для того, чтобы всё это просто поставить на сцену.

Денис, я хочу немножко суммировать. Значит, первый шаг— мне нужны 3D-модели моего мира. Например, камни и мох, которые валяются на земле, или деревья, которые растут. Скажи, пожалуйста, камни, например. Каждый камушек— это отдельный объект в моём 3D-мире. Они типа все одинаковые или они отличаются друг от друга?

Нет, смотри, как обычно делается. Понятно, что эти модели представлены треугольниками в памяти компьютера. Чем больше треугольников, тем тяжелее это отрисовать, и тем больше памяти они занимают. Поэтому, допустим, модели для игр и для кино отличаются. Допустим, какой-нибудь персонаж для мультфильмов или фильма, он может там быть миллионы треугольников или даже сотни миллионов треугольников. А для игры, там допустим весь бюджет кадра, это чтобы все объекты на кадре, всё что рисуется было там 5 миллионов в современных играх. Вот, это всё-всё-всё-всё, что ты рисуешь. И поэтому персонажа 50 тысяч, 100 тысяч треугольников могут быть. И объекты, они не все уникальны. То есть тебе достаточно, допустим, я не знаю, 3 вида камня. модели уникальные именно ты берешь, их в редакторе движка располагаешь в карте и можешь делать их копией и поворачивать их по-разному. Допустим, менять им масштаб, поворачивать, чтобы делать уникальный вид, чтобы не было повторяемости. Вот. И по факту у тебя движок сам обрабатывает, допустим, три вида камня уникальных, но он их повторяет, рисует одну и ту же информацию. То есть это в памяти мы не теряем.

Ты сказал, что объекты обычно делаются с помощью треугольников. Все, что я вижу в кадре, оно все с помощью треугольников?

Смотри, все объекты, получается, они состоят из каких-то поверхностей, а минимальная единица поверхности— это плоскость. То есть, допустим, из плоскостей ты можешь сделать сферу, если у тебя будут маленькие плоскости, ну, или любую другую форму. А минимальное количество точек, которые нужно, чтобы создать плоскость— это три. Если ты делаешь, допустим, квад или четырёхугольник, то это уже можно две плоскости провести. Это как вот у тебя стул на четырёх ножках, который шатается, то есть ты не можешь найти, потому что там две плоскости всегда может быть. Поэтому треугольники. Но при этом тут зависит от того, как рисуется, тут тоже большая тема очень, это вот разница между рейтрейсингом и растеризацией, то есть если мы говорим о растеризации, это всегда треугольники, но есть еще разные варианты ухищрений, как там не треугольниками делать, допустим точками можно, вот, но это такие вещи экзотические, в основном 95% я бы сказал это треугольники.

Я просто подумал вот волосы у персонажа, например, как например волосы задать треугольниками, не так очевидно.

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

И вода тоже, да, получается, состоит из... Вода тоже, да. Чума.

И вода, и ландшафт.

Так, окей, у нас, значит, состоят из треугольников, и мы их каким-то образом транслируем вот на мой двухмерный экран. Этот процесс сам по себе сказал, что вот есть два процесса— растеризация и рейтрейсинг. Рейтрейсинг— это технология, которая обычно используется в кино или в какой-то сложной компьютерной графике, когда отслеживают путь каждого луча света и то, как он отражается от объектов. Получается очень красиво, но очень медленно. Ссылка на разговор про компьютерную графику будет в описании к этому эпизоду. А растеризация, в чём там прикол? Почему это быстрее работает? Как быстро у вас получается за 10 миллисекунд сделать картинку?

Растеризация— это, получается, у нас есть треугольники, из которых состоит геометрия на сцене. Эти треугольники состоят из вершин и пикселей. Эти вершины треугольников проецируются на экран с помощью видеокарты. То есть там есть трансформация математическая из 3D в 2D. Допустим, треугольник, у него три вершины, они все спроектировались на экран, и дальше видеокарте надо просто построчно закрасить, ну как вот этот принтер печатает, закрасить просто вот этот треугольник на экране, его 2D-проекцию, по строчкам и определить, какого цвета должен быть каждый пиксель в этой строчке. И для того, чтобы определить, какого цвета должен быть пиксель, еще запускается программа на видеокарте, которая называется Shader, собственно. И там тоже программируемая логика, которую пишет программист на специальном языке, там C-подобном. И вот там эта логика решает в зависимости от того, что пришло из видеопамяти в этот треугольник. Допустим, в этот треугольник пришли текстуры, а там текстура листвы, там текстура камня, пришел источник света какой-то, пришли еще какие-то параметры. И вот используя все это, надо понять, какого цвета должен быть пиксель.

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

Ну, так и есть, так и есть, да.

Окей, есть какой-то способ получить объекты моего виртуального мира, 3D-объекты, которые я там вот либо сам построил в какой-то программе, либо где-то купил готовые, наложил на них текстуры, и после этого есть какой-то процесс, как видеокарта быстро на экране всё это показывает. Немножко хочу ещё про сам этот мир поговорить. Вот передо мной лес, например. Там типа, не знаю, сотни деревьев, как мне кажется. Что, реально сидит человек и определяет для каждого дерева его позицию? Как это обычно делается?

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

Блин, это звучит как игра Sims, если вы в неё играли, мне кажется.

Да-да-да, ну так и есть, так и есть, по сути, да. Ну или как там какой-нибудь городостроительный симулятор, там бывает типа SimCity, Cities: Skylines, там да, так и есть. Причём можно ещё обычно делать, что не только один объект, а допустим там у тебя сразу комбинация может быть, ты рассаживаешь одновременно и деревья, и камни с мхом, и какой-нибудь ещё ветки на земле, да, кустики, всё это, и вот так вот красишь, и всё. Ну это быстрая рассадка, потом, допустим, если художнику что-то не нравится, он может выделить какой-то отдельный элемент, там дерево подвинуть, если это в игровой зоне, там, или удалить, или отредактировать.

Офигеть. Это реально как в фотошопе, типа, когда рисуешь картинку, только... Да, ну, по сути,

можно просто относиться к игровому движку, к редактору, как к фотошопу, только в 3D. То есть там много инструментов, которые позволяют что-то сделать, там, удалить, добавить, быстро это сделать, процедурное и так далее.

Мне кажется, уже все слушатели такие, что за движок, что за движок, но до этого мы доберёмся. Пока ещё я добью эти вопросы. Вот я иногда вижу, что листья на ветру шевелятся. Это как работает? Там реально ветер прямо гуляет по карте?

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

Офигеть, мне начинается... вспоминаться курс по компьютерной графике, который мне в универе читали. Шейдеры— это программа, привязанная либо к пикселю, либо вот к вершине. До сих пор взрывает мне мозг, как видеокарта может там типа запустить эту программу, там у тебя экран 1024x768, например, там в типа в миллионе экземпляров. И вот это происходит каждые 16 миллисекунд. Так, вот я толкаю камень, и он катится вниз по склону. За счет чего это происходит? Потому что это уже не просто графика, это какая-то логика поведения, может даже физика можно назвать.

Смотри, персонаж, допустим, есть твой, у него, как я говорил, 50, там, 100 тысяч треугольников используется. Он красивый, детализированный, у него там есть какие-нибудь, я не знаю, там, заклёпки, там, элементы брони, может быть, если это там какой-нибудь робот-шлем. А при этом, с точки зрения физики, ему такая детализация не нужна. Есть физический мир отдельный, который просчитывает физические взаимодействия и столкновения объектов. Для него, допустим, этот персонаж может быть описан сферами, боксами или там, капсулями, это там, так называемым. То есть, допустим, у него может быть корпус— это какая-нибудь там комбинация сфер боксов, может быть, для упрощения, вот, которая просто описывает максимально похоже его в целом форму.

Тело прямоугольное, голова— шар.

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

Если есть пересечения, то они толкаются друг о другу.

Если есть пересечения, то тогда, допустим, там может еще делаться более точный тест, т.е. все-таки там в физике может быть треугольное представление, оно может совпадать, но это уже на крайний случай. Т.е. сначала все сравниваются боксы с фермы, потому что это быстро сравнить на это дешево. И потом уже, если там что-то пересеклось из них, может сравниваться уже представление в треугольниках. И дальше уже после этого есть настроенные теми же самыми художниками или там геймдизайнерами физические параметры объектов. Допустим, вот этот объект, какая у него масса. Обычно в физической интерфейсе всегда есть масса, чтобы потом взаимодействие как-то сделать. То есть, допустим, у тебя, чтобы не было так, что там персонаж толкнул камень, он улетел, как, не знаю, там, в воздушный шарик. шар какой-нибудь в небо, вот, для этого сдаётся масса, там ещё другие параметры всякие, например, трение, ещё много всего в зависимости от типа объекта. Потом уже происходит взаимодействие, да, физический движок сообщает, что вот этот объект с такой массой с объектом с такой массой повзаимодействовал, и вот этот объект должен подвинуться. Ещё бывает, допустим, такая вещь, как hero объектом, кинетически он называется обычно, то есть тот, которым управляет пользователь, то есть чтобы не было такого, что персонаж пнул камень, допустим, и сам улетел, а камень на месте остался, то есть обычно... Тот, кто управляет, он всегда считается, там, объектом, допустим, с бесконечной массой, и он всё расталкивает.

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

Важный компонент вообще всех игровых движков, есть очень много библиотек, которые ответственны за звук сторонние, Wwise, FMOD, ну и также движки делают свои собственные, пишут. То есть звук работает похожим образом, как и остальные объекты. Обычно художники в сцене, в игровой расставляют тоже объекты какие-то, допустим, у тебя есть какой-то игровой монстр, и он может либо как на себе возить какой-то объект, отвечающий за звук, то есть художники к нему прикрепили какой-то объект в редакторе, и там написано, что объект— звук. И у него там в настройках написано путь к файлу, который он исполняет, и какая-то логика прописана. Допустим, звук там проиграть один раз, или повторять, или проигрывать по какому-то событию. Может быть монстр, не знаю, бежит, или там еще что-то делает, атакует, проигрывается звук.

Но при этом, типа, этот объект, а, не видим, б, в физическом мире, скорее всего, тоже никак, типа, не участвует в взаимодействии.

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

И типа отражение ещё, скорее всего, эхо можешь даже, наверное, сделать.

Да, эхо, там всякие там реверберации, эффект допплера, всякие эффекты, когда объект там от тебя отдаляется, к тебе приближается, там тоже куча всего.

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

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

Так, очень классно. Но есть еще такая ситуация, вот я, например, захожу в деревню, и в ней жители живут как будто своей жизнью. Они ходят по домам, ложатся спать, я не знаю, там кушают. Это тоже? Каждый из них вот так заскриптован?

Есть разные подходы. Если ты хочешь запрограммировать, как у тебя перемещается какой-то персонаж, допустим, вот если там, какие-то жители в деревне. У каждого из них может быть какая-то заранее заготовленная анимация и маршрут того, как они перемещаются. Вот от какой точки к какой. Пример такой интересный. В Counter-Strike 1.6 были боты, и у них была система вейпоинтов, так называемых. Вейпоинты— это именно маршрут. Кто-то, геймдизайнер, в редакторе расставлял, что вот этот бот, или там персонаж NPC, вот в случае в твоем примере, он появляется здесь, у него точечку он ставит в 3D-мире, потом бежит сюда, точечку ставит в 3D-мире, потом бежит там за дом, точечку в 3D-мире. То есть это, по сути, как маршруты, как GPS, то есть куда он должен... точку пробежаться.

Остановки для автобуса.

Да, типа того. Только для персонажей. В случае, в котором ты говоришь зацикленный, персонаж там, не знаю, стоит где-нибудь на улице, кормит коров, потом там идет, набирает воду, потом идет там в избу куда-нибудь, там что-то делает, потом выходит, что-то еще делает, и потом по кругу. То есть вот это все зациклено может быть. Это может быть запрограммировано. Но, допустим, если у тебя в игре мало этих персонажей, то у них там прописаны анимации, все равно надо художнику создать анимацию красивую, как он что-то делает. Если там совсем много, какой-то город, допустим, GTA, то там они могут быть заскриптованы по-другому. Движок может говорить, что в зависимости от мощности этого компьютера заспаунить 50 прохожих и выбрать им рандомную анимацию какую-то, что вот 50 прохожих, из них 10 идут, 2 стоят, а остальные там еще что-то делают. Вот, это тоже изготовленная анимация, но они там рандомно выбраны, у них там рандомно моделька выбрана может быть, что там типа цвет какой-то разный, одежда и так далее.

Таааак... Блин, это выглядит, даже не знаю, то ли шоу Трумана, когда игровой персонаж проходит, а вокруг него актеры, типа, начинают что-то делать. И еще я, кстати, заметил, что в последнее время в играх персонажи движутся очень реалистично. У них там, типа, руки, ноги, вот вообще анимация движения, если раньше она была условно такой, типа, вот реальный 3D-объект просто перемещается, то теперь я не очень понимаю, даже из каких частей он состоит. Как это работает?

За счёт анимации, смотри, у тебя есть какой-то персонаж, человек, допустим, и в том же софте каком-нибудь, может быть типа 3ds Max, Maya, можно запрограммировать его анимацию. Допустим, для ходьбы есть у объектов ещё виртуальный скелет, и этот скелет соответствует, по сути, как... похож на человеческий. Если смотреть на персонажа, у него есть, допустим, в колене точка, есть там в тазу, там несколько точек, есть в стопах точки, вот. И художник что делает? Он делает ключевые кадры. В редакторе он перемещает вот эти точки, собственно, колено там, стопу и так далее, таз. Допустим, делает там, что одна нога вперед чуть-чуть, потом Другая нога вперёд, и потом кадры между ними, они генерируются автоматически. И это вот анимация, которая сделана вручную. Бывает анимация сделана с помощью motion capture. Для фильмов используется всегда, для игр в большинстве, но это тоже стоит денег, поэтому это не всегда удаётся сделать. Конечно, тоже анимацию сейчас можно скачивать, уже готовые есть. То есть, допустим, та же ходьба, бег, это там супер популярные вещи. Более сложно это, если у тебя есть какой-то там монстр четырёхногий или там шестиногий, тогда уже надо потратить Ну то есть записываются в студии, берутся актёры, на них крепятся маркеры, они двигаются по-разному, и потом получается это всё сохраняется в отдельный анимационный файл, грубо говоря, чистится, всё специально делается, то же самое, вот эти ключевые кадры оптимизируются под игру, потому что там это огромные объёмы памяти. бывает обычно, потому что много датчиков, много движения, и потом, собственно, помещается в игру, и все, у тебя поэтому есть реалистичный персонаж. Плюс еще увеличивается с каждым годом, улучшается графика, увеличивается количество возможных треугольников, которые можно рисовать, поэтому у тебя персонажи становятся более детализированными и анимация у них улучшается.

Блин, это же настоящий motion capture, то, что вот когда Джеймс Кэмерон вешал датчики на актёров Аватара.

Да, то же самое в играх используется, да.

Когда мы готовились к этому эпизоду, редактор рассказывал, что у него любимая игра— это Stray, когда как кошка бегает, типа ты играешь за кошку. Она тоже двигалась очень плавно, так как кошки на самом деле движутся. Я вот думаю, неужто они на кота тоже повесили эти motion capture датчики?

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

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

На движок можно смотреть таким образом, что есть у тебя, допустим, фотошоп, в котором ты рисуешь картинки какие-то, что-то редактируешь, рисуешь картинки, а движок— это то же самое, что фотошоп, только для игр. То есть у тебя там это редактор игр, в котором у тебя вместо картинки создается игра. Есть разные игры, допустим, у тебя там шутер от первого лица, есть там какая-нибудь приключенческая игра от третьего лица, там гоночка, не знаю, стратегии, но всем этим играм нужны похожие вещи. Хоть у них и отличаются, как мы уже выяснили, 3D-объекты, но по сути то, что им надо, оно в целом очень схоже. Поэтому все, что их объединяет, выделено в игру. Вот, допустим, как мы сказали, звуковая система есть. Звук нужен везде, поэтому он обрабатывается похожим образом, поэтому вот эта часть, она общая, она находится в движке, она не зависит от игры. В какую бы игру ты ни играл, тебе везде нужен звук. Дальше есть физика. Конечно, ты можешь разные игры делать, 2D, 3D, но в большинстве игр тебе нужна физика, потому что объекты взаимодействуют между собой в игровом мире. Поэтому физическая часть, физический движок может называться, он тоже там присутствует, это общая часть. Потом, допустим, у тебя есть какая-то логика освещения, оптимизации игры так, чтобы у тебя отсекались невидимые объекты, чтобы у тебя рисовалось только то, что нужно. Применялось освещение. Допустим, освещение, оно есть во всех играх. То есть у тебя есть тени, есть свет, есть, допустим, отражения, преломления. Это тоже общая часть. Потом, как я сказал, вот эти инструменты для художников, для создания игрового мира. Там рассадка деревьев. То есть, допустим, деревья рассадить, это может быть в стратегии, в гонках, вообще неважно какая игра, любая. Поэтому инструмент общий. Поэтому вот это всё, оно и есть игровой движок. Это все вот эти общие части, объединенные в один. И когда ты делаешь игру, ты фокусируешься только на игровой логике и своем игровом мире. Тебе не надо думать о том, вот как, допустим, мне, я не знаю, звук сделать. Потому что тебе не надо с нуля его писать. Тебе не надо с нуля писать физические взаимодействия. графику с нуля писать, потому что она в основном готова, и всё. По сути, это обычно редактор, где у тебя есть viewport, окошечко, там ты видишь трёхмерный мир. Ты можешь как, по сути, в игре как бы летать свободно камерой в этом трёхмерном мире и кликать на объекты, их выделять, их удалять, перемещать, там смотреть свойства какие-то. У тебя обычно есть окно там снизу, слева, справа с ассетами твоими, ассет, то есть это именно единицы контента, ресурсы, которые ты можешь вытащить Да, ресурсы, да, и ты их там драгондропаешь. У тебя, может быть, ресурс— это 3D-модель, у тебя, может быть, ресурс— это звук. Ты его вытаскиваешь, драгондропаешь в мир и потом перемещаешь. Может быть, там физический объект, может быть, даже игровая логика, там какой-то скрипт. Вытаскиваешь зону, она тоже невидима, но она в редакторе отображается по какой-то там дебажной кнопке, по дебажной функциональности, там, чтобы видеть, когда игрок заходит, что там происходит в этой зоне. Вот, и там обычно есть сверху кнопка, в движках бывает play, то есть то, что ты наделал, ты нажимаешь кнопку play, у тебя начинает, собственно, игра проигрываться. То есть уже в окне И при этом ты можешь, допустим, подебажить в динамике, в самом-то же окне редактора, играя в игру, кликать на какие-то объекты, смотреть состояние. То есть, допустим, если что-то пошло не так, почему это произошло.

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

Да, в играх похожие роли, просто они по-другому называются. Допустим, у тебя есть геймдизайнер, который прописывает игровую логику, у тебя есть, допустим, художник-3D-моделист, он именно отвечает за 3D-модели, то есть он изготавливает вот эти 3D-модели отдельно в своем софте, там в Maya, в Maxie. Бывают там левел-дизайнеры, допустим, это художник по картам, то есть он берет все те модели, которые произвели художники по моделям, и их именно располагает в мире красиво, их соединяет. строит между ними, подмазывает, допустим, чем-то там подкрашивает еще дополнительно, чтобы они смотрелись органично все в одной карте. Есть там еще, допустим, концепт-художники бывают, которые, то есть это как в фильмах тоже в других отраслях, рисуют концепты игровых уровней или в целом игрового мира, по которым потом, собственно, вот эти вот 3D-художники делают нужные модели необходимые, и художники по уровням, там левел-дизайнеры, они собирают все это вместе.

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

Разница есть, да. Но если смотреть сначала от первого лица и от третьего лица, в чем разница? Обычно в игре от третьего лица бывает больше угол обзора у тебя в целом. То есть это значит, что больше объектов может попадать в кадр на отрисовку. И у тебя нужно еще всегда иметь персонажа от третьего лица, вблизи которого ты видишь твой персонаж. И он должен быть сделан детализированно, и для него могут быть использованы отдельные алгоритмы, как его обрабатывать, потому что он может рисоваться в большем качестве обычно, чем всё остальное, потому что ты его видишь. Плюс для него нужны очень крутые анимации всегда. Допустим в Uncharted'е были такие анимации сделаны интересные, когда ты проходишь рядом со стенкой какой-то, а он мог просто рукой прикоснуться к ней, ну так, чтобы если он совсем близко проходит, просто рукой положить.

Чума. То, как человек обычно делает, да, для того, чтобы не удариться об стену.

Да-да, например, так. И, допустим, в игре от третьего лица всё это нужно делать. То есть тебе нужно тратить бюджет игры, грубо говоря, на вот эти анимации, на 3D-модель, на какие-то, может быть, дополнительные подходы. А если игра от первого лица, какой-нибудь типа Дума, то там другие проблемы. Тебе это вообще не надо. Тебе не надо запариваться по модели персонажа, но есть модели врагов. Модели, им тоже нужны анимации, но другие требования к ним. То есть они не должны быть такие детализированные, они не супер близко.

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

Естественно Unreal, сейчас Unreal Engine 5. Unity, есть еще много других всяких типа там Godot какой-нибудь, есть там RPG Maker, там Ogre был еще движок давно. Unreal в основном там сейчас ударился в то, чтобы в фильмах использоваться, поэтому у них там фокус на всякие такие супер реалистичные решения, на графику, но в играх тоже активно используется, тоже очень популярный движок.

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

Ну там, конечно, сейчас уже немножко всё смешалось и движут в разные стороны всё это с новыми апдейтами, но в целом концептуально. В играх-движках какая бывает логика, что есть у тебя объект на сцене, допустим это модель, вот ты поставил модель тоже, там персонажа или там дерево, и вот у тебя в описании, ты на этот объект кликаешь, у тебя написано, что этот объект он модель. И всё. И ты вытащишь другой объект, он только звук. А есть подход, такой называется Entity Component System, то есть это типа компонентная система по-русски, если говорить. Это когда у тебя объект, он по сути не объект, а объект это просто пустой контейнер, как бы сущность. У него там под капотом может быть какой-то ID-шник или что-то, еще какой-то идентификатор. Но по сути этот объект, он коллекция каких-то других компонентов, которые придают ему свойства. Пример такой, что у тебя может быть объект, костёр какой-нибудь, ну допустим он у тебя сразу состоит из каких-то полений, которые горят, и ты создаёшь, вот в случае с компонентной системой, ты бы создал его как? У тебя была бы пустая вот entity сущность, в неё бы добавил компонент модель. Эта модель, по сути, ты прописываешь, что вот это поление, потом ты добавил бы в эту же entity компонент, допустим, эффект частицами, там огонь чтобы был, потом ты бы добавил звук какой-нибудь, типа там трескающегося вот этих вот полений там в огне. И в итоге у тебя получилась вот энтитей, там написано список, модель, список эффект-частиц, там список компонента, там звук и так далее. И в чём отличие? Что в случае, если у тебя просто это объекты сцены, то у тебя было бы это всё отдельными сущностями, то есть у тебя была отдельная модель лежала в сцене, отдельно там эффект-частиц, отдельно звук. И допустим тебе надо это передвинуть куда-то, тебе надо всё... подвинуть по отдельности, а тут в этом случае ты двигаешь все вместе, но это как бы еще меньше только из проблем. В целом получается, что с точки зрения движка тебе обрабатывать это гораздо проще, потому что у тебя движок не знает конкретно какие объекты, какие сущности, то есть какие сущности, какие компоненты имеет, он просто идет вот я обрабатываю все модели в параллель, вот обрабатываю все эффекты частиц, Все звуки. Все звуки и так далее. Вот. И получается, что в этом случае у тебя обработка всего этого быстрее гораздо происходит, и этот подход более расширяемый. То есть у тебя есть компоненты, которые расширяют свойства конкретного какого-то объекта. То есть ты собираешься как из конструктора сам. А в случае с объектами в сцене, обычными, у тебя это получается гораздо сделать сложнее и потом сложнее поддерживать.

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

Точно сказать не могу, но много людей. Там сотни, тысячи.

О-хо-хой.

Ну, потому что, как мы обсуждали, то есть есть много частей. Допустим, вот звук, физика, графика. Только в графике там куча людей, которые разрабатывают новые фичи для этих движков. А в Unreal там вот добавляли, может быть, ты слышал, что добавляли в Unreal Engine 5, То есть такие киллер фичи, Nanite, это отрисовка геометрии, более крутая, нексгеновая такая, и система освещения реалистичного Lumen. И только над Lumen я просто смотрел там по ней презентации, как они работают, потому что я как бы тоже работаю над движком, а не над игрой. Поэтому только вот над этими именно графическими фичами там работали десятки человек. А это по сути графические фичи, которые составляют часть графического движка в игровом движке.

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

Поэтому там огромные команды.

О какой продолжительности проекта идет речь? Потому что вот мы поговорили про размер команды, но когда я думаю о стоимости программного продукта, там еще имеет значение время. Типа, не знаю, год его разрабатывали или там 10 лет вкладывали такой командой? Сколько лет обычным движкам?

У движков очень много лет. То есть если так смотреть, то Unreal 5 основан на 4, а 4 основан на 3. Но вообще по открытым источникам обычно пишут, что все версии Unreal основаны на предыдущем. То есть первые версии вышли в начале 2000-х. Больше 20 лет уже, получается.

Типа больше 20 лет вкладываются в это.

Да, это огромные деньги, там миллионы долларов, тысячи людей и 20 лет разработки.

Да-да, это типа десятки тысяч лет разработки, мне кажется.

Ну, если помножить на людей, да.

Скажи, пожалуйста, все ли популярные игры сделаны на вот таких крупных коммерческих движках?

Нет, далеко не все сделаны. Обычно тут смысл какой? Если команда маленькая и ты хочешь сделать игру именно, то выбирают движок готовый, потому что нет времени разрабатывать движок. Но есть обычно команды, допустим, под приставки эксклюзивы, те же PlayStation, Sony Santa Monica, который разрабатывал God of War. У него движок кастомный. То же самое касается Naughty Dog. Uncharted под PlayStation тоже кастомный движок Call of Duty тоже, там много частей, у них тоже свои движки В целом, обычно, если компания крупная и хочет иметь какую-то технологическую безопасность, можно так сказать, то тогда они вкладываются в разработку своего движка При этом, если ты делаешь свой движок под какую-то конкретную игру или под конкретный жанр, то можно его сделать быстрее по производительности, потому что тебе не надо поддерживать какие-то там generic решения, что на твоем движке могут сделать игру в другом жанре Но это же как бы и хорошо и плохо, потому что плохо то, что ты можешь делать только одну игру в одном жанре, но хорошо то, что по производительности будет лучше и больше контроля над тем, потому что если ты используешь сторонний движок, ты периодически получаешь от него апдейты, а апдейты могут что-то менять, что-то ломать, что ты не хочешь. И часто бывает, что люди форкаются и они, допустим, просто фиксируются на какой-то ревизии движка и больше никогда не обновляются. И, допустим, какие-то если баги возникают в движке у тебя, тебе надо репортить этот баг на вот этой компании движка, которой ты пользуешься, и он может там встать в очередь, может быть неприоритетным, и ты будешь долго ждать фикса. А если у тебя свой движок, то у тебя свои программисты есть, которые там пофиксят этот баг гораздо быстрее.

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

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

Эти движки очень мощные платформы для разработки. Ты уже упомянул, что они иногда используются для кино. Используются ли они для разработки не игр? Ну, короче, для разработки чего-то кроме игр.

Да-да-да, но тот же Unreal может использоваться для... Помимо кино, симуляторы могут быть различные. Ну и допустим, есть движки, которые сделаны под игры и под симуляторы. Допустим, вот российский движок есть Unigine. У него там портфолио, если посмотреть на сайте, там они под различные... Допустим, авиасимулятор используется потом. архитектурный какой-то софт, допустим, тебе нужно сделать визуализацию, там какой-то новый, не знаю, международный комплекс, бизнес-центр, завод, всё что угодно. Визуализацию сделать там супер точно, у тебя там размеры должны быть, ну там тоже другие требования, потому что там должны быть детали, размеры все выверены, для этого используется. Ну то есть всё, что касается такого вот производства бизнеса, там может быть какие-то детали, ну CAD. То есть это именно для проектирования визуализации, там медицинские тоже могут быть какие-то визуализации. Ну то есть много таких вещей, которые не связаны с играми, но связаны с графикой, но там бывают другие требования немножко. Если какую-то деталь, там двигатель надо, допустим, автомобиля, там чертёж его трёхмерный сделать у него, там могут быть миллиарды треугольников, потому что там надо, чтобы все там болты, там какие-то заклёпки, всё это было трёхмерно. И там тоже всякие алгоритмы, которые используются для оптимизации. Но там типа игрологии никакой нету, естественно, звука нету. Там нужно просто быстро это отрисовать эффективно.

Ты это уже немножко затрагивал с точки зрения разработчиков движков, а вот я написал игру, например, на Unreal Engine, она, моя игра, запустится сразу и на PlayStation, и на Xbox, и на Windows, или нужно как-то специально еще мне, как разработчику игры, что-то для этого сделать?

Смотри, как разработчику игры, если ты хочешь, чтобы игра работала на ПК, на приставке, то во-первых, там у приставок могут быть свои требования к интерфейсу, как минимум. Допустим, если посмотришь на приставочный интерфейс, обычно он как-то сделан более лаконично, и там крупнее элементы. То есть, то, что ты смотришь на него не в упор, сидя за стулом на компьютере, ты смотришь с дивана, допустим. Поэтому там ее элементы обычно бывают больше. Плюс, естественно, тебе надо переделывать систему ввода, input. Ну, еще не переделывать, а адаптировать его, потому что вот у тебя на компьютере рассчитано на то, что какие-то элементы клавиатуры мышкой используют.

Суперточная мышка.

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

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

Ну да, да.

Куда развиваются игровые движки? Какие задачи перед собой ставят разработчики? Потому что ты сам разработчик движка, участвуешь в разработке движка. Где вот этот передний край науки сейчас?

В идеале должно быть, чтобы движок работал на можно большем количестве платформ, я бы сказал. Все стремятся к тому, чтобы была всегда лучшая производительность, всегда за ней гонится. Это такая бесконечная гонка, грубо говоря, потому что вырастают требования художественные, то есть хотят все реалистичнее картинку, хотят художники более сложные, допустим, и дизайнеры там задумки свои реализовывать, и художественные задумки также. Миры открытые все больше и больше становятся. Производительность ухудшается, поэтому программисты и разработчики движка работают над оптимизацией постоянно, потом инструменты постоянно улучшаются, то есть идеальных нет, все равно у всех движков есть плюсы и минусы, и сложно сделать что-то, что будет всегда работать красиво и быстро во всех случаях возможных, поэтому делаются специализированные инструменты, и растут постоянно количество платформ, на которых запускается движок, и все больше и больше их будет, я думаю, в будущем, потому что там Девайсов количество увеличивается, консоли не так быстро устаревают, как хотелось бы, допустим, сейчас. Вот PlayStation 4, 4 Pro, я сам играю на PlayStation 4 Pro, там, допустим, у меня пятого нету, хотя пятой уже несколько лет. Ну, вроде уже как бы на консолях те же самые. Есть какая-то более-менее хорошая графика, и как будто бы надобность в новых консолях, она типа не так высока, как, допустим, было между PlayStation 2, PlayStation 3 поколениями.

И ты уже не можешь игнорировать предыдущее поколение консолей, когда выпускаешь современную игру.

Да, если во времена PlayStation 3 совершенно поменялась архитектура, вышли новые игры, старый PlayStation остался, но постепенно умер. А сейчас, допустим, вышел PlayStation 5, но большинство игр выходило сразу одновременно и под PS5, и под PS4. И они сейчас до сих пор там продолжают, насколько я знаю, так выходить. Четвертый PlayStation, типа, там продано миллионами копий, и люди до сих пор играют. В общем, не так охотно расстаются. Но тут еще есть такой момент, что архитектура не поменялась. Вот после PS3 архитектура приставок стала очень похожа на ПК, ну там x86, похожая разработка. То есть PS4, 5, Xbox'ы соответствующие, там аналоги, они все похожи на комп, грубо говоря.

Можно делать просто Graceful Degradation, когда всё чуть-чуть становится похоже, но типа всё равно продолжает работать.

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

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

Если ты хочешь разрабатывать движки именно, то есть такой автор, американский Джейсон Грегори, у него есть книга, называется Game Engine Architecture, архитектура игрового движка. Это, по сути, такая библия разработчика игровых движков. У него уже много редакции этой книги вышло, и вот если ты посмотришь, там обычно в интернете, если хочешь свой движок разрабатывать, всегда рекомендуется эта книга. Я ее читал тоже, она очень интересная. Она как раз то, что я рассказывал, по сути, вот эти вот системы, Типа физика, звук, анимация, графика. Она покрывает в целом, в общем, дает общее представление и помогает, если ты как разработчик хочешь начать разрабатывать свой движок или свою игру на своем движке, то тогда вот к этой книге обращаться можно. Еще есть книга интересная по тоже графической части, называется Real-Time Rendering. Там тоже много редакций, тоже интересная. По разработке конкретно игр я бы сказал, что самые крутые источники это туториалы на YouTube. Сейчас очень много, но тут зависит от движка, какой движок ты выберешь. Допустим, даже по выбору движка тоже много туториалов в вашем интернете поискать. Типа, хочу разработать игру, вот какой движок выбрать. Там только будет куча видосов, сравнений. Недавно смотрел видос, тоже интересный был. Назывался «Я сделал одну и ту же игру на восьми движках».

Охренеть вообще!

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

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

Да, да. Ну, я говорю, по Unreal, допустим, и по Unity там очень много туториалов на YouTube. Это на любой вопрос, как сделать какие-то там первые шаги, как засетапить, как там объекты сделать, чтобы взаимодействовали и так далее. Куча всего.

Ссылку на пару классных роликов мы положим в описании к этому эпизоду. Денис, спасибо тебе огромное за этот... Мне очень понравился разговор. Кажется, он очень интересный и так вводит в тему. Это подкаст Студия Либо-Либо, и сделали мы его совместно с Яндекс Практикум. Над подкастом работали редакторки Маша Агличева и Рита Берденникова, продюсеры Настя Медведева и Данил Остапов, звукорежиссер Юрий Шустицкий, за джингл спасибо Алексею Зеленскому.

Редактор субтитров А.Синецкая Корректор А.Егорова