Имеете [не имеете] дело с собственным игровым движком

Что мне больше всего нравится в gamedev, так это что большая часть игр и каждый первый кастомный игровой движок бросают вызов устоявшимися стереотипам разработки. Иначе зачем начинать разработку такого сложного и комплексного софта, когда десятки похожих софтин есть вокруг. Конечно такие монстры как Unreal и Unity и десяток монстриков калибром поменьше существенно упростили разработку во многих отношениях, привлекли тысячи разработчиков к созданию множество великолепных игр с использованием готовых технологий, освободив их от ямы отчаяния пустого уровня. Но также не оставляет мысль, что еще больше игр они похоронили. Невзирая на весь функционал и мощь U/U люди часто застревают в рамках, о которых они даже не подозревали. На протяжении многих лет наблюдаю как оригинальный контент в большинстве случаев убивается ассетсторами, если там есть что-то близкое или похожее к нужному объекту, функционалу и виду. Не поймите мои слова неправильно, я обеими руками за магазины ассетов и любых других ресурсов, скриптов и технологий, но беря что-то в магазине за доллар, вы уже с большой вероятностью не сделаете свое. Или сделаете конечно, но позже, но до этого «позже» еще надо дожить, а пока что у вас будет всё как у всех: одинаковые паттерны, одинаковые текстуры, одинаковое поведение, одинаковые модели… и одинаковые игры? Что тогда остается своего — уникальные механики и впечатления. В другом случае не было бы игры, вот только проблема, что сначала люди видят картинку. Хорошо если игрок через полчаса-час доберется до уникальных механик, одинаковая картинка вызывает в памяти игры в которые вы уже играли, а уникальная механика так никогда может быть и не увидена в игре.

---

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

RDR 2/GTA V (RAGE)
Starfrield (Creation Engine 2)
Baldur’s gate 3 (Divinity 4.0)
Resident Evil 4 (RE Engine)
The Legend of Zelda: Tears of the Kingdom (LunchPack)
Elder Ring (Dantelion)
Victoria 3 (Clausewitz Engine)
Horizon Forbidden West (Decima)
A Plague Tale:Requiem (Zouna Engine)
The Last of Us: Part I (Custom/?)
Syberia: The World Before (Unity)
Hogwarts Legacy (Unreal Engine 4)
Star Wars Jedi: Survivor(Unreal Engine 4)

Что такое игровой движок?

Это специальное программное обеспечение, больше уже похожее на среду разработки. Для многих игровых дизайнеров редактор является единственной средой разработки всего, и часто они даже не помышляют смотреть за границы его возможностей. Движок включает в себя различные настройки и конфигурации, которые оптимизируют и упрощают процесс создания видеоигр на совершенно разном наборе языков программирования. Он может включать в себя подсистемы для рендеринга графики в 2D или 3D, совместимого с разными форматами импорта, физическую подсистему для моделирования взаимодействий, звуковую подсистему, подсистемы управления игровым искусственным интеллектом (GOAI/CAI/BAI), не путайте с ИИ общего назначения вроде нейросетей, инструменты для скриптинга, редактор уровней и т.д. Многие из этих подсистем настолько сложны, что вполне тянут тоже называться полноценными движками.

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

Немного про синюю таблетку

В 21 год, Тим Суини создал ZZT, первую официальную игру от Epic Mega Games. Эта игра-головоломка имела очень простую графику на фоне графики с консолей — в конце концов, она была выпущена в 1991 году. Хотя игра не была самой современной, способ создания отдельно фреймворка и отдельно игры на нем был революционным. Небольшой коммерческий, но все же, успех привел позже к появлению Unreal, игры, в которой игроки контролировали заблудшего заключенного на инопланетном мире. Unreal был одной из лучших игр в свое время, с высоко детализированными внутренними и внешними местами для игроков. После выхода Unreal другие студии стали использовать движок для разработки, но стоимость его лицензирования была конечно запредельной — больше 1М$. Первая версия игрового движка Unreal от Epic сосредоточилась на создании комплекса инструментов и устранении технических трудностей. За десятилетия с тех пор движок стал универсальным инструментом разработки, так что сегодня на Unreal можно разрабатывать все типы софта, ориентированного на работу c 3D графикой. Сам движок обладает самым широким набором плагинов импорта/экспорта, и одной из самых продвинутых систем рендерингом, которые доступны в том числе и на мобилках.

