@um1x
Umid malikov
Tugun
@um1x
Umid malikov
Nanite умеет подтягивать киношные микрополигоны и сам решает, какую детализацию показать. Lumen считает глобальное освещение почти без запекания. После UE5 демо в духе «фильм внутри игры» перестали быть чистым CGI-роликом: многое из этого можно крутить в редакторе в реальном времени. Цена — железо, правильные ассеты и понимание, где виртуализация помогает, а где всё ещё нужен обычный LOD и дисциплина.
Visual scripting в Unreal — не «упрощённый C++», а отдельный язык графов. Дизайнер может собрать взаимодействие, камеру или UI, не дожидаясь программиста на каждый прототип. C++ остаётся для систем, где важны производительность, рефакторинг и чёткие границы модулей. Связка Blueprint + C++ — нормальный продакшен, а не компромисс. Если Blueprint «поплыл», это обычно сигнал вынести кусок в функцию, актор или C++, а не запретить графы вообще.
В 1998 году вышел шутер Unreal — и движок внутри него сразу задумывали как продукт, а не только как код одной игры. Поэтому Unreal Engine с самого начала продавали другим студиям. Игра была демо технологий: освещение, скрипты, пайплайн контента. Сегодня Fortnite играет ту же роль: живой полигон, на котором обкатывают то, что потом приходит в редактор всем остальным.
В Godot нет отдельной «магии префабов» поверх мира. Сцена — дерево нод. Любую сцену можно вставить в другую как ноду. Персонаж, UI, пуля, целый уровень — одна и та же идея: маленький граф, который инстансится где нужно. Если проект растёт хаотично, почти всегда помогает вопрос: какое дерево я сейчас собираю, и не стоит ли вынести кусок в отдельную сцену.
Godot распространяется под MIT. Можно выпускать коммерческие игры, не отдавая процент с выручки и не подписывая отдельный контракт с движком. Это одна из причин, почему Godot любят школы, джемы и инди-команды: порог входа — скачать редактор, а не согласовать лицензию. Платите вы не «налог движку», а временем на документацию, аддоны и то, чтобы отдать пользу обратно сообществу.
Имя движка — отсылка к «В ожидании Годо». Хуан Линьецки и Ариэль Мансур годами ждали удобный открытый движок для своей студии в Латинской Америке — и в итоге написали свой. Сначала это был внутренний инструмент. Потом его выложили под MIT, и вокруг выросло сообщество, которому не нужно спрашивать разрешения, чтобы учить, форкать и продавать игры. Поэтому «Godo» здесь — не маскот, а напоминание: ждать идеальный инструмент можно бесконечно. Иногда проще сделать свой.
Hollow Knight, Among Us, Cuphead, Genshin Impact, Pokémon GO — очень разные игры, и у многих из них в основе Unity. Движок закрывает и 2D-платформеры на маленькую команду, и live-сервисы с миллионами игроков. Разница не в «можно / нельзя», а в том, как вы собираете пайплайн, UI и контент. Поэтому в этом сообществе нормально рядом обсуждать и мобильный прототип, и сложный 3D-проект.
GameObject сам по себе почти ничего не умеет. Поведение появляется, когда на него вешают компоненты: Transform, Rigidbody, скрипт на C#. Так задумывали движок, чтобы художник или дизайнер мог собрать сущность из готовых кусков, не лезя в C++. Если объект «не работает», в Unity почти всегда полезно спросить: какого компонента не хватает — а не «где спрятана магия движка».
Сегодня Unity ассоциируется с «собрал один раз — запустил везде». Но Unity 1.0 в 2005 году был редактором только для macOS. Windows-версия появилась позже, когда стало ясно: инди-командам нужен один движок на разные рабочие машины, а не дорогой AAA-инструментарий. Именно из этой идеи вырос принцип, из-за которого Unity до сих пор выбирают для мобильных, ПК и консольных сборок из одного проекта.

Делаем Tiny Trouble — кооп на 2–4 игрока. Вы маленькие роботы: портите важный ужин и стараетесь не попасться повару. Сайт: [Tiny Trouble](https://tiny-trouble-web.vercel.app/) Как вам концепт и визуал?