К сожалению, геймдев сегодня — далеко не самое популярное направление в 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 года?
Главная же проблема в использовании быстрых решений — будь-то готовые ассеты или генерация нейросетями — отсутствие доработки. Когда вся игра собрана на базе моделек из маркетплейса, которые даже не адаптировались под единый визуальный стиль, это хорошо заметно. Точно также хорошо заметны слишком уж пространные и не ведущие ни к чему диалоги персонажей, а также сюжеты записок, которые не выстраиваются в единую логику вымышленного мира. Сразу понятно, что сгенерированные заглушки просто «забыли» отредактировать.
Комментарии (34)
Jijiki
25.12.2025 18:07собственный движок это к сожалению единственный доступный пока-что фундамент(да долго, да больно, да по началу мы себя заставляем, если не скипнуть то пласт просто поглащается и подкрепляется) - целый пласт знаний, который можно изучить, и к сожалению аналог по типу УЕ5 даже пока в этой парадигме, который по тому же мифу и пародоксу приведёт туда же,
тоесть движок УЕ5 ведёт такого разраба вниз(человеку придётся погружаться в эти концепции), а собственный движок выталкивает вверх(на основе итерации и тестов человек приходит к какойто парадигме и уже на УЕ5 приходит понимая чо там), и невозможно этот процесс перепрыгнуть, рано или поздно, там нужно будет знать ситуацию
это как инь и янь они идут рука об руку
tator
25.12.2025 18:07Есть такoй прекрасный движок как Godot, вам нужно понимание, удачи. Читайте исходники движка написанные на плюсах и радуйтесь тому какой вы умный и все понимающий.
Jijiki
25.12.2025 18:07так а концепция обучения фундаментальному, на готовом никак не противоречит обучению на готовом, просто если мы говорим о программировании, а не продукте где за интерфейсом ничего не надо знать, и для дизайна тоже, мы говорим как раз о тех концепциях, которые выступают как ассемблер, понял ассемблер или понял эмулятор, пол дела сделано, дальше уже как говориться, хотите вы это дальше развивать или нет, вы либо переходите на готовое и уже фундаменталка даёт вам понимание и вы уже вот прям накодили или настроили движок, или вы просто уже что-то сделали, и вообще там на конце всё будет одно и тоже, разве что поставим действительно во главу угла сверх заточенный УЕ5 или на тот момент УЕ10
тоесть вы по существу же зададитесь вопросом зачем писать движок прям, или зачем писать рейтрейсер и вот как бы тут пишем не пишем дело такое. можем и не писать кстати, в любом случае же как-то же приходит понимание как решать коллизии, это же может быть лично вашим видением понимаете? тоесть есть какой-то значит начальный вопрос, раскрывая, который приходит понимание, ага, значит тут я сделаю вот так, потомучто вот так не хочу например, и вот тут знания вам помогут
tator
25.12.2025 18:07Я пытался реализовать поиск пути для своего ИИ агента в 3д пространстве, потратил около 60 часов чистого времени на это и добился только невнятной работы алгоритма Дейкстры. Десятки часов изучения теории графов, множество попыток создать сетку и алгоритм поиска оптимального пути, потом я понял что занимаюсь каким-то маразмом и просто стал использовать готовое решение. Я не понимаю как под капотом функция из меша строит сетку передвижения, но мне это и не нужно чтобы работать с этой сеткой и добиваться нужных мне результатов. Ещё до этого я занимался таким кретинизмом как написание 3д движка на Java с помощью библиотеки которая даёт доступ к openGl, я дошёл до создания простых геометрических фигур и их трансформации в пространстве, количество затраченного времени просто невероятное, выхлоп, около нулевой. Не вижу перспектив такого развития, когда изобретут волшебную таблетку бессмертия, я с радостью сяду и буду учить с 0 абсолютно все с чем работаю, пока что, увы, пользуюсь готовым без понимания как оно работает.
Jijiki
25.12.2025 18:07на сколько помню от карты высот получаем граф, можно же сгенерировать высоты, потом сгладить, получаем ланшафт, если нравится сохраняем в виде картинки, дорисовываем лаконичные градиенты логические, загружаем проверяем
Sollner
25.12.2025 18:07Как правильно когда-то кто-то (вот не помню кто) сказал "ты сюда игры делать пришёл? Ну так делай игру. А если тебе именно ковыряние в низах интересно - ковыряйся. Но для себя определись и себе честно ответь. От этого и будет зависеть твоё дальнейшее развитие"
Sadler
25.12.2025 18:07Спойлерну: в UE то же самое. Без репы с сырцами движка фиг что значимое разработаешь, документация помогает куда меньше, чем оригинальный код. Шаг влево - расстрел. Написание кастомных нод, в т.ч. асинхронных, кастомные типы ассетов, кастомные нодовые интерфейсы, работа со slate: всё это задолбаешься пилить по докам.
И это ещё когда оно не падает (тьфу-тьфу, в последний год это редкое явление). А если падает, то без чтения кода вокруг assert вообще будешь только танцевать с бубном, пытаясь понять, что там пошло не так.
VitalyZaborov
25.12.2025 18:07Это всё равно что утверждать, что программирование на Python тянет вас вниз, а на C++ - вверх. Или, если угодно, программирование на C++ - вниз, а на ассемблере - вверх.
Это просто технологии разных уровней. Движок даёт инструментарий, но и поверх него нужно написать много логики.
Jijiki
25.12.2025 18:07может оно и так, технологии разных уровней, но как только вы программист, а не дизайнер, вам придётся погрузится во что-то, что скачать, как что-либо сделать исходя из того что вам нужно или вы хотите. инструмент не инструмент, но знания вам будут нужны, если это всё вокруг того, что в команде есть всегда человек который не программирует, то да абсолютно с вами согласен менеджер не кодер, даём инструменты и ничего не обьясняем наверно, или нет?
не зная никакого уровня как вы определяете, что вы хотите? самое интересное в вашей парадигме кто это делает то что вы определяете?
VitalyZaborov
25.12.2025 18:07Какие-то мифы поверх мифов, не имеющие с реальностью ничего общего. Вы сами-то работали в геймдеве хоть когда-нибудь?
Johnny_Depp
25.12.2025 18:07Так это ИИ писало)
ggsel Автор
25.12.2025 18:07Как вы это поняли, интересно? По длинным тире?) У ИИ нет информации из первых рук. Просто попробуйте найти в Сети материалы (даже на английском языке), которые якобы могли послужить референсом. Вы просто не найдете. Нейронкой в принципе невозможно сделать нормальный материал про внутрянку или развенчание мифов.
SHAD0W137
25.12.2025 18:07"Нейронкой в принципе невозможно сделать нормальный материал про внутрянку или развенчание мифов"
У вас и не получилось)
Почти всё, что написано в этой статье - это никакая не "информация из первых рук". Это поверхностный обзор не разбирающегося в теме человека. Ну, то есть примерно то, что выдаёт AI поиск от Google.
Касаемо же материалов "даже на английском языке"... Я более, чем уверен, что Gemini 3 Pro выдаст куда более корректную с точки зрения правдивости статью, если ему просто запросить "Напиши статью про 12 мифов в игровой индустрии".ggsel Автор
25.12.2025 18:07Ну так предоставьте ссылки на материалы, где именно с ТОЙ ЖЕ стороны и ТАКИМИ ЖЕ доводами развенчиваются ЭТИ ЖЕ мифы. Хотя бы из нескольких источников соберите, откуда якобы нейронка могла нахватать. Уверенным быть хорошо. Но вы серьезное обвинение предъявили.
Kingas
25.12.2025 18:07А я вот наоборот, давно хотел влиться в геймдев, но без понижения в опыте из другого домена, и тут тяжело конечно. Вот не нашлось студии, где можно было так шифтнуться в геймдев без опыта и не за бесплатно.
А по делу. Как игрок с опытом в своё время скажу сразу, любой апскейлинг сильно бьёт по чёткости изображения. Например, я лично не могу его терпеть и думаю норм игроки скажут тоже самое.
Высокополигональные модели это действительно высокая нагрузка, раньше помню использовались либо заготовленные LOD, либо да алгоритмы отсечения до рендеринга на видюхе. Но по факту не рисуется миллион полигонов, даже средняя видюха сдохнет рисуя миллион. Это я проверял, в лоб так не рисуется и это не совсем корректно так писать. Вот про автоматический LOD не слышал.
И не по теме, ещё блюры уже сколько в геймдеве применяются, но это так же фича, которая с большой вероятностью никому не нужна и люди, если давно в играх, то просто это отключают.
ggsel Автор
25.12.2025 18:07Для апскейлинга есть регулируемая резкость обычно в настройках. Детализация изображения в режиме качества давно никак не падает с DLSS в режиме качества. И это не простой апскейлинг, а на основе глубокого обучения, из которого он и восстанавливает детали. Кроме того, реконструкция лучей, встроенная в DLSS, избавляет от шумов в тенях и отражениях.
Высокополигональные модели сильно бьют по производительности только в движках без Mesh Shading или Nanite, или аналогов. Автоматические лоды существуют очень давно. Просто раньше они работали грубо.
SHAD0W137
25.12.2025 18:07Ух ты! С первого пункта я ожидал, что будет какая-то дрисня. Но чтоб настолько!
С чего бы начать-то... А давайте тоже по пунктам. А то писать много. Заранее извиняюсь за несерьёзный и не очень литературный стиль изложения.
1. "На самом деле роль программистов в разработке игр сводится к написанию кода по указке дизайнеров — они лишь исполнители, которые ничего не определяют в концепции проекта." Не, вы серьёзно даже элементарных исследований не провели? Игры буквально диктовались программистами. Без программиста дизайнер будет пердеть в стенку. А с плохим программистом выйдет кривая поделка, а не игра. Когда игры не были крупным бизнесом (ну то есть до нулевых), все они создавались энтузиастами-программистами. "Лишь исполнители" вам сделают кривое уродство на анриале на блупринтах. Программирование - само по себе искусство, но в вопросах геймдева это искусство возведено в степень безумия.
2. Геймдизайнер - это глава разработки игры. В старой концепции разработки и в небольших студиях. Геймдиректор нужен тогда, когда над игрой работают 100+ человек и более одного геймдизайнера. Новомодное веяние, в процентном соотношении главой разработки чаще выступают всё-таки геймдизайнеры. Геймдиректор же, как правило, кто-то вроде "главного геймдизайнера"
3. Собственный движок лучше универсального. Это не сарказм, это ФАКТ. Он дороже, но он всегда ЛУЧШЕ. Универсальных движков не существует. Тот же Unreal заточен под игры с открытым миром от первого-третьего лица. Только своими руками можно сделать ЛУЧШИЙ движок под конкретную игру. Ибо в различиях между жанрами и даже просто кор-концепциями игры требуется на уровне ядра использовать конкретные технологии. Можно для этих целей использовать и Unreal и ему подобные, но программистам всё равно придётся досконально изучать код движка, чтобы перекомпилировать его под свои цели. Стоит ли говорить, что технологический стек Unreal не то что морально устаревший, он технически очень далёк от идеала.
4. Не "большинство багов в игре - следствие плохого кода". ВСЕ баги в игре - следствие плохого кода. За исключением разве что визуальных багов (когда рука сквозь голову проходит и т.п.) Любой движок, любая технология в нём создаются программистами. Пролетел сквозь карту? Ошибка программиста. Переполнение стека? Ошибка программиста. Сильно сдавленные физические объекты разлетелись во все стороны с огромной силой? Ошибка программиста (или осознанное допущение программиста). Факт в том, что избавиться от багов в принципе нельзя, но любой баг - это ошибка программиста. Даже если незначительная.
5. Мультяшная графика и примитивная графика это схожие понятия, но не взаимозаменяемые. Мультяшная графика есть в условных Overwatch или Paladins. Примитивная графика - это Minecraft или тот же Fortnite. В первом нет детализации моделей, а текстуры прорисованы в безумно низком разрешении, а во втором текстур в принципе нет (и материалов как будто бы тоже не густо, все поверхности одинаково пластиковые).
И да, это не миф, а распространённое мнение.
6. Удивительно, но красота графики зависит как раз таки от технологичности. Художник в своей экспрессивности не ограничен, а вот в технологиях - очень даже. Отсюда хорошую графику можно получить только при грамотном использовании различных карт нормалей, AO, текстур, глубоких настроек рендеринга и оптимизации. Если бы визуал игры зависел только от художников, а не от технологического стека, то современные игры не различались в графике между студиями.
7. Это факт. Во всех играх, где основой освещения сделали рейтрейсинг, просто подняли системные требования. Графически в сравнении с классическими методами запекания они не стали, а реалистичности в существующем рейтрейсинге не больше, чем в старых технологиях, ибо "реализма" можно добиться только path-трейсингом и только со множественной выборкой. В реальном времени такое пока что остаётся неподъёмной задачей.
8. Это факт и ошибка терминологии. DLSS - это даже не сглаживание. Это рендер изображения в более низком качестве и его апскелинг со всеми вытекающими артефактами. Технология именно сглаживания от тех же Nvidia называется DLAA и эта штука прилично нагружает систему. А самым распространённым сглаживанием в вопросах качества и скорости является SMAA.
9. Что ж, первый полноценный миф.
10. Ещё один неплохой полумиф. С одной стороны да - нагрузка во многом зависит уже не от самих моделей, а от пайплайна, в котором они участвуют. Но факт в том, что вся нагрузка как раз таки рождается из детализации моделей. Видеокарта по определению обрабатывает треугольники. Чем больше треугольников - тем больше нагрузки на всех этапах рендеринга. Nanite это лишь костыль, который может помочь "сгладить" бездарность тех, кто добавлял ассеты с неадекватным количеством полигонов.
11. Верный миф. Физика стала лучше, но только у тех, кто продолжает её внедрять, а не забивает болт.
12. Это не миф. Это во-первых мнение, а во-вторых, очень даже ФАКТ. Нейросети не умеют делать модели с правильной сеткой и оптимизированной топологией. А ещё у нейросетей нет художественного видения в той или иной мере.
Использование же готовых ассетов никогда не принижалось. Инди-разработчики активно заявляют об их использовании, а крупные студии просто реюзают одни и те же ассеты из своих старых проектов.
Итого... действительно мифами из 12 можно назвать от силы... ТРИ. 3/12. 25% Это плохой результат, идите учить матчасть.
Короче, очень советую "авторам", которые пишут подобные статьи (подозреваю, что через нейронки), ознакомиться хотя бы с базовыми вещами в теме, по которой собираются вещать. В особенности когда пытаются вещать про технологическую сторону. По ней книжек и материалов не так уж много, а существующие очень массивные и углублённые. Очевидно, случайный сммщик с поверхностными знаниями в этой теме так глубоко копаться не станет. Но и позориться не надо, распространяя дезинформацию.
Ну и, наконец, вот эту необразованную дрисню, не имеющую с реальностью ничего общего, вы лучше лейте на ТВ или в пабликах в ВК. Хабр - не место для НАСТОЛЬКО ущербной писанины. Это даже не "статья", это "вброс".ggsel Автор
25.12.2025 18:07А вот и хороший пример далеких от реальности представлений непрофильного айтишника. У которого, в отличие от профессионального игрового журналиста с опытом в геймдеве и профилем по геймдеву, нет ни контактов из крупняка, ни опыта с актуальными технологиями. Ни желания никогда не было долго разбираться в теме, судя по тому, что вы написали. Первые пункты вообще устаревшие. А дальше местами сами себе противоречите. Это явный обывательский взгляд, а никакое не разоблачение.
VitalyZaborov
25.12.2025 18:07Это отличный пример комментария, который полезнее и информативнее самой статьи.
Пожалуйста, не переходите на личности, здесь это не принято. Человек не пожалел времени - отписался по каждому пункту. Вы же "написали" статью по теме, в которой не разбираетесь, чтобы порекламировать маркетплейс. Так какой смысл воевать в коммнтах? Пишите ещё, может, следующая лучше получится.
ggsel Автор
25.12.2025 18:07А статью почитать человек пожалел времени явно — видно же, что с подзаголовками спорит, а не статьей. Как и получше изучить вопрос, прежде чем писать по нему разбор. Человек только снова приводит заблуждения, к которым приходят люди со слишком поверхностным взглядом или додумываниями на основе личного опыта из совсем другого профиля разработки. Ну или если никогда не взаимодействовали с современными технологиями на глубоком уровне.
VitalyZaborov
25.12.2025 18:07Эм... Но если у вас заголовок и то, что под ним - так отличаются по смыслу, что можно спорить отдельно с каждым - может это тоже проблема статьи?
Ну да ладно, давайте разберём какой-нибудь кейс. Вот Вы пишете:
На самом деле роль программистов в разработке игр сводится к написанию кода по указке дизайнеров — они лишь исполнители, которые ничего не определяют в концепции проекта.
В единичных случаях, когда ресурсы не считают, это может быть так. Но даже в крупных студиях дизайнеру стоит учитывать сложности технической реализации его замыслов, чтобы не сорвать сроки. Ему много что нужно учитывать, не только мнение программистов. Тут многое зависит от компании, но и в больших командах зачастую стараются учитывать мнение программистов, QA, художников и прочих, не только ГД. Да, в команде на 1000 человек физически невозможно реализовать хотелки всех, но если большинству коллег ваша фича не нравится - она и игрокам вряд ли зайдёт. В небольших командах влияние одного (непрофильного) специалиста на геймдизайн, разумеется выше. И потому что общаются они плотнее, и потому что учитывать косты при разработке приходится жёстче.
Сам по себе вопрос "кто главный специалист" - не вполне корректен. Главный в бизнесе - тот, кто зарплату платит: инвестор, издатель, CEO. Ну а что программисты по ТЗ работают - так это работа такая, ничего удивительного. ГД и сами из каких-то целей и задач исходят когда прописывают дизайн.
Если же рассужать на уровне "без кого не сделать игру - без программиста, художника или геймдизайнера?" То без художника на готовых ассетах сделать её точно можно. Без программиста на UE с блупринтами - ну да, тоже можно. Но сложную логику так писать тяжело, не всё задуманное получится сделать. И даже так автор игры всё равно превращается в программиста, просто на визуальном языке. Программист же может сделать игру один, хоть и будет заниматься задачами геймдизайнера.
В онлайн-проектах роль программистов более значительна, так как всем нужен хороший сетевой код.
А хороший клиенский код, значит, никому не нужен? Если рассматривать именно сетевой код (то есть синхронизацию клиента и сервера, отдельно от собственной логики клиента и сервера), то он зачастую реализован в движке. То есть на онлайновом проекте может даже не быть программиста, который этим занимается. Могут быть отдельные команды, которые пишут логику клиента (обработка ввода, UI) и сервера (расчёты урона, попаданий, работа с БД), но именно пересылка данных - не их специализация.
Однако знания по разработке сетевых игр практически невозможно получить из открытых источников (не говоря уже о классическом образовании).
У всех популярных движков есть документация, в которой написано всё, что нужно для разработки сетевой игры на этом движке. У UE и Unity есть даже официальные примеры (например, Lyra Starter Game). Кроме этого хватает и роликов, и курсов. Эта информация очень даже открыта.
По этим причинам большинство кодеров не только не подходят для геймдева, но и сами не хотят туда идти.
Да нет, вполне подходят. Я знаю много историй когда люди без проблем приходили в геймдев из совершенно других отраслей. Причём не в мелкие стартапы, а сразу в ААА.
Поэтому я скорее соглашусь с комментарием SHAD0W137, чем с текстом статьи.
ggsel Автор
25.12.2025 18:07Вы пишете про первые годы геймдева. А статья про сегодня.
Геймдизайнер бывает главой разработки в небольших проектах, но по факту это совмещение с работой творческого руководителя. А второе больше, чем первое.
Тоже какое-то устаревшее представление, явно не из первых рук.
Перечитайте еще раз что написано было в этом пункте. Вы судя по всему прочли лишь заголовок. Баги случаются и просто от нестандартного взаимодействия систем. Что невозможно предусмотреть.
Снова устаревшее представление, что в Fortnite примитивная графика. Да и статью явно читали невнимательно.
«Если бы визуал игры зависел только от художников, а не от технологического стека, то современные игры не различались в графике между студиями». Ну то есть художники у всех одинаковые? Вы программист, который принижает заслуги художников?
Вы хоть одно прямое сравнение смотрели? Ну и никто не будет в сегодняшних реалиях возвращаться к ручной проработке. И даже для железа давно не проблема, потому что много RT-ядер в любых актуальных моделях видеокарт.
DLSS включает в себя и продвинутое сглаживание. А DLAA это просто режим работы в 100% разрешения (т. е. без апскейлинга, но всё равно с обработкой нейросетями). Ну и не забываем про реконструкцию лучей, которая вычищает картинку от артефактов.
Здесь разобрались.
У человека явно не было желания подольше поразбираться в современных подходах к проработке ЛОДов.
Здесь разобрались.
В целом, согласен.
MaxKitsch
25.12.2025 18:07Миф №3. Собственный движок лучше универсального
Скорее современным мифом «универсальный движок подойдёт для любых проектов». Выбор между своим движком и универсальным зависит от того, насколько уникальной является игровая механика.
Например, Noita использует собственный движок "Falling Everything" и он позволяет создать совершенно уникальный игровой опыт.
No Man's Sky использует собственный движок и это позволяет генерировать огромную бесшовную вселенную.
С другой стороны, для более типовых проектов, разумеется, хватит готового решения.
Johnny_Depp
Если что геймдев это не только сырые подделки по оверпрайсу на анриле и юнити.
Кстати, судя по первому предложению о том что программисты им не нужны, становится ясно почему многие современные продукты такие сырые.
Ну и статья очевидно ии-шная.
ggsel Автор
Дальше первого предложения написано, что всё-таки нужны)
Johnny_Depp
Тогда вы противоречите сами себе и становится только хуже
ggsel Автор
Эм... Статья про мифы)
Johnny_Depp
Если сказать одно, а потом противоположное , это называется противоречие
ggsel Автор
Так и не было утверждения, что программисты НЕ НУЖНЫ
tbogachenko
Но никто не идёт) там же написано
QTPie
Во-первых, в статье нет слов, что программисты не нужны. Во-вторых, а кому им то? Ты думаешь, Ggsell это разработчик игр? Это просто рекламный пост, где человек, не имеющий никакого отношения к разработке игр, вставляет баннер своего маркетплейса ниже сгенерированного текста