Другая синяя таблетка

В 2004 году Николас Фрэнсис, Йоахим Анте и Дэвид Хелгасон создали игровой движок Unity в небольшой квартире в Копенгагене. Платформа очень известная, писать про неё не буду, отмечу что примерно половина игр на мобилках в мире сделаны на ней. То, что начиналось как проект по интересам от студентов, вскоре превратилось в топ движок мирового уровня. Но не стоит забывать, что конечной целью все же является коммерческий успех движка, и остальное, как говорится, история.
Еще про синие таблетки

Красная таблетка

Когда я только пришел в большой игрострой одним из основных движков в студии был Unity, там был еще Frostbite, но во-первых его давали только на крупные проекты, а мобильные SimCity Built It!/Sims Mobile к таким не относились. Во вторых движок был сложным: и для команды, которая на нем делала игру выделялась еще одна команда, которая помогала усмирять «лапку». Не скажу, что Юнити на уровне движка намного проще, но на уровне редактора это просто были мопед и suzuki sgx. А вот со стороны кода это выглядело прямо наоборот. В третьих «фростик» был для больших ПК/консольных игр, и его рантайм занимал под полтора гигабайта на пустом уровне.

В четверых редактор просто тихо падал на кириллических символах в именах файлов. Просто движок был написан для масштабных игр уровня Battlefield: Bad Company, Dragon Age: Inquisition, Need For Speed: The Run. Хе-хе, iPhone 4-5, если мне не изменяет память хорошо если гигабайт оперативки разрешал выделить в то время. Но зато движок был одним из первых, который использовал все возможности DX12, такие как например compute шейдеры, тред-контексты или bindless texture.

После выхода Plants vs. Zombies: Garden Warfare его пробовали портировать на мобилки, но безуспешно. И только в 2019 движок добрался до Nintendo Switch (Plants vs. Zombies: Battle for Neighborville).

Возвращаюсь к Unity, который ничуть не менее известный, и вроде бы достаточно взрослый и по идее должен подходить под любые проекты. С ним тоже были проблемы, но уже на уровне архитектуры. Движок в полную противоположность Frostbite рассчитан на небольшие по масштабам игры. Так что в какой-то момент, его пришлось форкнуть и начать дорабатывать уже под нужды Sims Mobile. Причина по которой форкнули Unity была в большом числе мелких проблем, которые выросли в большой такой снежный ком и очень мешали разработке. Мне запомнилась проблема с обработкой callback’ов, которые были сделаны на слое C#, но часть своего рантайма держали в виде одного единого vector’a на уровне плюсов. Знаете что происходило, когда в объект добавлялся новый колбек? Движок лочил старый вектор, выделял память для нового массива колбеков, копировал туда все + 1 и удалял старый. Так было реализовано с первой версии и всех устраивало. Это было сделано для безопасной работы с колбеками и оно прекрасно работало на небольших объемах. В играх где один объект имел 1, 2, 3 да пусть даже десять колбеков их изменение не вызывало проблем. Но в Sims Mobile у одного объекта могли быть их сотни, да еще и могли динамически меняться. Вы наверное зададитесь вопросом «А зачем столько?» Причиной была необходимость реализовать систему smart objects, т.е. когда объект (например стул) предоставлял подошедшему к нему симсу информацию, что на него можно сесть, и это было сделано через колбек. Кстати похожую систему затащили недавно в Unreal 5.1

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

А если делать свое?

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

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

Атомная бомба: ударная волна и разрушение

Nuke Thunder: математика и оптимизация

Исходный код движка долгое время была закрыт от сообщества, но слухи о выходе в опенсорс в компаниии обсуждались еще году в 16. Вы также должны понимать, что такой объем кодовой базы просто выложить в опенсорс не получится. Фактические надо внутри компании выделить отдел или людей, которые будут подчищать хвосты, комментарии, код, убирать лицензионные или NDA части, вынести и облагородить API. Причем люди эти не просто джуны двух месяцев в компании, наоборот это самый что есть костяк команды разработчиков. Ну а сейчас вы можете сами посмотреть, как все там сделано. Отдельная благодарность гайдзинам что нашли силы и время заопенсорсить движок. https://github.com/GaijinEntertainment/DagorEngine
Есть там и мои правки. К тому коду, что связан с Nintendo Switch и AppleTV, автор приложил свои лапки..

Люди и технологии

