К сожалению, геймдев сегодня — далеко не самое популярное направление в IT. Возможно дело в том, что это работа не для «чистых» технарей, а скорее для дизайнеров. И подавляющее большинство айтишников не заняты разработкой игр напрямую, а подобный опыт у них был разве что в детстве (до того как выбрать место с куда лучшими условиями).
Все это приводит к огромному количеству мифов, которые зачастую идут именно от непрофильных разработчиков. В этой статье постараемся отделить зерна от плевел.
Автор: Роман Перов
Миф №1. Программисты — одни из главных специалистов в разработке игр (или вообще самые главные)
На самом деле роль программистов в разработке игр сводится к написанию кода по указке дизайнеров — они лишь исполнители, которые ничего не определяют в концепции проекта.
В онлайн-проектах роль программистов более значительна, так как всем нужен хороший сетевой код. Без него серверная часть в принципе не будет хорошо работать. Это касается матчмейкинга, синхронизации действий игроков, регистрации попаданий и многого другого.
Однако знания по разработке сетевых игр практически невозможно получить из открытых источников (не говоря уже о классическом образовании). Это очень квалифицированный труд, который при этом еще и оплачивается ниже рынка IT в целом, потому что геймдев не считается системно значимым.
По этим причинам большинство кодеров не только не подходят для геймдева, но и сами не хотят туда идти (а значит и знаний из первых рук касательно разработки игр у них обычно нет).
Миф №2. Геймдизайнер — глава разработки игры
Кодзиму, Миядзаки, Лейка и других знаменитых творческих руководителей по разработке авторских игр почему-то продолжают называть геймдизайнерами. Хотя правильнее скорее будет геймдиректор.
Геймдизайнер же занимается проработкой игровых систем и механик. Иногда ему также приходится заниматься левел-дизайном и даже нарративным. Правда, на непосредственное написание сценарных текстов обычно все же выделяют отдельных сценаристов.
Миф №3. Собственный движок лучше универсального
Сегодня большинство игр создаются в формате экшена от третьего или первого лица — самого дружелюбного для игроков. И для любых подвидов экшен-игр те же Unreal Engine и Unity имеют очень удобные заготовки и инструментарий, что сильно упрощает и ускоряет разработку.
Во времена UE4 на проприетарном движке еще можно было добиться лучшей производительности при схожем уровне картинки. Но UE5 уже предоставляет технологии рендеринга кинематографического качества, многие из которых автоматизированы.
Более того, при заработке менее миллиона долларов в год даже не придется платить отчисления разработчикам движка. При этом все пользователи SDK получают полноценную техническую поддержку.
Поэтому сегодня создание и поддержка собственной технологической базы для игры и выглядит наивно. Исключением здесь могут быть только небольшие проекты вроде 2D-платформеров и различных аркад. А также решения от старейших студий вроде ID Software, DICE или Remedy — они еще могут себе это позволить. В то же время даже CD Projekt Red уже отказалась от собственного движка в пользу UE5.
Миф №4. Большинство багов в играх — следствие плохого кода
Ошибки в играх возникают не только из‑за некачественного программирования. В игровой разработке огромное количество взаимосвязанных систем: анимации, физика, сетевой код, поведение AI, скрипты, триггеры, контент, материалы, уровни. Любое изменение в одной подсистеме может вызвать непредвиденный эффект в другой.
Кроме того, любая игра — это интерактивная и непредсказуемая среда. Игроки могут действовать нестандартно, ломая предполагаемые сценарии, что сложно предусмотреть. Поэтому баги — это не всегда показатель «плохого кода», а часто следствие комплексности и вариативности игровых систем.
Миф №5. «Мультяшная» графика = примитивная
Конечно, стилизованный арт-дирекшен помогает скрывать недостатки рендеринга, но это не означает автоматически, что недостатков много. Или что проработка визуала халтурная. Например, недавняя Borderlands 4 может похвастать всеми самыми современными технологиями: от физически корректных материалов и динамического глобального освещения до микрогеометрии и процедурных анимаций. И все это хорошо заметно при прямом сравнении не только с предшественницами, но и с другими «комиксовыми» играми, особенно в 4K-разрешении.
Другой хороший пример — Fortnite. Простая «мультяшная» картинка в ней была только в первые пару лет после релиза, а затем Epic Games сделали свое творение главным полигоном для обкатки новых технологий Unreal Engine. И после этого не только детализация, но и качество освещения значительно выросли.
Миф №6. Чем технологичнее графика, тем игра красивее
Выше мы уже упоминали, что даже стилизованные игры бывают высокотехнологичными. И обычно это идет им на пользу. Однако вопрос намного сложнее.
С одной стороны, есть много примеров игр с устаревшей графикой, которые отлично выглядят до сих пор. Вспомнить хотя бы Half-Life 2 или первый BioShock. Всё потому, что в первую очередь красота картинки зависит от качества арт-дирекшена. И лишь во вторую от используемых технологий.
С другой стороны, при неумелом использовании современных технологий, картинку иногда может не спасти даже хорошая работа художников. Один из недавних примеров — Dragon’s Dogma 2. Разглядеть в ней качественный арт-дирекшен мешает плоское освещение (особенно «замыливаются» лица), а пейзажи сильно пострадали из-за движка, который едва вывез бесшовный открытый мир.
Миф №7. Трассировка лучей лишь повысила системные требования
Как и в любом IT-направлении, в геймдеве тоже совершенствуются инструменты. Трассировка лучей одновременно упростила разработку освещения и улучшила его качество. Без рейтрейсинга вообще невозможно сделать поведение света в сцене полностью корректным — лишь правдопободобным. Но даже для такого результата раньше требовалось огромное количество ручной работы.
Кроме того, сегодня больше не делают видеокарты без RT-ядер, даже бюджетные или для консолей. Поэтому простая гибридная тра��сировка уже перестала быть значительной нагрузкой на «железо». По-настоящему тяжелой пока остается продвинутая трассировка пути, но до ее внедрения как стандарта рендеринга в графике реального времени еще далеко.
Миф №8. DLSS делает картинку хуже
Принято считать, что лучше всего картинка в игре выглядит в нативном разрешении. Однако многие забывают, что после вывода видимого ракурса сцены на монитор (растеризации) требуется дополнительная обработка. А один из главных аспектов постобработки — сглаживание краев объектов, чтобы избавиться от «лесенок» из пикселей.
До изобретения апскейлинга на базе нейросетей все классические методы сглаживания, кроме SSAA (по сути, даунскейлинга, с соответствующим влиянием на производительность), справлялись со своей задачей посредственно. Даже если «лесенки» становились менее заметными, края объектов мерцали во время движения камеры. И лишь апскейлинг DLSS и последние версии FSR это исправили.
Получается, что благодаря умному апскейлингу не только повышается FPS, но и улучшается картинка. А заметить сниженное разрешение рендеринга в том же DLSS 4 можно лишь в режиме производительности.
Миф №9. Фотореалистичные текстуры делают из фотографий
Такой подход давно устарел. Примерно в середине 2000-х индустрия стала ориентироваться на жидкокристаллические HD-экраны с разрешением 720p и выше. Картинка на «плазме» и плоских мониторах в тонком корпусе стала значительно четче, чем на старых ламповых дисплеях. Сам термин HD означает высокую четкость.
И самым логичным решением для улучшения этой самой четкости многим показалось использование цифровых фотографий реальных поверхностей для создания текстур. Ведь тогда еще толком не использовались продвинутые материалы и шейдеры.
Сегодня же роль текстур значительно снизилась — они стали лишь заготовкой для отображения поверхности. А основную картинку делают как раз материалы, взаимодействующие с освещением, и шейдеры, отвечающие за эффекты. Кроме того, оказалось, что любой узор можно алгоритмизировать, а значит и текстуру легко создать без использования фотографии прямо в редакторе. Поэтому большинство разработчиков отказались от фототекстур еще в конце 2000-х.
Впрочем, сегодня наследниками фототекстур можно считать 3D-сканы (самая известная библиотека — Quixel). Они обычно более качественные, чем процедурные текстуры. Правда, 3D-сканы не бесплатные.
Миф №10. Высокополигональные модели — главный источник нагрузки на «железо»
Видеокарты в современных играх куда сильнее нагружены сложностью материалов, количеством проходов отложенного рендеринга, качеством освещения и объемом вычислений для постобработки. Геометрия давно перестала быть узким местом: технологии вроде Nanite, сеточных шейдеров и аппаратного отсечения полигонов позволяют выводить миллионы треугольников без ощутимых потерь.
Гораздо более ресурсоемкими сегодня являются сложные шейдеры, большое количество динамических источников света, тени высокого разрешения и эффекты вроде объемного тумана или прозрачности. Поэтому оптимизация давно перестала быть про банальное уменьшение количества полигонов в кадре, а про грамотное распределение вычислительных ресурсов в целом.
Миф №11. Раньше физика в играх была более продвинутой, чем сейчас
Сегодня игроки часто вспоминают Half-Life 2, Red Faction и другие проекты, где физика казалась революционной. В середине 2000-х появлялись первые аппаратные ускорители физики, в движки активно внедряли ragdoll, симуляцию воздействия гравитации на интерактивные объекты и базовую разрушаемость. Однако даже тогда продвинутые физические эффекты встречались лишь в отдельных проектах, а большинство игр использовали ограниченные и заранее подготовленные решения.
В современных играх подобные эффекты используются наоборот чаще, но более точечно. Это стало настолько привычным, что теперь симуляцию тканей, волос, жидкостей, эффектов частиц и многое другое игроки воспринимают как что-то само собой разумеющееся, а не работу физического движка.
Также под крутой физикой часто имеют в виду разрушаемость. В старенькой Red Faction она была ключевой механикой, поэтому под нее строили весь геймдизайн. А в современной The Finals сделать еще более масштабную разрушаемость смогли только благодаря задействованию облачных вычислений. Если же у разработчиков нет ресурсов на собственный дата-центр, а их игра не целиком посвящена разрушаемости или бросанию предметов, то вполне закономерно, что продвинутой физике будет уделено мало внимания.
Подобные решения принимаются еще на начальных этапах разработки, иначе дизайн игры просто сломается, и проект никогда не будет выпущен.
Миф №12. Использовать готовые ассеты или нейросети при разработке игр — плохо
Различные шаблоны, готовые наработки и автоматизацию в индустрии используют уже много лет. Сами по себе движки вроде все тех же Unreal Engine или Unity служат технологической базой и постепенно движутся к формату простого в использовании конструктора.
При разработке любого крупного проекта есть много рутинных задач, упростить выполнение которых означает не только ускорение разработки, но и экономию бюджета. Зачем вручную прорабатывать каждый листик на дереве, если для этого давно существует решение вроде SpeedTree, использовавшееся еще в Oblivion 2006 года?
Главная же проблема в использовании быстрых решений — будь-то готовые ассеты или генерация нейросетями — отсутствие доработки. Когда вся игра собрана на базе моделек из маркетплейса, которые даже не адаптировались под единый визуальный стиль, это хорошо заметно. Точно также хорошо заметны слишком уж пространные и не ведущие ни к чему диалоги персонажей, а также сюжеты записок, которые не выстраиваются в единую логику вымышленного мира. Сразу понятно, что сгенерированные заглушки просто «забыли» отредактировать.