Знаете чем еще хороша разработка своего движка/технологии? Она привлекает лучших специалистов, чем разработка под известный и устоявшийся софт. Тут наверное не очень верно сопоставление с водителями, но несколько раз слышал его от лида: седаны S-classa я постоянно вижу на дорогах, много ли ты видел болидов формулы 1 в Питере.

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

Есть и обратная сторона. В студии есть люди, которые пришли с готовых движков вроде Unreal/Unity/Godot c другим пайплайном и методиками разработки, нередко между нами возникают обсуждения об использований индивидуальных технологий, связанные с затратами, временем и сложностью.

«Создавать собственный движок (технологию) — это безумие?», «Это стоит слишком дорого», «Еще не выпустили игру, но тратим время на разработку велосипедов»

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

Дорого?

Скорее да, чем нет. Есть мнение о том, что создание своего движка/технологии является очень дорогостоящим. Построение собственного игрового движка или другой технологии для разработки чего либо, не только игр, включает в себя существенные начальные затраты. В большинстве случаев эти инвестиции принесут значительную экономию в долгосроке, я все же больше разработчик, а не экономист, но за долгое время в игрострое видно как собственные движки студий развивались во времени и какие преимущества получаются со временем. Только не думайте, что расходы на другого разработчика, ориентированного на лицензированную технологию будут ниже, добавьте сюда расходы на саппорт и роялти, особенно когда игра становится успешной. Кроме того, зарплаты программистов, способных покопаться в кишочках Unreal и дописать новый функционал, выходящий за рамки новой ноды для БТ или изменить поведение GAS/CAS, резко подскакивает. Не буду указывать компанию, зарплата Unreal/C++ AI помидора в офис в Барселоне на третью часть известного проекта в задачи которого входит переработка BT/AI стека движка начинается от 2х, тогда как обычному помидору просто со знанием плюсов и опытом в анриале от 4 лет предлагают 1х, ищут уже полгода.

Конечно же созданный движок не будет уровня Unreal/Unity, как минимум из-за того что 70% возможностей их функционала вам не нужно. Еще один существенный недостаток у индивидуальных технологии — для создания базового игрового движка такого уровня требуется несколько лет инженерных работ, но часто цикл разработки игр и требования инвесторов от новой студии требуют результатов раньше, гораздо раньше, чем это становится экономически оправданным. Часто студии решают эту проблему, выпуская сначала игры на готовых движках, чтобы получить прочную материальную базу для развития, и постепенно заменяя отдельные части собственными решениями. Получившийся в итоге Frunrealstein благополучно вырастает в кастомный движок. Угадайте на чем сделана например вот эта популярная игра.

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

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

Электроники и Activision являются очень прибыльными компаниями, которые давно поняли, что доход от игр на своем движке значительно больше, а также исключает оплату разработки движка для конкурентов, это как с арендой жилья и ипотекой, оплата аренды не делает квартиру вашей, и только немного ниже чем ипотека. Электроники это поняли еще в 90-е, поэтому ни о каком использовании сторонних движков вроде Unreal/Unity в этих студиях вы скорее всего не услышите, исключение могут составлять вновь приобретенные студии, которых еще не перевели на движок собственного разлива, особенно если игра начала приносить более менее хороший доход. Более того, это ставит студии в зависимость от внешних технологий и проблемы шаринга технологий, какие бы ни были возможности движка они никогда не будут удобны всем, и опять — либо вы начинаете свой форк с преферансом и дамами, либо ищете похожие компоненты в ассетсторе. В любом случае вы не являетесь владельцем технологии.

Есть все, но все ли нужно?

Собственный движок/технология это инвестиция в будущие проекты, если конечно вы не собираетесь выпустить одну игру и уехать на Гоа дауншифтить. Преимущества накапливаются со временем, от недостатков вы можете избавиться здесь и сейчас, и не зависеть от необходимости поддерживать легион прошлых версий. Готовые движки поставляются с огромным количеством функций и инструментов, а также с огромным количеством легаси функционала, потому что н-нада, даже если конкретный проект его никогда не использует. Эти 50% избыточности замедляют и саму разработку, и требуют больше ресурсов, как человеческих так и железа. Вы хотели бы получить 20% перфа просто из воздуха, просто убрав ненужные компоненты из кода движка? На 60 фпс, вы получите 12 свободных фреймов, а это возможность добавить новые механики, больше нпс, лучше текстуры, красивые шейдеры, и еще много чего. Но вы не можете этого сделать, потому что даже не знали о такой возможности, или знаете, но все равно ничего сделать не можете, потому что это сломает смежную систему движка.

Не открою большой тайны, если скажу, что разработчики обычно тратят большую часть времени на отладку и доводку функционала, а не на написание нового кода. Иногда итерации могут выполняться сотни раз в день. Поэтому возможность запуска отладочных сборок и быстрая компиляция выходят на первый план, в идеале движок еще должен поддерживать один из механизмов hot-reload (изменения кода или функционала без перекомпиляции), технических сейвов если хотите, сохранением стейтов между запусками, чего ни Анриал ни Юнити не предоставляют из коробки. Это фантастически ускоряет разработку и экономит часы жизни разработчика каждый день. И конечно гораздо приятнее работать хотя бы в 30 фпс, а не 10 или 5 на большом уровне.

Может пробовали собрать Unreal под дебагом, хотябы c -01? Он компилируется почти 20 минут на 10-ядерном cpu двухлетней выдержки с 32 гигабайтами оперативки и немного залазит в своп.

Хотя код движка относительно чистый и модульный, функционала столько, что он собирается ну очень долго. При этом фпс тоже порядком просядет, забудьте о 60 фпс под отладкой, особенно с -O0. Другой пример — отладочная версия Godot или текущего движка с которым я работаю, собираются минут за 5 и все еще позволяет работать в 60 фпс в режиме -O1 и в 30фпс в -O0.

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

Сложно?

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

Небольшой пример: при портировании одной игры на Nintendo Switch столкнулись с тем, что нужно было получить драйвер звука для версии fmod 1.4, но в 2011 году свича просто не было на рынке, поэтому и драйверов для него никаких нет в принципе для этой версии fmod. Вендор говорит, переходите на версию 3.1, вот только переход подразумевает смену API, потому что в версии fmod 2.x были breaking changes, перекодирование всех звуков в новый формат и роялти за использование новой версии. Без доступа к исходникам движка скорее всего бы пришлось пойти вторым путем, но получилось проанализировать код драйверов от Playstation 3 и адаптировать их для новой платформы.

Еще один один пример: в 2016 мне довелось помогать с разработкой игры о симуляции большого мира, с самого начала целью игры было создать относительно живой мир, количество активных существ (NPC) в котором приближалось к 50к. Но управление таким большим числом существ в рамках одного уровня, выходило за рамки возможностей известных игровых движков. Нужна была архитектура, которая бы справилась с таким объемом данных, при этом команда не хотела отказываться от выбранного стека разработки. В итоге весь нужный код был написан на с++ и вынесен в отдельную dll, которая мапила фиксированный кусок памяти в движок и выполняла вычисления в тредах, пока сам движок занимался собственно только рендером, UI, и обработкой ввода. Получилось бы это сделать на нативных средствах самого движка без доступа к исходникам? 99% что нет. Помимо проблемы работы с большим объемом данных, второй огромной проблемой было то, что игра была процедурная. На релизе от движка остался только рендер, даже отрисовка UI и обработка ввода уехали в кастом код. Не было никаких middleware или открытых опенсорс решений, которые бы решали поставленные задачи или могли бы помочь в разработке. Все специфично для каждой отдельной игры.

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

Взгляд в будущее

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

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

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

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

Вместо выводов

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

Тут вот в чем дело. Мне кажется довольно естественным, что если хочешь хорошо — ты МОЖЕШЬ ПОПРОБОВАТЬ сделать сам. Если ты крут и вообще умный — у тебя получится. Но для этого надо инвестиции, время, ресурсы (люди)

Я считаю естественным цикл — студия зарождается, берет какой-нибудь unity и пробует себя. Если не взлетело — пару раз еще можно попробовать, не взлетело вообще — п***р, разбежались.
А если сходу вложиться в свой движок, 99% что ты даже до выпуска первой игры не дойдешь, а если и дойдешь — какие шансы что она окажется успешной? Ведь помимо движка есть идея, графика, и кучу всего, включая рекламу.

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

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

И помните, что ваш любимый большой и всемогущий Uniginrealdotmeladegore, тоже когда-то начинали студенты в гараже.
З.Ы. Frostbite не в счёт, его сразу делали по идеальному плану разработчики с тысячелетним опытом 🙂

 

Источник